疎結合の非同期処理

このパターンは？

重い処理や急増するリクエストを、直接同期呼び出しせずにいったん「間に箱を挟んで」捌く構成。Azure でのマイクロサービス設計でも頻出の「疎結合」パターンです。

• スパイクを**バッファ（負荷平準化）**して取りこぼさない
• 失敗を**リトライ／デッドレター（DLQ）**で安全に退避
• 送信側と処理側を独立にスケール

構成

[フロント/Producer]
   │ イベント発生
   ▼
Event Grid (同報) ──► 複数の Service Bus キュー ──► ワーカー(Functions / Container Apps) ──► Cosmos DB / Blob
                          │
                          └─ 失敗 ─► デッドレター(退避)

別解1: Service Bus トピック/サブスクリプション (SQL フィルターで宛先別ルーティング)
別解2: Event Hubs (高スループットなストリーム取り込み・複数コンシューマーグループ)

コンポーネントの役割と使い分け

• Service Bus / Queue Storage: バッファ。ワーカーがポーリングし、PeekLock（ロック）＋デッドレターで確実に処理。順序や重複検出が要るなら Service Bus
• Event Grid: 1イベントを複数へプッシュで同報（ファンアウト）。Azure 内部イベント（Blob 作成など）への反応や SaaS 連携も。Event Grid → 複数の Service Bus キューが鉄板
• Event Hubs: ログ・テレメトリを毎秒数百万件規模で取り込むストリーム。コンシューマーグループで複数処理系が同じストリームを並行読み取り
• ワーカー: Functions（短時間・イベント駆動）/ Container Apps（長時間・常駐・KEDA でキュー長スケール）

設計の勘所

• 処理は冪等に（Service Bus / Event Grid とも既定は**最低1回（at-least-once）**配信＝重複し得る）
• 厳密な順序が要るなら Service Bus のセッション、送信側の再送由来の重複には重複検出
• ワーカーは**キューの長さ（ActiveMessages）**で自動スケール（Container Apps の KEDA、Functions の Scale Controller）
• 大きいペイロードは Blob Storage に置き、メッセージには参照を入れる（Claim-Check パターン）
• 「業務処理の確実な引き渡し」は Service Bus、「事実の通知・配布」は Event Grid、「高スループットなストリーム取り込み」は Event Hubs と要件で選ぶ

Well-Architected の観点

• 信頼性: バッファ・リトライ・デッドレターで取りこぼさない。PeekLock + Complete で処理完了まで削除しない
• パフォーマンス効率: 送信/処理を独立スケール。Event Hubs のパーティションで並列度を確保
• コスト最適化: 必要な時だけ処理。Functions 消費プランや Container Apps のゼロスケールでアイドル課金を止める

よくある落とし穴

選び方の早見表

メッセージング3兄弟の違い

Azure には目的の異なる3つの非同期基盤があり、混同しやすい点です。