Azure Service Bus では、慣れ親しんだキューとトピック サブスクリプションのセマンティクスを業界主導の Advanced Message Queuing Protocol (AMQP) プロトコルで利用することによって、エンタープライズ メッセージングのシナリオがシンプルになります。お客様には Azure サービスと緊密に統合されたフル マネージドのサービスとしてのプラットフォーム (PaaS) オファリングが提供され、高可用性、セキュリティで保護された設計、スケーラビリティを最上級のエクスペリエンスとして実現しながら、高スループットで信頼性の高い待機時間のメッセージング ブローカーが提供されます。Microsoft では、大部分のアプリケーション スタックとエコシステムにおけるお客様のワークロードのために、Azure Service Bus を提供することを目標としています。

このビジョンに沿って、Azure Service Bus の Premium レベルで AMQP による Java Message Service (JMS) 2.0 のサポートがプレビューになったことをお知らせいたします。このことにより、お客様は Java と Spring のワークロードをシームレスに Azure にリフト アンド シフトできるようになると同時に、クラウドにおける最高レベルのエンタープライズ メッセージングによってアプリケーション スタックを最新化できるようにもなります。

企業のお客様は、ワークロードを Azure へリフト アンド シフトしようとするときに、クラウドネイティブの Azure オファリングを活用することで、アプリケーション スタックを最新化する機会を得ることができます。これは、データを格納または移動するデータ プレーンのコンポーネントにより適していて、サービスとしてのインフラストラクチャ (IaaS) でホストされているセットアップから、よりクラウドネイティブな PaaS のセットアップへ移行することによるメリットがあります。

データベースとデータ ストアでは、標準化された API とプロトコルが確立されたことで、シームレスな移行への道が開かれました。アプリケーションは実際のプロバイダーまたはこの標準化された API の実装に依存せず、ごくわずかまたは構成のみのコード変更によって、アプリケーションが現在のオンプレミスのプロバイダーから Azure のフル マネージド PaaS オファリングに移行でき、予期したとおりに動作します。

エンタープライズ メッセージング エコシステムは近年までデータ エコシステムと比べて大幅に分断化されていましたが、AMQP 1.0 プロトコルが 2011 年に標準化されたことで、プロトコルの実装によってすべてのエンタープライズ メッセージ ブローカー間で一貫性のある動作が保証されるようになりました。しかし、それでも API コントラクトの標準化には至らなかったので、エンタープライズ メッセージング スペースの分断化は存続しています。

Java Enterprise コミュニティ (さらには Spring) は、エンタープライズ メッセージング ブローカーとやり取りを行うときにプロデューサーとコンシューマー アプリケーションで利用される API を標準化するために、Java Message Service (JMS 1.1 および 2.0) の仕様をいくらか進展させました。Apache QPID コミュニティは、AMQP による JMS の API 仕様の実装によって、これを前進させました。QPID-JMS は、スタンドアロンであっても Spring JMS パッケージの一部であっても、さまざまなメッセージ ブローカーを使用して作業しているほとんどの企業のお客様にとって事実上の JMS 実装です。

AMQP による Azure Service Bus への既存のアプリケーションの接続

このプレビューでサポートされている機能の一覧 (一般提供で完全に同等のものを予定) に従って、Azure Service Bus ではすべての Java Message Service API コントラクトがサポートされているため、お客様は既存のアプリケーションを修正せずに Azure で利用できます。現在サポートされている JMS の機能の一覧は以下のとおりです。

• キュー。
• トピック。
• 一時キュー。
• 一時トピック。
• サブスクリプション。
  • 共有の永続的サブスクリプション。
  • 共有の非永続的サブスクリプション。
  • 非共有の永続的サブスクリプション。
  • 非共有の非永続的サブスクリプション。
• QueueBrowser。
• TopicBrowser。
• 上記の全エンティティの自動作成 (まだ存在しない場合)。
• メッセージ セレクター。
• 配信遅延 (スケジュール設定されたメッセージ) を使用したメッセージの送信。

オンプレミスまたは IaaS でホストされている JMS プロバイダーから Azure Service Bus へのシームレスな移行

既存の JMS ベースのアプリケーションを Azure Service Bus に接続するには、Azure Service Bus JMS Maven パッケージまたは Spring Boot 用の Azure Service Bus スターターをアプリケーションの pom.xml に追加して、Azure Service Bus 接続文字列を構成パラメーターに追加するだけです。

前述のように、構成のみのコード変更により、お客様はメッセージ ブローカーに依存しないビジネス ロジックを維持でき、ベンダー ロックインを防ぐことができます。
  

シンプルな価格設定、簡単なデプロイ、スケーラブルなリソース割り当て

Azure Service Bus での JMS のサポートを活用することにより、お客様はライセンスを調達したり独自の IaaS コンピューティングでエンタープライズ メッセージング ブローカーを管理したりするオーバーヘッドをなくし、メッセージング ユニットごとの固定価格でコスト管理をシンプルにできるようになりました。また、プロビジョニングの自動スケールアップおよびダウンを活用してワークロードの変動に対応できます。

他の Azure オファリングとの統合によるアプリケーション スタックのさらなる最新化

Azure Service Bus を他の Azure オファリングと統合できるので、アプリケーション スタックを最新化してシンプルにすることもできます。それを行う方法をいくつかご紹介します。

1. Azure Logic Apps: Azure Service Bus 用の Azure Logic Apps コネクタを利用して、さまざまな重要なビジネス ワークフローを、シンプルなローコードの従量課金制のサーバーレス オファリングに置き換えることができます。
2. Azure Functions: Azure Service Bus 用の Azure Functions トリガーを利用して、カスタム アプリケーションをシンプルな従量課金制のサーバーレス PaaS オファリングに置き換えることができます。
3. Azure Monitor とアラート: Azure Monitor とアラートを利用して、Azure Service Bus の名前空間、キュー、トピック、サブスクリプション レベルのメトリックを監視できます。
4. Azure KeyVault: Azure KeyVault との統合を利用して、カスタマー マネージド キーで名前空間のデータを暗号化できます。
5. 仮想ネットワークとプライベート エンドポイント: 仮想ネットワーク サービス エンドポイントを使用して Azure Service Bus へのアクセスをセキュリティで保護できます。プライベート エンドポイントを使用して、プライベート ネットワークでホストされているアドレスによって、クラウドでホストされているサービスに接続できます。

今すぐご利用ください

今すぐご利用になるには、Service Bus 名前空間と JMS の機能のプロビジョニングを行い、既存の Java および Spring アプリケーションを Apache ActiveMQ から Service Bus へ移行しましょう。