メッセージブローカーとは？ Wallarm解説

メッセージブローカー(MB)とは？

これは、さまざまなサービスやプログラム間で、送信や統計情報の共有のためにメッセージを交換しやすくする無料ソフトです。Cloud-native、OpenStack、マイクロサービスベース、そして複合クラウドフレームワークなどは、標準的な通信方法を得ることでMBの恩恵を受けることができます。

この目的のため、対応するメッセージ形式間で通信内容を変換します。これにより、全く異なるプログラミング言語を利用していても、互いに依存するサービス同士が即時に連携しやすくなります。

‍

メッセージブローカーの主な構成要素

MBの内部構造を詳しく確認していきます。

• Producer: この部分はコマンドの送信とメッセージブローカーとの通信を担当します。パブリッシュ/サブスクライブ方式では、発行者と呼ばれます。
• Consumer: この部分はMBからメッセージを受信する役割を担います。パブリッシュ/サブスクライブ方式では、加入者と呼ばれます。
• Queue: メッセージブローカーとメッセージキューの違いは、MBがFIFO原則に基づいてコマンドを順序付けて保存するために、キューというデータ型を利用する点にあります。 
• Exchanger: これは、キュー上に構築された論理的な仕組みで、コンシューマーやプロデューサーがコマンドの送受信を行うグループを形成できるよう、キューへの書き込みや監視を制御します。

‍

マイクロサービスにおけるメッセージブローカーとは？

マイクロサービスのフレームワークでシステムを開発すると、完成時には複数のマイクロサービスが存在するようになります。その際の課題は、各サービス間の連携がうまくいかない点です。中央のブローカーを利用すれば、各マイクロサービスが相互に調整可能となります。さらに、新しいサービスを追加する場合も、単にブローカーに接続するだけで済みます。

‍

メッセージブローカーのパターン

基本的な通信配信方式には次の2種類があります:

• ポイントツーポイント通信

送信者と受信者が1対1で対応する場合に、この方式が採用されます。キュー内の各メッセージはたった一人の受信者によって処理されるため、一度だけの確実な処理が求められる給与計算や金融取引などに適しています。

• パブリッシュ/サブスクライブ方式:

この方式では、まずコマンドが作成されトピックへ投稿され、その後、複数のコンシューマーがそのトピックを購読します。購読しているすべてのアプリが投稿されたメッセージを受け取る仕組みとなっており、単一の情報源から多数の受信者へ情報が共有されます。たとえば航空会社が最新の運航情報を一斉に発信する場合などに適しています。

‍

メッセージブローカーとAPIの違い

「Representational State Transfer（REST）」は、ウェブサービス構築のための一連のガイドラインを指します。REST APIはマイクロサービス間の通信によく利用され、統一されたステートレスな操作やリクエストを提供します。

REST API間の通信はHTTP上で行われます。しかし、HTTPはリクエスト/レスポンスプロトコルであるため、シンクロナスな処理が必要な場合にAPIセキュリティが効果を発揮します。そのため、要求や命令を行うサービス向けのREST APIは、ゼロレイテンシの応答を前提として設計される必要があります。もし、応答待ちのメッセージブローカーが利用できなければ、送信側は応答が返るまで待たされます。APIゲートウェイとメッセージブローカーの両方とも、冗長性やエラー処理の仕組みを持つべきです。

一方、MBはサービス間で非同期通信を可能にし、互いの応答を待つ必要がなくなります。これにより、システムの堅牢性と障害耐性が向上し、パブリッシュ/サブスクライブ方式のアーキテクチャはサービスの調整を容易にするため、システムのスケールアップも簡単になります。さらに、MBは利用状況を記録します。

‍

メッセージブローカーとESSの違い

イベントストリーミングソリューション（ESS）はパブリッシュ/サブスクライブ方式のみを提供するのに対し、メッセージブローカーは通常、複数の通信方式を備えています。大量のデータ処理を前提に設計されたESSは容易に拡張でき、受信データをテーマごとに分類し一定期間保存することが可能です。しかし、ESSではメッセージが正常に配信されたか、どの顧客に届けられたかを確認する手段がありません。

ESSは同時接続ユーザー数の拡張性で優れていますが、メッセージの再送やキューイングといった堅牢な障害対策機能が不足しています。

‍

メッセージブローカーとESBの違い

ビジネス向けのサービス指向アーキテクチャにおいて用いられるESB（Enterprise Service Bus）は、通信プロトコルやデータフォーマットを共通の言語に統合し、すべてのサービスやアプリが共有できるようにします。メッセージブローカーの例では、例えばXMLからJSONへの変換が可能です。ESBはペイロードの変換を自動化し、集中管理されたプラットフォームが接続、ルーティング、リクエスト処理を担います。

ESBは構築や維持が複雑で、運用環境でのトラブルシューティング、スケーリング、更新が難しいため、同等の機能をより低コストで提供する軽量な代替手段が求められています。ESBの人気が低下する中、マイクロサービスアーキテクチャの支持が広がっています。

‍

メッセージブローカーの利用例

メッセージブローカーは、さまざまな業種や企業コンピューティング環境において、多様なビジネス要件を満たすために活用されます。

以下は、メッセージブローカーがよく利用される一般的な用途です:

• ECサイトでの注文処理や受注業務: オンラインで事業を展開する場合、ウェブサイトやECプラットフォームの信頼性がブランド評価に大きく影響します。障害耐性の向上やメッセージの一回限りの処理を実現できるため、オンライン注文の処理に適しています。
• 決済処理および金融取引: 支払いが一度だけ行われることが重要です。メッセージブローカーを利用することで、決済情報が失われたり重複したりすることなく、確実に確認でき、仲介ネットワークが不安定な場合でもシステム間で安定した連携が実現できます。
• 機密性の高いデータの保管中および送信中の安全確保: 規制の厳しい業界や重大なセキュリティ課題に直面している場合、エンドツーエンド暗号化に対応した通信システムを選択することで安全性が高まります。

‍

実際のメッセージブローカー活用例

• Rest APIs

最近では、ウェブフロントエンドやモバイルアプリをREST APIバックエンドと組み合わせて利用する例が一般的です。クライアントサーバーの通信はHTTPを用いて行われます。しかし、リクエストで得た情報の処理に長時間を要する場合、または計算処理に時間がかかる場合はどうなるでしょうか？

さらに、その時に接続に問題が生じた場合、利用者が応答を受け取れない可能性があります。こうした状況では、メッセージブローカーを利用することで、メッセージの確実な配信が保証されます。

• Mobile Applications

ダウンロード済みのモバイルアプリに情報を共有したいと仮定すると、一部の利用者がオンラインでない場合でも、WebSocketを利用したメッセージブローカーを使えば、サインイン時に自動的にメッセージが届けられます。

• Data Management for Internet of Things (IoT) Devices

1つのネットワークには、数千台ものIoTデバイスが存在し、それぞれが独自のデータを生成します。そのデータの量や速度を考慮すると、HTTPプロトコルだけで管理するのは最適とは言えない場合があります。

• Keeping Tabs on Website Engagement

例えば、一般公開されたウェブアプリの利用状況を把握したいとします。そのため、ウェブ内で行われるクリック、ページビュー、検索クエリなどの操作が該当するフォーラムに送信され、取得されたデータは即時処理や監視に利用され、各操作は固有のトピックごとに分類されます。

‍

メッセージブローカー利用の利点と欠点

利点:

• 各サービスが同時に動作していなくても相互に通信できる点。送信側がどの状態にあっても、メッセージブローカーが動作していれば受信側と連携が可能です。最終利用者においても同様です。
• 非同期処理の導入により、システム全体のパフォーマンスが大幅に向上します。重い処理は別途手順で実行できるため、ソフトウェアが迅速に動作し、利用体験が向上します。
• メッセージの確実な配信により信頼性が向上します。受信されなかった場合、即時または後で再送するオプションがあり、未達メッセージは死レター方式で別ルートに振り分けられます。

欠点:

• 学習コストが高い点 – 複数の設計パターンを持つメッセージブローカーが存在するため、各違いや利用タイミングを理解する必要があります。また、設定が難しいという課題もあります。
• システムが複雑になるに連れて、デバッグが困難になります。
• AMQPメッセージブローカーは、新たな構成要素をシステムに加えるため、全体の複雑性が増す場合があります。

‍

メッセージブローカーのツール

現代のアプリ間の通信を円滑にするため、現在よく知られているメッセージブローカーを以下にまとめました。

• Memphis

Memphisは、プログラマーがアプリ内ストリーミング向けに開発したオープンソースのMBです。データ駆動型ソフトウェアは短時間で拡張・展開可能となり、他の機能とともにMemphisの提供する機能が利用できるとされています。MemphisはNATSの主な機能を活用し、自動最適化、スキーマ管理、インライン処理、デバッグツールを提供します。

• RabbitMQ

RabbitMQは2007年に初公開され、以降、最も有名で成功しているMBのひとつとなっています。Erlangで開発されているため非常に軽量で、クラウド環境とオンプレミス環境の両方で展開可能です。

• Apache Kafka

Apache Kafkaは、分割、レプリケーション、障害耐性を設計に直接取り入れた堅牢なMBです。TCPに基づく分散アーキテクチャにより、クライアントとサーバ間の通信が実現され、物理ハードウェア、仮想マシン、コンテナ環境でも優れた性能を発揮します。主な機能は、未送信メッセージのバッファリングや、処理とデータ生成の分離などです。

‍

結論

プロデューサーとコンシューマーのアーキテクチャを採用することで、多様なユースケースに対応するシステム構築が容易になります。ITシステムが近代化する中で、MBはますます重要な役割を担うことが期待されます。つまり、現代の技術進化した環境では、メッセージブローカーは欠かせない存在です。