Apache Kafka と RabbitMQ は、広く使用されている 2 つのメッセージング ブローカーであり、アプリケーション間のメッセージ交換の分離を可能にします。 それらの最も重要な特徴は何ですか。また、両者の違いは何ですか? 概念に行きましょう。
RabbitMQ
RabbitMQ は、当事者間の通信とメッセージ交換のためのオープンソースのメッセージ ブローカー アプリケーションです。 Erlang で開発されているため、非常に軽量で効率的です。 Erlang 言語は、分散システムに重点を置いて Ericson によって開発されました。
より伝統的なメッセージング ブローカーと見なされます。 パブリッシャー/サブスクライバー パターンに基づいていますが、構成で設定されている内容に応じて、通信を同期または非同期で処理できます。 また、プロデューサーとコンシューマー間のメッセージの配信と順序付けも保証します。
AMQP、STOMP、MQTT、HTTP、および Web ソケット プロトコルをサポートしています。 メッセージ交換の 3 つのモデル: トピック、ファンアウト、ダイレクト:
- トピックまたはテーマごとの直接および個別の交換 [topic]
- キューに接続されているすべてのコンシューマーは、 [fanout] メッセージ
- 各消費者は送信されたメッセージを受け取ります [direct]
以下は、RabbitMQ のコンポーネントです。
生産者
プロデューサーは、メッセージを作成して RabbitMQ に送信するアプリケーションです。 それらは、RabbitMQ に接続してメッセージを発行できる任意のアプリケーションです。
消費者
コンシューマーは、RabbitMQ からのメッセージを受信して処理するアプリケーションです。 それらは、RabbitMQ に接続してメッセージをサブスクライブできる任意のアプリケーションにすることができます。
取引所
エクスチェンジは、プロデューサーからメッセージを受信し、適切なキューにルーティングする役割を果たします。 直接交換、ファンアウト交換、トピック交換、ヘッダー交換など、いくつかの種類の交換があり、それぞれに独自のルーティング ルールがあります。
キュー
キューは、コンシューマーによって消費されるまでメッセージが格納される場所です。 これらは、アプリケーションによって作成されるか、メッセージが交換に公開されるときに RabbitMQ によって自動的に作成されます。
バインディング
バインディングは、交換とキューの間の関係を定義します。 これらはメッセージのルーティング ルールを指定します。このルールは、メッセージを適切なキューにルーティングするために交換によって使用されます。
RabbitMQ のアーキテクチャ
RabbitMQ は、メッセージ配信にプル モデルを使用します。 このモデルでは、コンシューマーはブローカーのメッセージを積極的に要求します。 メッセージは、ルーティング キーに基づいて適切なキューにメッセージをルーティングする責任を負うエクスチェンジに公開されます。
RabbitMQ のアーキテクチャは、クライアント/サーバー アーキテクチャに基づいており、連携して信頼性が高くスケーラブルなメッセージング プラットフォームを提供する複数のコンポーネントで構成されています。 AMQP の概念は、Exchange、Queue、Binding、および Publisher と Subscriber というコンポーネントを提供します。 パブリッシャーはメッセージをエクスチェンジにパブリッシュします。
Exchange はこれらのメッセージを受け取り、特定のルール (バインディング) に基づいて 0 ～ n 個のキューに配信します。 キューに格納されたメッセージは、コンシューマーが取得できます。 簡単な形式では、メッセージ管理は次のように RabbitMQ で行われます。
画像ソース: VMware
- パブリッシャーはメッセージを送信して交換します。
- Exchange はメッセージをキューやその他の交換に送信します。
- メッセージが受信されると、RabbitMQ は受信確認を送信者に送信します。
- コンシューマーは、RabbitMQ への永続的な TCP 接続を維持し、受信しているキューを宣言します。
- RabbitMQ はメッセージをコンシューマーにルーティングします。
- コンシューマは、メッセージ受信の成功またはエラーの確認を送信します。
- 正常に受信されると、メッセージはキューから削除されます。
アパッチ・カフカ
Apache Kafka は、LinkedIn が Scala で開発した分散型オープンソース メッセージング ソリューションです。 高いスケーラビリティとパフォーマンスを備えたパブリッシャー/サブスクライバー モデルでメッセージを処理し、保存することができます。
受信したイベントまたはメッセージを保存するには、パーティションを使用してノード間でトピックを分散します。 パブリッシャー/サブスクライバー パターンとメッセージ キュー パターンの両方を組み合わせ、各コンシューマーのメッセージの順序を保証する役割も果たします。
Kafka は、リアルタイムのデータ ストリームを処理するための高いデータ スループットと低レイテンシを専門としています。 これは、サーバー (ブローカー) 側で過度のロジックを回避することと、いくつかの特別な実装の詳細を回避することによって実現されます。
たとえば、Kafka は RAM をまったく使用せず、データをすぐにサーバーのファイル システムに書き込みます。 すべてのデータがシーケンシャルに書き込まれるため、RAM に匹敵する読み取り/書き込みパフォーマンスが実現されます。
これらは、Kafka をスケーラブルで、パフォーマンスが高く、フォールト トレラントにする主な概念です。
トピック
トピックは、メッセージにラベルを付けたり分類したりする方法です。 引き出しが 10 個あるクローゼットを想像してみてください。 各ドロワーはトピックになることができ、クローゼットは Apache Kafka プラットフォームであるため、メッセージをグループ化することに加えて、トピックに関する別のより良い類推がリレーショナル データベースにテーブル化されます。
プロデューサー
プロデューサーまたはプロデューサーは、メッセージング プラットフォームに接続し、特定のトピックに関する 1 つ以上のメッセージを送信する人です。
消費者
コンシューマーは、メッセージング プラットフォームに接続し、特定のトピックに関する 1 つ以上のメッセージを消費する人物です。
ブローカ
Kafka プラットフォームにおけるブローカーの概念は、事実上 Kafka そのものにすぎず、トピックを管理し、メッセージやログなどを保存する方法を定義するのはブローカーです。
集まる
クラスタは、スケーラビリティとフォールト トレランスを向上させるために相互に通信する、または通信しない一連のブローカです。
ログファイル
各トピックは、そのレコードをログ形式で、つまり構造化された順序で保存します。 したがって、ログ ファイルはトピックの情報を含むファイルです。
パーティション
パーティションは、トピック内のメッセージのパーティション レイヤーです。 このパーティショニングにより、Apache Kafka の弾力性、フォールト トレランス、およびスケーラビリティが確保されるため、各トピックは異なる場所に複数のパーティションを持つことができます。
Apache Kafka のアーキテクチャ
Kafka は、メッセージ配信のプッシュ モデルに基づいています。 このモデルを使用して、Kafka のメッセージは積極的にコンシューマーにプッシュされます。 メッセージはトピックにパブリッシュされ、クラスター内のさまざまなブローカーに分割および分散されます。
その後、コンシューマーは 1 つ以上のトピックにサブスクライブし、それらのトピックで作成されたメッセージを受信できます。
Kafka では、各トピックは 1 つ以上のパーティションに分割されます。 イベントが終了するのはパーティションです。
クラスタに複数のブローカがある場合、パーティションはすべてのブローカに (可能な限り) 均等に分散されます。これにより、1 つのトピックの書き込みと読み取りの負荷を一度に複数のブローカにスケーリングできます。 クラスターなので、ZooKeeper を使用して同期を実行します。
ストアを受け取り、レコードを配布します。 レコードは、イベントまたは情報であるシステム ノードによって生成されるデータです。 これはクラスターに送信され、クラスターはそれをトピック パーティションに格納します。
各レコードにはシーケンス オフセットがあり、消費者は消費するオフセットを制御できます。 したがって、トピックを再処理する必要がある場合は、オフセットに基づいて実行できます。
画像ソース: ウィキペディア
コンシューマーの最後に読み取ったメッセージ ID の管理や、新しく到着したデータをどのパーティションに書き込むかの決定などのロジックは、完全にクライアント (プロデューサーまたはコンシューマー) に移されます。
プロデューサーとコンシューマーの概念に加えて、トピック、パーティション、およびレプリケーションの概念もあります。
トピックは、メッセージのカテゴリを説明します。 Kafka は、トピック内のデータをレプリケートし、トピックを複数のサーバーに分割してスケーリングすることで、フォールト トレランスを実現します。
RabbitMQ 対 Kafka
Apache Kafka と RabbitMQ の主な違いは、これらのシステムに実装されている根本的に異なるメッセージ配信モデルによるものです。
特に、Apache Kafka は、コンシューマー自身がトピックから必要なメッセージを取得するときに、プル (プル) の原則に基づいて動作します。
一方、RabbitMQ は、必要なメッセージを受信者に送信することでプッシュ モデルを実装します。 そのため、Kafka は次の点で RabbitMQ と異なります。
＃1。 建築
RabbitMQ と Kafka の最大の違いの 1 つは、アーキテクチャーの違いです。 RabbitMQ は従来のブローカー ベースのメッセージ キュー アーキテクチャを使用しますが、Kafka は分散ストリーミング プラットフォーム アーキテクチャを使用します。
また、RabbitMQ はプル ベースのメッセージ配信モデルを使用しますが、Kafka はプッシュ ベースのモデルを使用します。
＃2。 メッセージの保存
RabbitMQ はメッセージを FIFO キュー (最初の入力 – 最初の出力) に入れ、キュー内のこのメッセージのステータスを監視します。Kafka はメッセージをログに追加 (ディスクへの書き込み) し、必要なデータの取得は受信者に任せます。トピックからの情報。
RabbitMQ は受信者に配信された後にメッセージを削除しますが、Kafka はログのクリーンアップがスケジュールされるまでメッセージを保存します。
したがって、Kafka は現在および以前のすべてのシステム状態を保存し、RabbitMQ とは異なり、履歴データの信頼できるソースとして使用できます。
＃3。 負荷分散
メッセージ配信のプル モデルのおかげで、RabbitMQ はレイテンシを短縮します。 ただし、メッセージが処理できるよりも速くキューに到着すると、受信者がオーバーフローする可能性があります。
RabbitMQ では、各受信者が異なる数のメッセージを要求/アップロードするため、作業の分散が不均一になり、処理中に遅延やメッセージの順序の損失が発生する可能性があります。
これを防ぐために、各 RabbitMQ レシーバーはプリフェッチ制限、つまり未確認メッセージの累積数の制限を構成します。 Kafka では、トピックのセクション (パーティション) 間で受信者を再分散することにより、負荷分散が自動的に実行されます。
＃4。 ルーティング
RabbitMQ には、キューイングのためにさまざまな交換にルーティングする 4 つの方法が含まれており、強力で柔軟な一連のメッセージング パターンを可能にします。 Kafka は、ルーティングせずにメッセージをディスクに書き込む方法を 1 つだけ実装します。
＃5。 メッセージの順序
RabbitMQ を使用すると、イベントの任意のセット (グループ) で相対的な順序を維持できます。Apache Kafka を使用すると、レプリケートされたログ (トピック) にメッセージを順番に書き込むことで、スケーラビリティを備えた順序を簡単に維持できます。
機能RabbitMQKafka アーキテクチャブローカーに接続されたディスクにメッセージを保存する分散ストリーミング プラットフォーム アーキテクチャ配信モデルプル ベースのプッシュ ベースメッセージを保存するメッセージを保存できないトピックへの書き込みによって注文を維持するロード バランシングプリフェッチ制限を構成する自動的に実行されるルーティングルーティングする 4 つの方法を含むメッセージをルーティングする方法は 1 つだけメッセージの順序付けグループ内の順序を維持することを許可する書き込みによって注文を維持するトピックへ外部プロセス必要ありませんZookeeper インスタンスの実行が必要プラグイン複数のプラグイン限定的なプラグイン サポートあり
RabbitMQ と Kafka はどちらも広く使用されているメッセージング システムであり、それぞれに独自の長所とユース ケースがあります。 RabbitMQ は、メッセージ キューイングに優れた柔軟で信頼性が高くスケーラブルなメッセージング システムであり、信頼性が高く柔軟なメッセージ配信を必要とするアプリケーションにとって理想的な選択肢です。
一方、Kafka は、大量のデータの高スループットのリアルタイム処理用に設計された分散ストリーミング プラットフォームであり、データのリアルタイム処理と分析を必要とするアプリケーションに最適です。
RabbitMQ の主な使用例:
電子商取引
RabbitMQ は、電子商取引アプリケーションで、在庫管理、注文処理、支払い処理など、異なるシステム間のデータ フローを管理するために使用されます。 大量のメッセージを処理し、メッセージが確実に正しい順序で配信されるようにすることができます。
健康管理
ヘルスケア業界では、RabbitMQ を使用して、電子医療記録 (EHR)、医療機器、臨床意思決定支援システムなどの異なるシステム間でデータを交換しています。 適切な情報を適切なタイミングで利用できるようにすることで、患者のケアを改善し、エラーを減らすことができます。
金融業務
RabbitMQ は、取引プラットフォーム、リスク管理システム、支払いゲートウェイなどのシステム間のリアルタイム メッセージングを可能にします。 トランザクションが迅速かつ安全に処理されるようにするのに役立ちます。
IoT システム
RabbitMQ は IoT システムで使用され、さまざまなデバイスとセンサー間のデータ フローを管理します。 帯域幅が限られており、接続が断続的な環境でも、データを安全かつ効率的に配信するのに役立ちます。
Kafka は、大量のデータをリアルタイムで処理するように設計された分散ストリーミング プラットフォームです。
Kafka の主なユースケース
リアルタイム分析
Kafka はリアルタイム分析アプリケーションで使用され、生成されたデータを処理および分析し、企業が最新の情報に基づいて意思決定を行えるようにします。 大量のデータを処理し、最も要求の厳しいアプリケーションのニーズを満たすために拡張できます。
ログ集計
Kafka はさまざまなシステムやアプリケーションからログを集約できるため、企業はリアルタイムの問題を監視およびトラブルシューティングできます。 また、長期的な分析とレポートのためにログを保存するためにも使用できます。
機械学習
Kafka は、機械学習アプリケーションでデータをモデルにリアルタイムでストリーミングするために使用され、企業が最新の情報に基づいて予測を行い、アクションを実行できるようにします。 機械学習モデルの精度と有効性を向上させるのに役立ちます。
RabbitMQ と Kafka の両方に関する私の意見
メッセージキューを柔軟に管理するためのRabbitMQの幅広く多様な機能の欠点は、リソース消費が増加し、それに応じて負荷が増加するとパフォーマンスが低下することです。 これは複雑なシステムの操作モードであるため、ほとんどの場合、Apache Kafka はメッセージを管理するための最適なツールです。
たとえば、数十のシステムとサービスから多くのイベントを収集して集約する場合、それらの地理的予約、クライアント メトリック、ログ ファイル、および分析を考慮に入れ、情報ソースが増加する見込みがある場合、私は Kafka を使用することを好みます。ただし、高速メッセージングのみが必要な状況にある場合は、RabbitMQ が問題なく機能します。
Windows および Linux に Apache Kafka をインストールする方法もお読みください。
