Service Bus Premium メッセージング層
Service Bus メッセージングには、キューやトピックなどのエンティティが含まれており、エンタープライズ メッセージング機能と、クラウド スケールの豊富な発行/サブスクライブ セマンティクスが結合されます。 Service Bus メッセージングは、多くの高度なクラウド ソリューションで、通信のバックボーンとして使用されます。
Service Bus メッセージングに Premium レベルを導入して、ミッション クリティカルなアプリケーションのスケール、パフォーマンス、および可用性に関する顧客の一般的な要求に対処しています。 運用環境のシナリオでは、Premium レベルを使用することをお勧めします。 機能セットはほぼ同じですが、Service Bus メッセージングの standard と premium のレベルは、異なるユース ケースに応えるように設計されています。
次の表に、大まかな違いをいくつか示します。
基準 | Premium | Standard |
---|---|---|
スループット | 高スループット | 変わりやすいスループット |
パフォーマンス | 予測可能なパフォーマンス | 変わりやすい待機時間 |
価格 | 固定価格 | 従量課金制の変わりやすい料金 |
スケール | ワークロードをスケールアップおよびスケールダウンする機能 | 該当なし |
メッセージ サイズ | 最大 100 MB のメッセージ サイズ。 詳細については、大量メッセージ サポートに関する記事を参照してください。 | 最大 256 KB のメッセージ サイズ |
Service Bus Premium メッセージングでは、各顧客のワークロードが分離した状態で実行されるように、CPU とメモリのレベルでリソースが分離されます。 このリソースのコンテナーを、メッセージング ユニットと呼びます。 各 Premium 名前空間には、1 つ以上のメッセージング ユニットが割り当てられます。 各 Service Bus Premium 名前空間に対して 1、2、4、8、または 16 のメッセージング ユニットを購入することができます。 1 つのワークロードまたはエンティティが複数のメッセージング ユニットにまたがることができ、メッセージング ユニットの数は任意で変更できます。 その結果、Service Bus ベースのソリューションのパフォーマンスは、予測可能で反復可能になります。
このパフォーマンスは、より予測可能かつ利用可能なだけでなく、より高速です。 Premium メッセージングでのピークのパフォーマンスは、Standard レベルよりもはるかに高速です。
Premium メッセージングの技術的な相違点
次のセクションでは、Premium メッセージング レベルと Standard メッセージング レベルのいくつかの違いについて説明します。
エクスプレス エンティティ
分離されたランタイム環境で Premium メッセージングが実行されるため、Premium 名前空間ではエクスプレス エンティティがサポートされません。 エクスプレス エンティティでは、メッセージを永続記憶装置に書き込む前に、一時的にメモリに保持します。 Standard メッセージングで実行しているコードがあり、それを Premium レベルに移植したい場合は、エクスプレス エンティティ機能が無効になっていることを確認します。
Premium メッセージング リソースの使用
一般に、エンティティに対するどの操作でも、CPU とメモリが使用される可能性があります。 これらいくつかの操作を次に示します。
- キュー、トピック、サブスクリプションに対する作成、取得、更新、削除 (CRUD: Create、Retrieve、Update、Delete) などの管理操作。
- ランタイム操作 (メッセージの送受信)
- 操作とアラートの監視
ただし、追加の CPU とメモリ使用によりさらに課金されることはありません。 Premium メッセージング レベルでは、メッセージング ユニットの料金は単一です。
次の理由で、CPU とメモリの使用が追跡され、表示されます。
- システム内部に透明性を提供する。
- 購入したリソースの容量を把握する。
- スケール アップ/スケール ダウンを判断するのに役立つ容量計画。
必要なメッセージング ユニットの数は?
Azure Service Bus Premium 名前空間をプロビジョニングする場合は、メッセージング ユニット数を指定します。 これらのメッセージング ユニットは、名前空間に割り当てられる専用リソースです。 名前空間でパーティション分割が有効になっている場合、メッセージング ユニットはパーティション間で均等に分散されます。
Service Bus Premium 名前空間に割り当てられるメッセージング ユニット数は、ワークロードの変化 (増加または減少) を考慮して動的に調整できます。
アーキテクチャのメッセージング ユニット数を決定するときは、いくつかの要素を考慮する必要があります。
- 名前空間に割り当てられた "1 つまたは 2 つのメッセージング ユニット"、または "パーティションごとに 1 つのメッセージ ユニット" から始めます。
- 名前空間のリソース使用状況メトリック内の CPU 使用率メトリックを調査します。
- CPU 使用率が "20% を下回る" 場合は、名前空間に割り当てられたメッセージング ユニット数を "スケールダウン" できる可能性があります。
- CPU 使用率が70% を超える場合は、名前空間に割り当てられたメッセージング ユニット数をスケールアップすると、アプリケーションにメリットがあります。
Service Bus 名前空間を構成して、自動スケーリングする (メッセージング ユニットを増減する) 方法については、「メッセージング ユニットを自動的に更新する」を参照してください。
注意
名前空間に割り当てられたリソースのスケールは、プリエンティブまたはリアクティブにすることができます。
プリエンプティブ:(季節性や傾向により) 追加のワークロードが予想される場合は、ワークロードが増える前に、さらに多くのメッセージング ユニットを名前空間に割り当てることができます。
リアクティブ:リソース使用状況メトリックを調べて追加のワークロードが特定された場合、増加する需要を組み込むために追加のリソースを名前空間に割り当てることができます。
Service Bus の課金メーターは時間単位です。 スケールアップの場合は、これらが使用された時間の追加リソースに対してのみ課金されます。
Premium メッセージングを使ってみる
Premium メッセージングは簡単に使い始めることができ、そのプロセスは Standard メッセージングと似ています。 まず、Azure Portal で名前空間を作成します。 [価格レベル] で [Premium] を選択します。 [価格の詳細を表示] を選択して、各レベルについての詳細を表示します。
Azure Resource Manager テンプレートを使用して Premium 名前空間を作成することもできます。
大きいメッセージのサポート
Azure Service Bus Premium レベルの名前空間では、最大 100 MB の大きいメッセージ ペイロードを送信する機能がサポートされています。 この機能は主に、他のエンタープライズ メッセージング ブローカー上で大きいメッセージ ペイロードが使用され、Azure Service Bus にシームレスに移行しようとしているレガシ ワークロードを対象としています。
Azure Service Bus 上で大きいメッセージを送信するときの考慮事項をいくつか次に示します。
- Azure Service Bus Premium レベルの名前空間上でのみサポートされます。
- Advanced Message Queuing Protocol (AMQP) プロトコルを使用している場合にのみサポートされます。 SBMP または HTTP プロトコルを使用しているときはサポートされません。Premium レベルでは、SBMP および HTTP プロトコルの最大メッセージ サイズは 1 MB です。
- Java Message Service (JMS) 2.0 クライアント SDK および他の言語のクライアント SDK を使用しているときにサポートされます。
- 大きいメッセージを送信すると、スループットが低下し、待機時間が長くなります。
- 100 MB のメッセージ ペイロードがサポートされていますが、Service Bus 名前空間からのパフォーマンスの信頼性を確保するために、メッセージ ペイロードはできるだけ小さくすることをお勧めします。
- 最大メッセージ サイズは、キューまたはトピックに送信されたメッセージにのみ適用されます。 サイズ制限は、受信操作には適用されません。 このため、特定のキュー (またはトピック) の最大メッセージ サイズは更新できます。
- バッチ処理はサポートされていません。
2026 年 9 月 30 日に Azure Service Bus 用の SBMP プロトコルのサポートは終了するため、2026 年 9 月 30 日以降はこのプロトコルを使用できなくなります。 その日付より前に、(重要なセキュリティ更新プログラムと強化された機能が提供される) AMQP プロトコルを使った最新の Azure Service Bus SDK ライブラリに移行してください。
詳細については、サポート廃止のお知らせに関するページを参照してください。
新しいキュー (またはトピック) に対して大きいメッセージのサポートを有効にする
大きいメッセージのサポートを有効にするには、次の画像に示すように、新しいキュー (またはトピック) を作成するときに最大メッセージ サイズを設定します。
既存のキュー (またはトピック) に対して大きいメッセージのサポートを有効にする
既存のキュー (またはトピック) に対して大きいメッセージのサポートを有効にすることもできます。これを行うには、次の画像に示すように、その特定のキュー (またはトピック) の [概要] で [最大メッセージ サイズ] を更新します。
ネットワークのセキュリティ
次のネットワーク セキュリティ機能は、Premium レベルでのみ使用できます。 詳しくは、ネットワーク セキュリティに関する記事をご覧ください。
Azure portal を使用した IP ファイアウォールの構成は、Premium レベルの名前空間でのみ使用できます。 ただし、Azure Resource Manager テンプレート、CLI、PowerShell、または REST API を使用して、他のレベルの IP ファイアウォール規則を構成することもできます。 詳細については、IP ファイアウォールの構成に関する記事をご覧ください。
保存データの暗号化
ストレージ サブシステムに格納されているすべてのデータは、Microsoft マネージド キーを使用して暗号化されます。 独自のキー (別名: カスタマー マネージド キー) を使用する場合、データは引き続き Microsoft マネージド キーを使用して暗号化されますが、さらに、Microsoft マネージド キーがカスタマー マネージド キーを使用して暗号化されます。 この機能を使用して、Microsoft マネージド キーの暗号化に使用されるカスタマー マネージド キーへの作成、ローテーション、無効化、およびアクセスの取り消しを実行できます。 カスタマー マネージド キー機能の有効化は、名前空間での 1 回限りのセットアップ プロセスです。 詳細については、Azure Service Bus の保存データの暗号化に関する記事をご覧ください。
パーティション分割
パーティション分割に関しては、Standard レベルと Premium レベルの間にいくつかの違いがあります。
- パーティション分割は、Basic または Standard SKU のすべてのキューおよびトピックに対するエンティティの作成で使用できます。 1 つの名前空間に、パーティション分割されたエンティティとパーティション分割されていないエンティティの両方を含めることができます。 Premium レベル用の名前空間の作成時にパーティション分割を使用でき、その名前空間内のすべてのキューとトピックがパーティション分割されます。 以前に移行された、Premium 名前空間内のパーティション分割されたエンティティは、引き続き期待どおりに動作します。
- Basic または Standard SKU でパーティション分割が有効になっている場合、Service Bus は 16 個のパーティションを作成します。 Premium レベルでパーティション分割が有効になっている場合、パーティションの数は名前空間の作成時に指定されます。
詳細については、Service Bus でのパーティション分割に関する記事をご覧ください。
geo ディザスターとリカバリー
Azure Service Bus により、1 つのデータセンター内の複数の障害ドメインにまたがるクラスター間で、個々のマシンまたはラック全体の致命的な障害のリスクが分散されています。また、透過的な障害検出およびフェールオーバー メカニズムが実装されるため、通常はそのような障害発生時にも、顕著な中断なしに、保証されたサービス レベル内でサービスが動作し続けます。 Premium 名前空間には 2 つ以上のメッセージング ユニットを含めることができます。これらのメッセージング ユニットは、データセンター内の複数の障害ドメインに分散され、すべてのアクティブな Service Bus クラスター モデルがサポートされます。
Premium レベルの名前空間の場合、物理的に分離された 3 つの施設間 (可用性ゾーン) で停止リスクがさらに分散されます。また、サービスには、データセンターの致命的な損失に瞬時に対処するための十分な容量が予約されています。 可用性ゾーンのサポートする、障害ドメイン内のオールアクティブ Azure Service Bus クラスター モデルは、致命的なハードウェア障害またはデータセンター機能全体の致命的な損失が発生した場合の回復性に関して、オンプレミスのメッセージ ブローカー製品よりも優れています。 それでも、広範囲の物理的な破壊によって、これらの手段によっても十分に防御できない致命的な状況が生じるおそれがあります。
Service Bus geo ディザスター リカバリー (Geo-DR) 機能は、容易にこの大きさの災害から復旧し、アプリケーションの構成を変更することなく、障害が発生した Azure リージョンを完全に破棄できるように設計されています。 Azure リージョンの破棄には、通常、いくつかのサービスが含まれます。この機能は、主に複合アプリケーション構成の整合性を維持するためのものです。 Service Bus Premium レベルでは、この機能がグローバルに使用できます。
geo ディザスター リカバリー機能を使用すると、名前空間 (エンティティ、構成、プロパティ) の構成全体が、プライマリ名前空間からペアになっているセカンダリ名前空間に継続的にレプリケートされるようになり、プライマリからセカンダリへの 1 回限りのフェールオーバーの移動をいつでも開始できます。 フェールオーバー移動を行うと、名前空間の選択したエイリアス名がセカンダリ名前空間に再指定されてから、ペアリングが解除されます。 フェールオーバーは、開始されるとほぼ瞬時に完了します。
詳細については、「Azure Service Bus の geo ディザスター リカバリー」を参照してください。
geo レプリケーション
geo レプリケーション機能は、障害および災害に対して Azure Service Bus アプリケーションを保護するオプションの 1 つであり、メタデータ (エンティティ、構成、プロパティ) とデータ (メッセージ データと、メッセージのプロパティ/状態の変更) の両方のレプリケーションを提供しますが、前のセクションで説明した Geo-DR 機能はメタデータのみをレプリケートします。
geo レプリケーション機能を使用すると、名前空間のメタデータとデータが、プライマリ Azure リージョンから 1 つ以上のセカンダリ Azure リージョンに、継続的にレプリケートされることが保証されます。
- キュー、トピック、サブスクリプション、フィルター。
- エンティティ内に存在するデータ。
- 名前空間内のメッセージに対して実行されたすべての状態変更とプロパティ変更。
- 名前空間の構成。
この機能を使用すると、任意のセカンダリ Azure リージョンをいつでもプライマリに昇格できます。 セカンダリを昇格すると、選択したセカンダリ Azure リージョンに名前空間の名前が再ポイントされ、プライマリとセカンダリの Azure リージョン間でロールが切り替わります。 昇格は、開始するとほぼ瞬時に行われます。
Java Message Service (JMS) のサポート
Premium レベルでは、JMS 1.1 および JMS 2.0 がサポートされます。 詳細については、Azure Service Bus Premium で JMS 2.0 を使用する方法に関する記事をご覧ください。
Standard レベルでは、キューに重点を置いた JMS 1.1 サブセットだけがサポートされています。 詳細については、Azure Service Bus Standard での Java Message Service 1.1 の使用に関する記事をご覧ください。
次のステップ
「メッセージング ユニットを自動的に更新する」記事を参照してください。