マイクロサービス間の通信やIoTデバイスのデータ収集で、メッセージングシステムの選定に迷っている方に向けた内容です。MQTT、AMQP、RabbitMQ、Kafka、NATS、Apache Pulsarという名前は聞いたことがあっても、どれが自分のケースに合うのか判断が難しいという声はよく聞かれます。この記事では、それぞれの技術的な立ち位置を整理し、判断軸に沿って選び方を示します。
まず前提として整理しておきたいのは、これらが同じレイヤーの技術ではないという点です。メッセージングシステムとは、送信側と受信側が直接通信せず、中間の仕組み（ブローカーやプロトコル）を介してメッセージをやり取りする基盤の総称です。直接通信では相手が応答可能な状態を前提にしますが、メッセージングシステムはこの依存を切り離します。
分散システムは本質的に非同期です。サービスは落ちますし、ネットワークは不安定になりますし、負荷は予測できないタイミングで跳ね上がります。メッセージングの仕組みは、送信側（プロデューサー）と受信側（コンシューマー）を分離することで、こうした現実を吸収する役割を持ちます。
判断軸を整理する
選定を始める前に、4つの軸で自分のプロジェクトを診断してみます。
通信相手の性質という軸があります。相手がIoTデバイスのような低帯域・バッテリー制約のある端末なのか、あるいはサーバー同士のサービス間通信なのかで、選ぶべき層が変わります。MQTTは軽量なパブリッシュ/サブスクライブ（発行と購読によるメッセージ配信）プロトコルで、不安定で低帯域なネットワーク上の端末向けに設計されています。
メッセージの永続性と再生可能性も重要な軸です。メッセージを一度配信したら消えてよいのか、それとも後から再生（リプレイ）して再処理する必要があるのかを考えます。Kafkaは配信済みのメッセージも一定期間ログとして保持し、複数のコンシューマーが同じデータを何度でも読み直せる設計です。RabbitMQのような伝統的なキューは、消費されたメッセージを基本的に保持しません。
プロトコル標準か具体的な実装かという区別も見落とされがちです。AMQP（Advanced Message Queuing Protocol）はプロトコルの仕様であり、単体でデプロイする製品ではありません。実際にAMQPスタイルのメッセージングを使う場合、多くのチームはRabbitMQを選びます。RabbitMQが実装しているのはAMQP 0-9-1という初期の方式で、後にOASISが標準化したAMQP 1.0とは別物である点に注意が必要です。
マルチテナンシーと地理分散の要件も軸になります。単一のクラスタで多数のテナントを収容したり、複数リージョンにまたがるデプロイが必要な場合、KafkaよりもApache Pulsarの層別アーキテクチャが有利になる場面があります。
選択肢を並べて比較する
| 技術 | カテゴリ | 主な用途 | データの扱い |
|---|---|---|---|
| MQTT | メッセージングプロトコル | 制約デバイス・不安定網での軽量通信 | 揮発性、配信優先 |
| AMQP | メッセージングプロトコル | 標準化されたブローカー間ルーティング | プロトコル仕様のみ |
| RabbitMQ | メッセージブローカー | キューによる作業分配・ワークフロー | 消費後は基本削除 |
| Kafka | イベントストリーミング基盤 | 大規模データパイプライン、再生可能なイベント | ログとして永続保持 |
| NATS | メッセージングシステム | 軽量・低レイテンシーなサービス間通信 | 長期保存を前提としない |
| Apache Pulsar | メッセージング&ストリーミング統合基盤 | キューとストリーム両方を1基盤で提供 | 層別ストレージで永続化 |
表からもわかるように、RabbitMQとKafkaは「競合」というより「用途が違う」関係です。RabbitMQは即時処理のタスクキューに強く、Kafkaは後から何度も読み直すイベントログに強いという違いがあります。
NATSはKafkaやPulsarと比べてシンプルな構成で、レイテンシーの低さを重視するサービス間メッシュ通信に向いています。長期保存の機能（NATS StreamingやJetStream）も追加できますが、基本思想は軽量さです。
ケース別の推奨
センサーやスマートデバイスからテレメトリを収集し、間欠的な接続を前提とするなら、MQTTブローカー（Mosquitto、HiveMQ、EMQXなど）を選びます。バッテリー消費とペイロードの小ささが優先されるためです。
社内のバッチ処理・非同期タスク実行・ワークフローの順序制御が中心であれば、RabbitMQが妥当です。ルーティングの柔軟性（トピック交換、デッドレターキューなど）が実務で使いやすい設計になっています。
ログ集約、クリックストリーム分析、複数チームが同じイベントを異なる目的で再利用する必要があるなら、Kafkaを検討します。Kafka ConnectやKafka Streamsのエコシステムも、データパイプライン構築を後押しします。
マイクロサービス間のリクエスト・レスポンスやPub/Subを、運用の複雑さを抑えつつ実現したいなら、NATSが選択肢に入ります。Kubernetes上のサイドカーとして軽量に動かせる点も評価されています。
複数のプロダクトチームがそれぞれ異なるテナントを持ち、キューとストリームの両方の要件が混在する組織であれば、Apache Pulsarの検討価値があります。BookKeeperによる層別ストレージが、長期保持と低レイテンシー配信を両立させる設計だからです。
あえて見送るべき条件
小規模なチームで運用リソースが限られている場合、Kafkaや Pulsarのような分散クラスタ型の基盤は見送るべきです。ZooKeeperやBookKeeperの運用ノウハウが必要になり、学習コストが選定効果を上回ることがあります。
単純なリクエスト・レスポンス通信で十分な場面に、メッセージングシステムを導入するのも過剰設計になりがちです。HTTP APIの同期呼び出しで完結する処理に非同期基盤を挟むと、デバッグの複雑さだけが増える可能性があります。
IoTの文脈でないのにMQTTを選ぶのも避けたい選択です。MQTTのブローカーはトピックベースのシンプルな配信に最適化されており、複雑なルーティングやメッセージの永続的な再生には向いていません。
導入前に確認すること
選定の最終判断をする前に、実際に手元で試せる確認方法を挙げます。
- 各技術の公式ドキュメントで、自分の想定するメッセージ量（1秒あたりのメッセージ数）に対するベンチマーク事例が公開されているか確認する
- RabbitMQとKafkaはいずれもDocker公式イメージが提供されているため、
docker runで数分のうちにローカル検証環境を立てて挙動を比較できる - 既存のクラウド環境がAWSかGCPかによって、マネージドサービス（Amazon MQ、MSK、Google Cloud Pub/Subなど）の有無も選定コストに直結する
まとめ
メッセージングシステムの選定は、「何が競合しているか」を正しく捉えることから始まります。RabbitMQとKafkaは用途が違うのであって優劣ではありません。
判断軸としては、通信相手の性質、メッセージの永続性と再生可能性、プロトコルと実装の区別、マルチテナンシー要件の4点を確認します。
まずは自分のワークロードの特性を1つずつ表に当てはめ、Dockerでの検証環境を1つ立ち上げて実際のスループットとレイテンシーを測ってみると判断がしやすくなります。