クレーム チェック パターン

Claim-Check パターンを使用すると、ワークロードはメッセージング システムにペイロードを格納せずにペイロードを転送できます。 このパターンは、ペイロードを外部データ ストアに格納し、「Claim Check」 を使用してペイロードを取得します。 Claim Check は、一意で不明瞭なトークンまたはキーです。 ペイロードを取得するには、アプリケーションが Claim-Check トークンを外部データ ストアに提示する必要があります。

コンテキストと問題

従来のメッセージング システムは、大量の小さなメッセージを管理するように最適化されており、多くの場合、処理できるメッセージ サイズに制限があります。 大きなメッセージは、これらの制限を超えるリスクがあるだけでなく、メッセージング システムがシステムを格納するときにシステム全体のパフォーマンスを低下させる可能性もあります。

解決策

Claim-Check パターンを使用して、メッセージ システムに大きなメッセージを送信しないでください。 代わりに、ペイロードを外部データ ストアに送信し、そのペイロードの Claim-Check トークンを生成します。 メッセージング システムは、Claim-Check トークンでメッセージを受信アプリケーションに送信し、これらのアプリケーションがデータ ストアからペイロードを取得できるようにします。 メッセージング システムでは、ペイロードが表示または格納されることはありません。

1. Payload
2. ペイロードをデータ ストアに保存します。
3. Claim-Check トークンを生成し、Claim-Check トークンを使用してメッセージを送信します。
4. メッセージを受信し、Claim-Check トークンを読み取ります。
5. ペイロードを取得します。
6. ペイロードを処理します。

Claim-Check パターンに関する問題と考慮事項

Claim-Check パターンを実装する場合は、次の推奨事項を考慮してください。

• 使用されたメッセージを削除します。 メッセージをアーカイブする必要がない場合は、受信アプリケーションがメッセージとペイロードを使用した後で、メッセージとペイロードを削除します。 同期または非同期の削除戦略を使用します。

  • 同期削除: 従量課金アプリケーションは、従量課金直後にメッセージとペイロードを削除します。 削除はメッセージ処理ワークフローに関連付け、メッセージング ワークフローのコンピューティング容量を使用します。

  • 非同期削除: メッセージ処理ワークフロー外のプロセスは、メッセージとペイロードを削除します。 削除プロセスをメッセージ処理ワークフローから切り離し、メッセージングワークフロー コンピューティングの使用を最小限に抑えます。

• パターンを条件付きで実装します。 メッセージ サイズがメッセージング システムの制限を超えた場合、Claim-Check パターンを適用するロジックを送信側アプリケーションに組み込みます。 小さいメッセージの場合は、パターンをバイパスし、小さいメッセージをメッセージング システムに送信します。 この条件付きアプローチにより、待機時間が短縮され、リソースの使用率が最適化され、スループットが向上します。

Claim-Check パターンを使用する場合

次のシナリオは、Claim-Check パターンの主なユース ケースです。

• メッセージング システムの制限事項: メッセージ サイズがメッセージング システムの制限を超える場合は、Claim-Check パターンを使用します。 ペイロードを外部ストレージにオフロードします。 Claim-Check トークンを持つメッセージのみをメッセージング システムに送信します。

• メッセージング システムのパフォーマンス: 大きなメッセージがメッセージング システムに負担をかけ、システムのパフォーマンスが低下している場合は、Claim-Check パターンを使用します。

次のシナリオは、Claim-Check パターンの二次的なユース ケースです。

• 機密データ保護: メッセージング システムに表示したくない機密データがペイロードに含まれている場合は、Claim-Check パターンを使用します。 ペイロード内の機密情報のすべてまたは一部にパターンを適用します。 メッセージング システムを介して直接送信することなく、機密データをセキュリティで保護します。

• 複雑なルート指定シナリオ: 複数のコンポーネントをトラバースするメッセージは、シリアル化、逆シリアル化、暗号化、および復号化のタスクが原因でパフォーマンスのボトルネックを引き起こす場合があります。 Claim-Check パターンを使用して、中間コンポーネントによる直接メッセージ処理を防ぎます。

Claim-Check パターンを使用したワークロード設計

設計者は、ow the Claim-Check pattern can be used in their workloads's design to address the goals and principles covered in the Azure Well-Architected Framework の柱で説明されている目標と原則に対処するために、ワークロードの設計でどのようにクレーム・チェックパターンを使用できるかを評価する必要があります。 次に例を示します。

設計決定と同様に、このパターンで導入される可能性のある他の柱の目標とのトレードオフを考慮してください。

Claim-Check パターンの例

次の例は、Azure が Claim-Check パターンの実装を容易にする方法を示しています。

• Azure メッセージング システム: この例では、Azure Queue Storage、Azure Event Hubs (Standard API)、Azure Service Bus、Azure Event Hubs (Kafka API) の 4 つの異なる Azure メッセージング システム シナリオについて説明します。

• Claim-Check トークンの自動生成と手動生成: これらの例では、Claim-Check トークンを生成する 2 つの方法も示します。 コード例 1 から 3 では、送信アプリケーションがペイロードを Azure Blob Storage に転送するときに、Azure Event Grid がトークンを自動生成します。 コード例 4 は、実行可能なコマンドライン クライアントを使用した手動トークン生成プロセスを示しています。

ニーズに合った例を選択し、提供されているリンクに従ってコードを GitHub で表示します。

次のステップ

• エンタープライズ統合パターンのサイトに、このパターンの説明があります。
• 別の例については、「Claim-Check パターンを使用する大きな Service Bus メッセージの処理」(ブログの投稿) を参照してください。
• 大きいメッセージを処理するための別のパターンとして、分割と集約があります。
• NServiceBus のようなライブラリでは、"データ バス" 機能を使用して、このパターンをすぐにサポートできます。

関連リソース

• 非同期要求-応答パターン
• 競合コンシューマー パターン
• シーケンシャルなコンボイ パターン