# 分散メッセージブローカ ## 定義 分散メッセージブローカ(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) ## 未解決の問い - 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 のベンダー値を鵜呑みにするべきではない。共有ストレージベース設計がネットワーク障害時にどう振る舞うかも未公開。 ## 関連 - 製品: [[Apache Kafka]]、[[AMQP]]、[[RabbitMQ]] - ソース: [[@2017__arXiv__A Survey of Distributed Message Broker Queues]] - 隣接概念: [[テレメトリ]](監視データの伝送路として broker が使われる)