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

Azure Service Bus は、信頼性の高いメッセージ キュー機能や永続的なパブリッシュ/サブスクライブ メッセージング機能など、クラウドベースのメッセージ指向ミドルウェアの一連のテクノロジをサポートしています。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 do 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. つまり、受信者は、通常はキューに追加された順序でメッセージを受信して処理します。That is, receivers typically receive and process messages in the order in which they were added to the queue. そして、1 つのメッセージ コンシューマーだけが、各メッセージを受信して処理します。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) don't have to send and receive messages at the same time. これは、メッセージが永続的にキューに格納されているためです。That's because messages are stored durably in the queue. さらに、プロデューサーは、メッセージの処理と送信を続ける場合、コンシューマーからの応答を待つ必要がありません。Furthermore, the producer doesn't have to wait for a reply from the consumer 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 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 best use of the worker computers even if the worker computers with processing power 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 aren't aware of each other, a consumer can be upgraded without having any effect on the producer.

キューの作成Create queues

キューは、Azure portalPowerShellCLI、または Resource Manager テンプレートを使用して作成できます。You can create queues using the Azure portal, PowerShell, CLI, or Resource Manager templates. 次に、C#JavaPythonJavaScriptPHP、および Ruby で記述されたクライアントを使用して、メッセージを送受信します。Then, send and receive messages using clients written in C#, Java, Python, JavaScript, PHP, and Ruby.

受信モードReceive modes

Service Bus がメッセージを受信する 2 つの異なるモードを指定できます。You can specify two different modes in which Service Bus receives messages.

  • 受信して削除Receive and delete. このモードでは、コンシューマーからの要求が Service Bus に到達すると、メッセージが読み取り中としてマークされ、コンシューマー アプリケーションに返されます。In this mode, when Service Bus receives the request from the consumer, it marks the message as being consumed and returns it to the consumer application. このモードは最もシンプルなモデルです。This mode is the simplest model. これは障害発生時にアプリケーション側でメッセージを処理しないことを許容できるシナリオに最適です。It 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 がメッセージを読み取り中としてマークすると、アプリケーションは再起動時にメッセージの消費を開始します。As Service Bus marks the message as being consumed, the application begins consuming messages upon restart. クラッシュ前に読み取られたメッセージは見逃してしまいます。It will miss the message that it consumed before the crash.
  • ピーク ロックPeek lock. このモードでは、受信処理は 2 段階になります。これにより、メッセージが失われることを許容できないアプリケーションに対応することができます。In this mode, the receive operation becomes two-stage, which makes it possible to support applications that can't tolerate missing messages.
    1. 次に読み取られるメッセージを検索し、他のコンシューマーが受信できないよう ロック してから、アプリケーションにメッセージを返します。Finds the next message to be consumed, locks it to prevent other consumers from receiving it, and then, return the message to the application.

    2. アプリケーションでのメッセージの処理が終了した後、Service Bus サービスに対して受信プロセスの第 2 段階を完了するよう要求が行われます。After the application finishes processing the message, it requests the Service Bus service to complete the second stage of the receive process. 次に、サービスによって このメッセージが消費済みとしてマーク されます。Then, the service marks the message as being consumed.

      アプリケーションは、なんらかの理由でメッセージを処理できない場合に、Service Bus サービスに対してメッセージを 破棄 するように要求できます。If the application is unable to process the message for some reason, it can request the Service Bus service to abandon the message. Service Bus によってメッセージの ロックが解除され、同じコンシューマーまたは競合する別のコンシューマーが再度そのメッセージを受信できるようになります。Service Bus unlocks the message and makes it available to be received again, either by the same consumer or by another competing consumer. 第 2 に、ロックに関連付けられた タイムアウト があります。Secondly, there's a timeout associated with the lock. ロックがタイムアウトになる前にアプリケーションがメッセージの処理に失敗した場合には、Service Bus によってメッセージのロックが解除され、再度受信できる状態になります。If the application fails to process the message before the lock timeout expires, Service Bus unlocks the message and makes it available to be received again.

      メッセージが処理された後、Service Bus サービスに対してメッセージを完了するように要求する前にアプリケーションがクラッシュした場合、アプリケーションが再起動する際に Service Bus によってメッセージがアプリケーションに再配信されます。If the application crashes after it processes the message, but before it requests the Service Bus service to complete the message, Service Bus redelivers the message to the application when it restarts. 一般に、この処理は 1 回以上 の処理と呼ばれます。This process is often called at-least once processing. つまり、各メッセージは 1 回以上処理されます。That is, each message is processed at least once. 特定の状況では、同じメッセージが再配信される可能性があります。However, in certain situations the same message may be redelivered. 重複した処理を許されないシナリオの場合は、重複を検出する追加ロジックをアプリケーションに追加します。If your scenario can't tolerate duplicate processing, add additional logic in your application to detect duplicates. 詳しくは、「重複検出」をご覧ください。For more information, see Duplicate detection. この機能は 厳密に 1 回 の処理と呼ばれます。This feature is known as exactly once processing.

      注意

      これらの 2 つのモードの詳細については、「受信操作の解決」を参照してください。For more information about these two modes, see Settling receive operations.

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

キューでは、1 つのコンシューマーが 1 つのメッセージを処理できます。A queue allows processing of a message by a single consumer. キューとは対照的に、トピックとサブスクリプションは、"発行とサブスクライブ" のパターンで一対多の形式の通信を実現します。In contrast to queues, topics and subscriptions provide a one-to-many form of communication in a publish and subscribe pattern. これは、多数の受信者にスケーリングする場合に便利です。It's useful for scaling to large numbers of recipients. 発行された各メッセージは、トピックに登録している各サブスクリプションで使用できるようになります。Each published message is made available to each subscription registered with the topic. パブリッシャーがトピックにメッセージを送信すると、1 つ以上のサブスクライバーが、これらのサブスクリプションに設定されているフィルター規則に応じて、メッセージのコピーを受け取ります。Publisher sends a message to a topic and one or more subscribers receive a copy of the message, depending on filter rules set on these subscriptions. サブスクリプションでは、追加のフィルターを使用して、受信するメッセージを限定できます。The subscriptions can use additional filters to restrict the messages that they want to receive. パブリッシャーは、メッセージをキューに送信するのと同じ方法でトピックにメッセージを送信します。Publishers send messages to a topic in the same way that they send messages to a queue. ただし、コンシューマーはトピックから直接メッセージを受信しません。But, consumers don't receive messages directly from the topic. 代わりに、コンシューマーはトピックのサブスクリプションからメッセージを受信します。Instead, consumers receive messages from subscriptions of the topic. トピック サブスクリプションは、トピックに送信されたメッセージのコピーを受け取る仮想キューのようなものです。A topic subscription resembles a virtual queue that receives copies of the messages that are sent to the topic. コンシューマーは、キューからメッセージを受信する場合と同じ方法で、サブスクリプションからメッセージを受信します。Consumers receive messages from a subscription identically to the way they receive messages from a queue.

キューのメッセージ送信機能はそのままトピックに相当し、メッセージ受信機能はサブスクリプションに相当します。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. トピックとサブスクリプションは、Azure portalPowerShellCLI、または Resource Manager テンプレートを使用して作成できます。You can create topics and subscriptions using the Azure portal, PowerShell, CLI, or Resource Manager templates. 次に、C#JavaPythonJavaScriptPHP、および Ruby で記述されたクライアントを使用して、メッセージをトピックに送信し、メッセージをサブスクリプションから受信します。Then, send messages to a topic and receive messages from subscriptions using clients written in C#, Java, Python, JavaScript, PHP, and Ruby.

ルールとアクション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. サブスクリプションの作成時に、メッセージのプロパティを操作するフィルター式を指定できます。When a subscription is created, you can supply a filter expression that operates on the properties of the message. プロパティには、システム プロパティ (Label など) とカスタム アプリケーション プロパティ (StoreName など) の両方を指定できます。この場合、SQL フィルター式は省略可能です。The properties can be both the system properties (for example, Label) and custom application properties (for example, StoreName.) The SQL filter expression is optional in this case. SQL フィルター式を指定しない場合は、サブスクリプションで定義されている任意のフィルター アクションが、そのサブスクリプションのすべてのメッセージに対して実行されます。Without a SQL filter expression, any filter action defined on a subscription will be done 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.

Java Message Service (JMS) 2.0 のエンティティJava message service (JMS) 2.0 entities

次のエンティティには、Java Message Service (JMS) 2.0 API を通じてアクセスできます。The following entities are accessible through the Java message service (JMS) 2.0 API.

  • 一時キューTemporary queues
  • 一時トピックTemporary topics
  • 共有の永続的サブスクリプションShared durable subscriptions
  • 非共有の永続的サブスクリプションUnshared durable subscriptions
  • 共有の非永続的サブスクリプションShared non-durable subscriptions
  • 非共有の非永続的サブスクリプションUnshared non-durable subscriptions

JMS 2.0 エンティティについてと、それらを使用する方法について、さらに学習してください。Learn more about the JMS 2.0 entities and about how to use them.

次のステップNext steps

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