編集

次の方法で共有


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

Azure Event Grid
Azure Blob Storage

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 の柱で説明されている目標と原則に対処するために、ワークロードの設計でどのようにクレーム・チェックパターンを使用できるかを評価する必要があります。 次に例を示します。

重要な要素 このパターンが柱の目標をサポートする方法
信頼性設計の決定は、ワークロードが誤動作に対して回復性を持ち、障害後に完全に復旧するのに役立ちます。 メッセージング システムでは、専用データ ストアに多くの場合存在する信頼性と障害復旧は提供されません。 メッセージからデータを分離すると、ペイロードの信頼性が向上する可能性があります。 この分離により、障害発生後にペイロードを回復できるデータ冗長性が容易になります。

- RE: 03 障害モード分析
- RE:09 災害復旧
セキュリティ設計の決定により、ワークロードのデータとシステムの機密性整合性、および可用性が確保されます。 Claim-Check パターンでは、メッセージから機密データを抽出し、セキュリティで保護されたデータ ストアに格納できます。 この設定により、より厳密なアクセス制御を実装して、機密データを使用するサービスのみがアクセスできるようにします。 同時に、キューの監視に使用されるサービスなど、関連のないサービスからこのデータが非表示になります。

- SE:03 データ分類
- SE:04 セグメンテーション
コスト最適化は、ワークロードの投資収益率の維持と改善に重点を置いています。 メッセージングシステムはメッセージ サイズに制限を課すことが多く、サイズ制限の増加がプレミアム機能であることが多いです。 メッセージ本文のサイズを小さくすると、より安価なメッセージングソリューションを使用できる場合があります。

- CO:07 コンポーネントコスト
- CO:09 フローコスト
パフォーマンスの効率化 は、スケーリング、データ、コード回を最適化することによって、ワークロードが 効率的に需要を満たすのに役立ちます。 Claim-Check パターンでは、大規模なメッセージをより効果的に管理することで、アプリケーションとメッセージング システムの送受信の効率が向上します。 これにより、メッセージング システムに送信されるメッセージのサイズが縮小され、必要な場合にのみ、受信アプリケーションが大きなメッセージにアクセスできるようになります。

- PE:05 スケーリングとパーティショニング
- PE: 12 パフォーマンスの継続的な最適化

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

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 で表示します。

サンプル コード メッセージング システムのシナリオ トークン ジェネレーター アプリケーションの受信 データ ストア
コード例 1 Azure Queue Storage Azure Event Grid 機能 Azure Blob Storage
コード例 2 Azure Event Hubs (Standard API) Azure Event Grid 実行可能なコマンドライン クライアント Azure Blob Storage
コード例 3 Azure Service Bus Azure Event Grid 機能 Azure Blob Storage
コード例 4 Azure Event Hubs (Kafka API) 実行可能なコマンドライン クライアント 機能 Azure Blob Storage

次のステップ