RabbitMQ と Kafka: 違いは明らかです!

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

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

この記事では、まず RabbitMQ と Apache Kafka の内部実装に関連する概念を紹介します。次に、2 つのテクノロジの主な違いと、それぞれの長所と短所を紹介します。最後に、2 つのテクノロジの選択方法について説明します。

1. 非同期メッセージモード

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

1. メッセージキュー

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

メッセージキュー

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

2. パブリッシュ/サブスクライブ

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

公開/購読

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

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

1) コンシューマーが稼働している間のみ存在する一時的なサブスクリプション。コンシューマーが終了すると、対応するサブスクリプションと未処理のメッセージは失われます。

2) 永続サブスクリプション: このタイプのサブスクリプションは、積極的に削除しない限り常に存在します。コンシューマーが終了した後も、メッセージング システムはサブスクリプションを維持し続け、後続のメッセージは引き続き処理されます。

2. ラビットMQ

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

1. キュー

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

2. メッセージ交換機

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

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

RabbitMQ メッセージ交換

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

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

キューと組み合わせたパブリッシュ/サブスクライブ

アパッチカフカ

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

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

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

1. テーマ

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

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

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

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

カフカプロデューサー

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

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

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

Kafka コンシューマー

2. Kafka によって実装されたメッセージ モード

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

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

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

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

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

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

4. RabbitMQとKafkaの大きな違い

RabbitMQ はメッセージブローカーですが、Apache Kafka は分散ストリーミングシステムです。セマンティクスからは違いがわかるようですが、それらの内部特性のいくつかは、さまざまなユースケースをうまく設計できるかどうかに影響します。

たとえば、Kafka はストリーミング データに最適ですが、RabbitMQ ではストリーム内のメッセージの順序を維持するのが困難です。

一方、RabbitMQ には再試行ロジックとデッドレター交換が組み込まれていますが、Kafka では実装ロジックがユーザーに任されています。

このセクションでは、さまざまなシステム間の主な違いに焦点を当てます。

1. メッセージの順序

RabbitMQ は、キューまたは交換に送信されるメッセージの順序を保証しません。コンシューマーがプロデューサーからのメッセージを順番に処理するのは論理的に思えますが、これは非常に誤解を招きます。

RabbitMQ のドキュメントには次のように記載されています。

「チャネルに公開され、エクスチェンジ、キュー、および出力チャネルを使用して配信されたメッセージは、最終的には送信された順序で受信されます。」

——RabbitMQ ブローカーセマンティクス

言い換えれば、私たちが単一の消費者である限り、受け取るメッセージは順序どおりです。ただし、複数のコンシューマーが同じキューからメッセージを読み取ると、メッセージが処理される順序は保証されません。

コンシューマーはメッセージを読み取った後にキューに戻す（または再送信する）ことがあるため（処理が失敗した場合など）、メッセージの順序は保証されません。

メッセージがキューに戻されると、別のコンシューマーは、キューに戻されたメッセージの後のメッセージをすでに処理していたとしても、そのメッセージの処理を続行できます。したがって、コンシューマー グループは、次の表に示すように、メッセージを順序どおりに処理しません。

RabbitMQ を使用したメッセージ順序の消失の例

もちろん、同時コンシューマーの数を 1 に制限することで、RabbitMQ でのメッセージの順序を確保できます。より正確には、並列メッセージ処理によって順序が乱れる問題が発生するため、単一のコンシューマー内のスレッド数を 1 に制限します。

ただし、システム規模が大きくなるにつれて、シングルスレッドのコンシューマー モデルはメッセージ処理機能に重大な影響を与えます。したがって、このオプションを軽々しく選択すべきではありません。

一方、Kafka では、メッセージ処理において信頼性の高い順序保証が提供されます。 Kafka は、同じトピック パーティションに送信されたすべてのメッセージが順番に処理されることを保証します。

前述したように、デフォルトでは、Kafka はラウンドロビン パーティショナーを使用して、対応するパーティションにメッセージを配置します。ただし、プロデューサーは各メッセージにパーティション キーを設定して、データの論理フローを作成できます (同じデバイスからのメッセージや、同じテナントに属するメッセージなど)。

同じストリームからのすべてのメッセージは同じパーティションに配置されるため、コンシューマー グループが順番に処理できます。

ただし、同じコンシューマー グループ内では、各パーティションが 1 つのコンシューマーの 1 つのスレッドによって処理されることにも注意する必要があります。その結果、単一のパーティションの処理能力を拡張できなくなります。

ただし、Kafka では、トピック内のパーティションの数をスケーリングして、各パーティションが処理できるメッセージ数を減らし、追加のパーティションを処理するためにコンシューマーを追加することができます。

勝者：

Kafka はメッセージの順序どおりの処理を保証するため、明らかに勝者です。 RabbitMQ はこの分野では比較的弱いです。

2. メッセージルーティング

RabbitMQ は、定義されたサブスクライバー ルーティング ルールに基づいて、メッセージ交換でサブスクライバーにメッセージをルーティングできます。トピック交換は、routing_key と呼ばれる特別なヘッダーを介してメッセージをルーティングできます。

あるいは、ヘッダー交換では、任意のメッセージ ヘッダーに基づいてメッセージをルーティングできます。どちらの交換でも、消費者は関心のあるメッセージ タイプを効果的に設定できるため、ソリューション アーキテクトに大きな柔軟性が提供されます。

一方、Kafka では、コンシューマーがトピック内のメッセージを処理する前にフィルタリングすることはできません。サブスクライブされたコンシューマーは、特に指定がない限り、パーティション内のすべてのメッセージを受信します。

開発者は、トピックからメッセージを読み取り、フィルター処理し、フィルター処理されたメッセージをコンシューマーがサブスクライブできる別のトピックにプッシュする Kafka ストリーミング ジョブを使用できます。ただし、これにはより多くの作業とメンテナンスが必要になり、可動部品も増えます。

勝者：

RabbitMQ は、メッセージのルーティングとフィルタリングをより適切にサポートします。

3. メッセージのタイミング

RabbitMQ には、メッセージがキューに送信される時間を測定するためのいくつかの機能が用意されています。

1) メッセージの存続時間 (TTL)

RabbitMQ に送信されるすべてのメッセージは、TTL プロパティに関連付けることができます。パブリッシャーは、TTL を直接設定することも、キューのポリシーに従って設定することもできます。

システムは、設定された TTL に応じてメッセージの有効期間を制限できます。コンシューマーが予想時間内にメッセージを処理しない場合、メッセージはキューから自動的に削除されます (後続のすべてのメッセージと同様に、デッドレター交換に移動されます)。

TTL は、時間に敏感なコマンドに特に役立ちます。これらのコマンドは、一定期間内に処理されないと意味がなくなるためです。

2) 遅延/スケジュールされたメッセージ

RabbitMQ は、プラグインを通じて遅延メッセージやスケジュールされたメッセージをサポートできます。メッセージ交換でこのプラグインを有効にすると、プロデューサーは RabbitMQ にメッセージを送信でき、プロデューサーは RabbitMQ がメッセージをコンシューマー キューにルーティングするのにかかる時間を遅らせることができます。

この機能により、開発者は将来のコマンド、つまりそれまで処理されるべきではないコマンドをスケジュールできます。たとえば、プロデューサーがスロットリング ルールに遭遇すると、それらの特定のコマンドの実行が後で延期されることがあります。

Kafka はこれらの機能を提供しません。メッセージが到着するとすぐにパーティションに書き込まれるため、コンシューマーはメッセージをすぐに処理できます。

Kafka はメッセージに対して TTL メカニズムも提供していませんが、アプリケーション層で実装できます。

ただし、覚えておかなければならないのは、Kafka パーティションは追加モードのトランザクション ログであるということです。したがって、メッセージのタイミング (またはパーティション内の位置) を処理することはできません。

勝者：

この実装は本質的に Kafka に制約を与えるため、RabbitMQ が明らかに勝者です。

4. メッセージの保持

コンシューマーがメッセージを正常に消費すると、RabbitMQ は対応するメッセージをストレージから削除します。この動作は変更できません。これは、ほぼすべてのメッセージ ブローカー設計に不可欠な部分です。

逆に、Kafka はトピックごとにタイムアウトを設定し、タイムアウトに達しないすべてのメッセージは保持されます。メッセージの保持に関しては、Kafka はそれをメッセージ ログとしてのみ扱い、コンシューマーの消費ステータスは考慮しません。

コンシューマーは各メッセージを無制限に使用でき、パーティション オフセットを操作してこれらのメッセージを時間的に「前後に」処理できます。 Kafka はパーティション内のメッセージの保持時間を定期的にチェックします。設定された保存期間を超えると、メッセージは削除されます。

Kafka のパフォーマンスはストレージ サイズに依存しません。したがって、理論的には、そこにメッセージを保存してもパフォーマンスにはほとんど影響がありません (ノードにそれらのパーティションを保持するのに十分なスペースがある限り)。

勝者：

Kafka はメッセージを保存するように設計されていますが、RabbitMQ はそうではありません。したがって、ここでは比較の余地はなく、カフカが勝者です。おすすめ: 最も包括的なJava面接の概要と回答分析

5. フォールトトレランス

メッセージ、キュー、イベントを扱う場合、開発者はメッセージ処理が常に成功すると想定することがよくあります。結局のところ、プロデューサーが各メッセージをキューまたはトピックに配置すると、コンシューマーがメッセージの処理に失敗しても、成功するまで再試行するだけです。

このアプローチは表面的には正しいように思えますが、よく考える必要があります。まず、シナリオによってはメッセージの処理が失敗する可能性があることを認識する必要があります。したがって、ソリューションの一部に人間の介入が必要な場合でも、それらの状況を適切に処理する必要があります。

メッセージ処理では、次の 2 つの障害が発生する可能性があります。

1) 一時的な障害 - 障害は、ネットワーク接続、CPU 負荷、サービスのクラッシュなどの一時的な問題が原因で発生します。何度も試行することで、この失敗を軽減することができます。

2) 永続的な障害 - 障害は、追加の再試行では解決できない永続的な問題によって発生します。一般的な原因としては、ソフトウェアのバグや無効なメッセージ形式（汚染されたメッセージなど）が挙げられます。

設計者や開発者として、私たちは自分自身に問いかける必要があります。「メッセージ処理の失敗を何回再試行すればよいのか。再試行の間隔はどのくらいにすればよいのか。一時的な障害と永続的な障害をどのように区別すればよいのか。」

最も重要なのは、「すべての再試行が失敗した場合、または永続的な障害が発生した場合は、どうすればよいか」ということです。

もちろん、ビジネス分野が異なれば答えも異なりますが、メッセージング システムは通常、独自のソリューションを実装するためのツールを提供します。

RabbitMQ は、メッセージ処理の失敗を処理するために、配信の再試行やデッドレター交換 (DLX) などの機能を提供します。

DLX の主なアイデアは、適切な構成情報に従ってルーティング障害メッセージを DLX に自動的に送信し、例外再試行、再試行回数、「人間の介入」キューへの送信など、スイッチ上のルールに従ってさらに処理することです。

RabbitMQ で再試行を処理するための可能なパターンについての追加情報を提供する次の記事を参照してください。

リンク: https://engineering.nanit.com/rabbitmq-retries-the-full-story-ca4cc6c5b493

RabbitMQ で覚えておくべき最も重要なことは、1 つのコンシューマーがメッセージを処理または再試行している間 (キューに返す前であっても)、他のコンシューマーがこのメッセージに続く他のメッセージを同時に処理できるということです。

コンシューマーがメッセージの処理を再試行する場合、メッセージ処理ロジック全体はブロックされません。したがって、コンシューマーは、システム全体の動作に影響を与えることなく、どれだけ時間がかかってもメッセージの処理を同期的に再試行できます。

コンシューマー1はメッセージ1の処理を再試行し続け、他のコンシューマーは他のメッセージの処理を継続できる。

RabbitMQ とは異なり、Kafka はそのようなメカニズムをすぐに使用できるようには提供していません。 Kafka では、アプリケーション層でメッセージ再試行メカニズムを提供して実装する必要があります。

さらに、コンシューマーが特定のメッセージを同期的に処理している場合、同じパーティション上の他のメッセージは処理できないことに注意する必要があります。

コンシューマーはメッセージの順序を変更できないため、特定のメッセージを拒否して再試行し、その後に続くメッセージを送信することはできません。パーティションは単なる追加モードのログであることを覚えておいてください。

アプリケーション層のソリューションとしては、失敗したメッセージを「再試行トピック」に送信し、そのトピックからの再試行を処理することが考えられます。ただし、この方法ではメッセージの順序が失われます。

Uber のエンジニアが実装したこの例は、Uber.com でご覧いただけます。メッセージ処理の遅延が問題にならない場合は、エラーを適切に監視する Kafka ソリューションで十分な場合があります。

コンシューマーがメッセージの再試行をブロックされている場合、下位パーティションのメッセージは処理されません。

勝者：

RabbitMQ は、この問題を解決するためのすぐに使用できるメカニズムを提供するため、勝者です。

6. 伸縮式

RabbitMQ と Kafka のパフォーマンスをチェックするベンチマークは複数あります。

一般的なベンチマークは特定の状況に限定される場合がありますが、一般的に Kafka は RabbitMQ よりも優れたパフォーマンスを発揮すると考えられています。

Kafka はパフォーマンスを向上させるためにシーケンシャル ディスク I/O を使用します。

Kafka のパーティショニング アーキテクチャから判断すると、水平拡張では RabbitMQ よりも優れています。もちろん、RabbitMQ は垂直拡張においてより多くの利点があります。

Kafka の大規模な展開では、通常、1 秒あたり数十万件、さらには数百万件のメッセージを処理できます。

過去に、Pivo​​tal は 1 秒あたり 100 万件のメッセージを処理する Kafka クラスターを文書化しました。ただし、これは 30 ノードのクラスターで実行され、メッセージの負荷は複数のキューと交換にわたって最適に分散されました。

リンク: https://content.pivotal.io/blog/rabbitmq-hits-one-million-messages-per-second-on-google-compute-engine

一般的な RabbitMQ の展開は 3 ～ 7 個のノードのクラスターで構成され、これらのクラスターでは負荷を異なるキューに分散する必要はありません。これらの典型的なクラスターは、通常、1 秒あたり数万件のメッセージを処理することが期待されます。

勝者：

どちらのメッセージング プラットフォームも大きな負荷を処理できますが、Kafka の方がスケーリングに優れており、RabbitMQ よりも高いスループットを実現できるため、このラウンドでは Kafka が勝利します。

ただし、ほとんどのシステムはまだこれらの限界に達していないことに注意する価値があります。したがって、何百万ものユーザーを抱える次世代の非常に人気のあるソフトウェア システムを構築しているのでない限り、スケーラビリティについてあまり心配する必要はありません。結局のところ、どちらのメッセージング プラットフォームも問題なく動作します。

7. 消費者の複雑さ

RabbitMQ はスマートブローカーとダムコンシューマーモデルを使用します。コンシューマーはコンシューマー キューに登録し、その後 RabbitMQ は受信メッセージをコンシューマーにプッシュします。 RabbitMQ にはプル API もあります。ただし、ほとんど使用されません。

RabbitMQ は、メッセージの配布とキューからのメッセージの削除 (および DLX への転送) を管理します。消費者はこれを考慮する必要はありません。

RabbitMQ アーキテクチャの設計によれば、負荷が増加すると、システムに変更を加えなくても、キュー上のコンシューマー グループを 1 つのコンシューマーから複数のコンシューマーに効果的に拡張できます。

RabbitMQの効率的なスケーリング

対照的に、Kafka はダムブローカーとスマートコンシューマーモデルを使用します。コンシューマー グループ内のコンシューマーは、それらの間でトピック パーティションのリースを調整する必要があります (特定のパーティションがコンシューマー グループ内の 1 人のコンシューマーによってのみリッスンされるように)。

コンシューマーはパーティション オフセット インデックスを管理および保存する必要もあります。幸いなことに、Kafka SDK ではすでにカプセル化されているため、自分で管理する必要はありません。

さらに、負荷が低い場合、単一のコンシューマーが複数のパーティションを並行して処理および管理する必要があり、コンシューマー側でより多くのリソースが消費されます。

もちろん、負荷が増加するにつれて、コンシューマーの数がトピック内のパーティションの数と等しくなるようにコンシューマー グループをスケーリングする必要があります。これには、追加のパーティションを追加するように Kafka を構成する必要があります。

ただし、負荷が再び減少すると、以前に追加したパーティションを削除できなくなり、コンシューマーにさらに作業を追加する必要があります。それにもかかわらず、上で述べたように、Kafka SDK はすでにこの追加作業を実行しています。

Kafka パーティションは削除できず、スケールダウン後にコンシューマーはより多くの作業を行うことになります。

勝者：

設計上、RabbitMQ は愚かな消費者向けに構築されています。つまり、このラウンドでは RabbitMQ が勝利します。

5. どのように選択するのですか?

今、私たちは「RabbitMQ をいつ使用し、Kafka をいつ使用するのか」という重要な質問に直面しています。上記の違いをまとめると、次のような結論を導き出すのは難しくありません。

以下の場合には RabbitMQ が推奨されます。

• 高度で柔軟なルーティング ルール。
• メッセージタイミング制御（メッセージの有効期限またはメッセージの遅延を制御）
• コンシューマーがメッセージ（一時的または永続的）の処理に失敗する可能性が高いシナリオにおける高度なフォールト トレランス。
• よりシンプルな消費者実装。

Kafka を優先する:

• 厳密なメッセージ順序。
• 過去のメッセージを再生する可能性を含め、メッセージの保持時間を延長します。
• 従来のソリューションでは実現できない高いスケーラビリティ。

ほとんどの場合、これら 2 つのメッセージング プラットフォームで要件を満たすことができます。しかし、最も適切なツールを選択するのは私たち建築家次第です。決定を下す際には、上で強調した機能上の違いと非機能上の制限を考慮する必要があります。

これらの制限は次のとおりです。

• 2 つのメッセージング プラットフォームに関する現在の開発者の理解。
• マネージド クラウド ソリューションの可用性 (該当する場合)。
• 各ソリューションの運用コスト。
• ターゲット スタック用の SDK の可用性。

複雑なソフトウェア システムを開発する場合、必要なすべてのメッセージング ユース ケースを実装するために同じメッセージング プラットフォームを使用したくなることがあります。しかし、私の経験では、両方のメッセージング プラットフォームを併用すると、通常はより多くのメリットが得られます。

たとえば、イベント駆動型アーキテクチャ システムでは、RabbitMQ を使用してサービス間でコマンドを送信し、Kafka を使用してビジネス イベント通知を実装できます。

その理由は、イベント通知はイベント トレース、バッチ操作 (ETL スタイル)、または監査の目的でよく使用されるため、Kafka のメッセージ保持機能は非常に価値があるからです。

対照的に、コマンドは通常、コンシューマー側で追加の処理を必要とし、その処理は失敗する可能性があるため、高度なフォールト トレランス機能が必要です。

ここで、RabbitMQ には多くの優れた機能があります。これについては将来的に詳細な記事を書くかもしれませんが、適合性は特定のニーズによって異なるため、結果は異なる可能性があることに留意する必要があります。

VI.結論

この記事は、多くの開発者が RabbitMQ と Kafka を同等のものとして扱っていることに気づいたために書かれました。この記事を参考にして、技術的な実装とそれらの技術的な違いの両方について深く理解していただければ幸いです。

これにより、2 つのプラットフォームは、その違いを通じてユースケースに適したサービスを提供するようになります。どちらのメッセージング プラットフォームも優れており、さまざまなユース ケースに非常によく対応します。

しかし、ソリューション アーキテクトとして、各ユース ケースの要件を理解し、最適化し、最も適切なソリューションを選択するのは私たちの責任です。