パーティション分割されたキューとトピックPartitioned queues and topics

Azure Service Bus では、メッセージを処理する複数のメッセージ ブローカーとメッセージを格納する複数のメッセージング ストアを採用しています。Azure Service Bus employs multiple message brokers to process messages and multiple messaging stores to store messages. 従来のキューまたはトピックは、単一のメッセージ ブローカーで処理されて 1 つのメッセージング ストアに格納されます。A conventional queue or topic is handled by a single message broker and stored in one messaging store. Service Bus "パーティション" では、キューとトピック、つまり "メッセージング エンティティ" を複数のメッセージ ブローカーとメッセージング ストアにパーティション分割することもできます。Service Bus partitions enable queues and topics, or messaging entities, to be partitioned across multiple message brokers and messaging stores. パーティション分割は、パーティション分割されたエンティティの全体のスループットが、単一のメッセージ ブローカーまたはメッセージング ストアのパフォーマンスによって制限されなくなることを意味します。Partitioning means that the overall throughput of a partitioned entity is no longer limited by the performance of a single message broker or messaging store. また、1 つのメッセージング ストアが一時的に停止しても、パーティション分割されたキューまたはトピックは使用することができます。In addition, a temporary outage of a messaging store does not render a partitioned queue or topic unavailable. パーティション分割されたキューとトピックには、トランザクションやセッションのサポートなど、あらゆる高度な Service Bus 機能を含めることができます。Partitioned queues and topics can contain all advanced Service Bus features, such as support for transactions and sessions.

注意

パーティション分割は、Basic または Standard SKU のすべてのキューおよびトピックに対するエンティティの作成で使用できます。Partitioning is available at entity creation for all queues and topics in Basic or Standard SKUs. Premium メッセージング SKU では使用できませんが、Premium 名前空間のパーティション分割された既存のエンティティは継続して正常に動作します。It is not available for the Premium messaging SKU, but any previously existing partitioned entities in Premium namespaces continue to work as expected.

既存のキューまたはトピックでパーティション分割のオプションを変更することはできません。このオプションを設定できるのはエンティティの作成時のみです。It is not possible to change the partitioning option on any existing queue or topic; you can only set the option when you create the entity.

動作のしくみHow it works

パーティション分割されたキューまたはトピックはそれぞれ、複数のパーティションで構成されます。Each partitioned queue or topic consists of multiple partitions. パーティションはそれぞれ別々のメッセージング ストアに格納され、別々のメッセージ ブローカーで処理されます。Each partition is stored in a different messaging store and handled by a different message broker. パーティション分割されたキューまたはトピックにメッセージが送信されると、Service Bus はそのメッセージをいずれかのパーティションに割り当てます。When a message is sent to a partitioned queue or topic, Service Bus assigns the message to one of the partitions. 対象のフラグメントは、Service Bus によってランダムに選択されるか、送信側で指定できるパーティション キーによって選択されます。The selection is done randomly by Service Bus or by using a partition key that the sender can specify.

クライアントがパーティション分割されたキューからのメッセージまたはサブスクリプションからパーティション分割されたトピックへのメッセージを受信する場合、Service Bus はすべてのパーティションを照会してメッセージを探し、いずれかのメッセージング ストアから取得された最初のメッセージを受信側に返します。When a client wants to receive a message from a partitioned queue, or from a subscription to a partitioned topic, Service Bus queries all partitions for messages, then returns the first message that is obtained from any of the messaging stores to the receiver. Service Bus は、追加の受信要求を受信すると、他のメッセージをキャッシュして返します。Service Bus caches the other messages and returns them when it receives additional receive requests. 受信側クライアントはパーティション分割を認識しません。パーティション分割されたキューやトピックの動作 (読み込み、完了、遅延、配信不能、プリフェッチなど) は、クライアント側には通常のエンティティの動作と同じに見えます。A receiving client is not aware of the partitioning; the client-facing behavior of a partitioned queue or topic (for example, read, complete, defer, deadletter, prefetching) is identical to the behavior of a regular entity.

パーティション分割されたキューやトピックとのメッセージの送受信に追加費用は発生しません。There is no additional cost when sending a message to, or receiving a message from, a partitioned queue or topic.

パーティション分割の有効化Enable partitioning

Azure Service Bus でパーティション分割されたキューとトピックを使用するには、Azure SDK Version 2.2 以降を使用するか、HTTP 要求で api-version=2013-10 以降を指定します。To use partitioned queues and topics with Azure Service Bus, use the Azure SDK version 2.2 or later, or specify api-version=2013-10 or later in your HTTP requests.

StandardStandard

Standard メッセージング レベルでは、Service Bus キューおよびトピックは、1 GB、2 GB、3 GB、4 GB、5 GB で作成できます (既定値は 1 GB)。In the Standard messaging tier, you can create Service Bus queues and topics in 1, 2, 3, 4, or 5-GB sizes (the default is 1 GB). パーティション分割が有効な場合、Service Bus は指定されたサイズごとにエンティティの 16 個のコピー (16 個のパーティション) を作成します。With partitioning enabled, Service Bus creates 16 copies (16 partitions) of the entity, each of the same size specified. そのため、サイズが 5 GB のキューを作成すると、パーティションが 16 個であるため、最大キュー サイズは 5 * 16 = 80 GB になります。As such, if you create a queue that's 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, in the Overview blade for that entity.

PremiumPremium

Premium レベルの名前空間では、エンティティのパーティション分割はサポートされていません。In a Premium tier namespace, partitioning entities are not supported. ただし、Service Bus のキューとトピックは、1 GB、2 GB、3 GB、4 GB、5 GB、10 GB、20 GB、40 GB、80 GB で引き続き作成できます (既定値は 1 GB)。However, you can still create Service Bus queues and topics in 1, 2, 3, 4, 5, 10, 20, 40, or 80-GB sizes (the default is 1 GB). キューまたはトピックのサイズは、Azure portal のそのエンティティの [概要] ブレードで確認できます。You can see the size of your queue or topic by looking at its entry on the Azure portal, in the Overview blade for that entity.

パーティション分割されたエンティティを作成するCreate a partitioned entity

パーティション分割されたキューまたはトピックを作成する方法は複数あります。There are several ways to create a partitioned queue or topic. ご使用のアプリケーションからキューまたはトピックを作成する際に、QueueDescription.EnablePartitioning プロパティまたは TopicDescription.EnablePartitioning プロパティをそれぞれ true に設定することで、キューまたはトピックのパーティション分割を有効にできます。When you create the queue or topic from your application, you can enable partitioning for the queue or topic by respectively setting the QueueDescription.EnablePartitioning or TopicDescription.EnablePartitioning property to true. これらのプロパティは、キューまたはトピックが作成された時点で設定される必要があり、従来の WindowsAzure.ServiceBus ライブラリのみで使用できます。These properties must be set at the time the queue or topic is created, and are available only in the older WindowsAzure.ServiceBus library. 既に説明したように、既存のキューまたはトピックでこれらのプロパティを変更することはできません。As stated previously, it is not possible to change these properties on an existing queue or topic. 例:For example:

// Create partitioned topic
NamespaceManager ns = NamespaceManager.CreateFromConnectionString(myConnectionString);
TopicDescription td = new TopicDescription(TopicName);
td.EnablePartitioning = true;
ns.CreateTopic(td);

また、Azure portal で、パーティション分割されたキューまたはトピックを作成することもできます。Alternatively, you can create a partitioned queue or topic in the Azure portal. ポータルでキューまたはトピックを作成する場合は、キューまたはトピックの [作成] ダイアログ ボックスにある [パーティション分割の有効化] オプションが既定でオンになっています。When you create a queue or topic in the portal, the Enable partitioning option in the queue or topic Create dialog box is checked by default. このオプションを無効にできるのは Standard レベルのエンティティのみです。Premium レベルでは、パーティション分割はサポートされておらず、チェック ボックスは無効です。You can only disable this option in a Standard tier entity; in the Premium tier partitioning is not supported, and the checkbox has no effect.

パーティション キーの使用Use of partition keys

パーティション分割されたキューまたはトピックにメッセージがエンキューされると、Service Bus はパーティション キーが存在するかどうかを調べます。When a message is enqueued into a partitioned queue or topic, Service Bus checks for the presence of a partition key. パーティション キーが見つかった場合は、そのキーに基づいてパーティションを選択します。If it finds one, it selects the partition based on that key. パーティション キーが見つからない場合は、内部アルゴリズムに基づいてパーティションを選択します。If it does not find a partition key, it selects the partition based on an internal algorithm.

パーティション キーを使用する場合Using a partition key

セッションやトランザクションなどの一部のシナリオでは、メッセージを特定のパーティションに格納する必要があります。Some scenarios, such as sessions or transactions, require messages to be stored in a specific partition. このようなシナリオでは必ず、パーティション キーを使用する必要があります。All these scenarios require the use of a partition key. 同じパーティション キーを使用するメッセージはすべて、同じパーティションに割り当てられます。All messages that use the same partition key are assigned to the same partition. そのパーティションが一時的に使用できなくなると、Service Bus はエラーを返します。If the partition is temporarily unavailable, Service Bus returns an error.

以下に示すように、シナリオに応じて、さまざまなメッセージ プロパティがパーティション キーとして使用されます。Depending on the scenario, different message properties are used as a partition key:

SessionId: メッセージに SessionId プロパティが設定されている場合、Service Bus はパーティション キーとして SessionID を使用します。SessionId: If a message has the SessionId property set, then Service Bus uses SessionID as the partition key. このように、同じセッションに属するメッセージはすべて、同じメッセージ ブローカーによって処理されます。This way, all messages that belong to the same session are handled by the same message broker. セッションでは、Service Bus はメッセージの順序と、セッション状態の整合性を保証することができます。Sessions enable Service Bus to guarantee message ordering as well as the consistency of session states.

PartitionKey:メッセージに PartitionKey プロパティは設定されているが、SessionId プロパティは設定されていない場合、Service Bus は PartitionKey プロパティ値をパーティション キーとして使用します。PartitionKey: If a message has the PartitionKey property but not the SessionId property set, then Service Bus uses the PartitionKey property value as the partition key. メッセージで SessionId プロパティと PartitionKey プロパティが両方とも設定されている場合、この 2 つのプロパティの値は同じである必要があります。If the message has both the SessionId and the PartitionKey properties set, both properties must be identical. PartitionKey プロパティが SessionId プロパティとは異なる値に設定されている場合、Service Bus は無効操作例外を返します。If the PartitionKey property is set to a different value than the SessionId property, Service Bus returns an invalid operation exception. セッションを認識しないトランザクション メッセージを送信側が送信する場合は、PartitionKey プロパティを使用する必要があります。The PartitionKey property should be used if a sender sends non-session aware transactional messages. パーティション キーを使用することにより、トランザクション内で送信されるすべてのメッセージを同じメッセージング ブローカーで処理することができます。The partition key ensures that all messages that are sent within a transaction are handled by the same messaging broker.

MessageId: キューまたはトピックで RequiresDuplicateDetection プロパティが true に設定され、SessionId プロパティまたは PartitionKey プロパティが設定されていない場合は、MessageId プロパティ値がパーティション キーとしての役割を果たします。MessageId: If the queue or topic has the RequiresDuplicateDetection property set to true and the SessionId or PartitionKey properties are not set, then the MessageId property value serves as the partition key. (送信元のアプリケーションでメッセージ ID が割り当てられていない場合は、Microsoft .NET および AMQP のライブラリで自動的に割り当てられます)。この場合は、同じメッセージのすべてのコピーが同じメッセージ ブローカーによって処理されます。(The Microsoft .NET and AMQP libraries automatically assign a message ID if the sending application does not.) In this case, all copies of the same message are handled by the same message broker. この ID により、Service Bus は重複したメッセージの検出と削除ができるようになります。This ID enables Service Bus to detect and eliminate duplicate messages. RequiresDuplicateDetection プロパティが true に設定されていない場合、Service Bus は MessageId プロパティをパーティション キーと見なしません。If the RequiresDuplicateDetection property is not set to true, Service Bus does not consider the MessageId property as a partition key.

パーティション キーを使用しない場合Not using a partition key

パーティション キーが存在しない場合、Service Bus は、ラウンドロビン方式で、パーティション分割されたキューまたはトピックのすべてのパーティションにメッセージを配信します。In the absence of a partition key, Service Bus distributes messages in a round-robin fashion to all the partitions of the partitioned queue or topic. 選択されたパーティションが使用できない場合、Service Bus はメッセージを別のパーティションに割り当てます。If the chosen partition is not available, Service Bus assigns the message to a different partition. このように、メッセージング ストアが一時的に使用できなくても送信操作は成功します。This way, the send operation succeeds despite the temporary unavailability of a messaging store. ただし、パーティション キーで提供される保証された順序にはなりません。However, you will not achieve the guaranteed ordering that a partition key provides.

可用性 (パーティション キーなし) と一貫性 (パーティション キーを使用) の間のトレードオフの詳細については、こちらの記事を参照してください。For a more in-depth discussion of the tradeoff between availability (no partition key) and consistency (using a partition key), see this article. この情報は、パーティション分割された Service Bus エンティティにも同様に適用されます。This information applies equally to partitioned Service Bus entities.

Service Bus が別のパーティションにメッセージをエンキューする時間を確保するには、メッセージの送信元のクライアントによって指定される OperationTimeout 値が 15 秒を超える必要があります。To give Service Bus enough time to enqueue the message into a different partition, the OperationTimeout value specified by the client that sends the message must be greater than 15 seconds. OperationTimeout プロパティを既定値の 60 秒に設定することをお勧めします。It is recommended that you set the OperationTimeout property to the default value of 60 seconds.

パーティション キーは、メッセージを特定のパーティションに "ピン留め" します。A partition key "pins" a message to a specific partition. このパーティションを保持しているメッセージング ストアを使用できない場合、Service Bus はエラーを返します。If the messaging store that holds this partition is unavailable, Service Bus returns an error. パーティション キーが存在しない場合、Service Bus は異なるパーティションを選択できるので、操作は成功します。In the absence of a partition key, Service Bus can choose a different partition and the operation succeeds. したがって、パーティション キーが必要でない場合は、パーティション キーを指定しないことをお勧めします。Therefore, it is recommended that you do not supply a partition key unless it is required.

高度なトピック: パーティション分割されたエンティティでのトランザクションの使用Advanced topics: use transactions with partitioned entities

トランザクションの一部として送信されるメッセージでは、パーティション キーを指定する必要があります。Messages that are sent as part of a transaction must specify a partition key. キーは次のプロパティのいずれかです: SessionIdPartitionKey、または MessageIdThe key can be one of the following properties: SessionId, PartitionKey, or MessageId. 同じトランザクションの一部として送信されるすべてのメッセージで、同じパーティション キーを指定する必要があります。All messages that are sent as part of the same transaction must specify the same partition key. トランザクション内でパーティション キーなしのメッセージを送信しようとすると、Service Bus は無効操作例外を返します。If you attempt to send a message without a partition key within a transaction, Service Bus returns an invalid operation exception. 同じトランザクション内で異なるパーティション キーを持つ複数のメッセージを送信しようとすると、Service Bus は無効操作例外を返します。If you attempt to send multiple messages within the same transaction that have different partition keys, Service Bus returns an invalid operation exception. 例:For example:

CommittableTransaction committableTransaction = new CommittableTransaction();
using (TransactionScope ts = new TransactionScope(committableTransaction))
{
    Message msg = new Message("This is a message");
    msg.PartitionKey = "myPartitionKey";
    messageSender.SendAsync(msg); 
    ts.CompleteAsync();
}
committableTransaction.Commit();

パーティション キーとなるプロパティが設定されている場合、Service Bus はメッセージを特定のパーティションに "ピン留め" します。If any of the properties that serve as a partition key are set, Service Bus pins the message to a specific partition. この動作は、トランザクションが使用されているかどうかにかかわらず起こります。This behavior occurs whether or not a transaction is used. 必要でない限り、パーティション キーを指定しないことをお勧めします。It is recommended that you do not specify a partition key if it is not necessary.

パーティション分割されたエンティティでのセッションの使用Using sessions with partitioned entities

トランザクション メッセージを、セッションを認識するトピックまたはキューに送信するには、メッセージに SessionId プロパティが設定されている必要があります。To send a transactional message to a session-aware topic or queue, the message must have the SessionId property set. PartitionKey プロパティも指定されている場合は、このプロパティの値が SessionId プロパティの値と同じである必要があります。If the PartitionKey property is specified as well, it must be identical to the SessionId property. これらが異なる場合、Service Bus は無効操作例外を返します。If they differ, Service Bus returns an invalid operation exception.

通常の (パーティション分割されていない) キューまたはトピックと異なり、単一のトランザクションを使用して複数のメッセージを別々のセッションに送信することはできません。Unlike regular (non-partitioned) queues or topics, it is not possible to use a single transaction to send multiple messages to different sessions. これを試みると、Service Bus は無効操作例外を返します。If attempted, Service Bus returns an invalid operation exception. 例:For example:

CommittableTransaction committableTransaction = new CommittableTransaction();
using (TransactionScope ts = new TransactionScope(committableTransaction))
{
    Message msg = new Message("This is a message");
    msg.SessionId = "mySession";
    messageSender.SendAsync(msg); 
    ts.CompleteAsync();
}
committableTransaction.Commit();

パーティション分割されたエンティティでのメッセージの自動転送Automatic message forwarding with partitioned entities

Service Bus では、パーティション分割されたエンティティを送信元または送信先とするメッセージの自動転送、およびパーティション分割されたエンティティ間でのメッセージの自動転送をサポートしています。Service Bus supports automatic message forwarding from, to, or between partitioned entities. メッセージの自動転送を有効にするには、ソース キューまたはサブスクリプションで QueueDescription.ForwardTo プロパティを設定する必要があります。To enable automatic message forwarding, set the QueueDescription.ForwardTo property on the source queue or subscription. メッセージでパーティション キー (SessionIdPartitionKeyMessageId) が指定されている場合、そのパーティション キーが出力先エンティティで使用されます。If the message specifies a partition key (SessionId, PartitionKey, or MessageId), that partition key is used for the destination entity.

考慮事項とガイドラインConsiderations and guidelines

  • 高い整合性機能: パーティション キーの明示的制御、重複データ検出、セッションといった機能が使用されるエンティティの場合、メッセージング操作は常に特定のパーティションにルーティングされます。High consistency features: If an entity uses features such as sessions, duplicate detection, or explicit control of partitioning key, then the messaging operations are always routed to specific partition. いずれかのパーティションにトラフィックが集中した場合や、基になるストアに異常が生じた場合、それらの操作は失敗し、可用性が低下します。If any of the partitions experience high traffic or the underlying store is unhealthy, those operations fail and availability is reduced. それでも全体として堅牢性は、パーティション分割されていないエンティティと比べれば、はるかに高くなります。問題が発生するのはトラフィックの一部だけです。すべてのトラフィックで問題が発生するわけではありません。Overall, the consistency is still much higher than non-partitioned entities; only a subset of traffic is experiencing issues, as opposed to all the traffic. 詳細については、「Event Hubs における可用性と一貫性」を参照してください。For more information, see this discussion of availability and consistency.
  • 管理: 作成、更新、削除といった操作は、エンティティのすべてのパーティションに対して実行する必要があります。Management: Operations such as Create, Update, and Delete must be performed on all the partitions of the entity. 異常のあるパーティションが 1 つでもあると、それらの操作は失敗します。If any partition is unhealthy, it could result in failures for these operations. Get 操作に関して言えば、メッセージ数などの情報は、全パーティションから集計する必要があります。For the Get operation, information such as message counts must be aggregated from all partitions. いずれかのパーティションに異常があった場合、そのエンティティの可用性ステータスは "制限あり" として報告されます。If any partition is unhealthy, the entity availability status is reported as limited.
  • 低量メッセージのシナリオ: このようなシナリオの場合、特に HTTP プロトコルの使用時には、すべてのメッセージを取得するために、複数の受信操作を実行する必要が生じることがあります。Low volume message scenarios: For such scenarios, especially when using the HTTP protocol, you may have to perform multiple receive operations in order to obtain all the messages. 受信要求の場合、フロント エンドは、すべてのパーティションを受信し、返されたすべての応答をキャッシュします。For receive requests, the front end performs a receive on all the partitions and caches all the responses received. 以降、同じ接続上で行われる受信要求でこのキャッシュを利用できるため、受信で発生する遅延は小さくなります。A subsequent receive request on the same connection would benefit from this caching and receive latencies will be lower. ただし複数の接続が存在する場合や、HTTP を使用している場合は、要求ごとに新しい接続が確立されます。However, if you have multiple connections or use HTTP, that establishes a new connection for each request. そのため、要求元と同じノードに応答が届く保証はありません。As such, there is no guarantee that it would land on the same node. 既存のメッセージがすべてロックされ、別のフロント エンドでキャッシュされている場合は、受信操作から nullが返されます。If all existing messages are locked and cached in another front end, the receive operation returns null. 最終的にはメッセージの有効期限が切れ、再度受信できる状態になります。Messages eventually expire and you can receive them again. HTTP キープアライブの使用をお勧めします。HTTP keep-alive is recommended.
  • メッセージの参照/ピーク: 従来の WindowsAzure.ServiceBus ライブラリでのみ使用可能です。Browse/Peek messages: Available only in the older WindowsAzure.ServiceBus library. PeekBatch は、必ずしも MessageCount プロパティに指定された数のメッセージを返すとは限りません。PeekBatch does not always return the number of messages specified in the MessageCount property. 一般に、この動作には 2 つの理由があります。There are two common reasons for this behavior. 1 つ目は、メッセージのコレクションの総サイズが、最大サイズである 256 KB を超えていることです。One reason is that the aggregated size of the collection of messages exceeds the maximum size of 256 KB. 2 つ目は、キューまたはトピックの EnablePartitioning プロパティtrue に設定されている場合に、要求されたメッセージ数を満たすだけのメッセージがパーティションにない可能性があります。Another reason is that if the queue or topic has the EnablePartitioning property set to true, a partition may not have enough messages to complete the requested number of messages. 通常、アプリケーションは、決まった数のメッセージを受信する必要がある場合、そのメッセージ数に達するまで、または読み取るメッセージがなくなるまで、PeekBatch を繰り返し呼び出す必要があります。In general, if an application wants to receive a specific number of messages, it should call PeekBatch repeatedly until it gets that number of messages, or there are no more messages to peek. コード サンプルを含む詳細については、QueueClient.PeekBatch または SubscriptionClient.PeekBatch に関する API ドキュメントをご覧ください。For more information, including code samples, see the QueueClient.PeekBatch or SubscriptionClient.PeekBatch API documentation.

最近追加された機能Latest added features

パーティション分割されたエンティティの制限事項Partitioned entities limitations

現在、Service Bus は、パーティション分割されたキューまたはトピックに以下の制限を適用します。Currently Service Bus imposes the following limitations on partitioned queues and topics:

  • Premium メッセージング レベルでは、パーティション分割されたキューとトピックをサポートしていません。Partitioned queues and topics are not supported in the Premium messaging tier. セッションは、SessionId を使用することで Premier レベルでサポートされます。Sessions are supported in the premier tier by using SessionId.
  • パーティション分割されたキューまたはトピックは、単一のトランザクションの別々のセッションに属するメッセージの送信はサポートしていません。Partitioned queues and topics do not support sending messages that belong to different sessions in a single transaction.
  • Service Bus は、現在、名前空間あたり最大 100 のパーティション分割されたキューまたはトピックをサポートします。Service Bus currently allows up to 100 partitioned queues or topics per namespace. パーティション分割された各キューまたはトピックは、名前空間あたり 10,000 エンティティのクォータに対してカウントされます (Premium レベルには適用されません)。Each partitioned queue or topic counts towards the quota of 10,000 entities per namespace (does not apply to Premium tier).

次の手順Next steps

AMQP 1.0 プロトコル ガイドで、AMQP 1.0 メッセージング仕様の核となる概念を確認します。Read about the core concepts of the AMQP 1.0 messaging specification in the AMQP 1.0 protocol guide.