Storage キューと Service Bus キューの比較
この記事では、Microsoft Azure によって提供されている Storage キューと Service Bus キューという 2 種類のキューの相違点と共通点について説明します。 この情報を使用すると、どちらのソリューションが自分のニーズに最も適しているかについて、より多くの情報に基づいて判断できるようになります。
はじめに
Azure では Storage キューと Service Bus キューの 2 種類のキュー メカニズムをサポートしています。
Storage キューは Azure Storage インフラストラクチャの一部です。 これらにより、多数のメッセージを格納することができます。 メッセージには、HTTP または HTTPS を使用して、認証された呼び出しを介して世界中のどこからでもアクセスできます。 キュー メッセージの許容される最大サイズは 64 KB です。 キューには、ストレージ アカウントの総容量の上限を超えない限り、数百万のメッセージを含めることができます。 キューは通常、非同期的な処理用に作業のバックログを作成するために使用されます。 詳細については、Azure Storage キューの概要に関するページを参照してください。
Service Bus キューは、より大きな Azure メッセージング インフラストラクチャの一部です。このインフラストラクチャでは、キュー処理やパブリッシュ/サブスクライブなどの高度な統合パターンがサポートされています。 これらは、複数の通信プロトコル、データ コントラクト、信頼ドメイン、ネットワーク環境などにまたがる可能性があるアプリケーションやアプリケーション コンポーネントの統合を目的としています。 Service Bus のキュー、トピック、サブスクリプションの詳細については、「Service Bus のキュー、トピック、サブスクリプション」をご覧ください。
テクノロジの選択に関する考慮事項
Storage キューと Service Bus キューの機能セットは、多少異なります。 ご自身の特定のソリューションのニーズに応じて、どちらか一方を選択することも、両方を選択することもできます。
特定のソリューションの目的に合うキュー テクノロジを判断する際、ソリューション設計者および開発者はこれらの推奨事項を検討する必要があります。
Storage キューの使用を検討する
ソリューション設計者または開発者として、次の場合に Storage キューの使用を検討してください。
- アプリケーションは 80 ギガバイトを超えるメッセージをキューに格納する必要がある場合。
- アプリケーションでキュー内のメッセージ処理の進行状況を追跡したい場合。 これは、メッセージを処理しているワーカーがクラッシュした場合に役に立ちます。 別のワーカーでその情報を使用して、前のワーカーが中断した時点から処理を再開できます。
- キューに対して実行されたすべてのトランザクションのサーバー側のログが必要な場合。
Service Bus キューの使用を検討する
ソリューション設計者または開発者として、次の場合に Service Bus キューの使用を検討してください。
- ソリューションで、キューをポーリングせずにメッセージを受信できる必要がある場合。 Service Bus では、Service Bus がサポートする TCP ベースのプロトコルを使用し、長いポーリングの受信操作を使用することによってこれを実現できます。
- キューによるメッセージの配信が先入れ先出し (FIFO) の順序で行われることが保証される必要がある場合。
- ソリューションで、自動重複検出をサポートする必要がある場合。
- アプリケーションでメッセージを実行時間の長い並列ストリームとして処理する必要がある場合 (メッセージは、それ自体の [セッション ID] プロパティを使用してストリームに関連付けられます)。 このモデルでは、処理を行うアプリケーションの各ノードは、メッセージではなくストリームに対して競合します。 処理を行うノードにストリームが渡されると、そのノードはトランザクションを使用してアプリケーション ストリームの状態を確認できます。
- 複数のメッセージをキューに送信したりキューから受信したりする際にトランザクション動作と原子性が必要な場合。
- アプリケーションの処理するメッセージが、64 KB を超える可能性はあるが、256 KB または 1 MB の制限 (選んだサービス レベルにより異なる) に達することはないと思われる場合 (ただし、Service Bus キューは最大 100 MB のメッセージを処理する可能性があります)。
- ロールベースのアクセス モデルを提供して、キューの送信側と受信側に異なる権限/アクセス許可を与える必要がある場合。 詳細については、次の記事を参照してください。
- キューのサイズが 80 GB を超えることはない場合。
- AMQP 1.0 標準ベースのメッセージング プロトコルを使用する必要がある場合。 AMQP の詳細情報については「Service Bus AMQP の概要」をご覧ください。
- 最終的には、キューベースのポイントツーポイント通信から、パブリッシュ/サブスクライブ メッセージング パターンへの移行を想定している場合。 このパターンは、追加の受信者 (サブスクライバー) の統合を可能にします。 各受信者は、キューに送信されたメッセージの一部またはすべての独立したコピーを受け取ります。
- メッセージング ソリューションでは、追加のインフラストラクチャ コンポーネントを構築する必要なく、「少なくとも 1 回」および 「少なくとも 1 回」 の配信をサポートする必要があります。
- ソリューションで、バッチ メッセージの発行および使用が必要な場合。
Storage キューと Service Bus キューの比較
次のセクションの表は、キューの機能を論理的にグループ化したものです。 これらを使用すると、Azure Storage キューと Service Bus キューの両方で使用できる機能を一目で比較できます。
基本的な機能
このセクションでは、Storage キューと Service Bus キューで提供される基本的なキュー機能の一部を比較します。
| 比較条件 | Storage キュー | Service Bus キュー |
|---|---|---|
| 順序の保証 | なし 詳細については、「関連情報」セクションの最初のメモをご覧ください。 |
○ - 先入れ先出し (FIFO) (メッセージ セッションを使用) |
| 配信保証 | At-Least-Once | 少なくとも 1 回 (PeekLock 受信モードを使用)。これは既定値です) At-Most-Once (ReceiveAndDelete 受信モードを使用) さまざまな受信モードに関する詳細 |
| 分割不可能な操作のサポート | いいえ | はい |
| 受信動作 | 非ブロッキング (新しいメッセージがない場合はすぐに完了します) |
タイムアウトあり/なしのブロッキング (長いポーリングまたは "Comet 手法" を提供します) 非ブロッキング (.NET マネージド API のみを使用) |
| プッシュ型 API | いいえ | はい .NET、Java、JavaScript、Go SDK には、プッシュ型 API が用意されています。 |
| 受信モード | Peek & Lease | Peek & Lock Receive & Delete |
| 排他アクセス モード | リース ベース | ロック ベース |
| リース/ロックの期間 | 30 秒 (既定) 7 日間 (最大) (UpdateMessage API を使用してメッセージ リースを更新または変更できます) |
30 秒 (既定) 毎回同じロック期間メッセージ ロックを更新することも、自動ロック更新機能を使用して、クライアントでロックの更新を管理することもできます。 |
| リース/ロックの粒度 | メッセージ レベル 各メッセージには異なるタイムアウト値を設定できます。この値は UpdateMessage API を使用して、メッセージの処理中に必要に応じて更新できます。 |
キュー レベル (各キューのすべてのメッセージにはロック精度が適用されますが、前の行で説明したようにロックを更新できます) |
| 一括受信 | はい (メッセージを取得するときに最大 32 のメッセージ数を明示的に指定します) |
はい (事前取り込みプロパティを有効にして暗黙的に行うか、トランザクションを使用して明示的に行います) |
| 一括送信 | いいえ | はい (トランザクションまたはクライアント側のバッチ処理を使用) |
関連情報
- Storage キューのメッセージは一般的に先入れ先出しですが、順番が変わることがあります。 たとえば、メッセージの処理中にクライアント アプリケーションがクラッシュしたために、メッセージの表示タイムアウト期間が過ぎた場合などです。 表示タイムアウトが過ぎると、別の worker がデキューするために、メッセージがキューに再度表示されます。 そのとき、新しく表示可能になったメッセージが再デキューのためにキューに配置されることがあります。
- Service Bus キューで FIFO パターンを保証するには、メッセージング セッションを使用する必要があります。 Peek & Lock モードで受信したメッセージの処理中にアプリケーションがクラッシュした場合、キューの受信側は、次にメッセージング セッションを受け取ったときに、セッションのロック期間が経過した後、失敗したメッセージから開始します。
- Storage キューは、次のような標準的なキューイング シナリオをサポートするように設計されています。
- アプリケーション コンポーネントを分離してスケーラビリティや耐障害性を向上させる
- 負荷平準化
- プロセス ワークフローの構築
- Service Bus セッションのコンテキストでのメッセージ処理に関する不整合は、セッション状態を使用してセッションのメッセージ シーケンスの処理の進捗に関連するアプリケーションの状態を格納することと、受け取ったメッセージの解決に関するトランザクションを使用してセッション状態を更新することで回避できます。 このような一貫性機能は、他のベンダー製品では "厳密に 1 回の処理" と呼ばれることがあります。 トランザクション エラーは明らかにメッセージの再配信の原因となるため、この用語は正確には適切ではありません。
- Storage キューでは、開発者とオペレーション チームの双方に対し、キュー、テーブル、BLOB で一貫性のあるプログラミング モデルを提供します。
- Service Bus キューは、1 つのキューのコンテキストでローカル トランザクションをサポートします。
- Service Bus でサポートされている Receive and Delete モードを使用すると、メッセージング操作の数 (および関連するコスト) を削減できますが、配信の確実性が低下します。
- Storage キューではメッセージのリースを延長することのできるリースを提供します。 この機能により、ワーカー プロセスでメッセージのリースを短くすることができます。 そのため、ワーカーがクラッシュした場合にすぐに別のワーカーがメッセージを再度処理できます。 また、現在のリース時間より長い処理時間が必要になった場合に、ワーカーがメッセージのリースを延長できます。
- Storage キューでは、メッセージをエンキューまたはデキューするときに表示のタイムアウトを設定できます。 また、実行時にメッセージを別のリース値で更新したり、同じキューのメッセージを別の値で更新したりすることもできます。 Service Bus ロック タイムアウトは、キューのメタデータで定義されます。 ただし、定義済みのロック期間メッセージ ロックを手動で更新することも、自動ロック更新機能を使用して、クライアントでロックの更新を管理することもできます。
- Service Bus キューのブロッキング受信操作の最大タイムアウトは 24 日です。 ただし、REST ベースのタイムアウトの最大値は 55 秒です。
- Service Bus でサポートされているクライアント側のバッチ処理を使用すると、キュー クライアントで複数のメッセージをバッチ処理して 1 回の送信操作で処理を完了できます。 バッチ処理は非同期送信操作でのみ使用できます。
- 200 TB が上限の Storage キュー (アカウントを仮想化すればさらに確保可能) や無制限キューのような機能により、SaaS プロバイダーにとって理想的なプラットフォームになります。
- Storage キューでは、柔軟性が高くパフォーマンスに優れた委任アクセス制御メカニズムを提供します。
拡張機能
このセクションでは、Storage キューと Service Bus キューで提供される拡張機能を比較します。
| 比較条件 | Storage キュー | Service Bus キュー |
|---|---|---|
| スケジュールされた配信 | はい | はい |
| 自動的な配信不能レタリング | いいえ | はい |
| キューの有効期間の増加 | はい (表示のタイムアウトのインプレース更新を使用) |
はい (専用の API 関数を使用) |
| 有害なメッセージのサポート | はい | はい |
| インプレース更新 | はい | はい |
| サーバー側のトランザクション ログ | はい | いいえ |
| Storage のメトリック | はい 分単位のメトリックは、可用性、TPS、API 呼び出し数、エラー数などのリアルタイムのメトリックを提供します。 これらはすべてリアルタイムで、分単位で集計され、運用環境での発生から数分以内に報告されます。 詳細については、「Storage Analytics Metrics について」を参照してください。 |
はい Azure Service Bus でサポートされるメトリックの詳細については、「メッセージのメトリック」を参照してください。 |
| 状態管理 | いいえ | はい (アクティブ、無効、SendDisabled、ReceiveDisabled。これらの状態の詳細については、「キューの状態」を参照してください) |
| メッセージの自動転送 | いいえ | はい |
| キューの消去機能 | はい | はい |
| メッセージ グループ | いいえ | はい (メッセージング セッションを使用) |
| メッセージ グループ単位のアプリケーション状態 | いいえ | はい |
| 重複検出 | いいえ | はい (送信側で構成可能) |
| メッセージ グループの参照 | いいえ | はい |
| ID によるメッセージ セッションの取得 | いいえ | はい |
関連情報
- 両方のキュー テクノロジには、メッセージを後で配信するようにスケジュールできる機能があります。
- キューの自動転送を使用すると、数千のキューのメッセージを 1 つのキューに自動転送して、受信側アプリケーションはそのキューからメッセージを処理することができます。 このメカニズムを使用して、各メッセージ パブリッシャー間でセキュリティの確保、フロー制御、ストレージ分離を実現できます。
- Storage キューでは、メッセージの内容の更新がサポートされています。 この機能を使用すると、状態情報と進行状況の増分更新をメッセージに永続化して、メッセージの処理を最初からではなく前回のチェックポイントから開始することができます。 Service Bus キューでは、メッセージ セッションを使用して同じシナリオを実現できます。 詳細については、「メッセージ セッションの状態」を参照してください。
- Service Bus キューは配信不能レタリングをサポートします。 これは、次の条件を満たすメッセージを分離するのに役立ちます。
- 受信側アプリケーションでメッセージを正常に処理できない
- 有効期限が切れた Time-to-live (TTL) プロパティが原因で、メッセージが宛先に届かない。 TTL の値は、メッセージがキューに保持される期間を指定します。 Service Bus では、TTL が期限切れになると、メッセージが $DeadLetterQueue という特殊なキューに移動されます。
- Storage キューで "有害な" メッセージを検出するには、アプリケーションでメッセージをデキューするときにメッセージの DequeueCount プロパティを確認します。 DequeueCount が一定のしきい値を超えている場合は、そのメッセージをアプリケーション定義の "配信不能" キューに移動します。
- Storage キューでは、キューに対して実行されたすべてのトランザクションの詳細なログとメトリックの集計値を取得できます。 これらのオプションはいずれも、デバッグや、アプリケーションでの Storage キューの使い方を理解するのに役立ちます。 また、アプリケーションのパフォーマンス チューニングやキューの使用コストの削減にも役立ちます。
- Service Bus によってサポートされるメッセージ セッションでは、論理グループに属するメッセージを受信者に関連付けることができます。 これにより、メッセージとそれぞれの受信側の間にセッションのような関係が作成されます。 Service Bus でこの拡張機能を有効にするには、メッセージの [セッション ID] プロパティを設定します。 受信側では、特定のセッション ID をリッスンして、指定したセッション ID を共有するメッセージを受信できます。
- Service Bus キューの重複検出機能により、[メッセージ ID] プロパティの値に基づいて、キューまたはトピックに送信された重複するメッセージが自動的に削除されます。
容量およびクォータ
このセクションでは、容量および適用される可能性があるクォータの観点から Storage キューと Service Bus キューを比較します。
| 比較条件 | Storage キュー | Service Bus キュー |
|---|---|---|
| 最大キュー サイズ | 500 TB (1 つのストレージ アカウントの容量に制限) |
1 GB ～ 80 GB (パーティション分割を使用する Premium または Standard レベル) |
| 最大メッセージ サイズ | 64 KB (Base 64 エンコードを使用する場合は 48 KB) Azure では、キューと BLOB を組み合わせることでサイズの大きいメッセージをサポートし、1 つのアイテムに対して最大 200 GB までのメッセージをエンキューできます。 |
256 KB、1 MB、100 MB のいずれか (ヘッダーと本文の両方を含む。ヘッダーの最大サイズは 64 KB)。 サービス レベルに依存します。 |
| メッセージの最大 TTL | 無限 (API バージョン 2017-07-27 以降) | TimeSpan.MaxValue |
| キューの最大数 | 無制限 | 10,000 (Standard レベル) 1000 / メッセージング ユニット (Premium レベル) (サービス名前空間あたり) |
| 同時クライアントの最大数 | 無制限 | 5,000 |
関連情報
- Service Bus では、キューのサイズが制限されます。 キューの作成時に、キューの最大サイズを指定します。 これは 1 GB から 80 GB の間で指定できます。 キューのサイズがこの制限に達すると、追加の受信メッセージは拒否され、呼び出し元は例外を受け取ります。 Service Bus でのクォータの詳細情報については、「Service Bus のクォータ」をご覧ください。
- Standard メッセージング レベルでは、Service Bus キューおよびトピックは、1 GB (既定値)、2 GB、3 GB、4 GB、5 GB で作成できます。 Standard レベルでパーティション分割を有効にすると、Service Bus ではエンティティの 16 個のコピー (16 個のパーティション) を、指定された同じサイズで作成します。 そのため、サイズが 5 GB のキューを作成すると、パーティションが 16 個であるため、最大キュー サイズは 5 * 16 = 80 GB になります。 パーティション分割したキューまたはトピックの最大サイズは、Azure portal で確認できます。
- Storage キューでは、内容が XML セーフでないメッセージに対しては Base64 エンコードを使用する必要があります。 メッセージを Base64 エンコードを使用する場合、ユーザー ペイロードの上限は 64 KB ではなく 48 KB になります。
- Service Bus キューでは、キューに格納される各メッセージはヘッダーと本文の 2 つの部分で構成されます。 メッセージの合計サイズが、サービス レベルでサポートされる最大メッセージ サイズを超えることはできません。
- クライアントが TCP プロトコルで Service Bus キューと通信する場合は、1 つの Service Bus キューに対するコンカレント接続の最大数が 100 に制限されます。 この数は送信側と受信側で共有されます。 このクォータに達すると、追加の接続要求は拒否され、呼び出し元のコードが例外を受け取ります。 この制限は、REST ベースの API を使用してキューに接続するクライアントには適用されません。
- Service Bus Standard SKU での 10,000 個のキュー、または Service Bus Premium SKU でのメッセージング ユニットあたり 1000 個のキューを超えてスケーリングを行うために、Azure portal を使用して追加の名前空間を作成することもできます。
管理と操作
このセクションでは、Storage キューと Service Bus キューで提供される管理機能を比較します。
| 比較条件 | Storage キュー | Service Bus キュー |
|---|---|---|
| 管理プロトコル | HTTP/HTTPS 経由の REST | HTTPS 経由の REST |
| ランタイム プロトコル | HTTP/HTTPS 経由の REST | HTTPS 経由の REST AMQP 1.0 標準 (TCP と TLS) |
| .NET API | はい (.NET Storage Client API) |
はい (.NET Service Bus API) |
| ネイティブ C++ | はい | はい |
| Java API | はい | はい |
| PHP API | はい | はい |
| Node.js API | はい | はい |
| 任意のメタデータのサポート | はい | いいえ |
| キューの名前付け規則 | 最大 63 文字 (キューの名前は小文字で指定する必要があります) |
最大 260 文字 (キューのパスと名前では大文字と小文字は区別されません) |
| キューの長さを取得する機能 | はい (メッセージが TTL を過ぎて期限切れになっても削除されていない場合は概算値となります) |
はい (特定の時点の正確な値) |
| Peek 機能 | はい | はい |
関連情報
- Storage キューでは、キューの説明に名前と値のペアの形式の任意の属性を適用できます。
- 両方のキュー テクノロジには、メッセージをロックせずに表示できる機能も用意されています。この機能は、キューのエクスプローラー/ブラウザー ツールを実装する際に便利です。
- Service Bus の .NET ブローカー メッセージング API は、全二重 TCP 接続を使用して HTTP 経由の REST より高いパフォーマンスを発揮します。また、AMQP 1.0 標準プロトコルもサポートしています。
- Storage キューの名前は 3 ～ 63 文字の間で指定でき、小文字、数字、ハイフンを使用できます。 詳細については、「キューおよびメタデータの名前付け」をご覧ください。
- Service Bus のキュー名は最大 260 文字までの長さで指定でき、名前付け規則の制限は厳しくありません。 Service Bus のキュー名には、文字、数字、ピリオド、ハイフン、アンダースコアを使用できます。
認証と権限承認
このセクションでは、Storage キューと Service Bus キューでサポートされる認証および承認機能について説明します。
| 比較条件 | Storage キュー | Service Bus キュー |
|---|---|---|
| 認証 | 対称キーとロール ベースのアクセス制御 (RBAC) | 対象キーとロール ベースのアクセス制御 (RBAC) |
| ID プロバイダー フェデレーション | はい | はい |
関連情報
- どちらのキュー テクノロジでも、すべての要求を認証する必要があります。 匿名アクセスを使用するパブリック キューはサポートされていません。
- Shared Access Signature (SAS) 認証を使用すると、書き込み専用、読み取り専用、またはフル アクセスをユーザーに付与できる共有アクセス承認規則をキューに作成できます。 詳細については、「Azure Storage - SAS 認証」と「Azure Service Bus - SAS 認証」を参照してください。
- どちらのキューも、Microsoft Entra ID を使用したアクセスの承認をサポートしています。 Microsoft Entra ID によって返される OAuth 2.0 トークンを使用してユーザーまたはアプリケーションを承認すると、Shared Access Signature (SAS) よりも優れたセキュリティと使いやすさが提供されます。 Microsoft Entra ID を使用すると、コードにトークンを格納する必要がなく、潜在的なセキュリティの脆弱性を危険にさらす必要はありません。 詳細については、Azure Storage - Microsoft Entra 認証 と Azure Service Bus - Microsoft Entra 認証 を参照してください。
まとめ
2 つのテクノロジをより深く理解することにより、使用するキュー テクノロジとその状況について、より多くの十分な情報を得たうえでの決定を行うことができます。 Storage キューまたは Service Bus キューを使用する状況についての判断は明らかに多数の要因に依存します。 これらの要因は、アプリケーションとそのアーキテクチャの個々のニーズに大きく依存します。
Storage キューは、次のような理由から選択することをお勧めします。
- お使いのアプリケーションで Microsoft Azure のコア機能が既に使用されている場合
- サービス間の基本的な通信とメッセージングが必要な場合
- サイズが 80 GB を超えるキューが必要
Service Bus キューには、次のような多くの高度な機能が用意されています。 したがって、ハイブリッド アプリケーションを構築する場合や、お使いのアプリケーションでこれらの機能が必要な場合は、これを選択することをお勧めします。
次のステップ
次の記事では、Storage キューや Service Bus キューの使用に関する詳細情報を提供します。