次の方法で共有

Service Bus のキュー、トピック、サブスクリプション

  • [アーティクル]

Azure Service Bus は、信頼性の高いメッセージ キューイングと耐久性のあるパブリッシュ/サブスクライブ メッセージングをサポートしています。 Service Bus のメッセージング機能の中核を形成するメッセージング エンティティは、キュー、トピックおよびサブスクリプションです。

重要

Azure Service Bus を初めて使用する場合は、この記事を読む前に「Azure Service Bus とは」を参照してください。

キュー

キューでは、コンシューマーが競合している場合のメッセージ配信に先入れ先出し法 (FIFO) を使用します。 つまり、受信者は、通常はキューに追加された順序でメッセージを受信して処理します。 そして、1 つのメッセージ コンシューマーだけが、各メッセージを受信して処理します。

サービス キューの仕組みを示す画像。

キューを使用する主な利点は、アプリケーション コンポーネントの一時的な切り離しを達成することです。 言い換えると、メッセージはキューに永続的に格納されるため、プロデューサー (送信者) とコンシューマー (受信者) が同時にメッセージを送受信する必要はありません。 さらに、プロデューサーは、メッセージの処理と送信を続ける場合、コンシューマーからの応答を待つ必要がありません。

関連する利点として負荷平準化があります。これにより、プロデューサーとコンシューマーは異なるレートでメッセージを送受信できます。 多くのアプリケーションでは、システム負荷は時間の経過とともに変化します。 ただし、各作業単位に必要な処理時間は通常一定です。 メッセージ プロデューサーとコンシューマーの間をキューで仲介することは、コンシューマー側アプリケーションはピーク時ではなく平均時の負荷を処理できるだけでよいということを意味します。 キューの深さは、受信の負荷の変化に応じて増減します。 この機能により、アプリケーションの負荷に対応するために必要なインフラストラクチャの量に関する費用を直接節約できます。 負荷の増大に合わせて、キューからの読み取りのためにワーカー プロセスを追加できます。 各メッセージは、ワーカー プロセスの中の 1 つのプロセスによって処理されます。 さらに、このプルベースの負荷分散では、処理能力を持つ各ワーカー コンピューターがそれら独自の最大レートでメッセージをプルする場合でも、ワーカー コンピューターを最適に使用できます。 このパターンは、しばしば競合コンシューマーのパターンと呼ばれます。

キューを使用してメッセージ プロデューサーとメッセージ コンシューマーの間を仲介すると、必然的にコンポーネント間の結び付きは緩くなります。 プロデューサーとコンシューマーは相互に認識しないため、プロデューサーに影響することなく、コンシューマーをアップグレードできます。

キューの作成

キューは、次のいずれかのオプションを使用して作成できます。

次に、次のものを含むプログラミング言語で記述されたクライアントを使用してメッセージを送受信します。

受信モード

コンシューマーが Service Bus からメッセージを受信できる 2 つの異なるモードを指定できます。

  • 受信して削除。 このモードでは、コンシューマーからの要求が Service Bus に到達すると、メッセージが読み取り中としてマークされ、コンシューマー アプリケーションに返されます。 このモードは最もシンプルなモデルです。 これは障害発生時にアプリケーション側でメッセージを処理しないことを許容できるシナリオに最適です。 このシナリオを理解するために、コンシューマーが受信要求を発行した後で、メッセージを処理する前にクラッシュしたというシナリオを考えてみましょう。 Service Bus がメッセージを使用中としてマークすると、アプリケーションは再起動時にメッセージの使用を開始します。 クラッシュ前に読み取られたメッセージは見逃してしまいます。 一般に、この処理は多くても 1 回の処理と呼ばれます。
  • ピーク ロック。 このモードでは、受信処理は 2 段階になります。これにより、メッセージが失われることを許容できないアプリケーションに対応することができます。

    1. 次に読み取られるメッセージを検索し、他のコンシューマーが受信できないようロックしてから、アプリケーションにメッセージを返します。

    2. アプリケーションでのメッセージの処理が終了した後、Service Bus サービスに対して受信プロセスの第 2 段階を完了するよう要求が行われます。 次に、サービスによってこのメッセージが使用済みとしてマークされます。

      アプリケーションは、なんらかの理由でメッセージを処理できない場合に、Service Bus サービスに対してメッセージを破棄するように要求できます。 Service Bus によってメッセージのロックが解除され、同じコンシューマーまたは競合する別のコンシューマーが再度そのメッセージを受信できるようになります。 第 2 に、ロックに関連付けられたタイムアウトがあります。 ロックがタイムアウトになる前にアプリケーションがメッセージの処理に失敗した場合には、Service Bus によってメッセージのロックが解除され、再度受信できる状態になります。

      メッセージが処理された後、Service Bus サービスに対してメッセージを完了するように要求する前にアプリケーションがクラッシュした場合、アプリケーションが再起動する際に Service Bus によってメッセージがアプリケーションに再配信されます。 一般に、この処理は 1 回以上の処理と呼ばれます。 つまり、各メッセージは 1 回以上処理されます。 ただし、特定の状況では、同じメッセージが再配信される可能性があります。 重複した処理を許されないシナリオの場合は、重複を検出する追加ロジックをアプリケーションに追加します。 詳細については、重複検出を参照してください。これは、1 回きりの処理と呼ばれます。

      Note

      これらの 2 つのモードの詳細については、「受信操作の解決」を参照してください。

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

キューでは、1 つのコンシューマーが 1 つのメッセージを処理できます。 キューとは対照的に、トピックとサブスクリプションは、"発行とサブスクライブ" のパターンで一対多の形式の通信を実現します。 これは、多数の受信者にスケーリングする場合に便利です。 発行された各メッセージは、トピックに登録している各サブスクリプションで使用できるようになります。 パブリッシャーがトピックにメッセージを送信すると、1 つ以上のサブスクライバーがメッセージのコピーを受け取ります。

3 つのサブスクリプションを含む Service Bus トピックを示す画像。

サブスクリプションでは、追加のフィルターを使用して、受信するメッセージを限定できます。 パブリッシャーは、メッセージをキューに送信するのと同じ方法でトピックにメッセージを送信します。 ただし、コンシューマーはトピックから直接メッセージを受信しません。 代わりに、コンシューマーはトピックのサブスクリプションからメッセージを受信します。 トピック サブスクリプションは、トピックに送信されたメッセージのコピーを受け取る仮想キューのようなものです。 コンシューマーは、キューからメッセージを受信する場合と同じ方法で、サブスクリプションからメッセージを受信します。

キューのメッセージ送信機能はそのままトピックに相当し、メッセージ受信機能はサブスクリプションに相当します。 特に、この機能は、サブスクリプションでは、競合コンシューマー、一時的な切り離し、負荷平滑化、負荷分散など、キューに関してこのセクションで既に説明したのと同じパターンがサポートされることを意味します。

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

トピックの作成は、前のセクションで説明したキューの作成と似ています。 トピックとサブスクリプションは、次のいずれかのオプションを使用して作成できます。

次に、トピックにメッセージを送信し、次のものを含むプログラミング言語で記述されたクライアントを使用してサブスクリプションからメッセージを受信します。

ルールとアクション

多くのシナリオでは、特性のあるメッセージは、異なる方法で処理する必要があります。 この処理を実現するために、目的のプロパティを持つメッセージを検索し、該当するプロパティに特定の変更を行うようにサブスクリプションを構成できます。 Service Bus のサブスクリプションにはトピックに送信されたすべてのメッセージが表示されますが、仮想サブスクリプション キューにコピーできるのは、これらのメッセージの一部のみです。 このフィルター処理を行うには、サブスクリプション フィルターを使用します。 このような変更は、"フィルター アクション" と呼ばれます。 サブスクリプションの作成時に、メッセージのプロパティを操作するフィルター式を指定できます。 プロパティには、システム プロパティ (Label など) とカスタム アプリケーション プロパティ (StoreName など) の両方を指定できます。この場合、SQL フィルター式は省略可能です。 SQL フィルター式を指定しない場合は、サブスクリプションで定義されているすべてのフィルター アクションは、そのサブスクリプションのすべてのメッセージに対して実行されます。

完全な作業用サンプルについては、GitHub の TopicFilters サンプルを参照してください。 フィルターの詳細については、「トピック フィルターとアクション」を参照してください。

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

次のエンティティには、Java Message Service (JMS) 2.0 API を通じてアクセスできます。

  • 一時キュー
  • 一時トピック
  • 共有の永続的サブスクリプション
  • 非共有の永続的サブスクリプション
  • 共有の非永続的サブスクリプション
  • 非共有の非永続的サブスクリプション

JMS 2.0 エンティティについてと、それらを使用する方法について、さらに学習してください。

エクスプレス エンティティ

エクスプレス エンティティは、スループットが高くて待ち時間が短いシナリオのために作成されました。 エクスプレス エンティティでは、キューまたはトピックにメッセージが送信される場合、メッセージング ストアにすぐに格納されません。 代わりに、メッセージは最初にメモリにキャッシュされます。 エンティティに残っているメッセージは、遅延後にメッセージ ストアに書き込まれ、その時点で停止による損失から保護されます。

通常のエンティティでは、すべての実行時操作 (送信、完了、破棄、配信不能など) は、最初にストアに保存され、その後でのみ、成功としてクライアントに受信確認が送信されます。 エクスプレス エンティティでは、実行時操作は最初に成功としてクライアントに受信確認が送信され、その後でのみ、ストアに遅延保存されます。 その結果、コンピューターが再起動されたり、ハードウェアの問題が発生した場合、受信確認済みの一部の実行時操作がまったく保存されない可能性があります。 つまり、クライアントでエクスプレス エンティティを使うと待ち時間は短く、スループットは高くなりますが、それと引き換えに、データ損失やメッセージの再配信が発生する可能性があります。

さらに、Service Bus では、時間をかけて多くの最適化が行われてきました。つまり、現在、エクスプレス エンティティのスループットと待ち時間の利点は最小になっています。 それに加えて、Service Bus の Premium レベルでは、エクスプレス エンティティはサポートされていません。 このため、現在、この機能を使うことはお勧めしません。

次のステップ

好みの言語でサンプルを試してみてください。

以前の .NET および Java クライアント ライブラリを使用するサンプルについては、次のリンクを使用してください。

2026 年 9 月 30 日に、Azure SDK ガイドラインに準拠していない Azure Service Bus SDK ライブラリ WindowsAzure.ServiceBus、Microsoft.Azure.ServiceBus、および com.microsoft.azure.servicebus は廃止されます。 SBMP プロトコルのサポートも終了するため、2026 年 9 月 30 日以降はこのプロトコルを使用できなくなります。 この日付より前に、重要なセキュリティ更新プログラムと強化された機能が提供される、最新の Azure SDK ライブラリに移行してください。

古いライブラリは 2026 年 9 月 30 日以降も引き続き使用できますが、Microsoft から公式のサポートと更新プログラムは提供されなくなります。 詳細については、サポート廃止のお知らせに関するページを参照してください。