Azure Queue Storage

解決する課題

アクセスが急増してもバックエンドを詰まらせず、送信側と処理側を独立してスケールさせたい、という疎結合化のニーズに、最小限の機能と低コストで応えるのが Queue Storage です。高度な順序保証や Pub/Sub は不要で、「とにかくメッセージを安くためて順に処理する」用途に向きます。

• アクセス急増でバックエンドが処理しきれない、キューでバッファして負荷を平準化したい
• 送信側（フロント）と処理側（ワーカー）を疎結合にし、それぞれ独立にスケールさせたい
• 大量のジョブを安価にため込みたく、エンタープライズ機能までは要らない
• 処理が失敗したメッセージを取りこぼさず、再試行できるようにしたい

AWS で言えば Amazon SQS（とくに標準キュー）に近く、機能はシンプルでストレージ課金が中心という位置づけです。

主要概念と用語

• ストレージアカウント: キューを束ねる入れ物。Blob やテーブルと同じアカウント上に同居する
• キュー: メッセージを格納する順序付きの入れ物。1つのアカウントに多数作成できる
• メッセージ: キューに入れる1件のデータ。テキストやエンコードしたバイナリを持ち、1件あたりのサイズに上限がある
• 可視性タイムアウト（Visibility Timeout）: 取得したメッセージを一定時間ほかの受信側から隠す仕組み。処理が終わるまで二重取得を防ぐ。AWS SQS の同名機能に相当する
• メッセージ TTL: メッセージの保持期限。期限を過ぎると自動的に削除される
• デキューカウント（Dequeue Count）: そのメッセージが取得された回数。再試行の上限管理や毒メッセージ検出に使う
• ポップレシート（Pop Receipt）: メッセージ取得時に発行される識別子。削除や可視性更新の操作にはこの値が必要になる

仕様・制限・クォータ

• メッセージサイズ: 1件あたり最大で数十キロバイト程度（おおむね 64 KB まで）。大きなデータは Blob に置き、キューには参照だけを入れる
• キュー容量: 1つのキューに保持できるメッセージ数は実質的にストレージ容量の上限まで及び、テラバイト級の大量メッセージを安価に保持できる
• メッセージ保持（TTL）: 規定値があり、最大保持期間を超えると自動削除される。設定により無期限の保持も指定できる
• 配信方式: プル型で、受信側がキューをポーリングして取得する。プッシュ連携が要る場合は Event Grid や Functions のトリガーで補う
• 配信保証: 最低1回（at-least-once）。まれに同じメッセージが複数回配信されうるため、処理は冪等に作る
• 順序: 厳密な FIFO は保証されない（おおむね投入順だが保証ではない）。厳格な順序が必要なら Service Bus を使う
• 厳密な数値は変動しうるため、上限値は公式ドキュメントで確認すること

内部の仕組み

受信側はキューをポーリングしてメッセージを取得します。取得した瞬間にメッセージは削除されず、可視性タイムアウトの間だけほかの受信側から隠されます。処理に成功したら、受信時に得たポップレシートを使ってメッセージを明示的に削除します。

• 処理が成功し削除されれば、そのメッセージは二度と配信されない
• 可視性タイムアウト内に削除されなかった場合、メッセージは再び可視になり、別の受信側に再配信される（ワーカーがクラッシュしても取りこぼさない）
• 取得のたびにデキューカウントが増える。毒メッセージ（何度処理しても失敗するメッセージ）はこの値で検出する
• 標準では自動のデッドレターキューはなく、リトライ上限の管理や退避は受信側の実装で行う

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

• 負荷平準化（Queue-Based Load Leveling）: スパイクをキューで吸収し、受信側は自分のペースで処理する
• 競合コンシューマー: 複数のワーカーで同一キューを処理し、スループットを水平にスケールする
• 可視性タイムアウトは処理時間に合わせる: 短すぎると処理中に再配信され二重処理が起きやすく、長すぎるとクラッシュ後の再開が遅れる
• 取得後に明示削除: 処理が完全に終わってからメッセージを削除し、途中失敗時は再配信に任せる
• 大きいペイロードは Blob に置きキューには参照を入れる（Claim-Check パターン）
• 毒メッセージ対策: デキューカウントが規定回数を超えたメッセージは退避キューに移し、本処理を止めない
• KEDA などでキュー長に応じて受信側を自動スケールさせると、滞留を抑えつつコストも最適化できる

運用・監視

• Azure Monitor / ストレージメトリクスでキューのメッセージ数、トランザクション数、レイテンシ、エラー率を監視する
• メッセージ数（滞留）が増え続ける場合は、受信側ワーカーの不足やダウンストリーム障害を疑う
• スロットリングを示すレスポンスが出たら、アクセス集中やアカウント単位の上限到達を確認する
• 診断ログを Log Analytics に送り、遅い操作や高頻度のポーリングを把握する
• 毒メッセージが溜まる退避キューを定期的に確認し、処理ロジックやメッセージ形式の不具合を調査する

コスト

Queue Storage の最大の魅力は安さです。スループットを事前確保して支払う方式ではなく、課金は基本的に操作回数（トランザクション）と保存データ量、リージョン外へのデータ転送で決まります。単純なキュー用途であれば、エンタープライズ機能を持つ Service Bus より大幅に安く済みます。

セキュリティ

• 保存時暗号化はデフォルトで有効（ストレージサービスの暗号化）。通信は TLS で暗号化される
• アクセス制御はアカウントキー、SAS（Shared Access Signature）、Microsoft Entra ID（RBAC）から選べる。可能なら Entra ID とマネージド ID を使い、キーのハードコードを避ける
• アプリにはマネージド ID を付与して接続する（AWS の IAM ロール相当）
• SAS を使えば、有効期限と権限を絞った一時的なアクセスを発行できる
• プライベートエンドポイント（Private Link） で VNet 内からの到達に限定し、パブリックアクセスを最小化する

Well-Architected の観点

• 信頼性: 可視性タイムアウトと明示削除により、ワーカーがクラッシュしてもメッセージを取りこぼさず再配信できる。キューが送信側と処理側のバッファとなり、片側の障害がもう片側へ波及しにくい
• コスト最適化: スループットを確保して払う方式ではなく操作回数と保存量が中心のため、大量メッセージを安価に扱える。空ポーリングを抑え、過剰な機能を持つサービスを選ばないことで費用を最小化できる

試験で問われるポイント

関連サービス・比較

同じ「キューでメッセージをためる」用途でも、シンプルで安い Queue Storage と、順序保証や Pub/Sub を備える Service Bus のどちらを選ぶかが論点になります。AWS の対応サービスとあわせて整理します。

ハンズオン / CLI例

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

# ストレージアカウントを作成（キューはこのアカウント上に作る）
az storage account create \
  --name demoqueuestg0614 \
  --resource-group demo-rg \
  --location japaneast \
  --sku Standard_LRS

# キューを作成
az storage queue create \
  --name jobs \
  --account-name demoqueuestg0614 \
  --auth-mode login

# メッセージを1件送信
az storage message put \
  --queue-name jobs \
  --content "order-100" \
  --account-name demoqueuestg0614 \
  --auth-mode login

# メッセージを1件取得（可視性タイムアウトの間ほかから隠れる）
az storage message get \
  --queue-name jobs \
  --account-name demoqueuestg0614 \
  --visibility-timeout 30 \
  --auth-mode login

# キューにたまっているメッセージのおおよその件数を確認
az storage queue stats \
  --account-name demoqueuestg0614 \
  --auth-mode login