Azure Service Bus とは
Azure Service Bus は、メッセージ キューと、パブリッシュとサブスクライブのトピックを備えたフル マネージド エンタープライズ統合メッセージ ブローカーです。 Service Bus は、アプリケーションとサービスを相互に分離するために使用され、次のような利点があります。
- 競合する worker 間での作業の負荷分散
- サービスやアプリケーションの境界を越えたデータと制御の安全なルーティングおよび転送
- 高い信頼性を必要とするトランザクション作業の調整
概要
データは、メッセージを使用してさまざまなアプリとサービス間で転送されます。 メッセージは、メタデータで装飾されたコンテナーであり、データを格納します。 データは、次のような一般的な形式でエンコードされた構造化データなど、どのような種類の情報でもかまいません: JSON、XML、Apache Avro、プレーンテキスト。
一般的なメッセージング シナリオの例を次にいくつか示します。
メッセージング。 販売または購入の注文、仕訳帳、在庫移動などのビジネス データを転送します。
アプリケーションの切り離し。 アプリケーションとサービスの信頼性とスケーラビリティを向上します。 プロデューサーとコンシューマーは同時に、オンラインでなくても、すぐに利用できなくてもかまいません。 トラフィックの急増によってサービスに過大な負荷を掛けないように負荷は平準化されます。
負荷分散。 複数の競合コンシューマーが同時にキューから読み取ることができ、それぞれが特定のメッセージに対する排他的な所有権を取得します。
トピックとサブスクリプション。 パブリッシャーとサブスクライバーの間の 1 対 n のリレーションシップを可能にし、サブスクライバーは公開されたメッセージ ストリームから特定のメッセージを選択できます。
Transactions。 複数の操作をすべてアトミック トランザクションのスコープ内で行うことができます。 たとえば、次の操作をトランザクションのスコープ内で実行できます。
- 1 つのキューからメッセージを取得する。
- 処理の結果を 1 つ以上の異なるキューにポストする。
- 元のキューから入力メッセージを移動する。
結果は、入力メッセージの正常な解決など、成功した場合にのみ、ダウンストリーム コンシューマーから確認できるようになり、これにより、1 回限りの処理セマンティクスが可能になります。 このトランザクション モデルは、より大きなソリューション コンテキストにおける補正トランザクション パターンの堅牢な基盤です。
メッセージ セッション。 厳密なメッセージの順序付けやメッセージの遅延を必要とする、ワークフローと多重転送の高スケールな調整を実装します。
Apache ActiveMQ などの他のメッセージ ブローカーに慣れている場合、Service Bus の概念はご存じの概念と似ています。 Service Bus はサービスとしてのプラットフォーム (PaaS) であるため、重要な違いは、次のアクションについて心配する必要がないことです。 これらの作業は Azure が代わりに行います。
- ハードウェア障害についての心配
- オペレーティング システムや製品へのパッチの継続的な適用
- ログの配置とディスク領域の管理
- バックアップの処理
- 予備のマシンへのフェールオーバー
概念
このセクションでは、Service Bus の基本的な概念について説明します。
キュー
メッセージはキューに送受信されます。 受信側アプリがメッセージを受信して処理できるようになるまで、キューがメッセージを格納します。
キュー内のメッセージは到着順に並べ替えられ、タイムスタンプが付けられます。 ブローカーがメッセージを受信すると、常にメッセージはトリプル冗長性を備えたストレージに永続的に保持され、名前空間のゾーンが有効になっている場合は複数の可用性ゾーンにまたがって分散されます。 Service Bus は、クライアントから受け入れ済みと報告されるまで、メッセージをメモリまたは揮発性ストレージに保持します。
メッセージはプル モードで配信され、要求された場合のみメッセージが配信されます。 他の一部のクラウド キューにおけるビジーポーリング モデルとは異なり、プル操作は有効期間を長くし、メッセージが使用可能になった時点でのみ完了させることができます。
注意
Service Bus キューおよび Storage キューの比較については、「Storage キューと Service Bus キューの比較」を参照してください。
トピック
トピックを使用してメッセージを送受信することもできます。 キューはポイント間通信によく使用されますが、トピックはパブリッシュ/サブスクライブのシナリオで役立ちます。
トピックには複数の独立したサブスクリプションを含めることができます。これらはトピックにアタッチされますが、その点以外は受信側のキューと同じように動作します。 トピックのサブスクライバーは、そのトピックに送信された各メッセージのコピーを受信できます。 サブスクリプションは名前付きエンティティです。 サブスクリプションは既定では永続的ですが、有効期限が切れたら自動的に削除されるように構成することができます。 Service Bus Premium では、Java Message Service (JMS) API を介して、接続している間存在する揮発性サブスクリプションを作成することもできます。
サブスクリプションに対してルールを定義できます。 サブスクリプション ルールには、サブスクリプションにコピーするメッセージの条件を定義する "フィルター" と、メッセージのメタデータを変更できるオプションの "アクション" があります。 詳細については、「トピック フィルターとアクション」を参照してください。 この機能は次のシナリオで役立ちます。
- トピックに送信されたすべてのメッセージをサブスクリプションに受信させたくない。
- サブスクリプションを通過するときに、追加のメタデータでメッセージをマークアップする。
注意
キューとトピックの詳細については、「Service Bus のキュー、トピック、サブスクリプション」をご覧ください。
名前空間
名前空間はすべてのメッセージング コンポーネントのコンテナーです (キューとトピック)。 名前空間は 1 つ以上のキューとトピックを含むことができ、多くの場合、アプリケーション コンテナーとして機能します。
名前空間は他のブローカーの用語ではサーバーに相当しますが、概念が 1 対 1 で対応しているわけではありません。 Service Bus の名前空間は、すべてアクティブな多数の仮想マシンで構成される大規模なクラスターの自分の容量スライスです。 必要に応じて、3 つの Azure 可用性ゾーンにまたがります。 そのため、メッセージ ブローカーを大規模に実行する場合の可用性と堅牢性の利点をすべて得ることができます。 また、根底にある複雑さについて心配する必要はありません。 Service Bus はサーバーレスなメッセージングです。
高度な機能
Service Bus には、より複雑なメッセージングの問題を解決できる高度な機能もあります。 以下のセクションでは、その主な機能について説明します。
メッセージ セッション
Service Bus キューまたはサブスクリプションでのメッセージ処理で先入れ先出し (FIFO) 処理を保証するには、セッションを使用します。 セッションは、要求 - 応答のパターンを実装する場合にも使用できます。 要求 - 応答パターンを使用すると、送信側アプリケーションから要求が送信され、受信側から送信側アプリケーションへの応答の正しい送信手段が提供されます。 詳細については、メッセージ セッション を参照してください。
自動転送
自動転送機能を使用すると、キューまたはサブスクリプションを同じ名前空間に属する別のキューまたはトピックにチェーンできます。 自動転送が有効な場合は、Service Bus は、一方のキューまたはサブスクリプション (転送元) にあるメッセージを自動的に削除し、もう一方のキューまたはトピック (転送先) に追加します。 詳細については、「自動転送を使用した Service Bus エンティティのチェーン」を参照してください
配信不能処理
Service Bus キューおよびトピック サブスクリプションには、配信不能キュー (DLQ) と呼ばれるセカンダリ サブキューが用意されています。 配信不能キューによって、受信者に配信できないメッセージや処理できなかったメッセージが保持されます。 そのため、DLQ のメッセージを削除し、検査することができます。 アプリケーションでは、演算子を利用して、問題の修正とメッセージの再送信を行い、エラーが発生していたという事実をログに記録してから修正処置を行います。 詳しくは、「Service Bus の配信不能キューの概要」をご覧ください。
スケジュールされた配信
メッセージをキューまたはトピックに送信して、処理を遅延させることができます。 たとえば、特定の時点にシステムで処理できるようにジョブをスケジュールすることができます。 詳細については、「スケジュールされたメッセージ」を参照してください。
メッセージ遅延
キューまたはサブスクリプションのクライアントが処理すべきメッセージを受信したものの、アプリケーション内の特別な状況が原因ですぐに処理を行えない場合、メッセージを取得するタイミングを遅延させることができます。 メッセージは、キューまたはサブスクリプションに留まりますが、確保されます。 詳細については、「メッセージの遅延」を参照してください。
トランザクション
トランザクションにより、複数の操作が 1 つの実行スコープにグループ化されます。 Service Bus は、トランザクションのスコープ内の単一メッセージング エンティティ (キュー、トピック、サブスクリプション) に対するグループ化操作をサポートしています。 詳しくは、「Service Bus のトランザクション処理の概要」を参照してください。
フィルターとアクション
サブスクライバーは、トピックから受信するメッセージを定義できます。 これらのメッセージは、1 つ以上の名前付きのサブスクリプション ルールの形式で指定されます。 各ルールは、特定のメッセージを選択するフィルター条件と、選択したメッセージに注釈を付けるアクション (省略可能) で構成されています。 サブスクリプションは、対応するルールの条件ごとに、対応する各ルールに異なる注釈を付けることができる、メッセージのコピーを作成します。 詳細については、「トピック フィルターとアクション」を参照してください。
アイドル状態時の自動削除
アイドル状態時の自動削除機能を使用すると、アイドル間隔を指定できます。この間隔が経過すると、キューは自動的に削除されます。 この間隔は、キューでトラフィックがある場合にリセットされます。 最小時間は、5 分です。
重複検出
クライアントが送信操作の結果について何か疑問を持つようなエラーが発生した場合、重複メッセージの検出機能は、送信側が同じメッセージを再送信することを可能にすることで、このような状況を解決します。重複メッセージは、キューまたはトピックで削除されます。 詳しくは、「重複検出」をご覧ください。
メッセージの一括削除
Azure Service Bus では、メッセージの一括削除がサポートされています。 これは、キューまたはサブスクリプション内のメッセージが期限切れになったり、関連性がなくなったりしてクリーンアップが必要になった場合に便利です。 詳細については、一括削除に関する記事をご覧ください。
セキュリティ
Service Bus は、Shared Access Signatures (SAS)、ロールベースのアクセス制御 (RBAC)、および Azure リソースのマネージド ID などのセキュリティ プロトコルをサポートしています。
Service Bus では、Advanced Message Queuing Protocol (AMQP) 1.0 および HTTP/REST プロトコルがサポートされています。
geo ディザスター リカバリー
Azure リージョンまたはデータセンターでダウンタイムが発生すると、geo ディザスター リカバリーにより、異なるリージョンまたはデータ センターでデータ処理を継続できます。
注意
これらの機能の詳細については、Azure Service Bus の高度な機能に関するページを参照してください。
標準とプロトコルへの準拠
Service Bus のプライマリ ワイヤ プロトコルは Advanced Messaging Queuing Protocol (AMQP) 1.0 (オープンな ISO/IEC 標準) です。 これにより、Service Bus とオンプレミスのブローカー (ActiveMQ や RabbitMQ など) に対して機能するアプリケーションを作成できます。 AMQP プロトコル ガイドには、そうした抽象化を構築する場合に役立つ詳細情報が記載されています。
Service Bus Premium は、Java/Jakarta EE の Java Message Service (JMS) 2.0 API に完全に準拠しています。 また、Service Bus Standard では、キューに重点を置いた JMS 1.1 サブセットをサポートしています。 JMS は、メッセージ ブローカー用の一般的な抽象化であり、多くのアプリケーションやフレームワーク (広く使用されている Spring Framework など) と統合されています。 他のブローカーから Azure Service Bus に切り替える場合に必要なのは、キューとトピックのトポロジを再作成し、クライアント プロバイダーの依存関係と構成を変更することだけです。 例については、ActiveMQ の移行ガイドを参照してください。
クライアント ライブラリ
完全にサポートされている Service Bus クライアント ライブラリを Azure SDK 経由で利用できます。
- .NET 用 Azure Service Bus
- SDK 上に構築された高度な抽象化を提供するサード パーティ製フレームワークには NServiceBus や MassTransit などがあります。
- Java 用 Azure Service Bus ライブラリ
- Java JMS 2.0 用 Azure Service Bus プロバイダー
- JavaScript および TypeScript 用の Azure Service Bus モジュール
- Python 用 Azure Service Bus ライブラリ
Azure Service Bus のプライマリ プロトコルは AMQP 1.0 です。AMQP 1.0 に準拠している任意のプロトコル クライアントから使用できます。 いくつかのオープンソース AMQP クライアントには、Service Bus の相互運用性を明示的に示すサンプルが含まれています。 AMQP 1.0 クライアントで Service Bus の機能を直接使用する方法については、AMQP 1.0 プロトコル ガイドをご確認ください。
| 言語 | ライブラリ |
|---|---|
| Java | Apache Qpid Proton-J |
| C/C++ | Azure uAMQP C、Apache Qpid Proton-C |
| Python | Azure uAMQP for Python、Apache Qpid Proton Python) |
| PHP | Azure uAMQP for PHP |
| Ruby | Apache Qpid Proton Ruby |
| Go | Azure Go AMQP、Apache Qpid Proton Go |
| C#、F#、VB | AMQP .NET Lite、Apache NMS AMQP |
| JavaScript、Node | Rhea |
統合
Service Bus は、次のような多くの Microsoft および Azure サービスと完全に統合されています。
次のステップ
Service Bus メッセージングの基本的な使い方については、以下の記事を参照してください。