オープンソース ソフトウェア成熟度評価レポート - 分散メッセージ ミドルウェア

1. 背景

インターネット技術と金融技術の継続的な発展により、RPC から Web サービスへ、SOA の推進から RESTful へ、クラウド コンピューティングにおける PaaS と SaaS の推進など、分散アーキテクチャが金融企業で広く使用されるようになり、メッセージ ミドルウェアは分散システム間の通信、統合、統合において重要な役割を果たしてきました。

分散メッセージ ミドルウェアは、効率的で信頼性の高いメッセージ配信メカニズムを通じてアプリケーション システム間の結合を減らし、高性能なデータ交換を実現し、分散コンピューティング ネットワーク環境で高い可用性と一貫性を保証します。

金融企業は、数多くの分散メッセージ ミドルウェアに直面し、企業の長期的な発展に適した対応するオープン ソース ソフトウェアをどのように選択して決定するかという問題に直面しています。金融業界オープンソースソフトウェア研究ワーキンググループは、金融企業の実際のアプリケーションシナリオに基づいて、主流のオープンソース分散メッセージングミドルウェアの評価を確立および実装し、金融企業が成熟度が高く、企業のニーズに適したオープンソースソフトウェアを選択できるように支援しています。

2. 分散メッセージミドルウェア評価モデル

金融業界におけるオープンソースソフトウェア成熟度評価の全体モデルに基づいて、分散メッセージミドルウェア評価モデルが確立されています。全体的なモデルは、オープンソース ソフトウェアの特性、システム エンジニアリング分野のソフトウェア製品の品質に対する要件、および金融業界におけるオープンソース ソフトウェアの使用に対する需要を完全に組み合わせています。全体的なモデルは、オープンソース ライセンス、業界での認知度、製品の活力、サービス サポート、セキュリティ、互換性、保守性、スケーラビリティ、機能性、信頼性、使いやすさ、パフォーマンス効率など、12 の主要な評価属性と 117 の評価指標をカバーしています。

分散メッセージ ミドルウェアは、主にアプリケーション システム間のデータ転送のための分散システム アーキテクチャで使用され、さまざまな業界で広く使用されています。オープンソースの分散メッセージ ミドルウェアにはさまざまな種類があり、それぞれに独自の重点が置かれています。導入する際には、特定のアプリケーション シナリオと組み合わせて、最もコスト効率の高いオープン ソース製品を選択する必要があります。したがって、オープンソース ソフトウェアがもたらすリスクを防ぎ、金融企業がオープンソース ソフトウェアをより適切に適用できるようにサポートするために、分散メッセージ ミドルウェアの包括的な評価を実施する必要があります。

分散メッセージ ミドルウェア評価モデルは、金融企業が重視する特性と測定可能な指標を中心に構築されており、モデル全体の 12 の評価属性をカバーしています。分散メッセージミドルウェア評価モデルの詳細については、公開されている「金融業界におけるオープンソースソフトウェアの調査と評価 - 分散メッセージミドルウェア評価モデル」を参照してください。

3. 分散メッセージミドルウェアの紹介

メッセージ ミドルウェアには、メッセージの保存、転送、フィルタリング、キューイングなどの機能があります。分散環境におけるプロセス間の通信を拡張し、主にビジネス システムの分離、非同期メッセージ転送、ピーク フロー制御などのシナリオで使用されます。 IBM WebSphere MQ や TongLINK/Q などの従来の商用製品に加えて、オープンソースのメッセージ ミドルウェア テクノロジも近年急速に発展しています。一般的なものには、ActiveMQ、RabbitMQ、ZeroMQ、Kafka、MetaQ、RocketMQ などがあり、多くの業界で広く使用されています。

金融企業の適用状況やビジネスニーズに関する予備調査、現在の技術開発動向を考慮した上で、急速に発展している Kafka と広く普及している RabbitMQ を評価対象として選択しました。今後は他のメッセージキューミドルウェアについても評価を行っていく予定です。

1. カフカ

Kafka は、2010 年 12 月に LinkedIn によってオープンソース化された高スループットの分散メッセージング システムです。Apache Software Foundation のトップ サブプロジェクトの 1 つであり、ますます多くのオープンソース分散処理システムに統合されています。 Kafka は大規模なメッセージ処理アプリケーションに適しており、優れたスケーラビリティとパフォーマンスの利点を備えています。従来のメッセージング システムとは異なり、Kafka はログ集約やストリーミング データ処理などのシナリオでも広く使用されています。

Kafka は、高パフォーマンス、高可用性、分散という技術的特徴を備えています。 Kafka の強力な負荷分散およびレプリケーション戦略により、ノードの信頼性と高可用性が確保され、ノードの動的な拡張がサポートされます。設計と実装において、従来のメッセージ ミドルウェアとは大きく異なります。ファイルシステムを使用してメッセージのライフサイクルを管理し、一定の時間複雑度内でメッセージの永続性とデータアクセスを提供でき、メッセージのバッチ送信と圧縮送信をサポートし、優れたパフォーマンスを発揮します。従来の MQ として設計されておらず、主流のメッセージ サービス仕様に準拠していないため、トランザクションとプロトコルの互換性の点で欠けています。

2. ラビットMQ

2007 年に、AMQP 標準に基づく RabbitMQ 1.0 バージョンが Rabbit Technologies によってリリースされました。Rabbit Technologies は 2010 年に SpringSource に買収され、2013 年に Pivotal に合併されました。現在は Pivotal Software によって商用サポートされています。 RabbitMQ は、AMQP プロトコルを実装する Erlang ベースのオープンソース メッセージング ミドルウェアです。強力なメッセージ キュー サービスを提供しており、Web サーバーが要求に迅速に応答するためによく使用されます。クロスプラットフォームおよびクロス言語のメッセージ送信に適しています。

RabbitMQ は、信頼性の高いメッセージ伝送、柔軟なルーティング戦略、マルチプロトコルのサポートなどの特徴を備えています。 RabbitMQ には、信頼性の高いメッセージ送信を保証するための堅牢なメッセージ確認メカニズム、ユーザー ロール システム、認証および承認管理機能が備わっています。柔軟な交換およびバインディング ルール設定により、強力なメッセージ ルーティング機能が提供され、AMQP、HTTP、STOMP、MQTT などのプロトコルがサポートされます。さらに、RabbitMQ マルチノード クラスターのフェデレーションは外部サービスに依存せず、サービスの高可用性をサポートしますが、サービスの負荷分散にはサードパーティ コンポーネントの使用が必要です。

IV.評価環境

次の表に示すように、実際のビジネスでの使用状況とオープンソース ソフトウェアの主流の安定バージョンに基づいて、評価するオープンソース ソフトウェアを選択します。

表1 ソフトウェアバージョン情報

評価環境は、本番環境における業務システムの実際の動作環境を参考に構築されます。 Kafka と RabbitMQ それぞれに、ノードあたり 3 台の物理サーバーを備えた検証環境を構築します。各サーバーの構成は次の表の通りです。

表2 テスト環境情報

5. オープンソースソフトウェアライセンスの比較

オープンソースソフトウェアライセンスとは、オープンソースソフトウェアの許諾条件であり、商用利用、頒布、改変、特許許諾、私的利用、オープンソースコード、ライセンス契約書および著作権情報の記載、ネットワーク頒布の利用、同契約書の利用、変更の表明、責任の負担、商標の利用など、12 項目の使用要件および制限事項を規定しています。ユーザーがオープンソース ソフトウェアを商用目的で使用する場合、オープンソース ソフトウェア ライセンスの条件に従う必要があります。

Kafka と RabbitMQ オープンソース ソフトウェアのソース コードをスキャンした結果、Kafka で使用されているオープンソース ライセンスは Apache 2.0 であり、RabbitMQ で使用されているオープンソース ライセンスは MPL (Mozilla Public License) 1.1 であることがわかりました。

表3 オープンソースソフトウェアライセンスの比較

Kafka が準拠する Apache 2.0 プロトコルでは、オープン ソース ソフトウェアのソース コードの使用に関する制限が少なく、ユーザーは著作権や特許のリスクにさらされることなく、またソース コードを開示する必要もなく、派生製品を無料で使用、変更、公開できます。 RabbitMQ が採用している MPL 1.1 プロトコルは、オープン ソース ソフトウェア ソース コードの使用に関して比較的厳格です。無料で変更して使用できますが、変更されたソースコードはオープンソースである必要があり、MPL 1.1 プロトコルを引き続き使用する必要があります。同時に、RabbitMQ が準拠する MPL 1.1 プロトコルでは、変更されたコードの著作権はオープン ソース ソフトウェアの発起者に帰属することが求められます。

結果から、 Kafka と比較すると、RabbitMQ には、改変/派生製品のソース コードはオープン ソースでなければならない、再リリースは元のオープン ソース ライセンスに準拠しなければならない、コードの著作権はオープン ソース ソフトウェアの発起者に帰属するなどの問題があることがわかりました。したがって、企業がメッセージ ミドルウェアを含むクローズド ソースの商用製品をリリースする必要がある場合、Kafka が最初の選択肢となります。

6. 製品アクティビティの比較

オープンソースソフトウェア製品の活動は、オープンソースソフトウェアの持続可能性と進化の可能性を反映しており、主にオープンソースソフトウェアのバージョンリリース状況、オープンソースコミュニティの状況、ソフトウェアに対する注目度などの側面から分析されます。

1. ソフトウェアバージョンのリリース: Kafka は遅れてリリースされましたが、過去 2 年間で急速に更新されています。

オープンソース ソフトウェア バージョンのリリースは、オープンソース ソフトウェア開発の安定性と持続可能性を反映しています。このモデルは、バージョン番号、コード量、リリース時間を通じてオープンソース ソフトウェア バージョンのリリース状況を分析します。オープンソースソフトウェアのソースコードを解析すると、過去2〜3年のKafkaとRabbitMQのバージョンのリリース状況は以下のようになります。

図1 ソフトウェアバージョンとコードの変更

Kafka バージョン 1.0.0 は 2017 年 10 月にリリースされました。コード行数は 2 年前と比べて 5 倍以上に増加しており、バージョンのイテレーションは比較的高速です。過去 2 年間の Kafka のさまざまなバージョンの調査を通じて、バージョン アップデートでは主に以前のバージョンの欠陥が修正され、ビジネス処理のロジックが最適化され、自動パーティション バランス、セキュリティ認証、暗号化された送信、トランザクション、EOS (正確に 1 回限りのセマンティクス) などの新機能が追加されていることがわかりました。

2012 年に RabbitMQ バージョン 3.0 がリリースされて以来、コード行数は 30% 程度しか増加しておらず、バージョンの反復は比較的安定しています。過去 2 年間の RabbitMQ のさまざまなバージョンの調査を通じて、バージョン アップデートは主にサーバー、管理プラグイン、MQTT プラグイン、STOMP プラグイン、クライアントなどの欠陥/脆弱性の修復と機能の最適化であることがわかりました。主要機能の更新は少なく、コード変更の量も少ないです。

結果によると、Kafka と RabbitMQ の現在のリリースは比較的安定しており、Kafka コードはより速く成長し、RabbitMQ コードはより着実に成長しています。

（二） オープンソースコミュニティ: Kafka の貢献者は RabbitMQ の約 5 倍

オープンソースコミュニティの状況は、オープンソースソフトウェアの活動と将来のオープンソースソフトウェアの発展を反映しています。このモデルは、貢献者、提出量、貢献者レベルという 3 つの側面からオープンソース ソフトウェアのコミュニティ状況を分析および評価します。オープンソースコミュニティの状況を分析すると、Kafka と RabbitMQ のオープンソースコミュニティの状況は次のようになります。

図2 ソフトウェア貢献者と提出数の変化

図3 ソフトウェア貢献者レベルの分布の比較

貢献者の数で見ると、四半期あたりの Kafka 貢献者の数は RabbitMQ の 2 ～ 5 倍です。提出数に関して言えば、Kafka と RabbitMQ の四半期あたりの提出数に大きな違いはありません。貢献者レベルの分布に関して言えば、Kafka の貢献者の数は RabbitMQ の貢献者の数をはるかに上回っています (約 6 倍)。

結果は、オープンソース コミュニティの貢献者の数とレベルの点で、Kafka が RabbitMQ を上回っていることを示しています。提出量に関しては、どちらも安定した提出数を維持しています。

（三つ） ソフトウェアの注目: Kafka は RabbitMQ よりもフォロワーとユーザーが多い

オープンソース ソフトウェアに注目が集まっているのは、その魅力と実用性を反映しています。このモデルは、ソースコードの開発者の数、開発者が提起した要件の数、ブログ、フォーラム、書籍の数に焦点を当ててソフトウェアの人気度を分析します。ソフトウェア関連情報を分析することで、以下のようなソフトウェア注目情報が得られます。

図4 ソフトウェアの注目度の比較

ソフトウェアの注目度から判断すると、現在、Kafka に注目している開発者の数は RabbitMQ の 2 ～ 3 倍です。ソフトウェア要件の数で言えば、Kafka は RabbitMQ の 6 ～ 7 倍です。ブログ、フォーラム、書籍の数から判断すると、ブログ、フォーラム、書籍における Kafka の情報量は RabbitMQ の約 5 倍です。

結果は、Kafka のフォロワーとユーザーが RabbitMQ よりも多いことを示しています。

七。業界認知度とサービスサポートの比較

業界での認知度とサービス サポートは、業界におけるオープン ソース ソフトウェアの応用と専門的なサービスの提供を反映しています。アプリケーション統合ソリューションとクラウド コンピューティング サービスの両方を分析した結果を次の表に示します。

表4 業界の認知度とサービスサポート

結果から、Kafka と RabbitMQ はすでに多くの商用実践やアプリケーション事例があり、クラウド コンピューティング、ビッグ データなどのシナリオで広く使用されていることがわかります。 Kafka は、クラウド コンピューティングやビッグ データ プラットフォームで広く使用されています。

八、 機能比較

メッセージ ミドルウェアは、主に分散アプリケーション間の情報交換に使用されます。メッセージ プロデューサーはメッセージをサーバーに送信し、メッセージはコンシューマーがメッセージを取得するまでサーバーのメモリまたはディスクに保存されます。メッセージミドルウェアの機能に関しては、Kafka と RabbitMQ は主にサーバー、プロデューサー、コンシューマー、メッセージ送信の 4 つの側面から評価されます。

（1つ） サーバー機能: Kafka にはコア機能があり、RabbitMQ にはより包括的な機能があります

サーバーは主に、メッセージ、キュー、クラスター、セキュリティなどの管理と、アプリケーション サービス要求の処理を担当します。サーバーの技術的な特徴には、主にメッセージ、キュー、クラスターの 3 つの側面が含まれます。

表5 サーバーの技術的特徴の比較

Kafka の場合、メッセージ処理に関しては、メッセージがディスクに永続化され、ディスクの分散順次読み取りと書き込みによってメッセージの読み取りと書き込みの効率が向上します。キューに関しては、メッセージはトピックとパーティションを通じて生成および消費されます。パーティションのリモート定義とメッセージ ルーティングはサポートされておらず、消費はコンシューマー グループを通じてのみ実行できます。クラスターに関しては、Zookeeper は分散クラスターを調整および管理して、ノード パーティションのバランスの取れた分散、ノードの選択、プロデューサーとコンシューマーの調整、さまざまな構成サービスの提供を実現するために使用されます。

RabbitMQ では、メッセージ処理に関して、メッセージを保存するためのメモリとディスクの 2 つの方法が提供されています。メモリ方式を使用してメッセージを処理する方が効率的です。キューに関しては、プロデューサー キューとコンシューマー キューのリモート定義をサポートし、交換を通じてメッセージ ルーティング戦略を柔軟に構成できます。クラスタリングに関しては、Erlang の分散特性に基づいてクラスターが構築されます。各ノードは、クライアントにサービスを提供するピア ノードです。通常、負荷分散と障害転送にはサードパーティの負荷分散コンポーネントが必要です。

結果から、Kakfa はメッセージ ミドルウェアの中核機能を備え、配信とメッセージ処理を最適化しているのに対し、RabbitMQ はより包括的で、柔軟なメッセージ処理を実現するためのより多くの機能を提供していることがわかります。

（二） プロデューサー機能: KafkaとRabbitMQはどちらもコア機能を備えています

プロデューサーとは、メッセージを生成するアプリケーションのことです。プロデューサーがメッセージを生成すると、そのメッセージはサーバーに送信されます。サーバーはディスクまたはメモリを使用してメッセージを保存し、メッセージのコピーも保存します。生産者特性の比較を次の表に示します。

表6 生産者の技術的特徴の比較

表からわかるように、Kafka はバッチ転送機能とデータ圧縮機能を提供します。バッチ送信では一度に複数のメッセージを送信でき、データ圧縮によりネットワーク帯域幅の要件が削減されるため、メッセージ処理機能が向上します。送信の信頼性に関しては、RabbitMQ はプロデューサー クライアントのメッセージがキューに正しく配信されたことを確認するための確認メカニズムを提供します。 Kafka は、データが正しく受信され、ディスクに保存されたことを確認するための Ack メカニズムを提供します。

結果から、Kafka と RabbitMQ はどちらもコア機能を備えているものの、高度な機能に重点が置かれていることがわかります。

（三つ） コンシューマー特性: Kafka はプルモデルを使用し、RabbitMQ はプッシュモデルを使用します。

コンシューマーとは、メッセージを受信して​​処理するアプリケーションを指します。メッセージはメッセージ キュー ミドルウェア サーバーに送信された後、他のビジネス処理のためにコンシューマーに転送されます。消費者特性の比較は以下の表に示されています。

表7 消費者向け技術特性の比較

メッセージ消費モデルに関しては、Kafka はプル モデルを使用します。このモデルでは、コンシューマーが必要なメッセージに応じてサーバーからデータをプルします。 RabbitMQ はプッシュ モデルを使用します。このモデルでは、コンシューマーがサーバー キューとの長い接続を維持し、キュー内のメッセージがコンシューマーにプッシュされます。

メッセージの確認に関しては、Kafka はメッセージが確実に消費されることを保証するために、メッセージ確認メカニズム (「少なくとも 1 回」) を提供します。 RabbitMQ は、メッセージがコンシューマーに確実に届くように、コンシューマーが明示的に Ack を返すまでメッセージを削除しないメッセージ確認メカニズム (Ack) を提供します。さらに、RabbitMQ はメッセージのフィルタリングや事前読み取りカウントなどの機能も提供します。

結果は、Kafka と RabbitMQ が異なる消費モデルを採用していることを示しています。メッセージを取得する消費者の柔軟性と信頼性の点では、RabbitMQ はより包括的な機能を提供します。

（4） メッセージ送信機能: Kafkaにはコア機能があり、RabbitMQにはより包括的な機能がある

メッセージ送信モードには、主にポイントツーポイント (PTP) モードとパブリッシュサブスクライブ (Pub/Sub) モードがあります。メッセージ伝送の観点から、Kafka と RabbitMQ の技術的な特徴を比較すると次のようになります。

表8 メッセージ伝送技術特性の比較

Kafka と RabbitMQ はどちらもポイントツーポイント モードとパブリッシュ サブスクライブ モードをサポートしていますが、実装メカニズムに関しては、Kafka はコンシューマー グループに基づいており、RabbitMQ は AMQP プロトコルに基づいています。さらに、RabbitMQ は、メッセージの優先度、スケジュールされたメッセージ、JMS 仕様などの機能もサポートしています。

結果は、Kafka が主要なメッセージ転送要件を満たすことができるが、RabbitMQ がより高度な機能をサポートしていることを示しています。

9. パフォーマンス効率

メッセージ ミドルウェアのパフォーマンス効率は、主にクラスターのメッセージの送受信のスループット レートを指します。スループット指標は 2 つあります。1 つはプロデューサー/コンシューマーが 1 秒あたりに送信/受信したメッセージの数で、レコード/秒で測定されます。もう 1 つは、プロデューサー/コンシューマーが 1 秒あたりに送信/受信したメッセージの量で、MB/秒単位で測定されます。メッセージの送信スループットと受信スループットを測定することで、メッセージ キュー ミドルウェアのパフォーマンスを評価します。主なテストシナリオは次のとおりです。

（１）同時クライアント数：プロデューサー／コンシューマーの数を増やし続け、送受信スループットの変化をテストする。

（２）メッセージサイズ：メッセージサイズを継続的に増加させ、送信スループット率の変化をテストする。

（３）システムの信頼性：コピー数を増やしたり、応答モードを変更したりして送信スループットの変化をテストする。

（4）Kafkaの機能：Kafkaメッセージのバッチ送信、データ圧縮、パーティション数などの機能がスループットに与える影響をテストします。

（1つ） Kafka のスループットは、さまざまなプロデューサー数で RabbitMQ よりも優れています。

プロデューサーの数の変化に応じてメッセージ送信スループットをテストします。メッセージ サイズを 1000 バイトに設定し、スループットの増加が止まるまでプロデューサー スレッドの数を増やし続けます。テスト結果を下の図に示します。

図5 生産者数の増加がスループットに与える影響

テスト結果によると、Kafka の送信スループットは直線的に増加し始め、ピークに達した後は狭い範囲内で変動し、ピーク時には 1 秒あたり約 320,000 件のメッセージになります。 RabbitMQ の送信スループット レートは継続的に増加し始め、その後安定し、ピーク時には 1 秒あたり約 120,000 件のメッセージに達しました。 Kafka プロデューサーの数がパーティションの数より少ない場合、各プロデューサーはパーティションにメッセージを個別に送信できるため、スループット レートは直線的に増加します。パーティションよりもプロデューサーの数が多い場合、パーティション間の負荷分散がトリガーされ、スループットが変動します。 RabbitMQ がプロデューサーを追加すると、システムの並列処理が増加し、スループット レートは着実に増加した後、徐々に安定します。

結果は、プロデューサーの数が同じ場合、Kafka の送信スループットが RabbitMQ よりも大幅に高く、基本的に約 3 倍であることを示しています。

（二） さまざまなメッセージサイズにおいて、Kafka のスループットは RabbitMQ よりも優れています。

メッセージ サイズに応じて変化するメッセージ送信スループット レートをテストします。プロデューサー、コンシューマー、その他の条件を変更せずに、メッセージ サイズを 100 バイトから 10,000 バイトに増加します。テスト結果を下の図に示します。

図6 メッセージサイズの変更によるスループットへの影響

テスト結果によると、Kafka でも RabbitMQ でも、メッセージが大きくなると 1 秒あたりに送信されるメッセージ数は少なくなりますが、1 秒あたりに送信されるデータ量は多くなります。これは、各メッセージにペイロードに加えてメタデータが含まれているためです。ペイロードが大きくなるほど、メタデータの割合は小さくなります。したがって、メッセージ数は減りますが、1 秒あたりに送信されるデータ量は増加します。

結果によると、メッセージ サイズが同じ場合、Kafka の送信パフォーマンスは RabbitMQ をほぼ 1 桁上回っており、小さなメッセージを送信する場合は Kafka の利点がより明らかになっています。

（三つ） レプリカ数やレスポンスモードの違いは、Kafkaのパフォーマンスに比較的影響が少ない

コピー数と応答モードがメッセージ送信パフォーマンスに与える影響をテストします。レプリカの数を 0 から 2 に増やし、さまざまな応答モードでのスループットの変化をテストします。

図7 レプリカ数と応答モードがスループットに与える影響

テスト結果によると、Kafka がプライマリ パーティションとバックアップ パーティションにデータが書き込まれるのを待機して確認する場合、レプリカの数が 0 から 2 に増加するとスループットが 70% 低下します。他の 2 つの応答モードへの影響は小さくなります。バックアップがない場合、RabbitMQ のパフォーマンスは Kafka と比較して平均的です。ミラー モードをオンにしてレプリカの数を増やすと、スループット レートが 90% 以上低下します。

結果は、Kafka はシステムの信頼性を向上させる際のパフォーマンスの低下が少なく、RabbitMQ よりもレプリカ同期メカニズムが優れていることを示しています。

（4） Kafka の受信率は、消費者の数に応じて RabbitMQ よりも優れています。

メッセージ受信スループットがコンシューマーの数によってどのように変化するかをテストします。メッセージ サイズを 100 バイトに設定し、コンシューマーの数を徐々に増やします。スループットの変化は次の図に示されています。

図8 Kafka圧縮モードのスループットへの影響

テスト結果によると、同じグループの Kafka コンシューマーによってサブスクライブされたデータはグループ内の 1 人のメンバーにのみ割り当てられ、消費の進行状況は各メンバーによって維持されるため、同じパーティションのデータは、コンシューマーが異なるグループに分散されている場合にのみ並行して消費できます。この時点で消費スループットが大幅に向上します。 RabbitMQ の場合、複数のコンシューマーが異なるキュー内の同じデータをサブスクライブすると、メッセージを複数のキューに配信する必要があり、メッセージのレプリケーションにかかる時間が長くなります。したがって、すべての RabbitMQ コンシューマーが同じキューからデータを消費すると、異なるキューからデータを消費する場合よりもスループットが大幅に高くなります。

結果は、Kafka のメッセージ受信パフォーマンスが RabbitMQ よりも大幅に優れていることを示しています。同時に、Kafka は並列消費の機能を提供し、消費者数の増加に応じて消費率を直線的に増加させることができます。

（五） バッチメッセージ送信やデータ圧縮などの Kafka の機能により、スループット率が一定程度向上しました。

Kafka には、メッセージのバッチ送信、データ圧縮、トピックのパーティション分割、バッチ受信など、RabbitMQ にはない機能があります。このシナリオでは、異なるバッチ サイズ、パーティション数、または圧縮モードでの Kafka スループットの変化がテストされます。上記のパフォーマンス テスト シナリオでは、Kafka はデフォルト構成を使用し、送信されるバッチ数は 16384、圧縮モードは圧縮なし、フェッチ サイズは 1048576 バイトです。パーティション数はノード数の整数倍に設定することをお勧めします。テスト中は9に設定されていました。

図 9 Kafka がバッチごとに送信したメッセージ数がスループットに与える影響 図 10 コンシューマーが一度に受信するメッセージ数がパフォーマンスに与える影響

図11 Kafka 圧縮モードがスループットに与える影響 図12 Kafka パーティション数がスループットに与える影響

テスト結果によると、バッチ サイズが大きくなるにつれて、Kafka のスループットが大幅に増加することがわかります。これは、メッセージをバッチで送信すると、サーバー上の I/O 数とネットワーク転送のオーバーヘッドを削減できるためです。同時に、消費者が一度に受信したメッセージの量（バイト）が継続的に増加し、スループットを受け取るKafkaはさらに改善されます。消費者のビジネス処理のニーズに応じて、消費モードを独立して選択することをお勧めします。

Kafkaのスループットは、SnappyおよびLZ4圧縮モードで改善されていますが、GZIP圧縮モードでのパフォーマンスは、圧縮されていない状態のパフォーマンスよりも低くなっています。理論的には、エンドツーエンドのデータ圧縮でより重複したデータがあるほど、圧縮効果が向上し、ネットワーク帯域幅が少なくなります。ただし、圧縮率が高いほど、スループット率は必ずしもそうではありません。圧縮速度を上げると、圧縮と減圧の時間オーバーヘッドが増加します。

パーティションの数が増えると、カフカの送信スループットが大幅に増加し、徐々に減少します。 Kafkaのパーティション構造は、システムに並列消費機能を提供しますが、パーティションの数が大きすぎると、送信スループットが大幅に減少します。 Kafkaの負荷分散戦略によると、ノードの数の整数倍にパーティションの数を構成することで、リソース利用効率を改善できます。

結果は、Kafkaメッセージを送信するバッチ送信とバッチの両方がスループットを改善できることを示しています。スループットに対する圧縮モードの影響は、圧縮アルゴリズムの選択に依存します。パーティションの数が適切に増加すると、スループットが改善されますが、過度に多数がスループットが減少します。

上記のシナリオでのパフォーマンステストの後、RabbitMQとKafkaの両方が優れたパフォーマンスを持っていることがわかりますが、KafkaはRabbitMQ全体よりも高いスループットを持っています。

10。セキュリティ比較

メッセージミドルウェアのセキュリティには、主に、暴露されたセキュリティの脆弱性とセキュリティメカニズムの2つの側面が含まれます。 KafkaとRabbitmqの脆弱性情報とセキュリティメカニズムを評価し、結果を次の表に示します。

表9セキュリティの脆弱性とセキュリティメカニズムの比較

テーブルからわかるように、KafkaとRabbitmqはどちらもセキュリティメカニズムの観点から比較的包括的です。暴露されたセキュリティの脆弱性の観点から、Kafkaはこれまでに明らかに脆弱性を発見していませんが、Rabbitmqは14のセキュリティの脆弱性を暴露しています。主な脆弱性には、無許可のアクセス権を取得するためのセキュリティメカニズムのバイパス、クロスサイトのスクリプトの脆弱性、ログの読み取りによる機密情報の取得、およびサービスの拒否が含まれます。

結果は、セキュリティメカニズムと暴露されたセキュリティの脆弱性の観点から、KafkaがRabbitmqよりも安全であることを示しています。

11。スケーラビリティの比較

メッセージミドルウェアのスケーラビリティには、主にノードの水平拡張、動的拡張、負荷分散機能が含まれます。 KafkaとRabbitmqのテスト結果によると、スケーラビリティの違いを次の表に示します。

表10スケーラビリティ比較

ノード拡張に関しては、Kafkaは分散アーキテクチャを採用し、Zookeeperを介してノードを管理してノードの動的拡張を実現します。 RabbitMQノードの動的拡張には、サードパーティコンポーネントのサポートが必要です。負荷分散の観点から、Kafkaは、ノードにパーティションとレプリカを均等に配布する戦略を通じて生産者クライアントの負荷分散を達成し、各消費者に消費パーティションを均等に割り当て、負荷バランスを自動的にトリガーすることにより、消費者クライアントの負荷分散を達成し、クラスターヌード間のメッセージ負荷を効果的にバランスさせることにより、 RabbitMQは、サードパーティの負荷分散コンポーネントを使用する必要があるため、ノードを拡張した後、ノード情報を構成し、拡張の可用性に関してKafkaよりも弱い対応するロードバランシング戦略を更新する必要があります。

結果は、動的なスケーラビリティと負荷分散戦略の観点から、KafkaがRabbitMQよりも優れていることを示しています。

12。信頼性の比較

メッセージミドルウェアの信頼性には、主にノードが故障したときのクラスターとデータの可用性、およびメッセージ送信中の確認メカニズムとトランザクションサポートが含まれます。 KafkaとRabbitmqのテスト結果によると、違いを次の表に示します。

表11信頼性の比較

クラスターとデータの可用性に関しては、ノードが失敗すると、Kafkaはレプリカと選挙メカニズムを使用して、ノードとデータの高可用性を確保します。 RabbitMQは、ミラーバックアップメカニズムを使用して、ノードとデータの信頼性を確保します。メッセージのマルチコピーの同期と選挙戦略の観点から、KafkaはRabbitmqよりも柔軟で完全です。メッセージ送信の信頼性の観点から、Kafkaはバージョン0.11.0のトランザクションのサポートも追加し、重複排除メカニズム（正確に対象）を提供し、メッセージ伝達の信頼性を向上させました。 RabbitMQは、AMQPベースのトランザクションメカニズムと、生産者と送信者向けの複数のメッセージ確認メカニズムを実装しています。

結果は、KafkaとRabbitmqの両方が、ノードとデータの高可用性と信頼性の高いメッセージ送信の保証を提供できることを示しています。

13。他の機能の比較

メッセージミドルウェアの選択は、保守性、互換性、使いやすさなどの機能を評価する必要があります。 KafkaとRabbitmqの全体的な比較を次の表に示します。

表12他の特性の比較

結果は、広く使用されているメッセージミドルウェアとして、KafkaとRabbitMQがツールと統合の観点から優れた保守性と使いやすさを提供できることを示しています。互換性の観点から、既存のメッセージサービスプロトコルに対するKafkaのサポートは弱く、RabbitMQはプロトコル仕様との互換性が向上しています。

14. まとめ

分散メッセージングミドルウェア評価モデルに基づいて、オープンソースソフトウェアライセンス、業界認識、製品活動、サービスサポート、機能、パフォーマンス、セキュリティ、スケーラビリティ、信頼性、保守性、適合性、使用率など、12の側面からオープンソースソフトウェアKafkaとRabbitMQの満期評価を完了しました。各評価の結果は要約され、次のように比較されます。

表13 KafkaとRabbitmqの比較概要

一般に、分散されたメッセージミドルウェアKafkaとRabbitmqには、業界の認識、サービスサポート、信頼性、保守性、互換性、使いやすさの点で独自の特性があります。 Kafkaは、オープンソースライセンス、製品アクティビティ、パフォーマンス、セキュリティ、およびスケーラビリティの観点から、RabbitMQよりも優れています。 Kafkaは、よりリラックスしたライセンスを使用し、アクティビティが高く、RabbitMQよりもはるかに優れたパフォーマンスを発揮し、セキュリティとスケーラビリティの点でより良い保護を提供します。 KafkaはRabbitmQよりも機能性がわずかに少ないですが、すでに主要な機能があります。

上記のすべての評価結果に基づいて、申請プロセス中に企業がKafkaを優先することをお勧めします。

お問い合わせ

金融業界のオープンソースソフトウェア研究ワーキンググループ

ワーキンググループは、オープンソースソフトウェアをより適切に適用するための金融企業に研究サポートと技術的保証を提供し、オープンソースソフトウェアおよびサービスプロバイダーの評価モデル、評価実装、評価レポート、技術体験交換と共有、および業界技術開発研究における詳細な協力を実施することに取り組んでいます。ワーキンググループは、主に銀行、保険、証券、支払い機関などの有名な国内金融企業で構成されています。ワーキンググループに参加し、金融業界の革新的な技術開発に貢献することを歓迎します。

ho tungキット 021-20631821 [email protected]

王奇 021-20631825 [email protected]

Liu weihuai 021-20631824 [email protected]

江のダンニ 021-20631822 [email protected]