【めっせーじぶろーかー】

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

最終更新:
💡 サービス間の「伝言メモを預かる仲介者」

サービス間のメッセージを仲介するミドルウェア。キューなどへの保管や宛先への配分を通じて、送信側と受信側を直接つながずに連携させる。保存・再配送・重複の扱いは製品や設定による。

📌 このページのポイント
メッセージを預け、受信側が処理する 送信側 注文を送る ブローカー キューの例 受信側 処理 在庫を更新 送信の受領確認と、処理の確認は別 保存の条件・容量・再配送を確認 再配送:同じ注文が再び届く場合がある 同じ注文を二重に更新しない設計 外部の決済APIにも条件の確認が必要
矢印はメッセージの流れ。キューを介して1つの処理先へ渡す例で、複数購読先への配分や確認応答の経路は省略。保管・受領・処理成功は別で、保存条件や再配送への対策が必要。
ひよこ ひよこ
APIで直接サービスを呼べばいいのに、なんでメッセージブローカーが必要なの?
ペンギン先生 ペンギン先生
同期APIでは相手の停止や応答待ちが呼び出し側に影響する。メッセージを預けて別のタイミングで処理すれば、処理を分離できるよ。ただし、保管や送信の受領確認にも条件がある。常にすぐ成功し、受信側がいつまでも停止していてよい仕組みではないんだ。
ひよこ ひよこ
キューとトピックって何が違うの?
ペンギン先生 ペンギン先生
キューは受信待ちのメッセージを置き、複数の受信者で仕事を分担する例がある。Pub/Subでは複数の購読先へ同じ情報を届ける。RabbitMQならexchangeから各キューへ配分できるよ。トピックという名前だけで全受信者への配送を決めず、製品の購読・グループの仕組みを確認するんだ。
ひよこ ひよこ
届いたかどうかは、どう確認するの?
ペンギン先生 ペンギン先生
RabbitMQのpublisher confirmはブローカー側の受領、consumer ACKは受信側の処理確認で、別のものだよ。手動ACKでは処理を終えてから通知する。未ACKで接続が切れれば再びキューへ戻されるため、処理済みでも再配送されることがあるんだ。
ひよこ ひよこ
同じメッセージが2回来たら、2回処理されちゃう?
ペンギン先生 ペンギン先生
そうなる可能性があるので、再処理しても二重更新しない冪等性を考えるよ。IDを見て無視するだけでも、処理済み記録と実際の更新がずれると困る。Kafka内の読取・処理・書込はトランザクションとread_committedなどの適切な設定でexactly-onceにできるが、外部の決済やメール送信には別の協調が必要なんだ。
ひよこ ひよこ
急に注文が増えても、全部預かってくれる?
ペンギン先生 ペンギン先生
保管できる範囲で一時的な増加を受け止められるけれど、保存容量・期限・受信側の処理速度を考える。RabbitMQではキューの上限を設定でき、上限到達時に古いメッセージを落とすか新しい送信を拒否するかも設定次第。ブローカーを置くだけで無限に受け止められるわけではないよ。
もっと詳しく知りたい人へ

同じ注文で二重決済されないようにするには?

再配送されても同じ注文を二重に更新しない設計が必要だよ。決済APIが冪等キーに対応しているなら、同じ操作の再試行には同じキーを使い、処理済み記録と更新の整合性も確認する。キーの有効期間・対象操作・パラメータ条件はAPI次第。Kafkaのトランザクションだけでは外部APIの副作用まで保証できないんだ。

ペンギン
まとめ:ざっくりこれだけ覚えればOK!
「メッセージブローカー」って出てきたら「サービス間のメッセージを仲介する仕組み」と思えばだいたいOK!
📖 おまけ:英語の意味
「Message Broker」 = メッセージの仲介者
💬 Brokerは仲介者。送る側と受け取る側の間に立ち、メッセージを扱う役割を表す名前だよ。

参考資料

← 用語集にもどる