Azure Service Bus / Queue Storage

解決する課題

アクセス急増でバックエンドが詰まる → キューでバッファ（負荷平準化）
送信側と処理側を疎結合にして独立にスケールしたい
失敗したジョブを安全に退避・再試行したい（デッドレター）
1つのメッセージを複数の受信者に同報したい（トピック / サブスクリプション）

主要概念と用語

Azure には用途の異なる2つのキューがあります。まずどちらを使うかを押さえます。

Azure Service Bus: エンタープライズ向けメッセージブローカー。FIFO（順序保証）、トピック/サブスクリプション（Pub/Sub）、トランザクション、重複検出、セッションなどを備える
Azure Queue Storage: ストレージアカウント上のシンプルなキュー。機能は最小限だが安価で大容量（最大数 TB 規模まで保持可能）

Service Bus の主要用語:

キュー: 1対1（送信側 → 受信側）。**先入れ先出し（FIFO）**で配信
トピック / サブスクリプション: 1対多の Pub/Sub。1つのトピックに送ると複数サブスクリプションへコピー配信。SQL フィルターでルーティング可能
ロック（PeekLock）: 受信したメッセージを一定時間ロックし、他の受信側から隠す（SQS の可視性タイムアウトに相当）
デッドレターキュー（DLQ）: 規定回数の配信に失敗、または期限切れになったメッセージの退避先（サブキュー）
セッション: 関連メッセージをグループ化し、同一受信側で順序保証して処理する仕組み
重複検出: 一定時間内に同じ MessageId のメッセージを破棄し、送信側の再送による重複を防ぐ

仕様・制限・クォータ

代表的な上限値です（SKU により異なる）。

メッセージサイズ: Standard は最大 256 KB、Premium は最大 100 MB。Queue Storage は 64 KB（大きいデータは Blob ＋参照）
メッセージ保持（TTL）: Service Bus は最大 14 日。Queue Storage は最大 7 日（設定で無期限も可）
配信方式: いずれもプル型（受信側がポーリング）。プッシュ連携は Event Grid / Functions トリガーで補う
配信保証: 既定は最低1回（at-least-once）。Service Bus はトランザクションや重複検出で実質 exactly-once に近づけられる
SKU: Service Bus は Basic / Standard / Premium。トピックは Standard 以上、100 MB メッセージや専有リソース（CU）・VNet 統合は Premium

内部の仕組み

受信側はキューをポーリングしてメッセージを取得します。Service Bus の既定モード PeekLock では、取得したメッセージはロックタイムアウトの間ロックされ他の受信側から見えなくなります。処理が成功したら Complete（削除）、失敗時は Abandon（即時ロック解除して再配信）するか、ロックタイムアウトを過ぎると自動的に再配信されます。MaxDeliveryCount を超えるとDLQへ移動します。

もう一つの ReceiveAndDelete モードは取得と同時に削除する（高速だがクラッシュ時にメッセージを失う）
トピックでは、メッセージはサブスクリプションごとにコピーされ、各サブスクリプションが独立したキューのように振る舞う
at-least-once が前提なので、受信処理は冪等に作るのが鉄則

PeekLockでは受信時点で削除せず、処理成功後のCompleteで確定します。失敗やロック期限切れでは再配信され、規定回数を超えるとDLQへ移動します。トピックは購読ごとに独立したコピーを保持し、Queue Storageは単純で安価な処理に向きます。

二重処理に備える

既定は「最低1回」配信なのでまれに重複します。処理は冪等に作るのが基本。送信側の再送由来の重複は 重複検出、厳密な順序が要るなら セッションを使います。

設計パターン / ベストプラクティス

負荷平準化（Queue-Based Load Leveling）: スパイクをキューで吸収し、受信側は KEDA でキュー長に応じてスケール
競合コンシューマー: 複数ワーカーで同一キューを処理し、スループットを水平スケール
Pub/Sub: トピック/サブスクリプション＋SQL フィルターでイベントを宛先別にルーティング
DLQ で失敗を退避し、原因調査・再投入。DeadLetterReason で理由を確認
大きいペイロードは Blob に置きキューには参照（Claim-Check パターン）
PeekLock + Complete を基本にし、処理完了まで削除しない

運用・監視

Azure Monitor でメトリクスを監視: ActiveMessages（滞留数）、DeadletteredMessages、Size、スロットリング数
滞留増 → 受信側（ワーカー）不足やダウンストリーム障害を疑う
DLQ に溜まる → 処理ロジック / 権限 / メッセージ形式 / MaxDeliveryCount 設定を確認
Premium では 専有 CU（メッセージングユニット） の使用率を見てスケール判断
メッセージ本文を覗き見る Peek やサービスログ（診断設定）で調査

コスト

2系統で課金体系が大きく異なります。要件に対し過剰な SKU を選ばないことが肝です。

選択肢	課金の考え方	向いている用途
Queue Storage	操作回数＋保存容量（非常に安価）	大量・低コストでシンプルなキュー
Service Bus Basic	操作回数課金（キューのみ）	最小機能で安く始める
Service Bus Standard	メッセージ操作課金（トピック対応）	Pub/Sub や中規模の本番
Service Bus Premium	専有 CU 単位の固定課金	安定低レイテンシ・大容量・VNet 隔離

セキュリティ

Microsoft Entra ID + RBAC でアクセス制御（Azure Service Bus Data Sender/Receiver ロール）。資格情報をコードに埋めない
アプリには マネージド ID を付与して接続（AWS の IAM ロール相当）
保存時暗号化は既定で有効。Premium では カスタマーマネージドキー（Key Vault） も利用可
転送は TLS。Premium は プライベートエンドポイント / VNet サービスエンドポイントでネットワーク隔離

アンチパターン

SAS 接続文字列（共有アクセスキー）をアプリやリポジトリに直書きするのは NG。漏洩すれば誰でも送受信できます。マネージド ID + Entra ID/RBAC に寄せ、鍵の管理・ローテーション・漏洩リスクを排除しましょう。

観点	Service Bus	Queue Storage	AWS SQS
位置づけ	高機能メッセージブローカー	シンプル・安価なキュー	AWS のマネージドキュー
順序保証	FIFO / セッション	ベストエフォート	FIFO キュー
Pub/Sub	トピック/サブスクリプション	なし	SNS と組み合わせ
可視性制御	PeekLock（ロック）	可視性タイムアウト	可視性タイムアウト
失敗退避	DLQ（サブキュー）	（DLQ なし）	DLQ
権限付与	マネージド ID + Entra/RBAC	同左 / SAS	IAM ロール

ハンズオン / CLI例

# リソースグループを作成
az group create --name demo-rg --location japaneast

# Service Bus 名前空間（Standard）を作成
az servicebus namespace create \
  --resource-group demo-rg \
  --name demo-sbns-0603 \
  --location japaneast \
  --sku Standard

# キューを作成（重複検出・最大配信回数を指定）
az servicebus queue create \
  --resource-group demo-rg \
  --namespace-name demo-sbns-0603 \
  --name jobs \
  --max-delivery-count 5 \
  --enable-duplicate-detection true

# トピックとサブスクリプションを作成（Pub/Sub）
az servicebus topic create \
  --resource-group demo-rg --namespace-name demo-sbns-0603 --name events
az servicebus topic subscription create \
  --resource-group demo-rg --namespace-name demo-sbns-0603 \
  --topic-name events --name audit

# キューの一覧を確認
az servicebus queue list \
  --resource-group demo-rg --namespace-name demo-sbns-0603 -o table