Open2022/07/06にコメント追加3

RabbitMQ の調査

nukopy

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

メッセージブローカー message broker
- 概要
  - メッセージキューの管理および定義を行うソフトウェア。アプリケーション同士を接続してメッセージを送信するキューマネージャーとして機能する。
  - メッセージブローカーは多くの場合、信頼性の高いアプリケーション間通信、保証されたメッセージ配信を実現するため、メッセージキューと呼ばれるサブストラクチャーまたはコンポーネントに依存している。このキューには、コンシューム側アプリケーションがメッセージを処理できるようになるまでメッセージが保管されて配列される。メッセージ・キュー内では、メッセージは送信されたとおりの順序で保管され、受信が確認されるまでキューに残る。
- 機能
  - メッセージの受信、検証、保管、経路指定、適切な宛先への配信
- 嬉しいこと
  - システムが疎結合になること。他のアプリケーションとの間で仲介役として機能するため、受信側の場所やその活動状態、数を知らなくても、送信側がメッセージを発行できるようにしてくれる。これにより、システム内のプロセスとサービスの分離が容易になる。
- ユースケース
  - 信頼性の高いアプリケーション間通信、保証されたメッセージ配信が必要なシステム。
    - 金融取引
    - EC の注文の処理と履行
    - 保存時と移動中の機密データの保護

以下が分かりやすい。

メッセージブローカーによるメッセージングモデル

メッセージ・ブローカーは以下の 2 つのメッセージングモデル（メッセージ配信パターン）を提供する。

Point-to-Point メッセージング
- 1 対 1 のメッセージ送受信
- メッセージの送信側と受信側の間に1対1の関係がある、メッセージ・キューで使用される配信パターンです。キュー内の各メッセージは単一の受信側にのみ送信され、一度のみコンシュームされます。メッセージの処理が一度のみでなければならない場合、Point-to-Pointメッセージングが必要になります。このメッセージング・スタイルに適したユースケースの例としては、給与計算処理や金融取引処理などがあります。これらのシステムでは、それぞれの支払の送信が確実に一度のみ行われるという保証を、送信側と受信側の両方が必要とします。
パブリッシュ / サブスクライブ・メッセージング
- 1 対多のメッセージ送受信を行う、ブロードキャストスタイルの配信方式。
- 「pub/sub」と呼ばれることが多いこのメッセージ配信パターンでは、各メッセージのプロデューサーはメッセージをトピックにパブリッシュし、複数のメッセージ・コンシューマーはメッセージを受信したいトピックをサブスクライブします。トピックにパブリッシュされたすべてのメッセージは、そのトピックをサブスクライブしているすべてのアプリケーションに配信されます。これは、メッセージのパブリッシャーとそのコンシューマーとの間に1対多の関係がある、ブロードキャスト・スタイルの配信方式です。
- 例えば、航空会社が航空機の着陸時間や遅延状況の更新を配信すれば、複数の関係者がその情報を利用できるようになります。航空機の保守と給油を行う地上勤務員、荷物係、次の飛行の準備をする客室乗務員や操縦士、公共の場に通知する電光掲示板の操作者などが利用者として想定されます。このシナリオで使用するためには、パブリッシュ/サブスクライブ・メッセージング・スタイルが適しています。

サービス間通信の形態：メッセージブローカー vs REST API

REST API でのサービス間通信
- REST API で使用される HTTP プロトコルは要求 / 応答プロトコルであるため、同期的なサービス間通信となる
- 構成例
  - サービス A <---request / response---> サービス B
メッセージブローカーでのサービス間通信
- メッセージの送信側サービスが受信側サービスの応答を待機する必要がなく、非同期的なサービス間通信
- 構成例
  - サービス A ---publish---> メッセージブローカー ---subscribe---> サービス B

REST APIは、マイクロサービス間の通信によく使用されます。 Representational State Transfer（REST）という用語は、Webサービスを構築する際に開発者が従うことができる、一連の原則と制約を定義します。これらに従うサービスは、均一で共有されたステートレスのオペレーターと要求のセットを介して通信できるようになります。アプリケーション・プログラミング・インターフェース（API）は、RESTルールに準拠している場合にサービスでの相互の対話を可能にする、基本となるコードを示します。
REST APIは、Hypertext Transfer Protocol（HTTP）を使用して通信します。 HTTPは公衆インターネットの標準トランスポート・プロトコルであるため、REST APIは広く知られており、頻繁に使用され、広く相互運用されています。ただし、HTTPは要求/応答プロトコルであるため、同期的な要求/応答が必要な状況で使用するのが最適です。これは、REST APIを介して要求を行うサービスは、即時応答を期待するように設計されている必要があることを意味します。応答を受信するクライアントがダウンすると、送信側サービスは、応答が来るまでブロックされます。フェイルオーバーとエラー処理ロジックを両方のサービスに構築する必要があります。

REST API については以下が分かりやすい。

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

ユースケース

nukopy

RabbitMQ

OSS のメッセージブローカーの 1 つ。

https://www.rabbitmq.com/

RabbitMQ の機能

非同期メッセージング
メッセージルーティング --- 典型的ルーティングロジックを仕様
配信確認
多くのプログラミング言語サポート

RabbitMQ に出てくる用語

RabbitMQ
- メッセージブローカー。1 つの producer からのメッセージを受信し、1 つ以上の consumer にメッセージを配信する。consumer がメッセージを受け取るまで queue（待ち行列）にメッセージを保持する。
Queue
- メッセージブローカーに送信されてきたメッセージを保持する RabbitMQ のサブモジュール。
Producer
- メッセージを作成してメッセージブローカー / メッセージキューに送信するプログラム、アプリケーション、サービスのこと。
Consumer（Subscriber）
- メッセージを受信するプログラム、アプリケーション、サービスのこと。メッセージ受信を待機している。

RabbitMQ、Producer、Consumer は同じマシン上にある必要はない。

RabbitMQ 実装時に出てくる用語

Connection
Channels
Exchanges
Queues

nukopy

RabbitMQ のアプリケーションでの使用

RabbitMQ 実装時に出てくる概念

Connection
- アプリケーションと RabbitMQ との接続のこと。接続用のプロトコルは例えば AMQP など。
Channels
Exchanges
Queues