Service Bus のキュー、トピック、サブスクリプションService Bus queues, topics, and subscriptions

Microsoft Azure Service Bus は、信頼性の高いメッセージ キュー機能や永続的なパブリッシュ/サブスクライブ メッセージング機能など、クラウドベースのメッセージ指向ミドルウェアの一連のテクノロジをサポートしています。Microsoft Azure Service Bus supports a set of cloud-based, message-oriented middleware technologies including reliable message queuing and durable publish/subscribe messaging. このような "仲介型" メッセージング機能は、分離されたメッセージング機能と考えることができます。これは、Service Bus メッセージング ワークロードを使用するパブリッシュ/サブスクライブ、一時的な切り離し、負荷分散のシナリオをサポートします。These "brokered" messaging capabilities can be thought of as decoupled messaging features that support publish-subscribe, temporal decoupling, and load balancing scenarios using the Service Bus messaging workload. 分離型通信には、クライアントとサーバーを必要に応じて接続し、非同期に操作を実行できるなど多数の利点があります。Decoupled communication has many advantages; for example, clients and servers can connect as needed and perform their operations in an asynchronous fashion.

Service Bus のメッセージング機能の中核を形成するメッセージング エンティティは、キュー、トピックおよびサブスクリプション、ルール/アクション、ルール/アクションです。The messaging entities that form the core of the messaging capabilities in Service Bus are queues, topics and subscriptions, and rules/actions.

キューQueues

キューでは、コンシューマーが競合している場合のメッセージ配信に先入れ先出し法 (FIFO) を使用します。Queues offer First In, First Out (FIFO) message delivery to one or more competing consumers. つまり、受信者は、通常はキューに追加された順序でメッセージを受信して処理します。このとき、1 つのメッセージ コンシューマーだけが、各メッセージを受信して処理します。That is, receivers typically receive and process messages in the order in which they were added to the queue, and only one message consumer receives and processes each message. キューを使用する主な利点は、アプリケーション コンポーネントの "一時的な切り離し" を達成することです。A key benefit of using queues is to achieve "temporal decoupling" of application components. 言い換えると、メッセージはキューに永続的に格納されるため、プロデューサー (送信者) とコンシューマー (受信者) が同時にメッセージを送受信する必要はありません。In other words, the producers (senders) and consumers (receivers) do not have to be sending and receiving messages at the same time, because messages are stored durably in the queue. さらに、プロデューサーは、メッセージの処理と送信を続ける場合、メッセージ コンシューマーからの応答を待つ必要がありません。Furthermore, the producer does not have to wait for a reply from the consumer in order to continue to process and send messages.

関連する利点として "負荷平準化" があります。これにより、プロデューサーとコンシューマーは異なるレートでメッセージを送受信できます。A related benefit is "load leveling," which enables producers and consumers to send and receive messages at different rates. 多くのアプリケーションでは、システム負荷が時間の経過とともに変化しますが、各作業単位に必要な処理時間は通常一定に保たれます。In many applications, the system load varies over time; however, the processing time required for each unit of work is typically constant. 仲介のメッセージ プロデューサーとコンシューマーでキューを使用する場合、コンシューマー側アプリケーションに必要なのは、ピーク時の負荷ではなく平均的な負荷を処理できるようにプロビジョニングしておくことだけです。Intermediating message producers and consumers with a queue means that the consuming application only has to be provisioned to be able to handle average load instead of peak load. キューの深さは、受信の負荷の変化に応じて増減します。The depth of the queue grows and contracts as the incoming load varies. この機能は、アプリケーション負荷への対応に必要なインフラストラクチャに関する費用を直接節約できます。This capability directly saves money with regard to the amount of infrastructure required to service the application load. 負荷の増大に合わせて、キューからの読み取りのためにワーカー プロセスを追加できます。As the load increases, more worker processes can be added to read from the queue. 各メッセージは、ワーカー プロセスの中の 1 つのプロセスによって処理されます。Each message is processed by only one of the worker processes. さらに、このプルベースの負荷分散では、各ワーカー コンピューターがそれぞれ独自の最大レートでメッセージをプルするため、それらのコンピューターの処理能力が異なる場合であっても使用を最適化できます。Furthermore, this pull-based load balancing allows for optimum use of the worker computers even if the worker computers differ with regard to processing power, as they pull messages at their own maximum rate. このパターンは、"競合コンシューマー" パターンと呼ばれることもあります。This pattern is often termed the "competing consumer" pattern.

キューを使用してメッセージ プロデューサーとメッセージ コンシューマーの間を仲介すると、必然的にコンポーネント間の結び付きは緩くなります。Using queues to intermediate between message producers and consumers provides an inherent loose coupling between the components. プロデューサーとコンシューマーは相互に認識しないため、プロデューサーに影響することなく、コンシューマーをアップグレードできます。Because producers and consumers are not aware of each other, a consumer can be upgraded without having any effect on the producer.

キューの作成Create queues

キューは、Azure PortalPowerShellCLI、または Resource Manager テンプレートを使用して作成します。You create queues using the Azure portal, PowerShell, CLI, or Resource Manager templates. その後、QueueClient オブジェクトを使用して、メッセージの送信と受信を行います。You then send and receive messages using a QueueClient object.

キューの簡単な作成方法と、キューに対するメッセージの送信と受信を行う方法については、各メソッドのクイック スタートを参照してください。To quickly learn how to create a queue, then send and receive messages to and from the queue, see the quickstarts for each method. キューの使用方法の詳細なチュートリアルについては、「Service Bus のキューの使用」を参照してください。For a more in-depth tutorial on how to use queues, see Get started with Service Bus queues.

作業用サンプルについては、GitHub の BasicSendReceiveUsingQueueClient サンプルを参照してください。For a working sample, see the BasicSendReceiveUsingQueueClient sample on GitHub.

受信モードReceive modes

Service Bus がメッセージを受信する 2 つの異なるモードを指定できます。ReceiveAndDelete または PeekLock です。You can specify two different modes in which Service Bus receives messages: ReceiveAndDelete or PeekLock. ReceiveAndDelete モードでは、受信は単発の操作です。つまり、Service Bus は要求を受信すると、メッセージを読み取り中としてマークしてアプリケーションに返します。In the ReceiveAndDelete mode, the receive operation is single-shot; that is, when Service Bus receives the request, it marks the message as being consumed and returns it to the application. ReceiveAndDelete モードは最もシンプルなモデルであり、障害発生時にアプリケーション側でメッセージを処理しないことを許容できるシナリオに最適です。ReceiveAndDelete mode is the simplest model and works best for scenarios in which the application can tolerate not processing a message if a failure occurs. このシナリオを理解するために、コンシューマーが受信要求を発行した後で、メッセージを処理する前にクラッシュしたというシナリオを考えてみましょう。To understand this scenario, consider a scenario in which the consumer issues the receive request and then crashes before processing it. Service Bus がメッセージを読み取り中としてマークするため、アプリケーションは、再起動してメッセージの読み取りを再開すると、クラッシュ前に読み取られていたメッセージを見落とすことになります。Because Service Bus marks the message as being consumed, when the application restarts and begins consuming messages again, it will have missed the message that was consumed prior to the crash.

PeekLock モードでは、メッセージの受信処理は 2 段階になります。これにより、メッセージが失われることを許容できないアプリケーションに対応することができます。In PeekLock mode, the receive operation becomes two-stage, which makes it possible to support applications that cannot tolerate missing messages. Service Bus は要求を受け取ると、次に読み取られるメッセージを検索して、他のコンシューマーが受信できないようロックしてから、アプリケーションにそのメッセージを返します。When Service Bus receives the request, it finds the next message to be consumed, locks it to prevent other consumers from receiving it, and then returns it to the application. アプリケーションがメッセージの処理を終えた後 (または後で処理するために確実に保存した後)、受信したメッセージに対して CompleteAsync を呼び出して受信処理の第 2 段階を完了します。After the application finishes processing the message (or stores it reliably for future processing), it completes the second stage of the receive process by calling CompleteAsync on the received message. Service Bus は、CompleteAsync の呼び出しを確認すると、メッセージを読み取り済みとしてマークします。When Service Bus sees the CompleteAsync call, it marks the message as being consumed.

アプリケーションがなんらかの理由によってメッセージを処理できない場合には、受信したメッセージに対して (CompleteAsync の代わりに) AbandonAsync メソッドを呼び出すことができます。If the application is unable to process the message for some reason, it can call the AbandonAsync method on the received message (instead of CompleteAsync). このメソッドが呼び出されると、Service Bus によってメッセージのロックが解除され、同じコンシューマーまたは競合する別のコンシューマーが再度そのメッセージを受信できるようになります。This method enables Service Bus to unlock the message and make it available to be received again, either by the same consumer or by another competing consumer. 第二に、ロックに関連付けられたタイムアウトがあります。アプリケーションがクラッシュした場合など、ロックがタイムアウトになる前にアプリケーションがメッセージの処理に失敗した場合は、Service Bus によってメッセージのロックが解除され、再度受信できるようになります (基本的に既定で AbandonAsync 操作を実行します)。Secondly, there is a timeout associated with the lock and if the application fails to process the message before the lock timeout expires (for example, if the application crashes), then Service Bus unlocks the message and makes it available to be received again (essentially performing an AbandonAsync operation by default).

メッセージが処理された後、CompleteAsync 要求が発行される前にアプリケーションがクラッシュした場合は、アプリケーションが再起動する際にメッセージが再配信されます。In the event that the application crashes after processing the message, but before the CompleteAsync request is issued, the message is redelivered to the application when it restarts. 多くの場合、このプロセスは "少なくとも 1 回" の処理と呼ばれます。つまり、各メッセージは少なくとも 1 回は処理されますが、This process is often called At Least Once processing; that is, each message is processed at least once. 特定の状況では、同じメッセージが再配信される可能性があります。However, in certain situations the same message may be redelivered. 重複した処理を許容できないシナリオでは、メッセージの MessageId プロパティに基づいて実現可能な重複を検出するための追加のロジックがアプリケーションで必要になります。このプロパティはメッセージが再配信されても変わりません。If the scenario cannot tolerate duplicate processing, then additional logic is required in the application to detect duplicates, which can be achieved based upon the MessageId property of the message, which remains constant across delivery attempts. この機能は "厳密に 1 回" の処理と呼ばれます。This feature is known as Exactly Once processing.

トピックとサブスクリプションTopics and subscriptions

各メッセージが 1 つのコンシューマーによって処理されるキューとは異なり、"トピック" と "サブスクリプション" では、"パブリッシュ/サブスクライブ" パターンを使用した 1 対多形式の通信が行われます。In contrast to queues, in which each message is processed by a single consumer, topics and subscriptions provide a one-to-many form of communication, in a publish/subscribe pattern. パブリッシュされた各メッセージは、これは多数の受信者を対象とする場合に便利であり、トピックに登録している各サブスクリプションで使用できます。Useful for scaling to large numbers of recipients, each published message is made available to each subscription registered with the topic. メッセージは、トピックに送信された後、サブスクリプションごとに設定できるフィルター規則に基づいて、関連付けられている 1 つ以上のサブスクリプションに配信されます。Messages are sent to a topic and delivered to one or more associated subscriptions, depending on filter rules that can be set on a per-subscription basis. サブスクリプションでは、追加のフィルターを使用して、受信するメッセージを限定できます。The subscriptions can use additional filters to restrict the messages that they want to receive. メッセージは、キューに送信される場合と同じようにトピックに送信されますが、トピックからメッセージを直接受信することはありません。Messages are sent to a topic in the same way they are sent to a queue, but messages are not received from the topic directly. 代わりに、メッセージはサブスクリプションから受信します。Instead, they are received from subscriptions. トピック サブスクリプションは、トピックに送信されたメッセージのコピーを受け取る仮想キューのようなものです。A topic subscription resembles a virtual queue that receives copies of the messages that are sent to the topic. メッセージは、キューから受信する場合と同じ方法でサブスクリプションから受信します。Messages are received from a subscription identically to the way they are received from a queue.

比較として、キューのメッセージ送信機能はそのままトピックに相当し、メッセージ受信機能はサブスクリプションに相当します。By way of comparison, the message-sending functionality of a queue maps directly to a topic and its message-receiving functionality maps to a subscription. 特に、この機能は、サブスクリプションでは、競合コンシューマー、一時的な切り離し、負荷平滑化、負荷分散など、キューに関してこのセクションで既に説明したのと同じパターンがサポートされることを意味します。Among other things, this feature means that subscriptions support the same patterns described earlier in this section with regard to queues: competing consumer, temporal decoupling, load leveling, and load balancing.

トピックとサブスクリプションを作成するCreate topics and subscriptions

トピックの作成は、前のセクションで説明したキューの作成と似ています。Creating a topic is similar to creating a queue, as described in the previous section. メッセージの送信は、TopicClient クラスを使用して行います。You then send messages using the TopicClient class. メッセージを受信するには、トピックに対して 1 つまたは複数のサブスクリプションを作成します。To receive messages, you create one or more subscriptions to the topic. キューの場合に似ていますが、QueueClient オブジェクトの代わりに SubscriptionClient オブジェクトを使用して、サブスクリプションからメッセージを受信します。Similar to queues, messages are received from a subscription using a SubscriptionClient object instead of a QueueClient object. サブスクリプション クライアントを作成し、トピックの名前とサブスクリプションの名前、さらに必要に応じて受信モードをパラメーターとして渡します。Create the subscription client, passing the name of the topic, the name of the subscription, and (optionally) the receive mode as parameters.

完全な作業用サンプルについては、GitHub の BasicSendReceiveUsingTopicSubscriptionClient サンプルを参照してください。For a full working example, see the BasicSendReceiveUsingTopicSubscriptionClient sample on GitHub.

ルールとアクションRules and actions

多くのシナリオでは、特性のあるメッセージは、異なる方法で処理する必要があります。In many scenarios, messages that have specific characteristics must be processed in different ways. この処理を実現するために、目的のプロパティを持つメッセージを検索し、該当するプロパティに特定の変更を行うようにサブスクリプションを構成できます。To enable this processing, you can configure subscriptions to find messages that have desired properties and then perform certain modifications to those properties. Service Bus のサブスクリプションには、トピックに送信されたすべてのメッセージが表示されますが、仮想サブスクリプション キューにコピーできるのは、これらのメッセージの一部のみです。While Service Bus subscriptions see all messages sent to the topic, you can only copy a subset of those messages to the virtual subscription queue. このフィルター処理を行うには、サブスクリプション フィルターを使用します。This filtering is accomplished using subscription filters. このような変更は、"フィルター アクション" と呼ばれます。Such modifications are called filter actions. サブスクリプションを作成する場合、メッセージのシステム プロパティ (Label など) とカスタム アプリケーション プロパティ (StoreName など) の両方で機能するフィルター式を指定できます。この場合、SQL フィルター式は省略可能です。SQL フィルター式を指定しない場合は、サブスクリプションで定義されている任意のフィルター アクションが、そのサブスクリプションのすべてのメッセージに対して実行されます。When a subscription is created, you can supply a filter expression that operates on the properties of the message, both the system properties (for example, Label) and custom application properties (for example, StoreName.) The SQL filter expression is optional in this case; without a SQL filter expression, any filter action defined on a subscription will be performed on all the messages for that subscription.

完全な作業用サンプルについては、GitHub の TopicSubscriptionWithRuleOperationsSample サンプルを参照してください。For a full working example, see the TopicSubscriptionWithRuleOperationsSample sample on GitHub.

使用可能なフィルター値の詳細については、SqlFilter クラスと SqlRuleAction クラスのドキュメントを参照してください。For more information about possible filter values, see the documentation for the SqlFilter and SqlRuleAction classes.

次の手順Next steps

Service Bus のメッセージングの詳細と使用例については、次の詳細トピックをご覧ください。For more information and examples of using Service Bus messaging, see the following advanced topics: