メッセージ・ブローカーとは

メッセージ・ブローカーは、アプリケーション、システム、サービスが相互に通信し、情報を交換することを可能にするソフトウェアです。それを行うために、メッセージ・ブローカーは、正式なメッセージング・プロトコル間でメッセージを変換します。この変換により、相互依存するサービスは、作成された言語や実装されたプラットフォームが異なっていても、互いに直接「対話」することができます。

メッセージ・ブローカーは、メッセージング・ミドルウェア・ソリューションまたはメッセージ指向ミドルウェア（MOM）ソリューション内のソフトウェア・モジュールです。このタイプのミドルウェアは、アプリケーションのコンポーネント間のデータ・フローを処理する標準化された手段を提供することで、開発者がアプリケーションの中核ロジックに集中できるようにします。また、分散通信層として機能するため、複数のプラットフォームにわたるアプリケーションでの内部通信を可能にします。

メッセージ・ブローカーは、メッセージの検証、保管、経路指定、適切な宛先へのデリバリーを行うことができます。また、他のアプリケーションとの間で仲介役として機能するため、受信側の場所、その活動状態、または数量を知らなくても、送信側がメッセージを発行できるようにします。これにより、システム内のプロセスとサービスの分離が容易になります。

メッセージ・ブローカーは多くの場合、信頼性の高いメッセージ保管と確実なデリバリーを実現するために、メッセージ・キューと呼ばれるサブストラクチャーまたはコンポーネントに依存しています。このキューには、コンシューム側アプリケーションがメッセージを処理できるようになるまでメッセージが保管されて配列されます。メッセージ・キュー内では、メッセージは送信されたとおりの順序で保管され、受信が確認されるまでキューに残ります。

非同期メッセージング（15:11）（英語）では、メッセージ・ブローカーにより可能になるアプリケーション間通信のタイプに言及しています。非同期メッセージングは、貴重なデータの損失を防ぎ、パブリック・ネットワークでよくある断続的な接続や遅延の問題が発生した場合でもシステムが機能を継続できるようにします。非同期メッセージングでは、メッセージが他のメッセージと相対的に正しい順序で確実に一度だけデリバリーされることが保証されます。

メッセージ・ブローカーは、複数のメッセージ・キュー間の対話を処理するためのキュー・マネージャーと、データ・ルーティング、メッセージ変換、持続性、クライアント状態管理の機能を提供するサービスで構成することができます。

メッセージ・ブローカーのモデル

メッセージ・ブローカーは以下の2つの基本メッセージ配信パターンまたはメッセージング・スタイルを提供します。

Point-to-Pointメッセージング：メッセージの送信側と受信側の間に1対1の関係がある、メッセージ・キューで使用される配信パターンです。キュー内の各メッセージは単一の受信側にのみ送信され、一度のみコンシュームされます。メッセージの処理が一度のみでなければならない場合、Point-to-Pointメッセージングが必要になります。このメッセージング・スタイルに適したユースケースの例としては、給与計算処理や金融取引処理などがあります。これらのシステムでは、それぞれの支払の送信が確実に一度のみ行われるという保証を、送信側と受信側の両方が必要とします。

パブリッシュ/サブスクライブ・メッセージング：「pub/sub」と呼ばれることが多いこのメッセージ配信パターンでは、各メッセージのプロデューサーはメッセージをトピックにパブリッシュし、複数のメッセージ・コンシューマーはメッセージを受信したいトピックをサブスクライブします。トピックにパブリッシュされたすべてのメッセージは、そのトピックをサブスクライブしているすべてのアプリケーションに配信されます。これは、メッセージのパブリッシャーとそのコンシューマーとの間に1対多の関係がある、ブロードキャスト・スタイルの配信方式です。例えば、航空会社が自社便の着陸時刻や遅延状況などの最新情報を配信した場合、航空機の整備や給油を行う地上作業員、荷物の運搬を行う人、次のフライトの準備をする客室乗務員やパイロット、および一般の人に情報を伝えるディスプレイのオペレーターなど、複数の人がその情報を利用することができます。このシナリオで使用するためには、パブリッシュ/サブスクライブ・メッセージング・スタイルが適しています。

クラウド・アーキテクチャー内のメッセージ・ブローカー

クラウドネイティブ・アプリケーションは、柔軟性、拡張性、迅速な導入など、クラウド・コンピューティングの固有のメリットを活用するよう構築されています。これらのアプリケーションは、マイクロサービスと呼ばれる個別で再使用可能な小さいコンポーネントで構成されます。各マイクロサービスは、導入した後に互いに独立して実行できます。これは、どのマイクロサービスも、システム内の他のサービスに影響を与えることなく、更新、拡大、または再始動できることを意味します。コンテナにパッケージ化されることが多いマイクロサービスは、複数が連携してアプリケーション全体を構成します。各マイクロサービスには、他とは異なる可能性があるデータベースやデータ・モデルを含めて、それぞれ独自のスタックがあります。

マイクロサービスは、協調して機能するために、互いに通信する手段を持っている必要があります。メッセージ・ブローカーは、この共有された通信バックボーンの作成にマイクロサービスが使用するメカニズムの1つです。

メッセージ・ブローカーは、ハイブリッドクラウド環境内のオンプレミス・システムとクラウド・コンポーネントの間の通信を管理するためによく使用されます。メッセージ・ブローカーを使用すると、サービス間通信に対する制御が強化され、データがアプリケーションのコンポーネント間で安全に、信頼性高く効率的に送信されるようになります。メッセージ・ブローカーは、マルチクラウド環境の統合において同様の役割を果たせるため、異なるプラットフォーム上にあるワークロードとランタイムの間の通信を可能にします。また、個々のクラウド・ホスティング・サービスが要求ごとにオンデマンドで実行される、サーバーレス・コンピューティング（英語）での使用にも適しています。

メッセージ・ブローカーとAPI

REST API は、マイクロサービス間の通信によく使用されます。 Representational State Transfer（REST）という用語は、Webサービスを構築する際に開発者が従うことができる、一連の原則と制約を定義します。これらに従うサービスは、均一で共有されたステートレスのオペレーターと要求のセットを介して通信できるようになります。アプリケーション・プログラミング・インターフェース（API）は、RESTルールに準拠している場合にサービスでの相互の対話を可能にする、基本となるコードを示します。

REST APIは、Hypertext Transfer Protocol（HTTP）を使用して通信します。 HTTPは公衆インターネットの標準トランスポート・プロトコルであるため、REST APIは広く知られており、頻繁に使用され、広く相互運用されています。ただし、HTTPは要求/応答プロトコルであるため、同期的な要求/応答が必要な状況で使用するのが最適です。これは、REST APIを介して要求を行うサービスは、即時応答を期待するように設計されている必要があることを意味します。応答を受信するクライアントがダウンすると、送信側サービスは、応答が来るまでブロックされます。フェイルオーバーとエラー処理ロジックを両方のサービスに構築する必要があります。

メッセージ・ブローカーは、サービス間の非同期通信を可能にするので、送信側サービスが受信側サービスの応答を待機する必要がなくなります。これにより、メッセージ・ブローカーが使用されているシステムでの耐障害性とレジリエンシーが向上します。さらに、メッセージ・ブローカーを使用すると、パブリッシュ/サブスクライブ・メッセージング・パターンはサービス数の変更を直ちにサポートできるため、システムの拡張が容易になります。メッセージ・ブローカーは、コンシューマーの状態も追跡します。

メッセージ・ブローカーとイベント・ストリーミング・プラットフォーム

メッセージ・ブローカーは、メッセージ・キューやパブリッシュ/サブスクライブを含む複数のメッセージング・パターンをサポートできますが、イベント・ストリーミング・プラットフォームはパブリッシュ/サブスクライブ・スタイルの配信パターンのみを提供します。イベント・ストリーミング・プラットフォームは大量のメッセージを使用するために設計されており、すぐに拡張可能です。レコードのストリームをトピックと呼ばれるカテゴリーに配列し、事前に指定された時間だけ保管できます。ただし、イベント・ストリーミング・プラットフォームはメッセージ・ブローカーとは異なり、メッセージ配信を保証したり、どのコンシューマーがメッセージを受信したかを追跡することはできません。

イベント・ストリーミング・プラットフォームは、メッセージ・ブローカーよりも高い拡張性を提供しますが、耐障害性（メッセージの再送信など）を確保する機能は少なく、メッセージのルーティングとキューイングの機能はより制限されています。

イベント駆動型アーキテクチャーの詳細はこちらをご覧ください。

メッセージ・ブローカーとESB（エンタープライズ・サービス・バス）

エンタープライズ・サービス・バス（ESB）は、企業全体にわたって実装されるサービス指向アーキテクチャー（SOA）で使用されることがあるアーキテクチャー・パターンです。 ESBでは、一元化されたソフトウェア・プラットフォームが、通信プロトコルとデータ・フォーマットを、アーキテクチャー内のすべてのサービスとアプリケーションが共有できる「共通言語」に結合します。例えば、受信した要求を1つのプロトコル（XMLなど）から別のプロトコル（JSONなど）に変換できます。 ESBは、自動プロセスを使用してメッセージ・ペイロードを変換します。一元化されたソフトウェア・プラットフォームは、接続、ルーティング、要求処理などの他のオーケストレーション・ロジックも処理します。

しかし、ESBインフラストラクチャーは複雑であり、統合が困難で維持のコストが高い場合があります。実稼働環境で問題が発生した場合のトラブルシューティングは困難であり、拡張は容易ではなく、更新作業は単調です。

メッセージ・ブローカーは、ESBに代わる「軽量の」選択肢であり、サービス間通信のメカニズムに類似する機能をより簡単に安価で提供します。これらはESBがあまり使われなくなるにつれて普及してきたマイクロサービス・アーキテクチャーでの使用に適しています。

メッセージ・ブローカーのユースケース

メッセージ・ブローカーを実装すると、複数の業界や多様なエンタープライズ・コンピューティング環境にわたる幅広い種類のビジネス・ニーズに対応できるようになります。信頼できるアプリケーション間通信や保証されたメッセージ配信が必要な場合に、場所や機会を問わず役に立ちます。

メッセージ・ブローカーは、次のように使用されることがよくあります。

金融取引と決済処理： 支払が確実に一度のみ送信されることが重要になります。メッセージ・ブローカーを使用してこれらのトランザクションのデータを処理すると、支払情報が失われず、偶発的な重複もないことが保証されます。また、受信の証明が提供され、中間ネットワークがダウンしたときでもシステムは確実に通信できます。
e-コマースの注文の処理と履行： ビジネスをオンラインで行っている場合、ブランドの評判の高さは、Webサイトとe-コマース・プラットフォームの信頼性によって決まります。メッセージ・ブローカーは、強い耐障害性を持ち、メッセージが一度だけコンシュームされることを保証する機能があるため、オンライン注文の処理に非常に適した選択肢となっています。
保存時と移動中の機密データの保護： 業界の規制が厳しい場合、またはビジネスが重大なセキュリティー・リスクに直面している場合は、エンドツーエンドの暗号化機能を備えたメッセージング・ソリューションを選択します。