メッセージ・ブローカー
黒と青の背景
メッセージ・ブローカー

メッセージ・ブローカーは、クラウド・ネイティブ、マイクロサービス・ベース、サーバーレス、およびハイブリッドクラウド・アーキテクチャーをサポートする共通の統合メカニズムを構築するためのアプリケーション間通信技術です。


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

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

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

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

メッセージ・ブローカーは、信頼性の高いメッセージの保存と保証されたデリバリーを提供するために、多くの場合、 メッセージ・キュー と呼ばれる下部構造またはコンポーネントに依存しています。メッセージ・キューは、利用者側のアプリケーションがメッセージを処理できるようになるまで、メッセージを保存し、順序付けます。 メッセージ・キューでは、メッセージは送信された正確な順序で保存され、受信が確認されるまでキューに残ります。

非同期メッセージング (15:11)とは、メッセージ・ブローカーが実現するアプリケーション間通信の種類を指します。 パブリック ネットワークでよく起きる、断続的な接続性や遅延の問題があっても、貴重なデータの損失を防ぎ、システムの機能を維持することができます。 非同期メッセージングは、メッセージが他のメッセージに対して正しい順序で、1度限り配信されることを保証します。

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

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

メッセージ・ブローカーには、2つの基本的なメッセージ配信パターンまたはメッセージング・スタイルがあります。

  • ポイント・ツー・ポイント・メッセージング:  これは、メッセージの送信者と受信者が1対1の関係にあるメッセージ・キューで採用されている配布パターンです。 キュー内の各メッセージは、1人の受信者にのみ送信され、1度だけ消費されます。 ポイント・ツー・ポイント・メッセージングは、メッセージが1度だけ実行される必要がある場合に使用されます。 このメッセージング・スタイルに適したユースケースの例としては、給与計算や金融取引の処理などが挙げられます。 このようなシステムでは、送信者と受信者の両方が、各支払いが1度限り送信されることを保証する必要があります。
  • パブリッシュ/サブスクライブ・メッセージング:  「pub/sub」と呼ばれるこのメッセージ配信パターンでは、各メッセージのプロデューサーがトピックにメッセージをパブリッシュし、複数のメッセージ・コンシューマーがメッセージを受信したいトピックをサブスクライブします。 あるトピックに公開されたメッセージは、そのトピックをサブスクライブしているすべてのアプリケーションに配信されます。 これはブロードキャスト形式の配信方法で、メッセージの発行者とその消費者の間には一対多の関係があります。 例えば、航空会社が自社便の着陸時刻や遅延状況などの最新情報を配信した場合、航空機の整備や給油を行う地上作業員、荷物の運搬を行う人、次のフライトの準備をする客室乗務員やパイロット、および一般の人に情報を伝えるディスプレイでのオペレーターなど、複数の人がその情報を利用することができます。 このシナリオでは、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を介してリクエストを行うサービスは、即時のレスポンスを期待して設計されなければなりません。 レスポンスを受け取るクライアントがダウンしている場合、リプライを待つ間、送信側のサービスはブロックされます。 フェイルオーバーとエラー処理のロジックは、両方のサービスに組み込まれている必要があります。

メッセージ・ブローカーは、サービス間の非同期通信を可能にし、送信側のサービスが受信側のサービスからのリプライを待つ必要がなくなります。 これにより、採用されたシステムのフォールト・トレランスと回復力が向上します。 また、メッセージ・ブローカーを使用することで、pub/subメッセージング・パターンがサービスの数の変化に容易に対応できるため、システムの拡張が容易になります。 メッセージ・ブローカーは、消費者の状態も把握しています。


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

メッセージ・ブローカーは、メッセージ・キューやpub/subなど、2つ以上のメッセージング・パターンをサポートしていますが、イベント・ストリーミング・プラットフォームでは、pub/sub形式の配信パターンしか提供していません。 大量のメッセージを扱うために設計されたイベント・ストリーミング・プラットフォームは、容易に拡張することができます。 流れてくる記録をトピックと呼ばれるカテゴリーに分類し、あらかじめ決められた時間だけ保存することができます。 しかし、メッセージ・ブローカーとは異なり、イベント・ストリーミング・プラットフォームは、メッセージの配信を保証したり、どの消費者がメッセージを受け取ったかを追跡することはできません。

イベント・ストリーミング・プラットフォームは、メッセージ・ブローカーに比べて拡張性は高いものの、フォールト・トレランスを確保する機能(メッセージの再送など)は少なく、メッセージのルーティングやキューイングの機能も限られています。

 イベント・ドリブン・アーキテクチャーの詳細はこちら


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

 エンタープライズ・サービス・バス(ESB) は、企業に導入されている サービス指向アーキテクチャー で利用されることのあるアーキテクチャー・パターンです。 ESBでは、一元化されたソフトウェア・プラットフォームが、通信プロトコルやデータ・フォーマットを「共通言語」としてまとめ、アーキテクチャー内のすべてのサービスおよびアプリケーションが共有できるようにします。 例えば、受け取ったリクエストを、あるプロトコル(XMLなど)から別のプロトコル(JSONなど)に変換することができます。 ESBは、自動化されたプロセスを用いてメッセージのペイロードを変換します。 一元化されたソフトウェアプラットフォームは、接続性、ルーティング、およびリクエスト処理など、その他のオーケストレーション・ロジックも処理します。

しかし、ESBのインフラは複雑で、統合が難しく、維持費が高い場合があります。 実稼働環境で問題が発生した場合のトラブルシューティングが難しく、スケールアップも容易ではなく、更新作業も面倒です。

メッセージ・ブローカーは、ESBに代わる「軽量」なもので、サービス間のコミュニケーションのためのメカニズムという同様の機能を、よりシンプルに、より低コストで提供します。 ESBの衰退に伴って普及したマイクロサービス・アーキテクチャーでの使用に適しています。


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

メッセージ・ブローカーを導入することで、業界を超えて、エンタープライズ・コンピューティング環境の多様なビジネスニーズに対応することができます。 信頼性の高いアプリケーション間通信と確実なメッセージ配信が必要な場合には、いつでもどこでも役立ちます。

メッセージ・ブローカーは、次のような場合に採用されることが多いです。

  • 金融取引および支払処理:  支払が1度限り行われることを確実にすることが重要です。 これらのトランザクションのデータを処理するためにメッセージ・ブローカーを使用することで、支払い情報の紛失や誤った複製がないことが保証され、受領の証明となり、中間ネットワークが停止してもシステムは確実に通信することができます。
  • e-コマース注文処理とフルフィルメント: オンラインでビジネスを行っている場合、ブランドの評判の良し悪しは、ウェブサイトやe-コマース・プラットフォームの信頼性にかかっています。 メッセージ・ブローカーは、フォールト・トレランスを強化し、メッセージが1度限り消費されることを保証する機能を備えているため、オンライン注文を処理する際に使用するのが自然な選択です。
  • 保存中および転送中の機密データの保護:  規制の厳しい業界や、重大なセキュリティー・リスクに直面しているビジネスでは、エンドツーエンドの暗号化機能を備えたメッセージング・ソリューションを選択してください。

メッセージ・ブローカーとIBM Cloud

メッセージ・ブローカーは、クラウドへの行程で組織が アプリケーションをモダナイズ する際に、新たな重要性を帯びてきています。 世界で最も成功している企業の多く(Fortune 100の85%を含む)が、今日のアジャイルな開発環境、マイクロサービス・ベースとハイブリッドクラウド・インフラストラクチャー、および幅広いシステム・タイプと接続要件をサポートするように構築されているIBMのメッセージ・ブローカー機能に信頼を寄せています。

次のステップ:エンタープライズ・メッセージング・ソリューションの代表格である IBM MQのコア機能をベースに開発された IBM Cloud Pak for Integrationについてご紹介します。

 IBM Cloudアカウント で今すぐ始めましょう。


関連ソリューション

IBM MQ

IBM MQは、アプリケーション間で情報を巧みにかつ安全に移動させるエンタープライズ・グレードのメッセージング機能を提供します。


統合の自動化

アプリケーション、サービス、データを、市場で最も包括的な統合プラットフォームであるIBM Cloud Pak for Integrationで連携できます。