メッセージキューの仕組み ― 非同期処理を支える「伝言板」

ひと言でいうと「伝言板」だよ。システムAが「この仕事やっといて」とメッセージを書き込んで、システムBがそれを読んで処理する。AとBが直接やり取りしなくていいのがポイントだね。

たとえばECサイトで注文が入ったとき、在庫の引き当て・決済・メール送信を全部同期的にやると、どれか1つが遅いだけで画面が固まるよね。キューに「注文が入ったよ」と書いておけば、各システムが自分のペースで処理できる。これを疎結合・非同期処理と呼ぶんだ。

基本は Producer（送る側）→ Queue → Consumer（受け取る側）のFIFO、つまり先入れ先出しだよ。郵便ポストに手紙を入れた順番に届くイメージだね。配信モデルには大きく2種類あって、1対1の「Point-to-Point」と、1対多の「Pub/Sub」がある。Pub/Subはトピックに購読登録した全員にメッセージが届く仕組みだよ。

RabbitMQはAMQPプロトコルベースのメッセージブローカーだよ。特徴的なのはExchange（交換局）という仕組みで、Producerはキューに直接送るんじゃなくてExchangeに送る。Exchangeがルーティングキーとバインディングのルールに従って、適切なキューに振り分けるんだ。ダイレクト・トピック・ファンアウトなど振り分けパターンを選べるのが強みだね。

RabbitMQにはAck（確認応答）の仕組みがあるよ。Consumerが「処理完了」とAckを返すまでメッセージはキューに残る。失敗したら再配信されるんだ。それでも何度も失敗するメッセージはデッドレターキュー（DLQ）に移す。DLQに溜まったメッセージを後から調査・再処理できるから、データを失わずに障害対応できるんだよ。

Kafkaはメッセージを「トピック」に書き込んで、トピックを「パーティション」に分割するのが大きな特徴だよ。パーティションごとに順序が保証されるから、大量データを並列処理しつつ順番も守れる。さらにConsumer Groupという仕組みで、グループ内の各Consumerが別々のパーティションを担当するから、Consumerを増やすだけでスケールアウトできるんだ。

オフセットはパーティション内のメッセージの通し番号だよ。Consumerは「自分がどこまで読んだか」をオフセットで管理する。RabbitMQは読んだら消えるけど、Kafkaはメッセージを保持期間中ずっと残すから、オフセットを巻き戻せば過去のデータを再処理できる。これがログ集約やイベントソーシングに強い理由だね。

代表的なのは注文処理（決済→在庫→配送を非同期に連携）、メール送信（大量送信をキューで制御）、ログ集約（各サーバーのログをKafkaに集めて分析基盤へ流す）だね。マイクロサービス間の連携にも欠かせないよ。

実はこれが分散システム最大の難問の1つなんだ。配信保証には3種類あって、At-most-once（最大1回、届かないことがある）、At-least-once（最低1回、重複することがある）、Exactly-once（ちょうど1回）。ネットワーク障害やConsumer再起動を考えると、純粋なExactly-onceはほぼ不可能と言われているよ。

Kafkaの場合、0.11以降で「冪等プロデューサー」が導入されて、Producer→Broker間の重複を防げるようになったよ。Consumer側はトランザクションAPIと組み合わせることで「Exactly-once semantics」を実現しているけど、厳密にはBrokerとConsumerの間でAt-least-onceを冪等処理で補っている形なんだ。ちなみにLinkedInではKafkaで1日あたり数兆件のメッセージを処理しているよ。規模が桁違いだよね。