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

2021年10月11日

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

メッセージ・ブローカーは、正式なメッセージング・プロトコル間でメッセージを変換することにより、異なる言語で記述されていたり、異なるプラットフォームに実装されていたりする場合でも、アプリケーション、システム、およびサービスが通信して情報を交換できるようにするソフトウェアです。

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

メッセージ・ブローカーはメッセージを検証、保管、ルーティングし、適切な宛先に配信できます。他のアプリケーション間の仲介役として機能するため、送信者は、受信者がどこにいるか、アクティブかどうか、または受信者の数を知らなくてもメッセージを発行できます。これにより、システム内のプロセスやサービスの分離が容易になります。

メッセージ・ブローカーは、信頼性の高いメッセージ・ストレージと確実な配信を提供するために、消費側のアプリケーションが処理できるようになるまで、メッセージを格納して順序付けするメッセージ・キューと呼ばれるサブ構造またはコンポーネントに依存することがよくあります。メッセージキューでは、メッセージは送信されたとおりの順序で保存され、受信が確認されるまでキューに残ります。

非同期メッセージングとは、メッセージ・ブローカーによって可能になるアプリケーション間通信の種類を指します。これにより、貴重なデータの損失を防ぎ、公共ネットワークでよく見られる断続的な接続や遅延の問題に直面しても、システムを引き続き機能させることができます。非同期メッセージングでは、メッセージが他のメッセージに対して正しい順序で一回限り配信されることが保証されます。

メッセージ・ブローカーは、複数のメッセージ・キュー間の相互通信を処理するキュー・マネージャーや、データ・ルーティング、メッセージ変換、永続性、およびクライアント状態管理機能を提供するサービスで構成される場合があります。

ビジネス街をバックにスマホを持つ手

The DX Leaders

「The DX Leaders」は日本語でお届けするニュースレターです。AI活用のグローバル・トレンドや日本の市場動向を踏まえたDX、生成AIの最新情報を毎月お届けします。

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

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

ポイントツーポイント・メッセージング:メッセージの送信者と受信者が1対1の関係にあるメッセージキューで利用される配信パターンです。キュー内の各メッセージは1つの受信者にのみ送信され、1回だけ消費されます。ポイントツーポイント・メッセージングは、メッセージを1回だけ実行する必要がある場合に呼び出されます。このメッセージングスタイルに適したユースケースの例には、給与や金融取引の処理などがあります。これらのシステムでは、送信者と受信者の双方が、各支払いが一度(かつ一度だけ)送信されるという保証を必要とします。

パブリッシュ/サブスクライブ・メッセージング:このメッセージ配信パターンは、しばしば「pub/sub」と呼ばれます。このパターンでは、各メッセージ・プロデューサーが1つのトピックにメッセージをパブリッシュし、複数のメッセージ・コンシューマーがメッセージの受信を希望するトピックにサブスクライブします。トピックにパブリッシュされたすべてのメッセージは、そのトピックにサブスクライブしているすべてのアプリケーションに配信されます。これはブロードキャスト形式の配信方法であり、メッセージのパブリッシャーとその消費者の間に1対多の関係があります。たとえば、ある航空会社がフライトの着陸時間や遅延状況に関する最新情報を広める場合、航空機の保守や燃料補給を行う地上作業員、手荷物ハンドラー、フライト・アテンダント、次のフライトの準備をするパイロット、一般向けにディスプレイで通知するオペレーターなど、複数の関係者がその情報を利用できます。このシナリオでの使用には、Pub/Subメッセージング・スタイルが適しています。

AI Academy

ハイブリッドクラウドでAI対応を実現

IBMのエキスパートが主催するこのカリキュラムは、ビジネス・リーダーが成長を促進するAI投資に優先順位を付けるために必要な知識を習得できます。

クラウドアーキテクチャにおけるメッセージ・ブローカー

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

マイクロサービスには、連携して動作するために、相互に通信する手段が必要です。メッセージ・ブローカーは、この共有通信バックボーンを構築するために使用するメカニズムの1つです。

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

メッセージ・ブローカーとAPIの比較

REST APIは一般的にマイクロサービス間の通信に使用されます。Representational State Transfer(REST)は、開発者がウェブサービスを構築する際に従うことができる一連の原則と制約を定義します。RESTに準拠しているすべてのサービスは、統一された共有型のステートレスなオペレーターとリクエストのセットを介して通信できます。アプリケーション・プログラミング・インターフェース(API)は、RESTルールに準拠している場合に、サービスが相互に通信できるようにする基盤となるコードを示します。

REST APIは、Hypertext Transfer Protocol(HTTP)を使用して通信します。HTTPは公共インターネットの標準通信プロトコルであるため、REST APIは広く知られ、頻繁に使用され、広範な相互運用が可能です。ただし、HTTPは要求/応答プロトコルであるため、同期要求/応答が必要な状況で使用するのが最適です。これは、REST API経由でリクエストを行うサービスは、即時の応答を想定するように設計する必要があることを意味します。応答を受信するクライアントがダウンしている場合、応答を待つ間、送信サービスはブロックされます。フェイルオーバーとエラー処理ロジックは、両方のサービスに組み込む必要があります。

メッセージ・ブローカーはサービス間の非同期通信を可能にするので、送信側のサービスは受信側のサービスの応答を待つ必要がありません。これにより、メッセージ・ブローカーが採用されているシステムではフォールト・トレランスとレジリエンスが向上します。さらに、メッセージ・ブローカーを使用することで、パブ/サブのメッセージングパターンがサービス数の変化に容易に対応できるため、システムを拡張しやすくなります。また、メッセージ・ブローカーはコンシューマーの状態も記録します。

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

メッセージ・ブローカーは、メッセージ・キューやPub/Subを含む2つ以上のメッセージング・パターンをサポートできますが、イベント・ストリーミング・プラットフォームはPub/Subスタイルの配信パターンのみを提供します。イベント・ストリーミング・プラットフォームは、大量のメッセージに対応するように設計されており、容易に拡張可能です。レコードのストリームをトピックと呼ばれるカテゴリーに分類し、所定の時間だけ保存することができます。ただし、メッセージ・ブローカーとは異なり、イベント・ストリーミング・プラットフォームはメッセージの配信を保証したり、どのコンシューマーがメッセージを受信したかを追跡したりすることはできません。

イベント・ストリーミング・プラットフォームは、メッセージ・ブローカーよりも拡張性が高いものの、フォールト・トレランス(メッセージの再送信など)や、より制限されたメッセージ・ルーティングおよびキューイング機能を保証する機能が少なくなっています。

イベント駆動型アーキテクチャーに関する詳細はこちら。

メッセージ・ブローカーとESB(エンタープライズ・サービス・バス)の比較

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

ただし、ESBインフラストラクチャは複雑で、統合が難しく、保守に費用がかかる場合があります。本番環境で問題が発生した場合、トラブルシューティングは難しく、拡張は容易ではなく、更新は面倒です。

メッセージ・ブローカーは、同様の機能 (サービス間通信のメカニズム) をよりシンプルかつ低コストで提供する、ESBの「軽量な」代替手段です。ESBが支持されなくなったために普及が進んだマイクロサービスアーキテクチャでの使用に適しています。

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

メッセージ・ブローカーを実装すると、業種・業務を超えた、多様なエンタープライズ・コンピューティング環境内のさまざまなビジネス上のニーズに対応できます。メッセージ・ブローカーは、信頼性の高いアプリケーション間の通信と保証されたメッセージ配信が必要な場合に、時と場所を選ばず、役立ちます。

メッセージ・ブローカーは、多くの場合、次の方法で使用されます。

  • 金融取引と支払い処理:支払いが一度(かつ一度だけ)行われるようにすることが重要です。メッセージブローカーを使用してこれらのトランザクションのデータを処理することで、支払い情報が失われたり、誤って複製されたりすることがなくなり、受信の証明が得られ、仲介ネットワークがダウンしている場合でもシステムが確実に通信できるようになります。

  • Eコマースの注文処理とフルフィルメント: オンラインでビジネスを展開している場合、ブランドの評判はウェブサイトとeコマース・プラットフォームの信頼性に左右されます。フォールト・トレランスを強化し、メッセージが一度(かつ一度だけ)消費されることを保証するメッセージ・ブローカーの機能により、オンライン注文を処理する際には、メッセージ・ブローカーを使うことが自然な選択肢となっています。

  • 機密性の高いデータを保管時および転送時に保護:規制の厳しい業界や、事業が重大なセキュリティリスクに直面している場合は、エンドツーエンドの暗号化機能を備えたメッセージング・ソリューションをお選びください。
関連ソリューション
IBM MQ

ビジネス向けに、高性能でセキュリティーが充実した確実な配信メッセージングを実現しましょう。

IBM MQの詳細はこちら
クラウド・コンサルティング・サービス

ビジネスの俊敏性と成長を加速—IBMのクラウド・サービスとコンサルティングを利用して、あらゆるプラットフォーム上のアプリケーションを継続的にモダナイズします。

クラウド・コンサルティング・サービスの詳細はこちら
IBMインテグレーション・ソフトウェアおよびソリューション

統合プラットフォーム・ソフトウェアで接続・自動化して、ビジネスの可能性の解放しましょう。

 

統合ソフトウェアとソリューションの詳細はこちら
次のステップ

メッセージングネットワークを介してアプリケーションを動的、安全、確実に接続し、疎結合のメッセージ駆動型アプリケーションやイベント駆動型アプリケーションを大規模に構築できます。

    IBM MQの詳細はこちら IBMの統合ソフトウェアとソリューションをご覧ください