# 分散メッセージブローカ ## 定義 分散メッセージブローカ(Distributed Message Broker)は、ソフトウェアアーキテクチャの分離された段(stage)を**非同期 publish-subscribe**で疎結合させる中間層である。**単一障害点を持たない非集権トポロジ**の構築を促進し、耐障害性と高可用性を実現する。応用は分散アーキテクチャの段間通信、IoT デバイス間通信、イベント駆動処理アーキテクチャの実装に及ぶ。代表実装は [[Apache Kafka]]・[[AMQP]]([[RabbitMQ]]・Apache Qpid)・ActiveMQ・ZeroMQ・Amazon SQS・MSMQ など。(Source: [[@2017__arXiv__A Survey of Distributed Message Broker Queues]]) ## 横断的知見 - **設計選択の 2 軸: スループット vs 信頼性**: John+ arXiv2017 は同一テストベッド(5 ノード・Flotilla)で Kafka と AMQP/RabbitMQ を比較し、**Kafka はスループット最大化(信頼性をトレードオフ)・AMQP はレイテンシと配送信頼性最大化(スループットをトレードオフ)**という対照的な設計選択を経験的に示した。応用領域がこの軸を決定する: ログ集約・ページビュー・広告クリック等の**損失許容ワークロード**は Kafka が優位、金融取引・送金等の**損失非許容ワークロード**は AMQP が優位。設計起源(LinkedIn のログ処理 vs 金融取引処理)が現在の設計思想に直接反映されている。(Source: [[@2017__arXiv__A Survey of Distributed Message Broker Queues]] §6, §7) - **Kafka のスループット優位は OS 機構の活用に集約される**: SendFile API でカーネルバッファをバイパス・シーケンシャルディスク書き込みと OS ページキャッシュ依存・標準バッチング、の 3 つが Kafka の高スループット根拠である。broker レベルキャッシュを持たず OS のページキャッシュに完全依存する設計は、メモリ管理を OS に委ねることで「broker 実装の単純化」と「キャッシュヒット率向上」を同時に達成する。consumer の遅延が小さい限り大半のメッセージはキャッシュから供給される、という仮定がこの設計を成立させる。(Source: [[@2017__arXiv__A Survey of Distributed Message Broker Queues]] §3, §6) - **AMQP の低レイテンシ優位は「push モデル + 既定で非永続化」の組み合わせ**: Kafka が pull モデル(consumer が pace を決める)・既定で永続化(ディスク書き込みが介在)するのに対し、AMQP は push モデル(broker が consumer に届ける)・既定で非永続化(durable フラグで明示的に opt-in)である。この 2 つの設計選択が「メッセージが broker に到達してから consumer が処理を開始するまでの遅延」を最小化する。代償は耐障害性であり、broker クラッシュ時に非 durable queue のメッセージは失われる。(Source: [[@2017__arXiv__A Survey of Distributed Message Broker Queues]] §6) - **ルーティングの所在: producer 側 vs exchange 側**: Kafka は producer が topic を直接指定し broker は単に分配するだけだが、AMQP は producer が exchange に送り exchange が binding key と routing key の照合で queue を選ぶ。**ルーティング決定を broker 側に集約する**設計は、ルーティング変更時に producer/consumer を改修せず exchange の binding 再設定だけで済む利点を持つ。4 種 exchange(direct/topic/fanout/header)が peer-to-peer・pub-sub・broadcast の各通信パターンを単一プロトコル内で切り替え可能にする。(Source: [[@2017__arXiv__A Survey of Distributed Message Broker Queues]] §4, §C.2) - **multi P/C スケール時の resource contention が共通のボトルネック**: ノード数固定で producer/consumer を同一ノードに集中させると、Kafka(レイテンシ 100 倍悪化・consumer スループット 29 倍低下)・RabbitMQ(producer 15 で exchange 飽和)ともに性能が劣化する。Kafka では Zookeeper の単一ノード上での競合が、RabbitMQ では exchange のメッセージトラフィック飽和が原因と論文は説明する。**「ノード数を増やす」(水平スケール)と「ノードあたりの producer/consumer 数を増やす」(垂直スケール)は別問題で、後者は両系統ともに苦手**という共通パターンが浮かぶ。(Source: [[@2017__arXiv__A Survey of Distributed Message Broker Queues]] §5.2) - **「ストレージをブローカに持たせる」設計はブローカのスケールとストレージ効率を両立させ得る**: [[VAST Data]] の VAST Event Broker ([[@2025__VAST Data__VAST AI Operating System]])は Kafka 互換 API を保ちながら、トピックを [[DASEアーキテクチャ]] の DataBase テーブルとして実装した。結果: 3→88 ブローカで 99% スケーリング効率(ベンダー値)、Kafka 比 6 倍スループット/ブローカ(ベンダー値)、ストレージオーバーヘッド 66% → 3% 以下(ベンダー値)。Kafka がブローカ間でパーティションを複製することで耐障害性を確保するのに対し、DASE は共有ストレージ側の消去符号化で同等の耐障害性を達成するためログ複製が不要になる。ただしこれらの数値は自己申告であり第三者ベンチマークではない。(Source: [[@2025__VAST Data__VAST AI Operating System]] pp.120–121) - **既存サーベイの「スループット vs 信頼性」軸に対し、DDIA 2E は「RPC の代替としての疎結合」軸を提示する**: [[@2017__arXiv__A Survey of Distributed Message Broker Queues]] は Kafka/AMQP をベンチマークで比較し性能特性の対比を軸に据えるが、[[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 5 Encoding and Evolution]] はブローカを RPC の代替として位置づけ、(1) 受信者が落ちていてもバッファできる、(2) クラッシュしたプロセスへ自動再配送できる、(3) 送信者が受信者の IP を知る必要がない(サービスディスカバリ不要)、(4) 同一メッセージを複数受信者へ配れる、(5) 送信者と受信者を論理的に疎結合できる、という5つの利点を挙げる。前者が「ブローカ間でどう選ぶか」を論じるのに対し後者は「なぜ RPC でなくブローカを使うか」を論じており、両者を合わせると「ブローカを使うべきか」と「どのブローカを使うか」の2段階の意思決定が揃う。(Source: [[@2017__arXiv__A Survey of Distributed Message Broker Queues]], [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 5 Encoding and Evolution]]) - **既存サーベイが扱わない「スキーマ発展」の軸が DDIA 2E で追加される**: John+ 2017 はメッセージのエンコーディング形式やスキーマ互換性に触れず性能に専念するが、DDIA 2E はメッセージブローカがデータモデルを強制しない(メッセージは単なるバイト列)ことを踏まえ、Protocol Buffers・Avro・JSON のいずれかで符号化しスキーマレジストリ(Confluent Schema Registry 等)を併用してスキーマバージョンの互換性を管理する実務パターンを述べる。さらに、あるコンシューマがメッセージを別トピックへ再パブリッシュする場合、未知フィールドを保持し続けないとデータ喪失が起きる(→ [[スキーマ発展]] の前方互換性問題)という、ブローカ特有の追加論点を提示する。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 5 Encoding and Evolution]] "Message brokers") - **キュー(1受信者)/トピック(全購読者)という配送パターンの分類軸は、既存サーベイの Kafka(topic ベース)・AMQP(4種 exchange によるキュー/トピック混在)の対比と一致する**: DDIA 2E が挙げる2大パターン(名前付きキューへの追加と単一コンシューマでの受信、名前付きトピックへの publish と全サブスクライバへの配送)は、既存ページが分析した Kafka の topic/partition モデルと AMQP の exchange/binding モデルの違いを、より抽象化した形で再確認する。DDIA 2E はさらに**分散アクターフレームワーク**(Akka・Orleans・Erlang/OTP)を、メッセージブローカとアクタープログラミングモデルを単一フレームワークへ統合した設計として位置づけ、ノード内外を問わず同一のメッセージパッシング機構を使う点が既存サーベイの scope(ブローカ単体の性能比較)には含まれていない新しい切り口である。(Source: [[@2017__arXiv__A Survey of Distributed Message Broker Queues]], [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 5 Encoding and Evolution]] "Message brokers", "Distributed actor frameworks") - **DDIA 2E 第12章は John+ 2017 の「スループット vs 信頼性」ベンチマーク軸を、記帳(bookkeeping)コストという設計原理のレベルで説明し直す**: John+ 2017 は実測(multi P/C スケール時の Kafka vs RabbitMQ)からスループット/信頼性のトレードオフを経験的に示すが、[[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 12 Stream Processing]] はその原因をアーキテクチャ原理から説明する: ログベースブローカ(Kafka)はパーティション内の単調増加オフセットにより、コンシューマがメッセージ単位の確認応答を送る必要がなく定期的なオフセット記録のみで済むのに対し、AMQP/JMS 型ブローカはメッセージごとの確認応答・削除・再配送判定という重い記帳を必要とする。「オフセットで記帳コストを下げる」設計と「メッセージ単位で信頼性を保証する」設計という対比は、John+ が実測で示したスループット差を設計原理のレベルで裏づける。(Source: [[@2017__arXiv__A Survey of Distributed Message Broker Queues]] §5.2, [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 12 Stream Processing]] "Consumer offsets") - **ログベースブローカの「破壊的でない消費」という性質が、John+ 2017 が扱わなかった再現性(reprocessing)という利点を生む**: John+ 2017 はスループット・レイテンシ・可用性という運用時の性能特性を比較軸に据えるが、[[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 12 Stream Processing]] は AMQP/JMS 型の確認応答が本質的に破壊的操作(メッセージ削除)である点に着目し、ログベースブローカが読み取り専用の消費モデルによりコンシューマのオフセットを自由に巻き戻して再処理できることをバッチ処理との類似点として強調する。「同じジョブを違う処理コードで何度でも再実行できる」という性質は、性能ベンチマークには現れないが、開発・デバッグ・障害復旧の運用面で AMQP/JMS 型にはない実務的価値を持つ。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 12 Stream Processing]] "Replaying old messages") - **物理ディスクバッファは「バックプレッシャー」でも「無制限キューイング」でもない第三の選択肢として機能する**: DDIA 第12章冒頭のバックプレッシャー分類(破棄・バッファ・ブロック)に対し、ログベースブローカのディスクログは有限だが非常に大きい固定サイズバッファとして振る舞う。20TB・250MB/s のディスク1台で約22時間分のバッファを持てるという書籍の試算は、AMQP/JMS 型の「メモリが尽きたらどうするか」という運用上のリスクと対照的に、「消費が遅れても人間が対応する猶予がある」運用上の余裕を生む。この設計は John+ 2017 が測定した「ディスクへのスピル時の性能劣化」問題(§5)を、劣化ではなく計画的なバッファとして再定義するものだ。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 12 Stream Processing]] "Disk space usage", [[@2017__arXiv__A Survey of Distributed Message Broker Queues]] §5) - **DDIA が「計画的なバッファ」と再定義したディスクログを、HOTOS 25 の pubsub 批判論文は正反対の角度——バッファであること自体が問題である——から論じる**: DDIA 第12章は 20TB のディスクログが約22時間分の猶予を生む点を運用上の利点として描くが、[[@2025__HOTOS__Understanding the limitations of pubsub systems]] は pubsub の「decoupling」という謳い文句が、まさにこの有限バッファの存在によって破綻すると主張する。retention period(典型的に数日)を超えたコンシューマのメッセージはガベージコレクションされるが、pubsub システムはコンシューマにこの喪失を通知せず、失われた状態を回復する手段も提供しない。「メッセージはほぼ発行順に配送されるため、過大なバックログはサイレントな停止と見分けがつかない」という指摘は、DDIA が「消費が遅れても人間が対応する猶予がある」と評価した同じ性質を、「猶予が尽きたときに何が起こるか」という運用上の欠陥として裏側から照らす。両ソースは同じアーキテクチャ的事実(有限バッファ)を、運用上の利点(DDIA)と構造的リスク(HOTOS)という対照的な結論に結びつけており、突き合わせて初めて「バッファの寿命が尽きたときの回復手段の有無」が本質的な設計論点だと分かる。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 12 Stream Processing]] "Disk space usage", [[@2025__HOTOS__Understanding the limitations of pubsub systems]] "3.1 Failures of loose coupling") - **Kafka のトピックコンパクション(単一ソースでは利点、突き合わせで見える限界)**: DDIA 第12章はログコンパクションを「各キーの最新値のみを残すことで CDC トピックが単独でデータベースの完全なコピーを再構築できる手段」として肯定的に扱う(→ [[変更データキャプチャ(CDC)]])。HOTOS 25 論文はこの同じ機構(Kafka [24] のトピックコンパクション)を、「通知なしにコンパクションが起きるため subscriber は未見のイベントが消失したことに気づけない」「コンパクションはメッセージ損失を先送りするだけで解消しない」と評する。同じ機構が、レプリケーション用途(DDIA の CDC 文脈)では有用な保証として、pubsub のコンシューマ通知という別の要件からは不十分な保証として、異なる評価を受けている。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 12 Stream Processing]] "Log compaction", [[@2025__HOTOS__Understanding the limitations of pubsub systems]] "3.1 Failures of loose coupling") ## 未解決の問い - John+ 2017 の評価は 2017 年時点の Kafka(Zookeeper ベース)を対象にしている。2026 年現在の Kafka は **KRaft(Kafka Raft)**に移行中で、Zookeeper ボトルネックの含意は再評価が必要。KRaft 化後の multi P/C スケール性能はどう変わったか。 - Kafka は 0.11 以降 **idempotent producer + transactional writes + exactly-once semantics** を導入し、AMQP 的な信頼性保証を提供できるようになった。本サーベイの「Kafka = 非信頼 / AMQP = 信頼」の二分法は 2026 年でも有効か、それとも収束したか。 - **RabbitMQ Streams**(2021 導入)は Kafka 的なログ集約に対応する追加機能で、本サーベイの「RabbitMQ = キューベース / Kafka = ログベース」の対比が薄れている。同じ broker が両モードを提供する時代の設計選択軸は何か。 - 本サーベイは [[Apache Pulsar]](Yahoo! 発、storage と serving の分離)・[[Redpanda]](C++ 実装、Raft ベース、Zookeeper レス)・NATS JetStream を扱わない。これら後継・派生は「Kafka API 互換 + アーキテクチャ革新」という戦略を取るが、John+ 2017 の二分法のどこに位置づくか。 - IoT・エッジコンピューティング向けに MQTT が広く使われるが、本サーベイは触れない。「軽量・電力制約・断続接続」を前提とする broker は本サーベイの 2 軸(スループット vs 信頼性)とどう関係するか。 - broker-less 設計(ZeroMQ)と broker ベース設計の境界は本質的か、それとも「broker は単なるレイテンシトレードオフの選択」か。"smart endpoint, dumb network" 哲学が現代のサービスメッシュ(Istio・Linkerd)とどう関係するか。 - ベンチマーク方法論の標準化: John+ 2017 は Flotilla を改造して使ったが、broker 性能の業界標準ベンチが存在しない。TPC 系のような共通ベンチの不在は比較研究を困難にしている。 - VAST Event Broker は「ストレージ層を共有することで複製コストを排除する」という Kafka とは本質的に異なる設計方針をとる。第三者によるスループット・レイテンシ・耐障害性の独立検証はなく、VAST のベンダー値を鵜呑みにするべきではない。共有ストレージベース設計がネットワーク障害時にどう振る舞うかも未公開。 - DDIA 2E が挙げるメッセージブローカの5利点(バッファリング・自動再配送・サービスディスカバリ不要・複数配送・疎結合)のうち、Kafka と AMQP でどれがどの程度実現されているかは John+ 2017 のベンチマークだけでは判別できない。「利点」の軸(DDIA)と「性能特性」の軸(John+)を統合したベンチマーク設計は存在するか。 - 分散アクターフレームワーク(Akka・Orleans・Erlang/OTP)は Kafka・AMQP とは異なるアーキテクチャ選択(ブローカ+プログラミングモデルの統合)を取るが、John+ 2017 のようなスループット/レイテンシベンチマークで Kafka・AMQP と直接比較した研究はあるか。 - HOTOS 25 が提案する [[Watch(状態変更通知)]] は pubsub の「暗黙のストレージ層」を明示化することでバックログ通知・回復不能問題を解決すると主張するが、この提案自体はまだ Snappy(未公開)という実装途中のシステムでしか検証されていない。ログベースブローカ(Kafka)の実運用スケールで watch ベースアーキテクチャへ移行した際の性能・運用コストは未知数。 ## 関連 - 製品: [[Apache Kafka]]、[[AMQP]]、[[RabbitMQ]]、[[Debezium]] - ソース: [[@2017__arXiv__A Survey of Distributed Message Broker Queues]] / [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 5 Encoding and Evolution]] / [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 12 Stream Processing]] / [[@2025__HOTOS__Understanding the limitations of pubsub systems]] - 概念: [[スキーマ発展]] / [[変更データキャプチャ(CDC)]] / [[ストリーム処理の耐障害性]] / [[Watch(状態変更通知)]](pubsub をストレージ+watchへアンバンドリングする対抗アーキテクチャ) - 隣接概念: [[テレメトリ]](監視データの伝送路として broker が使われる) ## 出典 - [[@2017__arXiv__A Survey of Distributed Message Broker Queues]] - [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 5 Encoding and Evolution]]("Event-Driven Architectures", "Message brokers", "Distributed actor frameworks") - [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 12 Stream Processing]]("Messaging Systems", "Log-Based Message Brokers" 節) - [[@2025__HOTOS__Understanding the limitations of pubsub systems]](Atul Adya, Phil Bogle, Colin Meek. HOTOS 25. "3.1 Failures of loose coupling")