Storage キューと Service Bus キューの比較Storage queues and Service Bus queues - compared and contrasted

この記事では、現在 Microsoft Azure によって提供されている Storage キューと Service Bus キューという 2 種類のキューの相違点と共通点について説明します。This article analyzes the differences and similarities between the two types of queues offered by Microsoft Azure today: Storage queues and Service Bus queues. この情報を使用すると、それぞれのテクノロジを比較対照して、現在のニーズに最適なのはどちらのソリューションかを十分な情報に基づいて判断できるようになります。By using this information, you can compare and contrast the respective technologies and be able to make a more informed decision about which solution best meets your needs.

はじめにIntroduction

Azure では Storage キューService Bus キューの 2 種類のキュー メカニズムをサポートしています。Azure supports two types of queue mechanisms: Storage queues and Service Bus queues.

Storage キューは、Azure Storage インフラストラクチャの一部であり、単純な REST ベースの GET/PUT/PEEK インターフェイスを使用して、サービス内およびサービス間で信頼性の高い永続的なメッセージングを提供します。Storage queues, which are part of the Azure storage infrastructure, feature a simple REST-based GET/PUT/PEEK interface, providing reliable, persistent messaging within and between services.

Service Bus キューは、より大きな Azure メッセージング インフラストラクチャの一部です。このインフラストラクチャでは、キュー処理だけでなく、パブリッシュ/サブスクライブなどの高度な統合パターンがサポートされています。Service Bus queues are part of a broader Azure messaging infrastructure that supports queuing as well as publish/subscribe, and more advanced integration patterns. Service Bus キュー、トピック、およびサブスクリプションの詳細情報については、Service Bus メッセージングの概要に関するページを参照してください。For more information about Service Bus queues/topics/subscriptions, see the overview of Service Bus.

この 2 つのキュー テクノロジは共存していますが、最初に Storage キューが、Azure Storage サービス上に構築された専用のキュー ストレージ メカニズムとして導入されました。While both queuing technologies exist concurrently, Storage queues were introduced first, as a dedicated queue storage mechanism built on top of Azure Storage services. Service Bus キューは、より大きなメッセージング インフラストラクチャ上に構築されています。このインフラストラクチャは、複数の通信プロトコル、データ コントラクト、信頼ドメイン、ネットワーク環境などにまたがるアプリケーションやアプリケーション コンポーネントの統合を目的としています。Service Bus queues are built on top of the broader messaging infrastructure designed to integrate applications or application components that may span multiple communication protocols, data contracts, trust domains, and/or network environments.

テクノロジの選択に関する考慮事項Technology selection considerations

Storage キューと Service Bus キューは、どちらも現在 Microsoft Azure により提供されているメッセージ キュー サービスの実装です。Both Storage queues and Service Bus queues are implementations of the message queuing service currently offered by Microsoft Azure. 機能に若干の違いがあるため、個々のソリューションの要件や、解決する必要があるビジネス上または技術上の問題に応じて、いずれかまたは両方を使用できます。Each has a slightly different feature set, which means you can choose one or the other, or use both, depending on the needs of your particular solution or business/technical problem you are solving.

特定のソリューションの目的に合うキュー テクノロジを判断する際、ソリューション設計者および開発者はこれらの推奨事項を検討する必要があります。When determining which queuing technology fits the purpose for a given solution, solution architects and developers should consider these recommendations. 詳細については、次のセクションをご覧ください。For more details, see the next section.

ソリューション設計者または開発者として、次の場合に Storage キューの使用を検討してくださいAs a solution architect/developer, you should consider using Storage queues when:

  • アプリケーションは 80 GB を超えるメッセージをキューに格納する必要があります。Your application must store over 80 GB of messages in a queue.
  • アプリケーションでキュー内のメッセージ処理の進行状況を追跡する必要がある場合。Your application wants to track progress for processing a message inside of the queue. これは、メッセージを処理している worker がクラッシュした場合に役に立ちます。This is useful if the worker processing a message crashes. 後続の worker でその情報を使用して、前の worker が中断した時点から処理を再開できます。A subsequent worker can then use that information to continue from where the prior worker left off.
  • キューに対して実行されたすべてのトランザクションのサーバー側のログが必要な場合。You require server side logs of all of the transactions executed against your queues.

ソリューション設計者または開発者として、次の場合に Service Bus キューの使用を検討してくださいAs a solution architect/developer, you should consider using Service Bus queues when:

  • キューをポーリングせずにメッセージを受信できる必要がある場合。Your solution must be able to receive messages without having to poll the queue. Service Bus では、Service Bus でサポートする TCP ベースのプロトコルを使用し、長いポーリングの受信操作を使用することによってこれを実現できます。With Service Bus, this can be achieved through the use of the long-polling receive operation using the TCP-based protocols that Service Bus supports.
  • キューによるメッセージの配信が先入れ先出し (FIFO) の順序で行われることが保証される必要がある場合。Your solution requires the queue to provide a guaranteed first-in-first-out (FIFO) ordered delivery.
  • 自動重複検出をサポートする必要がある場合。Your solution must be able to support automatic duplicate detection.
  • アプリケーションでメッセージを実行時間の長い並列ストリームとして処理する必要がある場合 (メッセージは、自身の SessionId プロパティを使用してストリームに関連付けられます)。You want your application to process messages as parallel long-running streams (messages are associated with a stream using the SessionId property on the message). このモデルでは、処理を行うアプリケーションの各ノードは、メッセージではなくストリームに対して競合します。In this model, each node in the consuming application competes for streams, as opposed to messages. 処理を行うノードにストリームが渡されると、そのノードはトランザクションを使用してアプリケーション ストリームの状態を確認できます。When a stream is given to a consuming node, the node can examine the state of the application stream state using transactions.
  • 複数のメッセージをキューに送信したりキューから受信したりする際にトランザクション動作と原子性が必要な場合。Your solution requires transactional behavior and atomicity when sending or receiving multiple messages from a queue.
  • アプリケーションで処理するメッセージのサイズが 64 KB を超えることはあっても 256 KB の制限に到達することはないと考えられる場合。Your application handles messages that can exceed 64 KB but will not likely approach the 256 KB limit.
  • ロールベースのアクセス モデルを提供して、キューの送信側と受信側に異なる権限/アクセス許可を与える必要がある場合。You deal with a requirement to provide a role-based access model to the queues, and different rights/permissions for senders and receivers.
  • キューのサイズが 80 GB を超えることはない場合。Your queue size will not grow larger than 80 GB.
  • AMQP 1.0 標準ベースのメッセージング プロトコルを使用する必要がある場合。You want to use the AMQP 1.0 standards-based messaging protocol. AMQP の詳細情報については「Service Bus AMQP の概要」をご覧ください。For more information about AMQP, see Service Bus AMQP Overview.
  • いずれは、キュー ベースのポイント ツー ポイントの通信から、キューに送信されたメッセージの一部またはすべての独立したコピーを受信する追加の受信側 (サブスクライバー) をシームレスに統合できるメッセージ交換パターンに移行することを考えている場合。You can envision an eventual migration from queue-based point-to-point communication to a message exchange pattern that enables seamless integration of additional receivers (subscribers), each of which receives independent copies of either some or all messages sent to the queue. 後者は、Service Bus によってネイティブで提供される発行/サブスクライブ機能を指します。The latter refers to the publish/subscribe capability natively provided by Service Bus.
  • 追加のインフラストラクチャ コンポーネントを作成しなくても "At-Most-Once" の配信保証をサポートできる必要がある場合。Your messaging solution must be able to support the "At-Most-Once" delivery guarantee without the need for you to build the additional infrastructure components.
  • バッチ メッセージの発行および使用が必要な場合。You would like to be able to publish and consume batches of messages.

Storage キューと Service Bus キューの比較Comparing Storage queues and Service Bus queues

次のセクションの表では、キューの機能を論理的にグループ化しており、Azure Storage キューと Service Bus キューの両方で使用できる機能を一目で比較することができます。The tables in the following sections provide a logical grouping of queue features and let you compare, at a glance, the capabilities available in both Azure Storage queues and Service Bus queues.

基本的な機能Foundational capabilities

このセクションでは、Storage キューと Service Bus キューで提供される基本的なキュー機能の一部を比較します。This section compares some of the fundamental queuing capabilities provided by Storage queues and Service Bus queues.

比較条件Comparison Criteria Storage キューStorage queues Service Bus キューService Bus queues
順序の保証Ordering guarantee いいえNo

詳細については、追加情報セクションの最初のメモをご覧ください。For more information, see the first note in the “Additional Information” section.
はい - 先入れ先出し法 (FIFO)Yes - First-In-First-Out (FIFO)

(メッセージング セッションを使用)(through the use of messaging sessions)
配信保証Delivery guarantee At-Least-OnceAt-Least-Once At-Least-OnceAt-Least-Once

At-Most-OnceAt-Most-Once
分割不可能な操作のサポートAtomic operation support いいえNo はいYes

受信動作Receive behavior 非ブロッキングNon-blocking

(新しいメッセージがない場合はすぐに完了します)(completes immediately if no new message is found)
タイムアウトあり/なしのブロッキングBlocking with/without timeout

(長いポーリングまたは "Comet 手法" を提供します)(offers long polling, or the "Comet technique")

非ブロッキングNon-blocking

(.NET マネージド API のみを使用)(through the use of .NET managed API only)
プッシュ型 APIPush-style API いいえNo はいYes

OnMessageOnMessage セッション .NET APIOnMessage and OnMessage sessions .NET API.
受信モードReceive mode Peek & LeasePeek & Lease Peek & LockPeek & Lock

Receive & DeleteReceive & Delete
排他アクセス モードExclusive access mode リース ベースLease-based ロック ベースLock-based
リース/ロックの期間Lease/Lock duration 30 秒 (既定値)30 seconds (default)

7 日間 (最大) (UpdateMessage API を使用してメッセージ リースを更新または変更できます)7 days (maximum) (You can renew or release a message lease using the UpdateMessage API.)
60 秒 (既定値)60 seconds (default)

RenewLock API を使用してメッセージのロックを更新できます。You can renew a message lock using the RenewLock API.
リース/ロックの粒度Lease/Lock precision メッセージ レベルMessage level

(各メッセージには異なるタイムアウト値を設定できます。この値は UpdateMessage API を使用して、メッセージの処理中に必要に応じて更新できます)(each message can have a different timeout value, which you can then update as needed while processing the message, by using the UpdateMessage API)
キュー レベルQueue level

(各キューのすべてのメッセージに同じロック粒度が適用されますが、RenewLock API を使用してロックを更新できます)(each queue has a lock precision applied to all of its messages, but you can renew the lock using the RenewLock API.)
一括受信Batched receive はいYes

(メッセージを取得するときに最大 32 のメッセージ数を明示的に指定します)(explicitly specifying message count when retrieving messages, up to a maximum of 32 messages)
はいYes

(プレフェッチ プロパティを有効にして暗黙的に行うか、トランザクションを使用して明示的に行います)(implicitly enabling a pre-fetch property or explicitly through the use of transactions)
一括送信Batched send いいえNo はいYes

(トランザクションまたはクライアント側のバッチ処理を使用)(through the use of transactions or client-side batching)

追加情報Additional information

  • Storage キューのメッセージは一般的に先入れ先出しですが、メッセージの表示タイムアウト期限を過ぎたとき (たとえば処理中にクライアント アプリケーションがクラッシュした場合) などに順番が変わることがあります。Messages in Storage queues are typically first-in-first-out, but sometimes they can be out of order; for example, when a message's visibility timeout duration expires (for example, as a result of a client application crashing during processing). 表示タイムアウトが過ぎると、別の worker がデキューするために、メッセージがキューに再度表示されます。When the visibility timeout expires, the message becomes visible again on the queue for another worker to dequeue it. そのとき、もともとエンキュー時に後ろにあったメッセージの後にメッセージが (再デキューのために) 配置されることがあります。At that point, the newly visible message might be placed in the queue (to be dequeued again) after a message that was originally enqueued after it.
  • Service Bus キューで FIFO パターンを保証するには、メッセージング セッションを使用する必要があります。The guaranteed FIFO pattern in Service Bus queues requires the use of messaging sessions. Peek & Lock モードで受信したメッセージの処理中にアプリケーションがクラッシュした場合、キューの受信側は、次にメッセージング セッションを受け取ったときに、TTL (time-to-live) 期間が経過した後、失敗したメッセージから開始します。In the event that the application crashes while processing a message received in the Peek & Lock mode, the next time a queue receiver accepts a messaging session, it will start with the failed message after its time-to-live (TTL) period expires.
  • Storage キューは、アプリケーション コンポーネントを分離してスケーラビリティや耐障害性を向上させ、負荷平準化やプロセス ワークフロー構築を容易にするなどの、標準的なキュー シナリオをサポートするように設計されています。Storage queues are designed to support standard queuing scenarios, such as decoupling application components to increase scalability and tolerance for failures, load leveling, and building process workflows.
  • Service Bus キューは、At-Least-Once の配信保証をサポートしています。Service Bus queues support the At-Least-Once delivery guarantee. また、セッション状態を使用してアプリケーションの状態を格納し、トランザクションを使用してメッセージの受信とセッション状態の更新の原子性を確保することにより、At-Most-Once セマンティクスをサポートすることもできます。In addition, the At-Most-Once semantic can be supported by using session state to store the application state and by using transactions to atomically receive messages and update the session state.
  • Storage キューでは、開発者とオペレーション チームの双方に対し、キュー、テーブル、BLOB で一貫性のあるプログラミング モデルを提供します。Storage queues provide a uniform and consistent programming model across queues, tables, and BLOBs – both for developers and for operations teams.
  • Service Bus キューは、1 つのキューのコンテキストでローカル トランザクションをサポートします。Service Bus queues provide support for local transactions in the context of a single queue.
  • Service Bus でサポートされている Receive and Delete モードを使用すると、メッセージング操作の数 (および関連するコスト) を削減できますが、配信の確実性が低下します。The Receive and Delete mode supported by Service Bus provides the ability to reduce the messaging operation count (and associated cost) in exchange for lowered delivery assurance.
  • Storage キューではメッセージのリースを延長することのできるリースを提供します。Storage queues provide leases with the ability to extend the leases for messages. これにより、メッセージのリースを短くして、This allows the workers to maintain short leases on messages. worker がクラッシュした場合にすぐに別の worker がメッセージを再度処理できるようにしたり、Thus, if a worker crashes, the message can be quickly processed again by another worker. メッセージで現在のリース時間より長い処理時間が必要になった場合にメッセージのリースを延長したりすることができます。In addition, a worker can extend the lease on a message if it needs to process it longer than the current lease time.
  • Storage キューでは、メッセージをエンキューまたはデキューするときに表示のタイムアウトを設定できます。Storage queues offer a visibility timeout that you can set upon the enqueuing or dequeuing of a message. また、実行時にメッセージを別のリース値で更新したり、同じキューのメッセージを別の値で更新したりすることもできます。In addition, you can update a message with different lease values at run-time, and update different values across messages in the same queue. Service Busのロックのタイムアウトはキューのメタデータで定義されていますが、RenewLock メソッドを呼び出してロックを更新できます。Service Bus lock timeouts are defined in the queue metadata; however, you can renew the lock by calling the RenewLock method.
  • Service Bus キューのブロッキング受信操作の最大タイムアウトは 24 日です。The maximum timeout for a blocking receive operation in Service Bus queues is 24 days. ただし、REST ベースのタイムアウトの最大値は 55 秒です。However, REST-based timeouts have a maximum value of 55 seconds.
  • Service Bus でサポートされているクライアント側のバッチ処理を使用すると、キュー クライアントで複数のメッセージをバッチ処理して 1 回の送信操作で処理を完了できます。Client-side batching provided by Service Bus enables a queue client to batch multiple messages into a single send operation. バッチ処理は非同期送信操作でのみ使用できます。Batching is only available for asynchronous send operations.
  • 200 TB (テラバイト) が上限の Storage キュー (アカウントを仮想化すればさらに確保可能) や無制限キューのような機能により、Azure は SaaS プロバイダーにとって理想的なプラットフォームになります。Features such as the 200 TB ceiling of Storage queues (more when you virtualize accounts) and unlimited queues make it an ideal platform for SaaS providers.
  • Storage キューでは、柔軟性が高くパフォーマンスに優れた委任アクセス制御メカニズムを提供します。Storage queues provide a flexible and performant delegated access control mechanism.

高度な機能Advanced capabilities

このセクションでは、Storage キューと Service Bus キューで提供される高度な機能を比較します。This section compares advanced capabilities provided by Storage queues and Service Bus queues.

比較条件Comparison Criteria Storage キューStorage queues Service Bus キューService Bus queues
スケジュールされた配信Scheduled delivery はいYes はいYes
自動的な配信不能レタリングAutomatic dead lettering いいえNo はいYes
キューの有効期間の増加Increasing queue time-to-live value はいYes

(表示のタイムアウトのインプレース更新を使用)(via in-place update of visibility timeout)
はいYes

(専用の API 関数を使用)(provided via a dedicated API function)
有害なメッセージのサポートPoison message support はいYes はいYes
インプレース更新In-place update はいYes はいYes
サーバー側のトランザクション ログServer-side transaction log はいYes いいえNo
Storage のメトリックStorage metrics はいYes

分単位のメトリック: 可用性、TPS、API 呼び出し数、エラー数、その他のメトリックをすべてリアルタイムで提供します (分単位で集計され、運用環境での発生から数分以内にレポートされます)。Minute Metrics: provides real-time metrics for availability, TPS, API call counts, error counts, and more, all in real time (aggregated per minute and reported within a few minutes from what just happened in production. 詳細については、「Storage Analytics Metrics について」を参照してください。For more information, see About Storage Analytics Metrics.
はいYes

(GetQueues の呼び出しによる一括クエリ)(bulk queries by calling GetQueues)
状態管理State management いいえNo はいYes

Microsoft.ServiceBus.Messaging.EntityStatus.ActiveMicrosoft.ServiceBus.Messaging.EntityStatus.DisabledMicrosoft.ServiceBus.Messaging.EntityStatus.SendDisabledMicrosoft.ServiceBus.Messaging.EntityStatus.ReceiveDisabledMicrosoft.ServiceBus.Messaging.EntityStatus.Active, Microsoft.ServiceBus.Messaging.EntityStatus.Disabled, Microsoft.ServiceBus.Messaging.EntityStatus.SendDisabled, Microsoft.ServiceBus.Messaging.EntityStatus.ReceiveDisabled
メッセージの自動転送Message auto-forwarding いいえNo はいYes
キューの消去機能Purge queue function はいYes いいえNo
メッセージ グループMessage groups いいえNo はいYes

(メッセージング セッションを使用)(through the use of messaging sessions)
メッセージ グループ単位のアプリケーション状態Application state per message group いいえNo はいYes
重複検出Duplicate detection いいえNo はいYes

(送信側で構成可能)(configurable on the sender side)
メッセージ グループの参照Browsing message groups いいえNo はいYes
ID によるメッセージ セッションの取得Fetching message sessions by ID いいえNo はいYes

追加情報Additional information

  • 両方のキュー テクノロジには、メッセージを後で配信するようにスケジュールできる機能があります。Both queuing technologies enable a message to be scheduled for delivery at a later time.
  • キューの自動転送を使用すると、数千のキューのメッセージを 1 つのキューに自動転送して、受信側アプリケーションはそのキューからメッセージを処理することができます。Queue auto-forwarding enables thousands of queues to auto-forward their messages to a single queue, from which the receiving application consumes the message. このメカニズムを使用して、各メッセージ パブリッシャー間でセキュリティの確保、フロー制御、ストレージ分離を実現できます。You can use this mechanism to achieve security, control flow, and isolate storage between each message publisher.
  • Storage キューでは、メッセージの内容の更新がサポートされています。Storage queues provide support for updating message content. この機能を使用すると、状態情報と進行状況の増分更新をメッセージに永続化して、メッセージの処理を最初からではなく前回のチェックポイントから開始することができます。You can use this functionality for persisting state information and incremental progress updates into the message so that it can be processed from the last known checkpoint, instead of starting from scratch. Service Bus キューでは、メッセージ セッションを使用することで同じ機能を実現できます。With Service Bus queues, you can enable the same scenario through the use of message sessions. セッションでは、アプリケーションの処理状態を保存および取得できます (SetState および GetState を使用)。Sessions enable you to save and retrieve the application processing state (by using SetState and GetState).
  • Service Bus キューでのみサポートされている配信不能レタリングは、受信側のアプリケーションで正しく処理できないメッセージを分離する場合や、TTL (time-to-live) プロパティが期限切れになったためにメッセージが宛先に届かない場合に役立ちます。Dead lettering, which is only supported by Service Bus queues, can be useful for isolating messages that cannot be processed successfully by the receiving application or when messages cannot reach their destination due to an expired time-to-live (TTL) property. TTL の値は、メッセージがキューに保持される期間を指定します。The TTL value specifies how long a message remains in the queue. Service Bus では、TTL が期限切れになると、メッセージが $DeadLetterQueue という特殊なキューに移動されます。With Service Bus, the message will be moved to a special queue called $DeadLetterQueue when the TTL period expires.
  • Storage キューで "有害な" メッセージを検出するには、アプリケーションでメッセージをデキューするときにメッセージの DequeueCount プロパティを確認します。To find "poison" messages in Storage queues, when dequeuing a message the application examines the DequeueCount property of the message. DequeueCount が一定のしきい値を超えている場合は、そのメッセージをアプリケーション定義の "配信不能" キューに移動します。If DequeueCount is greater than a given threshold, the application moves the message to an application-defined "dead letter" queue.
  • Storage キューでは、キューに対して実行されたすべてのトランザクションの詳細なログとメトリックの集計値を取得できます。Storage queues enable you to obtain a detailed log of all of the transactions executed against the queue, as well as aggregated metrics. これらのオプションはいずれも、デバッグや、アプリケーションでの Storage キューの使い方を理解するのに役立ちます。Both of these options are useful for debugging and understanding how your application uses Storage queues. また、アプリケーションのパフォーマンス チューニングやキューの使用コストの削減にも役立ちます。They are also useful for performance-tuning your application and reducing the costs of using queues.
  • Service Bus でサポートされている "メッセージ セッション" の概念を使用すると、特定の論理グループに属するメッセージを特定の受信側に関連付けて、メッセージとその受信側の間にセッションのような関係を作成できます。The concept of "message sessions" supported by Service Bus enables messages that belong to a certain logical group to be associated with a given receiver, which in turn creates a session-like affinity between messages and their respective receivers. Service Bus でこの高度な機能を有効にするには、メッセージの SessionID プロパティを設定します。You can enable this advanced functionality in Service Bus by setting the SessionID property on a message. 受信側では、特定のセッション ID をリッスンして、指定したセッション ID を共有するメッセージを受信できます。Receivers can then listen on a specific session ID and receive messages that share the specified session identifier.
  • Service Bus キューでサポートされている重複検出機能により、MessageId プロパティの値に基づいて、キューまたはトピックに送信された重複するメッセージが自動的に削除されます。The duplication detection functionality supported by Service Bus queues automatically removes duplicate messages sent to a queue or topic, based on the value of the MessageId property.

容量およびクォータCapacity and quotas

このセクションでは、容量および適用可能なクォータの観点から Storage キューと Service Bus キューを比較します。This section compares Storage queues and Service Bus queues from the perspective of capacity and quotas that may apply.

比較条件Comparison Criteria Storage キューStorage queues Service Bus キューService Bus queues
最大キュー サイズMaximum queue size 500 TB500 TB

(1 つのストレージ アカウントの容量に制限)(limited to a single storage account capacity)
1 GB ~ 80 GB1 GB to 80 GB

(キューの作成時とパーティション分割を有効化するときに定義します。追加情報セクションをご覧ください)(defined upon creation of a queue and enabling partitioning – see the “Additional Information” section)
最大メッセージ サイズMaximum message size 64 KB64 KB

(Base64 エンコードを使用する場合は 48 KB)(48 KB when using Base64 encoding)

Azure では、キューと BLOB を組み合わせることでサイズの大きいメッセージをサポートし、1 つのアイテムに対して最大 200 GB までのメッセージをエンキューできます。Azure supports large messages by combining queues and blobs – at which point you can enqueue up to 200 GB for a single item.
256 KB1 MB256 KB or 1 MB

(ヘッダーと本文の両方を含む。ヘッダーの最大サイズは 64 KB)(including both header and body, maximum header size: 64 KB).

サービス レベルに依存します。Depends on the service tier.
メッセージの最大 TTLMaximum message TTL 無限 (api-version 2017-07-27 の時点)Infinite (as of api-version 2017-07-27) TimeSpan.MaxTimeSpan.Max
キューの最大数Maximum number of queues 無制限Unlimited 10,00010,000

(サービス名前空間あたり)(per service namespace)
同時クライアントの最大数Maximum number of concurrent clients 無制限Unlimited 無制限Unlimited

(最大 100 の同時接続数の制限は TCP プロトコル ベースの通信にのみ適用されます)(100 concurrent connection limit only applies to TCP protocol-based communication)

追加情報Additional information

  • Service Bus では、キューのサイズが制限されます。Service Bus enforces queue size limits. キューの最大サイズは、キューの作成時に 1 ~ 80 GB の値を指定できます。The maximum queue size is specified upon creation of the queue and can have a value between 1 and 80 GB. キューの作成時に設定したキュー サイズの値に達すると、その後の受信メッセージは拒否され、呼び出し元のコードが例外を受け取ります。If the queue size value set on creation of the queue is reached, additional incoming messages will be rejected and an exception will be received by the calling code. Service Bus でのクォータの詳細情報については、「Service Bus のクォータ」をご覧ください。For more information about quotas in Service Bus, see Service Bus Quotas.
  • パーティション分割は Premium レベルではサポートされていません。Partitioning is not supported in the Premium tier. Standard レベルでは、Service Bus キューを 1 GB、2 GB、3 GB、4 GB、5 GB のサイズで作成できます (既定値は 1 GB)。In the Standard tier, you can create Service Bus queues in 1, 2, 3, 4, or 5 GB sizes (the default is 1 GB). Standard レベルでは、パーティション分割を有効にすると (既定)、Service Bus は指定した各 GB あたり 16 個のパーティションを作成できます。In Standard tier, with partitioning enabled (which is the default), Service Bus creates 16 partitions for each GB you specify. そのため、5 GB のキューを作成すると、16 個のパーティションで、キューの最大サイズは (5 * 16) = 80 GB になります。As such, if you create a queue that is 5 GB in size, with 16 partitions the maximum queue size becomes (5 * 16) = 80 GB. パーティション分割したキューまたはトピックの最大サイズは、Azure Portal の各エントリで確認できます。You can see the maximum size of your partitioned queue or topic by looking at its entry on the Azure portal.
  • Storage キューでは、内容が XML セーフでないメッセージに対しては Base64 エンコードを使用する必要があります。With Storage queues, if the content of the message is not XML-safe, then it must be Base64 encoded. メッセージを Base64 エンコードを使用する場合、ユーザー ペイロードの上限は 64 KB ではなく 48 KB になります。If you Base64-encode the message, the user payload can be up to 48 KB, instead of 64 KB.
  • Service Bus キューでは、キューに格納される各メッセージはヘッダーと本文の 2 つの部分で構成されます。With Service Bus queues, each message stored in a queue is composed of two parts: a header and a body. メッセージの合計サイズが、サービス レベルでサポートされる最大メッセージ サイズを超えることはできません。The total size of the message cannot exceed the maximum message size supported by the service tier.
  • クライアントが TCP プロトコルで Service Bus キューと通信する場合は、1 つの Service Bus キューに対する同時接続の最大数が 100 に制限されます。When clients communicate with Service Bus queues over the TCP protocol, the maximum number of concurrent connections to a single Service Bus queue is limited to 100. この数は送信側と受信側で共有されます。This number is shared between senders and receivers. このクォータに達すると、その後の接続要求は拒否され、呼び出し元のコードが例外を受け取ります。If this quota is reached, subsequent requests for additional connections will be rejected and an exception will be received by the calling code. この制限は、REST ベースの API を使用してキューに接続するクライアントには適用されません。This limit is not imposed on clients connecting to the queues using REST-based API.
  • 1 つの Service Bus Service の名前空間で 10,000 を超える数のキューが必要な場合は、Azure サポート チームに連絡してキューの数を増やすことができます。If you require more than 10,000 queues in a single Service Bus namespace, you can contact the Azure support team and request an increase. Service Bus でキューの数を 10,000 より多くするために、Azure Portal を使用して追加の名前空間を作成することもできます。To scale beyond 10,000 queues with Service Bus, you can also create additional namespaces using the Azure portal.

管理と操作Management and operations

このセクションでは、Storage キューと Service Bus キューで提供される管理機能を比較します。This section compares the management features provided by Storage queues and Service Bus queues.

比較条件Comparison Criteria Storage キューStorage queues Service Bus キューService Bus queues
管理プロトコルManagement protocol HTTP/HTTPS 経由の RESTREST over HTTP/HTTPS HTTPS 経由の RESTREST over HTTPS
ランタイム プロトコルRuntime protocol HTTP/HTTPS 経由の RESTREST over HTTP/HTTPS HTTPS 経由の RESTREST over HTTPS

AMQP 1.0 Standard (TCP と TLS)AMQP 1.0 Standard (TCP with TLS)
.NET API.NET API はいYes

(.NET Storage Client API)(.NET Storage Client API)
はいYes

(.NET Service Bus API)(.NET Service Bus API)
ネイティブ C++Native C++ はいYes はいYes
Java APIJava API はいYes はいYes
PHP APIPHP API はいYes はいYes
Node.js APINode.js API はいYes はいYes
任意のメタデータのサポートArbitrary metadata support はいYes いいえNo
キューの名前付け規則Queue naming rules 最大 63 文字Up to 63 characters long

(キューの名前は小文字で指定する必要があります)(Letters in a queue name must be lowercase.)
最大 260 文字Up to 260 characters long

(キューのパスと名前では大文字と小文字は区別されません)(Queue paths and names are case-insensitive.)
キューの長さを取得する機能Get queue length function はいYes

(メッセージが TTL を過ぎて期限切れになっても削除されていない場合は概算値となります)(Approximate value if messages expire beyond the TTL without being deleted.)
はいYes

(特定の時点の正確な値)(Exact, point-in-time value.)
Peek 機能Peek function はいYes はいYes

追加情報Additional information

  • Storage キューでは、キューの説明に名前と値のペアの形式の任意の属性を適用できます。Storage queues provide support for arbitrary attributes that can be applied to the queue description, in the form of name/value pairs.
  • 両方のキュー テクノロジには、メッセージをロックせずに表示できる機能も用意されています。この機能は、キューのエクスプローラー/ブラウザー ツールを実装する際に便利です。Both queue technologies offer the ability to peek a message without having to lock it, which can be useful when implementing a queue explorer/browser tool.
  • Service Bus の .NET ブローカー メッセージング API は、全二重 TCP 接続を使用して HTTP 経由の REST より高いパフォーマンスを発揮します。また、AMQP 1.0 標準プロトコルもサポートしています。The Service Bus .NET brokered messaging APIs leverage full-duplex TCP connections for improved performance when compared to REST over HTTP, and they support the AMQP 1.0 standard protocol.
  • Storage キューの名前は 3 ~ 63 文字の間で指定でき、小文字、数字、ハイフンを使用できます。Names of Storage queues can be 3-63 characters long, can contain lowercase letters, numbers, and hyphens. 詳細については、「キューおよびメタデータの名前付け」をご覧ください。For more information, see Naming Queues and Metadata.
  • Service Bus のキュー名は最大 260 文字までの長さで指定でき、名前付け規則の制限は厳しくありません。Service Bus queue names can be up to 260 characters long and have less restrictive naming rules. Service Bus のキュー名には、文字、数字、ピリオド、ハイフン、アンダースコアを使用できます。Service Bus queue names can contain letters, numbers, periods, hyphens, and underscores.

認証と権限承認Authentication and authorization

このセクションでは、Storage キューと Service Bus キューでサポートされる認証および承認機能について説明します。This section discusses the authentication and authorization features supported by Storage queues and Service Bus queues.

比較条件Comparison Criteria Storage キューStorage queues Service Bus キューService Bus queues
AuthenticationAuthentication 対称キーSymmetric key 対称キーSymmetric key
セキュリティ モデルSecurity model SAS トークンを介した委任アクセス。Delegated access via SAS tokens. SASSAS
ID プロバイダー フェデレーションIdentity provider federation いいえNo はいYes

追加情報Additional information

  • どちらのキュー テクノロジでも、すべての要求を認証する必要があります。Every request to either of the queuing technologies must be authenticated. 匿名アクセスを使用するパブリック キューはサポートされていません。Public queues with anonymous access are not supported. SAS を使用すると、書き込み専用 SAS、読み取り専用 SAS、フルアクセス SAS を発行することで、このシナリオに対応できます。Using SAS, you can address this scenario by publishing a write-only SAS, read-only SAS, or even a full-access SAS.
  • Storage キューによって提供される認証方式では対称キーが使用されます。対称キーとは、SHA-256 アルゴリズムを使用してコンピューティングされ、Base64 文字列としてエンコードされるハッシュ ベースのメッセージ認証コード (HMAC) です。The authentication scheme provided by Storage queues involves the use of a symmetric key, which is a hash-based Message Authentication Code (HMAC), computed with the SHA-256 algorithm and encoded as a Base64 string. 各プロトコルの詳細情報については、「Azure ストレージ サービスの認証」をご覧ください。For more information about the respective protocol, see Authentication for the Azure Storage Services. Service Bus キューでは、対称キーを使用する類似のモデルをサポートします。Service Bus queues support a similar model using symmetric keys. 詳細については、「Service Bus での共有アクセス署名認証」をご覧ください。For more information, see Shared Access Signature Authentication with Service Bus.

まとめConclusion

2 つのテクノロジをより深く理解することにより、使用するキュー テクノロジとその状況について、より多くの十分な情報を得たうえでの決定を行うことができます。By gaining a deeper understanding of the two technologies, you will be able to make a more informed decision on which queue technology to use, and when. Storage キューと Service Bus キューを使用する状況についての判断は明らかにさまざまな要因に依存します。The decision on when to use Storage queues or Service Bus queues clearly depends on a number of factors. それらの要因がアプリケーションとそのアーキテクチャの個々のニーズに大きく依存している場合もあります。These factors may depend heavily on the individual needs of your application and its architecture. アプリケーションで既に Microsoft Azure のコア機能を使用している場合 (特にサービス間の基本的な通信およびメッセージングや、80 GB を超えるサイズのキューが必要な場合) は、Storage キューを選択できます。If your application already uses the core capabilities of Microsoft Azure, you may prefer to choose Storage queues, especially if you require basic communication and messaging between services or need queues that can be larger than 80 GB in size.

Service Bus キューには高度な機能が数多く用意されているため (セッション、トランザクション、重複検出、自動的な配信不能レタリング、持続性のある発行/サブスクライブの機能など)、ハイブリッド アプリケーションを作成する場合や、アプリケーションでこれらの機能が必要な場合は、Service Bus キューを選択できます。Because Service Bus queues provide a number of advanced features, such as sessions, transactions, duplicate detection, automatic dead-lettering, and durable publish/subscribe capabilities, they may be a preferred choice if you are building a hybrid application or if your application otherwise requires these features.

次の手順Next steps

次の記事では、Storage キューや Service Bus キューの使用に関する詳細情報を提供します。The following articles provide more guidance and information about using Storage queues or Service Bus queues.