AZ-305：Designing Microsoft Azure Infrastructure Solutions インフラストラクチャソリューションの設計 問3
インフラストラクチャソリューションの設計／アプリケーションアーキテクチャの設計ある EC サイトでは、注文メッセージを受け取って在庫引当・決済・出荷指示を行うバックエンド処理を設計しています。同一顧客の注文は到着順に処理する必要があり、同じ注文の二重送信は取り除きたく、処理に繰り返し失敗したメッセージは後で調査できるよう別の場所に隔離する必要があります。メッセージのスループットは中程度です。メッセージング基盤として適切なものはどれですか。
当サイトのオリジナル問題（AZ-305：Designing Microsoft Azure Infrastructure Solutionsの出題範囲「インフラストラクチャソリューションの設計」に対応。実際の試験問題ではありません）
- AAzure Event Hubs のイベントハブに注文を送信し、コンシューマーグループで読み取る
- BAzure Service Bus のキュー（セッションと重複検出を有効化）を使用する
- CAzure Event Grid のカスタムトピックにサブスクリプションを作成して配信する
- DAzure Queue Storage のキューを使用し、可視性タイムアウトで再処理する
正解：B
解説
Azure Service Bus は企業向けのメッセージブローカーで、セッションによる順序保証（同じ SessionId のメッセージを順に1つのコンシューマーへ渡す）、重複検出、配信不能（デッドレター）キュー、トランザクションなどを備え、注文処理のようなビジネス上重要なメッセージに向いています。本問では、SessionId に顧客ID を設定すれば同一顧客の注文を到着順に処理でき、各メッセージの MessageId に注文ID を設定すれば、同じ注文の二重送信を重複検出で取り除けます。ただし重複検出は、設定した時間ウィンドウ（既定10分・最大7日）の中で MessageId を照合する仕組みであり、ウィンドウを超える業務上の厳密な一回限りの処理まで保証するものではありません。確実な一意性が要る場合は、コンシューマー側も冪等に作り業務キーで重複を判定します。Event Hubs は大量のイベントストリームを取り込む用途で、メッセージごとの完了・放棄やデッドレターの仕組みを持ちません。Event Grid はイベントを購読者へプッシュ配信する反応型の基盤です。Queue Storage は大容量で安価ですが、順序保証も重複検出もありません。
選択肢ごとの解説
- A誤り。Event Hubs はパーティション内の順序は保てますが、メッセージ単位の重複検出やデッドレターは備えていません。大量のテレメトリ取り込み向けで、注文のような個別メッセージの処理には適しません。
- B正しい。SessionId に顧客IDを使えば顧客ごとの順序を保証し、MessageId に注文IDを設定して重複検出で二重送信を除去し、デッドレターキューで失敗メッセージを隔離できます。要件がすべて標準機能で満たせます（重複検出は時間ウィンドウ内の照合のため、ウィンドウを超える厳密な一回性にはコンシューマーの冪等化を併用します）。
- C誤り。Event Grid は状態変化などのイベントを購読者へ通知する仕組みで、配信は再試行後に破棄またはデッドレター化されるため、順序保証や重複検出は提供しません。
- D誤り。Queue Storage は FIFO を保証せず、重複検出の機能もありません。高い順序性と重複排除を求める業務メッセージの要件を満たせません。