RabbitMQとKafkaの比較

導入

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

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

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

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

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

メッセージキュー

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

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

公開/購読

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

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

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

1. 一時的なサブスクリプションは、コンシューマーが稼働している間のみ存在します。コンシューマーが終了すると、対応するサブスクリプションと未処理のメッセージは失われます。
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 のストレージ層を使用して、イベント トレースやログ監査などの機能を実装することもできます。

結論

RabbitMQ と Kafka は同等であると見なされることもありますが、実装は大きく異なります。したがって、これらを同じ種類のツールとして扱うことはできません。 1 つはメッセージ ミドルウェアであり、もう 1 つは分散ストリーミング システムです。

ソリューション アーキテクトとして、私たちはそれらの違いを認識し、特定のシナリオでどのタイプのソリューションを使用するかを可能な限り検討する必要があります。 2 番目のセクション (未完成) では、これらの違いを指摘し、それぞれのアプローチをいつ使用するかについてのガイダンスを提供します。

Wang Huan は、c/c++、golang、nodejs バックエンド開発エンジニアであり、k8s 愛好家で、現在は IM インターネット企業に勤務しています。