RabbitMQとKafkaの比較

導入

経験豊富なマイクロサービスシステムアーキテクトとして、私はよく「RabbitMQ と Kafka のどちらを選ぶべきですか?」と尋ねられます。何らかの理由で、多くの開発者はこれら 2 つのテクノロジを同等のものとして扱います。実際、いくつかのケースのシナリオでは、RabbitMQ と Kafka のどちらを選択しても違いはありませんが、基盤となる実装の点では、これら 2 つのテクノロジの間には多くの違いがあります。

シナリオによって必要なソリューションは異なり、間違ったソリューションを選択すると、ソフトウェアの設計、開発、保守の能力に重大な影響を与える可能性があります。

この記事では、まず基本的な非同期メッセージングモードを紹介し、次に RabbitMQ と Kafka とその内部構造情報を紹介します。第 2 部 (未完成) では、主に 2 つのテクノロジの主な違いと、それぞれの利点と欠点について説明します。最後に、2 つのテクノロジの選択方法について説明します。

非同期メッセージングモード

非同期メッセージングは、メッセージの生成と処理を分離するソリューションとして使用できます。メッセージングシステムについて話すとき、通常は、メッセージキューとパブリッシュ/サブスクライブという 2 つの主要なメッセージングパターンについて考えます。

メッセージキュー

メッセージキューは、プロデューサーとコンシューマーを分離するために使用できます。複数のプロデューサーが同じメッセージキューにメッセージを送信できます。ただし、メッセージがプロデューサーによって処理されると、メッセージはロックされるかキューから削除され、他のコンシューマーはメッセージを処理できなくなります。つまり、特定のメッセージは 1 人のコンシューマーによってのみ消費されます。

コンシューマーがメッセージの処理に失敗した場合、メッセージングシステムは通常、メッセージをキューに戻して、他のコンシューマーが引き続き処理できるようにすることに注意することが重要です。分離機能の提供に加えて、メッセージキューはプロデューサーとコンシューマーを個別にスケーリングし、エラー処理のフォールトトレランスを提供することもできます。

公開/購読

パブリッシュ/サブスクライブ (pub/sub) モデルでは、単一のメッセージを複数のサブスクライバーが同時に取得して処理できます。

たとえば、システムで生成されたイベントは、パブリッシャーがこのパターンを通じてすべてのサブスクライバーに通知するために使用できます。多くのキューイングシステムでは、トピックという用語は、パブリッシュ/サブスクライブモデルを指すためによく使用されます。 RabbitMQ では、トピックはパブリッシュ/サブスクライブモデルの特定の実装 (より正確には、交換の一種) ですが、この記事ではトピックとパブリッシュ/サブスクライブを同等のものとして扱います。

一般的に、サブスクリプションには 2 つの種類があります。

一時的なサブスクリプションは、コンシューマーが稼働している間のみ存在します。コンシューマーが終了すると、対応するサブスクリプションと未処理のメッセージは失われます。
永続サブスクリプションは、削除しない限り常に存在します。コンシューマーが終了した後も、メッセージングシステムはサブスクリプションを維持し続け、後続のメッセージは引き続き処理されます。

ラビットMQ

RabbitMQ は、メッセージミドルウェアの実装として、サービスバスとしてよく使用されます。 RabbitMQ は、上記の 2 つのメッセージモードをネイティブにサポートしています。その他の一般的なメッセージミドルウェアの実装としては、ActiveMQ、ZeroMQ、Azure Service Bus、Amazon Simple Queue Service (SQS) などがあります。これらのメッセージミドルウェアの実装には多くの共通点があります。この記事で説明した概念の多くは、これらのミドルウェアにほぼ適用できます。

列

RabbitMQ は、標準的なメッセージキューをすぐにサポートします。開発者は名前付きキューを定義し、パブリッシャーはこの名前付きキューにメッセージを送信できます。最後に、コンシューマーはこの名前付きキューを通じて保留中のメッセージを取得できます。

メッセージ交換

RabbitMQ はメッセージ交換を使用してパブリッシュ/サブスクライブモデルを実装します。パブリッシャーは、サブスクライバーが誰であるかを知らなくても、メッセージ交換にメッセージを公開できます。

交換にサブスクライブする各コンシューマーはキューを作成します。メッセージ交換は、生成されたメッセージをコンシューマーが消費できるようにキューに入れます。メッセージ交換では、さまざまなルーティングルールに基づいて、一部のサブスクライバーのメッセージをフィルター処理することもできます。

RabbitMQ は一時的なサブスクリプションタイプと永続的なサブスクリプションタイプの両方をサポートしていることに注意することが重要です。消費者は RabbitMQ の API を呼び出して、希望するサブスクリプションの種類を選択できます。

RabbitMQ のアーキテクチャ設計に基づいて、ハイブリッドアプローチを作成することもできます。つまり、サブスクライバーがチームを形成し、グループ内でコンシューマーとして競争して、特定のキュー上のメッセージを処理します。この加入者のグループはコンシューマーグループと呼ばれます。このようにして、パブリッシュ/サブスクライブモデルを実装し、受信したメッセージを処理するためにサブスクライバーをスケールアップすることができます。

アパッチカフカ

Apache Kafka はメッセージミドルウェアの実装ではありません。むしろ、それは単なる分散ストリーミングシステムです。

キューと交換に基づく RabbitMQ とは異なり、Kafka のストレージ層はパーティション化されたトランザクションログを使用して実装されます。 Kafka は、リアルタイムストリーム処理用のストリーミング API と、さまざまなデータソースとの統合を容易にするコネクタ API も提供します。ただし、これらはこの記事の範囲を超えています。

クラウドベンダーは、Kafka ストレージ層用のオプションのソリューションを提供します。たとえば、Azure Event Hubsy や AWS Kinesis Data Streams などです。 Kafka ストリーミング機能向けの特定のクラウドおよびオープンソースソリューションもいくつかありますが、これもこの記事の範囲外です。

テーマ

Kafka はキューのようなものを実装していません。したがって、Kafka はレコードのセットをカテゴリに保存し、これらのカテゴリをトピックと呼びます。

Kafka はトピックごとにメッセージのパーティション化されたログを維持します。各パーティションは、順序付けられた不変のレコードのシーケンスで構成され、メッセージは末尾に連続して追加されます。

メッセージが到着すると、Kafka はそれをパーティションの末尾に追加します。デフォルトでは、Kafka はラウンドロビンパーティショナーを使用して、メッセージを複数のパーティションに一貫して分散します。

Kafka は、メッセージの論理フローを作成する動作を変更できます。たとえば、マルチテナントアプリケーションでは、各メッセージのテナント ID に基づいてメッセージフローを作成できます。 IoT シナリオでは、一定レベルの ID 情報に基づいて、プロデューサーを特定のパーティションにマップできます。同じ論理フローからのメッセージが同じパーティションにマップされていることを確認します。これにより、メッセージがコンシューマーに順番に提供されることが保証されます。

コンシューマーは、パーティションオフセット (またはインデックス) を維持してメッセージを順番に読み取り、メッセージを消費します。

単一のコンシューマーは複数の異なるトピックから消費することができ、コンシューマーの数は利用可能なパーティションの最大数まで拡張できます。

したがって、トピックを作成するときは、作成されたトピックで予想されるメッセージスループットを慎重に考慮する必要があります。同じトピックを消費する複数のコンシューマーのグループをコンシューマーグループと呼びます。 Kafka が提供する API は、同じコンシューマーグループ内の複数のコンシューマー間のパーティションバランスと、コンシューマーの現在のパーティションオフセットの保存を処理できます。

Kafka のメッセージモデル

Kafka の実装は、パブリッシュ/サブスクライブモデルに非常によく適合します。

プロデューサーは特定のトピックにメッセージを送信でき、その後、複数のコンシューマーグループが同じメッセージを消費できます。各コンシューマーグループは、対応する負荷を処理するために個別にスケーリングできます。コンシューマーは独自のパーティションオフセットを維持するため、再起動後にオフセットを失わない永続サブスクリプションと、再起動後にオフセットを失い、再起動のたびにパーティション内の最新のレコードから読み取りを開始する一時サブスクリプションのどちらかを選択できます。

ただし、この実装は、一般的なメッセージキューモードと完全に同等であるとは言えません。もちろん、トピックを作成し、それをコンシューマーを持つコンシューマーグループに関連付けることで、一般的なメッセージキューをシミュレートできます。ただし、これには多くの欠点があり、パート 2 で詳しく説明します。

Kafka は、コンシューマーがメッセージを消費したかどうかに基づかず、事前に設定された時間パーティションにメッセージを保持することに注意することが重要です。この保持メカニズムにより、消費者は以前のメッセージを自由に読み返すことができます。さらに、開発者は Kafka のストレージ層を使用して、イベントトレースやログ監査などの機能を実装することもできます。