Azure Service Bus とはWhat is Azure Service Bus?

Microsoft Azure Service Bus は、メッセージ キューとパブリッシュとサブスクライブ トピックを備えたフル マネージド エンタープライズ統合メッセージ ブローカーです。Microsoft Azure Service Bus is a fully managed enterprise message broker with message queues and publish-subscribe topics. Service Bus は、アプリケーションとサービスを相互に分離するために使用され、次のような利点があります。Service Bus is used to decouple applications and services from each other, providing the following benefits:

  • 競合する worker 間での作業の負荷分散Load-balancing work across competing workers
  • サービスやアプリケーションの境界を越えたデータと制御の安全なルーティングおよび転送Safely routing and transferring data and control across service and application boundaries
  • 高い信頼性を必要とするトランザクション作業の調整Coordinating transactional work that requires a high-degree of reliability


データは、メッセージ を使用してさまざまなアプリとサービス間で転送されます。Data is transferred between different applications and services using messages. メッセージは、メタデータで装飾されたコンテナーであり、データを格納します。A message is a container decorated with metadata, and contains data. データは、次のような一般的な形式でエンコードされた構造化データなど、どのような種類の情報でもかまいません: JSON、XML、Apache Avro、プレーンテキスト。The data can be any kind of information, including structured data encoded with the common formats such as the following ones: JSON, XML, Apache Avro, Plain Text.

一般的なメッセージング シナリオの例を次にいくつか示します。Some common messaging scenarios are:

  • メッセージングMessaging. 販売または購入の注文、仕訳帳、在庫移動などのビジネス データを転送します。Transfer business data, such as sales or purchase orders, journals, or inventory movements.

  • アプリケーションの切り離しDecouple applications. アプリケーションとサービスの信頼性とスケーラビリティを向上します。Improve reliability and scalability of applications and services. プロデューサーとコンシューマーは同時に、オンラインでなくても、すぐに利用できなくてもかまいません。Producer and consumer don't have to be online or readily available at the same time. トラフィックの急増によってサービスに過大な負荷を掛けないように負荷は平準化されますThe load is leveled such that traffic spikes don't overtax a service.

  • "負荷分散"。Load Balancing. 複数の競合コンシューマーが同時にキューから読み取ることができ、それぞれが特定のメッセージに対する排他的な所有権を取得します。Allow for multiple competing consumers to read from a queue at the same time, each safely obtaining exclusive ownership to specific messages.

  • トピックとサブスクリプションTopics and subscriptions. パブリッシャーとサブスクライバーの間の 1 対 n のリレーションシップを可能にし、サブスクライバーは公開されたメッセージ ストリームから特定のメッセージを選択できます。Enable 1:n relationships between publishers and subscribers, allowing subscribers to select particular messages from a published message stream.

  • TransactionsTransactions. 複数の操作をすべてアトミック トランザクションのスコープ内で行うことができます。Allows you to do several operations, all in the scope of an atomic transaction. たとえば、次の操作をトランザクションのスコープ内で実行できます。For example, the following operations can be done in the scope of a transaction.

    1. 1 つのキューからメッセージを取得する。Obtain a message from one queue.
    2. 処理の結果を 1 つ以上の異なるキューにポストする。Post results of processing to one or more different queues.
    3. 元のキューから入力メッセージを移動する。Move the input message from the original queue.

    結果は、入力メッセージの正常な解決など、成功した場合にのみ、ダウンストリーム コンシューマーから確認できるようになり、これにより、1 回限りの処理セマンティクスが可能になります。The results become visible to downstream consumers only upon success, including the successful settlement of input message, allowing for once-only processing semantics. このトランザクション モデルは、より大きなソリューション コンテキストにおける補正トランザクション パターンの堅牢な基盤です。This transaction model is a robust foundation for the compensating transactions pattern in the greater solution context.

  • メッセージ セッションMessage sessions. 厳密なメッセージの順序付けやメッセージの遅延を必要とする、ワークフローと多重転送の高スケールな調整を実装します。Implement high-scale coordination of workflows and multiplexed transfers that require strict message ordering or message deferral.

Apache ActiveMQ などの他のメッセージ ブローカーに慣れている場合、Service Bus の概念はご存じの概念と似ています。If you're familiar with other message brokers like Apache ActiveMQ, Service Bus concepts are similar to what you know. Service Bus はサービスとしてのプラットフォーム (PaaS) であるため、重要な違いは、次のアクションについて心配する必要がないことです。As Service Bus is a platform-as-a-service (PaaS) offering, a key difference is that you don't need to worry about the following actions. これらの作業は Azure が代わりに行います。Azure takes care of those chores for you.

  • ログの配置とディスク領域の管理Placing logs and managing disk space
  • バックアップの処理Handling backups
  • オペレーティング システムや製品へのパッチの継続的な適用Keeping the operating systems or the products patched
  • ハードウェア障害についての心配Worrying about hardware failures
  • 予備のマシンへのフェールオーバーFailing over to a reserve machine

標準とプロトコルへの準拠Compliance with standards and protocols

Service Bus のプライマリ ワイヤ プロトコルは Advanced Messaging Queuing Protocol (AMQP) 1.0 (オープンな ISO/IEC 標準) です。The primary wire protocol for Service Bus is Advanced Messaging Queueing Protocol (AMQP) 1.0, an open ISO/IEC standard. これにより、Service Bus とオンプレミスのブローカー (ActiveMQ や RabbitMQ など) に対して機能するアプリケーションを作成できます。It allows customers to write applications that work against Service Bus and on-premises brokers such as ActiveMQ or RabbitMQ. AMQP プロトコル ガイドには、そうした抽象化を構築する場合に役立つ詳細情報が記載されています。The AMQP protocol guide provides detailed information in case you want to build such an abstraction.

Service Bus Premium は、Java/Jakarta EE の Java Message Service (JMS) 2.0 API に完全に準拠しています。Service Bus Premium is fully compliant with the Java/Jakarta EE Java Message Service (JMS) 2.0 API. また、Service Bus Standard では、キューに重点を置いた JMS 1.1 サブセットをサポートしています。And, Service Bus Standard supports the JMS 1.1 subset focused on queues. JMS は、メッセージ ブローカー用の一般的な抽象化であり、多くのアプリケーションやフレームワーク (広く使用されている Spring Framework など) と統合されています。JMS is a common abstraction for message brokers and integrates with many applications and frameworks, including the popular Spring framework. 他のブローカーから Azure Service Bus に切り替える場合に必要なのは、キューとトピックのトポロジを再作成し、クライアント プロバイダーの依存関係と構成を変更することだけです。To switch from other brokers to Azure Service Bus, you just need to recreate the topology of queues and topics, and change the client provider dependencies and configuration. 例については、ActiveMQ の移行ガイドを参照してください。For an example, see the ActiveMQ migration guide.

概念と用語Concepts and terminology

このセクションでは、Service Bus の概念と用語について説明します。This section discusses concepts and terminology of Service Bus.


名前空間は、すべてのメッセージング コンポーネントのコンテナーです。A namespace is a container for all messaging components. 複数のキューとトピックを 1 つの名前空間に格納できます。多くの場合、名前空間はアプリケーション コンテナーとして機能します。Multiple queues and topics can be in a single namespace, and namespaces often serve as application containers.

名前空間は他のブローカーの用語では "サーバー" に相当しますが、概念が 1 対 1 で対応しているわけではありません。A namespace can be compared to a "server" in the terminology of other brokers, but the concepts aren't directly equivalent. Service Bus の名前空間は、すべてアクティブな多数の仮想マシンで構成される大規模なクラスターの自分の容量スライスです。A Service Bus namespace is your own capacity slice of a large cluster made up of dozens of all-active virtual machines. 必要に応じて、3つの Azure 可用性ゾーンにまたがることができます。It may optionally span three Azure availability zones. そのため、メッセージ ブローカーを大規模に実行する場合の可用性と堅牢性の利点をすべて得ることができます。So, you get all the availability and robustness benefits of running the message broker at enormous scale. また、根底にある複雑さについて心配する必要はありません。And, you don't need to worry about underlying complexities. Service Bus は "サーバーレス" なメッセージングです。Service Bus is "serverless" messaging.


メッセージは キュー に送受信されます。Messages are sent to and received from queues. 受信側アプリがメッセージを受信して処理できるようになるまで、キューがメッセージを格納します。Queues store messages until the receiving application is available to receive and process them.


キュー内のメッセージは到着順に並べ替えられ、タイムスタンプが付けられます。Messages in queues are ordered and timestamped on arrival. ブローカーが受信すると、常にメッセージはトリプル冗長性を備えたストレージに永続的に保持され、名前空間のゾーンが有効になっている場合は複数の可用性ゾーンにまたがって分散されます。Once accepted by the broker, the message is always held durably in triple-redundant storage, spread across availability zones if the namespace is zone-enabled. Service Bus は、受信したことをクライアントにレポートした後に、メッセージをメモリや揮発性ストレージ内に残しません。Service Bus never leaves messages in memory or volatile storage after they've been reported to the client as accepted.

メッセージは プル モードで配信され、要求された場合のみメッセージが配信されます。Messages are delivered in pull mode, only delivering messages when requested. 他の一部のクラウド キューにおけるビジーポーリング モデルとは異なり、プル操作は有効期間を長くし、メッセージが使用可能になった時点でのみ完了させることができます。Unlike the busy-polling model of some other cloud queues, the pull operation can be long-lived and only complete once a message is available.


トピック を使用してメッセージを送受信することもできます。You can also use topics to send and receive messages. キューはポイント間通信によく使用されますが、トピックは公開/サブスクライブのシナリオで役立ちます。While a queue is often used for point-to-point communication, topics are useful in publish/subscribe scenarios.


トピックには複数の独立したサブスクリプションを含めることができます。これらはトピックにアタッチされますが、その点以外は受信側のキューと同じように動作します。Topics can have multiple, independent subscriptions, which attach to the topic and otherwise work exactly like queues from the receiver side. トピックのサブスクライバーは、そのトピックに送信された各メッセージのコピーを受信できます。A subscriber to a topic can receive a copy of each message sent to that topic. サブスクリプションは名前付きエンティティです。Subscriptions are named entities. サブスクリプションは既定では永続的ですが、有効期限が切れたら自動的に削除されるように構成することができます。Subscriptions are durable by default, but can be configured to expire and then be automatically deleted. Service Bus Premium では、JMS API を介して、接続している間存在する揮発性サブスクリプションを作成することもできます。Via the JMS API, Service Bus Premium also allows you to create volatile subscriptions that exist for the duration of the connection.

サブスクリプションに対してルールを定義できます。You can define rules on a subscription. サブスクリプション ルールには、サブスクリプションにコピーするメッセージの条件を定義する "フィルター" と、メッセージのメタデータを変更できるオプションの "アクション" があります。A subscription rule has a filter to define a condition for the message to be copied into the subscription and an optional action that can modify message metadata. 詳細については、「トピック フィルターとアクション」を参照してください。For more information, see Topic filters and actions. この機能は次のシナリオで役立ちます。This feature is useful in the following scenarios:

  • トピックに送信されたすべてのメッセージをサブスクリプションに受信させたくない。You don't want a subscription to receive all messages sent to a topic.
  • サブスクリプションを通過するときに、追加のメタデータでメッセージをマークアップする。You want to mark up messages with extra metadata when they pass through a subscription.

高度な機能Advanced features

Service Bus には、より複雑なメッセージングの問題を解決できる高度な機能があります。Service Bus includes advanced features that enable you to solve more complex messaging problems. 次のセクションでは、これらの機能のいくつかを説明します。The following sections describe several of these features.

メッセージ セッションMessage sessions

Service Bus の先入れ先出し (FIFO) 処理を作成するには、セッションを使用します。To create a first-in, first-out (FIFO) guarantee in Service Bus, use sessions. メッセージ セッションでは、関連メッセージのバインドなしシーケンスの排他的な順序指定処理が可能です。Message sessions enable exclusive, ordered handling of unbounded sequences of related messages. 高スケールな高可用性システムでセッションを処理できるようにするために、セッション機能によってセッション状態を保存することもできます。これにより、セッションはハンドラー間を安全に移動できます。To allow for handling sessions in high-scale, high-availability systems, the session feature also allows for storing session state, which allows sessions to safely move between handlers. 詳細については、「メッセージ セッション: 先入れ先出し (FIFO)」を参照してください。For more information, see Message sessions: first in, first out (FIFO).


自動転送機能は、キューまたはサブスクリプションを同じ名前空間内にある別のキューまたはトピックにチェーンします。The autoforwarding feature chains a queue or subscription to another queue or topic inside the same namespace. この機能を使用すると、Service Bus はキューまたはサブスクリプションからターゲットのキューまたはトピックにメッセージを自動的に移動します。When you use this feature, Service Bus automatically moves messages from a queue or subscription to a target queue or topic. そうした移動はすべてトランザクションとして実行されます。All such moves are done transactionally. 詳細については、「自動転送を使用した Service Bus エンティティのチェーン」を参照してください。For more information, see Chaining Service Bus entities with autoforwarding.

配信不能キューDead-letter queue

Service Bus のすべてのキューおよびトピック サブスクリプションには、配信不能キュー (DLQ) が関連付けられています。All Service Bus queues and topic subscriptions have an associated dead-letter queue (DLQ). DLQ は、次の条件を満たすメッセージを保持します。A DLQ holds messages that meet the following criteria:

  • どの受信者にも正常に配信できない。They can't be delivered successfully to any receiver.
  • タイムアウトした。They timed out.
  • 受信側アプリケーションによって明示的に一時保留されている。They're explicitly sidelined by the receiving application.

配信不能キュー内のメッセージには、それらがそこに配置された理由が注釈として付けられます。Messages in the dead-letter queue are annotated with the reason why they've been placed there. 配信不能キューには特殊なエンドポイントがありますが、その点以外は通常のキューと同様に動作します。The dead-letter queue has a special endpoint, but otherwise acts like any regular queue. アプリケーションやツールは、DLQ を参照したり、そこからデキューしたりできます。An application or tool can browse a DLQ or dequeue from it. 配信不能キューから自動転送することもできます。You can also autoforward out of a dead-letter queue. 詳しくは、「Service Bus の配信不能キューの概要」をご覧ください。For more information, see Overview of Service Bus dead-letter queues.

スケジュールされた配信Scheduled delivery

メッセージを遅延処理されるようにキューまたはトピックに送信し、メッセージを処理できるようになる時間を設定できます。You can submit messages to a queue or topic for delayed processing, setting a time when the message will become available for consumption. スケジュール設定されたメッセージはキャンセルすることもできます。Scheduled messages can also be canceled. 詳細については、「スケジュールされたメッセージ」を参照してください。For more information, see Scheduled messages.

メッセージ遅延Message deferral

キューまたはサブスクリプション クライアントは、受信したメッセージの取得を遅延させることができます。A queue or subscription client can defer retrieval of a received message until a later time. メッセージは想定外の順序でポストされている場合があり、クライアントは別のメッセージを受信するまで待機する必要があります。The message may have been posted out of an expected order and the client wants to wait until it receives another message. 遅延メッセージはキューまたはサブスクリプション内に残り、サービスによって割り当てられたシーケンス番号を使用して明示的に再アクティブ化する必要があります。Deferred messages remain in the queue or subscription and must be reactivated explicitly using their service-assigned sequence number. 詳細については、「メッセージの遅延」を参照してください。For more information, see Message deferral.


クライアント側のバッチ処理により、キューまたはトピックのクライアントは一連のメッセージを蓄積し、まとめて転送できます。Client-side batching enables a queue or topic client to accumulate a set of messages and transfer them together. これは、多くの場合、帯域幅を節約するために、またはスループットを向上させるために行われます。It's often done to either save bandwidth or to increase throughput. 詳細については、「クライアント側のバッチ処理」を参照してください。For more information, see Client-side batching.


トランザクションにより、複数の操作が 1 つの 実行スコープ にグループ化されます。A transaction groups two or more operations together into an execution scope. Service Bus では、単一トランザクションのスコープ内の複数のメッセージング エンティティに対してグループ化操作を実行できます。Service Bus allows you to group operations against multiple messaging entities within the scope of a single transaction. メッセージ エンティティは、キュー、トピック、またはサブスクリプションとすることができます。A message entity can be a queue, topic, or subscription. 詳しくは、「Service Bus のトランザクション処理の概要」を参照してください。For more information, see Overview of Service Bus transaction processing.

アイドル状態時の自動削除Autodelete on idle

アイドル状態時の自動削除機能を使用すると、アイドル間隔を指定できます。この間隔が経過すると、キューまたはトピックス サブスクリプションが自動的に削除されます。Autodelete on idle enables you to specify an idle interval after which a queue or topic subscription is automatically deleted. 最小時間は、5 分です。The minimum duration is 5 minutes. 詳細については、「QueueDescription.AutoDeleteOnIdle プロパティ」を参照してください。For more information, see the QueueDescription.AutoDeleteOnIdle Property.

重複検出Duplicate detection

重複検出機能を使用すると、送信側は同じメッセージを再送信し、重複する可能性のあるものをブローカーが削除できます。The duplicate detection feature enables the sender to resend the same message again and for the broker to drop a potential duplicate. 重複検出は、メッセージの message-id プロパティの追跡に基づいています。そのため、アプリケーションではメッセージを再送信するときに同じ値を使用するように注意する必要があります。その値は、アプリケーション固有のコンテキストから直接派生することがあります。The duplicate detection is based on tracking the message-id property of a message, meaning the application needs to take care to use the same value when resending the message, which might be directly derived from some application-specific context. 詳しくは、「重複検出」をご覧ください。For more information, see Duplicate detection.

geo ディザスター リカバリーGeo-disaster recovery

Azure リージョンでダウンタイムが発生した場合、ディザスター リカバリー機能により、異なるリージョンまたはデータ センター内でデータ処理を継続できます。When an Azure region experiences downtime, the disaster recovery feature enables data processing to continue operating in a different region or data center. この機能は、セカンダリ リージョン内で使用可能な名前空間の構造ミラーを保持し、名前空間 ID をセカンダリ名前空間に切り替えることができるようにします。The feature keeps a structural mirror of a namespace available in the secondary region and allows the namespace identity to switch to the secondary namespace. 既にポストされているメッセージは、可用性エピソードが収まったら復旧できるよう、以前のプライマリ名前空間に残ります。Already posted messages remain in the former primary namespace for recovery once the availability episode subsides. 詳細については、「Azure Service Bus の geo ディザスター リカバリー」を参照してください。For more information, see Azure Service Bus Geo-disaster recovery.


Service Bus は、AMQP 1.0 標準および HTTP または REST プロトコルとそれぞれのセキュリティ機構 (トランスポート レベルのセキュリティ (TLS) など) をサポートしています。Service Bus supports standard AMQP 1.0 and HTTP or REST protocols and their respective security facilities, including transport-level security (TLS). Shared Access Signature または Azure Active Directory のロール ベース セキュリティを使用して、クライアントにアクセスを許可することができます。Clients can be authorized for access using Shared Access Signature or Azure Active Directory role-based security.

不要なトラフィックから保護するために、Service Bus には、IP ファイアウォールや、仮想ネットワークとの統合などのセキュリティ機能が用意されています。For protection against unwanted traffic, Service Bus provides security features such as IP firewall and integration with virtual networks.

クライアント ライブラリClient libraries

完全にサポートされている Service Bus クライアント ライブラリを Azure SDK 経由で利用できます。Fully supported Service Bus client libraries are available via the Azure SDK.

Azure Service Bus のプライマリ プロトコルは AMQP 1.0 です。AMQP 1.0 に準拠している任意のプロトコル クライアントから使用できます。Azure Service Bus' primary protocol is AMQP 1.0 and it can be used from any AMQP 1.0 compliant protocol client. いくつかのオープンソース AMQP クライアントには、Service Bus の相互運用性を明示的に示すサンプルが含まれています。Several open-source AMQP clients have samples that explicitly demonstrate Service Bus interoperability. AMQP 1.0 クライアントで Service Bus の機能を直接使用する方法については、AMQP 1.0 プロトコル ガイドを参照してください。Review the AMQP 1.0 protocol guide to understand how to use Service Bus' features with AMQP 1.0 clients directly.

言語Language ライブラリLibrary
JavaJava Apache Qpid Proton-JApache Qpid Proton-J
C/C++C/C++ Azure uAMQP CApache Qpid Proton-CAzure uAMQP C, Apache Qpid Proton-C
PythonPython Azure uAMQP for PythonApache Qpid Proton PythonAzure uAMQP for Python, Apache Qpid Proton Python
PHPPHP Azure uAMQP for PHPAzure uAMQP for PHP
RubyRuby Apache Qpid Proton RubyApache Qpid Proton Ruby
GoGo Azure Go AMQPApache Qpid Proton GoAzure Go AMQP, Apache Qpid Proton Go
JavaScript、NodeJavaScript/Node RheaRhea


Service Bus は、次のような多くの Microsoft および Azure サービスと完全に統合されています。Service Bus fully integrates with many Microsoft and Azure services, for instance:

次のステップNext steps

Service Bus メッセージングの基本的な使い方については、以下の記事を参照してください。To get started using Service Bus messaging, see the following articles: