疎結合メッセージングのための Azure Service Bus

密結合のアーキテクチャでは、サービス同士が同期的に呼び出し合います。そのため、下流のサービスが遅延したり停止したりすると、呼び出し元も処理がブロックされたり失敗したりします。メッセージングキューは、プロデューサーとコンシューマーの間に非同期のバッファーを設けるため、下流サービスの遅延による障害が上流へ連鎖するのを防げます。Azure Service Bus は Microsoft のエンタープライズ向けメッセージングサービスであり、配信保証、順序制御、デッドレター機能を備えたキュー（ポイントツーポイント）とトピック（パブリッシュ/サブスクライブ）を提供します。

Service Bus の名前空間は、すべてのメッセージングエンティティ（キューとトピック）を格納する最上位のコンテナーであり、FQDN エンドポイント（例: myns.servicebus.windows.net）を提供します。名前空間には 3 つのレベルがあります。Basic（キューのみ、トピックなし、メッセージサイズは最大 256 KB）、Standard（キューとトピック、最大 256 KB）、Premium（キューとトピック、最大 100 MB のメッセージ、専用キャパシティ、VNet 統合、geo-disaster recovery）です。SLA に基づくパフォーマンスが必要な本番ワークロードでは、Premium が必要です。

Service Bus キューはメッセージを FIFO 順で格納し、各メッセージを1 つのコンシューマーだけに配信します。コンシューマーはピークロックの仕組みを使用してメッセージを受信します。処理中のメッセージは一時的に他のコンシューマーから見えなくなります。コンシューマーが正常に処理を完了した場合は、CompleteMessage()を呼び出してキューから削除します。処理に失敗した場合は、AbandonMessage()を呼び出すことで、メッセージが再び表示され、別の試行が可能になります。設定可能な配信試行回数を超えると、処理できないメッセージはデッドレターキュー（DLQ）に移動されます。

トピックはパブリッシュ/サブスクライブパターンを実装します。プロデューサーがトピックにメッセージを送信すると、そのトピック上の任意の数のサブスクリプションが、それぞれメッセージのコピーを受信します。サブスクリプションにはフィルター（SQL または相関式）を設定し、メッセージの一部だけを受信できます。たとえば、Priority プロパティが High と等しいメッセージだけを受信する HighPriority サブスクリプションを作成できます。これにより、1 つのトピックから多数の下流サービスへメッセージをファンアウトし、それぞれが異なるイベントのサブセットを処理できます。

Azure Service Bus SDK は、送受信に使用する ServiceBusClient を提供します。送信するには、ServiceBusSender を作成して SendMessageAsync() を呼び出します。受信するには、ServiceBusReceiver を作成して ReceiveMessageAsync()（プル型）を呼び出すか、イベントハンドラーを備えた ServiceBusProcessor を使用して、プッシュ型で継続的に処理します。Service Bus SDK で DefaultAzureCredential を使用すると、接続文字列が不要になり、パスワードレスのパターンを維持できます。

デッドレターキュー（DLQ）は、配信できないメッセージを自動的に受け取るサブキューです。メッセージは、最大配信回数を超えた場合、期限切れになった場合（TTL が経過した場合）、またはトピックのサブスクリプションフィルターの評価に失敗した場合に、デッドレター化されます。DLQ の監視は不可欠です。DLQ が増え続けている場合は、処理にシステム的な障害が発生していることを示します。DLQ のメッセージには元の内容に加えて、根本原因の診断に役立つデッドレターの理由と説明のプロパティが Service Bus によって追加されます。

セッションを使用すると、同じ論理グループに属するメッセージの厳密な順序を維持できます。各メッセージには SessionId（例: 顧客 ID や注文 ID）が付与され、セッション対応のコンシューマーは、特定のセッションに属するすべてのメッセージを FIFO 順で排他的に受信します。セッションは、手順を順番どおりに実行する必要があるワークフローに不可欠です。たとえば、特定の注文に関するすべてのイベントを Created → PaymentReceived → Shipped → Delivered の順に処理する場合などです。セッションは、キューまたはサブスクリプションの作成時に有効にします。

これら 3 つの Azure メッセージングサービスは混同されがちです。Service Busは、順序制御、セッション、DLQ を備えた信頼性の高いトランザクション対応のエンタープライズメッセージング向けで、注文処理、金融トランザクション、ワークフローオーケストレーションに適しています。Event Gridは、リアクティブなイベントルーティング（BLOB がアップロードされた、VM が削除されたなど）向けで、複数のハンドラーへのファンアウトに対応しますが、順序制御や再生には対応しません。Event Hubsは、毎秒数百万件のイベントを扱う高スループットのイベントストリーミング向けで、再生機能を備えており、IoT テレメトリやログ取り込みに適しています。順序、スループット、耐久性の要件に基づいて選択してください。

Service Bus のGeo-Disaster Recovery（Geo-DR）は、名前空間のメタデータ（キュー、トピック、サブスクリプション、アクセス ポリシー）をセカンダリ リージョンにレプリケートします。ペアリングされたリージョンは 1 つのエイリアス ホスト名を共有します。プライマリに障害が発生した場合は、フェールオーバーを開始すると、エイリアスがセカンダリを解決先として返します。ただし、Standard レベルではメッセージデータ（処理中のメッセージ）はレプリケートされません。メッセージをレプリケートできるのは Premium レベルの Geo-DR だけです。ミッションクリティカルなメッセージングで RTO と RPO の要件を満たすには、Premium と Geo-DR を使用してください。

高スループットのシナリオでは、キューやトピックの作成時にパーティション分割を有効にします。パーティション分割されたエンティティは、内部で複数のメッセージブローカーとストレージフラグメントを使用し、スループット容量を増やします。Standard レベルでは、パーティション分割されたエンティティの合計サイズは最大 80 GB です。各メッセージは、その PartitionKey プロパティに基づいてパーティションにルーティングされます（セッションが有効な場合の既定値はセッション ID です）。パーティション分割は作成時に一度だけ決定する項目であり、既存のキューをパーティション分割することはできません。パーティション分割の複雑さを伴わずに最高レベルの保証されたスループットを得るには、Premium レベルを使用してください。

Azure Monitorで監視する主な Service Bus メトリックは次のとおりです。Active Messages（キューの深さ。増加している場合はコンシューマーの遅延を示します）、Dead-lettered Messages（処理エラー）、Server Errors と User Errors（認証やスロットリングの問題）、Incoming Requests（全体的なスループット）。メトリックアラートを設定し、デッドレターキューがしきい値を超えて増加した場合や、アクティブなメッセージが一定時間にわたって消費されていない場合に、運用チームへ通知されるようにしてください。

このレッスンで学んだ Microsoft Azure Fundamentals（AZ-900）の概念について、理解度を確認します。

このレッスンでは、Service Bus キューがピーク ロックによる配信と、失敗したメッセージを格納するデッドレターキューを備えたポイントツーポイントメッセージングを提供すること、トピックとサブスクリプションがフィルタールールによって複数のコンシューマーにメッセージをファンアウトすること、そしてセッションによって同じ論理グループに属するメッセージを順序どおりに処理できることを学びました。次は、最新のマイクロサービスをデプロイするための Azure Container Apps について学びます。