Kafka vs RabbitMQ: ログストリーミングかブローカーか?
Kafkaは高throughputなストリーミングのために構築された分散型で再生可能なイベントログであり、RabbitMQはルーティングとタスクキューのために構築された柔軟なメッセージブローカーです。
Kafkaは順序付けされたパーティション分割済みのログを格納し、consumerは自分のoffsetで読み取るため、replay、event sourcing、非常に高いthroughputが可能になります。RabbitMQはexchange、キュー、柔軟なルーティングを備えたAMQPを実装し、タスク配信、RPC、メッセージ単位のacknowledgementを伴う複雑なルーティングトポロジで力を発揮します。Kafkaは耐久性のあるイベントストリームに、RabbitMQはスマートなメッセージ配信に関するものです。
| Kafka | RabbitMQ | |
|---|---|---|
| モデル | 分散ログ | ブローカー(AMQP) |
| Replay | あり(offset) | なし(消費して終了) |
| ルーティング | topic/partition | 豊富(exchange) |
| Throughput | 非常に高い | 高い |
| 最適な用途 | ストリーミング、event sourcing | タスクキュー、ルーティング |
ユースケースとパフォーマンス
Kafkaはイベントストリーミング、analyticsパイプライン、replayと複数の独立したconsumerを必要とするシステムに適しています。RabbitMQはワークキュー、request/response、acknowledgementとメッセージ単位の制御が欲しい複雑なルーティングに適しています。Kafkaはpartitionを介してthroughputをスケールし、RabbitMQは柔軟な配信セマンティクスで真価を発揮します。
CIにおいて
どちらもservice containerとして動作しますが、Kafkaは歴史的にZooKeeperを必要としていました(KRaftモードでこれが簡素化されます)。統合テストはbrokerの準備完了を待つべきです。どちらもマネージドrunnerで動作し、より高速なrunnerはbrokerの起動とend-to-endのテスト時間を短縮します。
結論
高throughputなイベントストリーミング、replay、複数のconsumerには、Kafkaです。柔軟なルーティング、タスクキュー、メッセージ単位のacknowledgementセマンティクスには、RabbitMQです。多くのアーキテクチャは両方を使います。イベントのバックボーンにKafkaを、タスク配信にRabbitMQをです。