メッセージングミドルウェアとして Kafka と RabbitMQ のどちらが優れていますか?

高い同時実行性と高いメッセージ スループットを重視する IM のインターネット シナリオでは、MQ メッセージ ミドルウェアは非常に重要なインフラストラクチャです。 IM システムのサーバー側アーキテクチャにおいて、メッセージ転送、メッセージピークシェービング、非同期メッセージ交換の役割を果たします。

もちろん、MQ メッセージ ミドルウェアの役割はこれだけにとどまりません。その価値はテクノロジーだけにあるのではなく、より重要なのは、同期メッセージ処理に関する従来の考え方を変えたことです。

たとえば、IM メッセージの履歴を保存する場合、従来の情報システムのアプローチでは、メッセージを受信した直後に同期してデータベースに保存することがあります。このアプローチは、同時実行性が低い場合にはうまく機能しますが、インターネットの同時実行性が高い環境では大惨事になります。

MQ メッセージ ミドルウェアはプールとして理解できます。プールの一方の端にはメッセージ プロデューサーがあり、もう一方の端にはメッセージ コンシューマーがあります。プロデューサーとメッセージ コンシューマーは直接接続する必要がないため、ビジネスの分離、分散アーキテクチャなど、多くの利点がもたらされます。プロデューサーとコンシューマーは互いに完全に透過的です。

ただし、市場には MQ メッセージ ミドルウェア製品が数多く存在します。 IM システムに欠かせないものとして、どのように選択すればよいのでしょうか?

メッセージキューミドルウェアとは

メッセージ キュー ミドルウェア (略してメッセージ ミドルウェア) とは、プラットフォームに依存しないデータ交換と、データ通信に基づく分散システムの統合のための、効率的で信頼性の高いメッセージ伝送メカニズムの使用を指します。

メッセージ パッシングおよびメッセージ キューイング モデルを提供することで、分散環境におけるアプリケーションの分離、柔軟なスケーリング、冗長ストレージ、トラフィック ピークの削減、非同期通信、データ同期などの機能を提供できます。分散システム アーキテクチャの重要なコンポーネントとして、重要な役割を果たします。

現在、さまざまなオープンソース メッセージ ミドルウェアが利用可能であり、ActiveMQ、RabbitMQ、Kafka、RocketMQ、ZeroMQ など、その多くは誰もがよく知っているものです。どれを選択しても、役に立たない領域がいくつかあります。結局のところ、それはあなた向けにカスタマイズされているわけではありません。

一部の大企業では、長期にわたる使用プロセスで一定の経験を蓄積しており、メッセージ キューの使用シナリオが比較的安定して確立されているか、現在市場に出回っているメッセージ ミドルウェアでは自社のニーズを満たすことができない場合があります。同時に、メッセージ ミドルウェアを自分用にカスタマイズするために自己研究を選択するだけの十分なエネルギーと人材も持っています。

ただし、ほとんどの企業は車輪の再発明を選択しないため、自社に適したメッセージ ミドルウェアを選択することが特に重要です。

前者であっても、安定した信頼性の高い関連製品が開発されるまでには、このような選択プロセスを経ることになります。

メッセージ ミドルウェアを全体的なアーキテクチャに導入する場合、コストや利点など、多くの要素を考慮する必要があります。どうすれば最高の費用対効果を実現できるでしょうか?

メッセージ ミドルウェアにはさまざまな種類がありますが、それぞれに重点が置かれています。自分に合ったものを選び、その長所を生かして弱点を避けるのが間違いなく最善の方法です。もし、このことに困惑しているのであれば、この記事が参考になるかもしれません。

さまざまなメッセージキューの簡単な説明

アクティブMQ

これは Apache によって開発され、Java で記述され、JMS1.1 仕様に完全に基づいたメッセージ指向ミドルウェアです。アプリケーションに対して、効率的でスケーラブル、かつ安定した安全なエンタープライズ レベルのメッセージ通信を提供します。

しかし、歴史的な理由と重い負担により、現在の市場シェアは次の 3 つのメッセージ ミドルウェアほど大きくはありません。その最新アーキテクチャは Apollo と名付けられ、次世代の ActiveMQ として知られています。興味のある学生は自分でそれについて学ぶことができます。

ラビットMQ

Erlang 言語で実装された AMQP プロトコルを使用するメッセージ ミドルウェアは、もともと金融システムに由来し、分散システムでメッセージを保存および転送するために使用されます。

RabbitMQ は、信頼性、可用性、スケーラビリティ、豊富な機能における優れたパフォーマンスにより、今日ますます多くの人々に認知されるようになりました。

カフカ

これはもともと LinkedIn によって、ZooKeeper コーディネーションに基づく分散型、マルチパーティション型、マルチレプリケーション型の分散メッセージング システムとして Scala 言語を使用して開発されました。現在、Apache Foundation に寄贈されています。

これは、水平方向のスケーラビリティと高スループットのために広く使用されている、高スループットの分散パブリッシュ/サブスクライブ メッセージング システムです。現在、Cloudera、Apache Storm、Spark、Flink などのオープンソースの分散処理システムが Kafka との統合をサポートするようになっています。

ロケットMQ

これは、Apache Foundation に寄贈された Alibaba のオープンソース メッセージング ミドルウェアです。 Java で開発されており、高スループット、高可用性、大規模分散システム アプリケーションに適しているという特徴があります。ダブル11の洗礼を経験しており、その強さを過小評価すべきではありません。

ゼロMQ

史上最速のメッセージキューとして知られており、C言語をベースに開発されています。 ZeroMQ は、複数のスレッド、コア、ホストにわたって弾力的にスケーリングするメッセージ処理キュー ライブラリです。

ほとんどの場合、これをメッセージ キュー ファミリとして分類することに慣れていますが、以前のものとは根本的に異なります。 ZeroMQ 自体はメッセージ キュー サーバーではなく、むしろ、元の Socket API にカプセル化のレイヤーを追加するだけの、基盤となるネットワーク通信ライブラリのセットのようなものです。

市場には、PhxQueue、CMQ、Tencent の CKafka、Go 言語をベースにした NSQ など、多くのメッセージ ミドルウェアが存在します。 Redis のような製品を一種のメッセージ ミドルウェアと見なす人もいます。

もちろん、それらはすべて素晴らしいのですが、この記事の長さではすべてを網羅することはできません。以下では、代表的なメッセージミドルウェアである RabbitMQ と Kafka を具体的に取り上げて分析し、公平かつ公正な立場に立ってメッセージミドルウェアの選択におけるポイントを説明します。

メッセージミドルウェアを選択する際のポイント

メッセージミドルウェアが要件を満たしているかどうかを測定するには、複数の側面から検討する必要があります。

まず第一に、機能面が重要です。これは、すぐに使用できる状態を可能な限り最大限に実現できるかどうかを直接決定し、それによってプロジェクト サイクルの短縮やコストの削減などを実現します。

メッセージミドルウェアの機能が要求される要件を満たさない場合、二次開発が必要となり、プロジェクトの技術的な難易度と複雑さが増し、プロジェクトサイクルが延長されます。

メッセージミドルウェアの具体的な選択基準

機能的次元

機能的次元は複数のサブ次元に分けることができ、大まかに次のように分類できます。

優先キュー

優先キューは先入先出キューとは異なります。優先度の高いメッセージは最初に消費される特権を持ち、これにより下流に対して異なるメッセージ レベルを保証できます。

ただし、この優先順位には、コンシューマーの消費速度がプロデューサーの速度よりも速く、メッセージ ミドルウェア サーバー (通常は単にブローカーと呼ばれる) にメッセージが蓄積されていないという前提条件も必要です。

その場合、送信されたメッセージの優先度を設定することには実際の意味がありません。なぜなら、メッセージはプロデューサーが送信するとすぐにコンシューマーによって消費されるため、ブローカーには最大で 1 つのメッセージしか存在せず、単一メッセージの優先度は無意味になるからです。

遅延キュー

ネットショッピングをしているときに、「30分以内に支払いが行われない場合、注文は自動的にキャンセルされます」というようなメッセージに遭遇したことはありませんか?これは遅延キューの典型的なアプリケーション シナリオです。

遅延キューには、対応する遅延メッセージが格納されます。いわゆる「遅延メッセージ」とは、メッセージが送信された後、コンシューマーがメッセージをすぐに受信することは期待されておらず、コンシューマーがメッセージを受信して​​消費できるようになるまで特定の期間待機することを意味します。

遅延キューは一般的に次の 2 つのタイプに分けられます。

• メッセージベースの遅延とは、メッセージごとに異なる遅延時間を設定することを意味します。その後、新しいメッセージがキューに入るたびに、遅延時間に従って再ソートされます。もちろん、これはパフォーマンスにも大きな影響を与えます。
• 実際のアプリケーションでは、キューベースの遅延が主に使用されます。 5 秒、10 秒、30 秒、1 分、5 分、10 分など、異なる遅延レベルのキューが設定されます。各キュー内のメッセージの遅延時間は同じであるため、遅延ソートによるパフォーマンスの低下を回避できます。時間指定メッセージは、特定のスキャン戦略 (タイミングなど) を通じて配信できます。

デッドレターキュー

何らかの理由でメッセージを正しく配信できない場合、メッセージが理由もなく破棄されないようにするために、通常、メッセージはデッドレターキューと呼ばれる特別な役割を持つキューに配置されます。

これに対応するのが「ロールバック キュー」の概念です。消費者が消費するときに例外が発生した場合、この消費に対する確認 (Ack) がないと想像してください。メッセージがロールバックされた後、そのメッセージは常にキューの先頭に配置され、その後継続的に処理されてロールバックされるため、キューが無限ループに陥ります。

この問題を解決するには、キューごとにフォールバック キューを設定します。これとデッドレターキューは両方とも、例外処理を確実に行うためのメカニズムを提供します。実際の状況では、バックオフ キューの役割は、デッド レター キューと再試行キューによって果たされます。

再試行キュー

実際、これは一種のロールバック キューと見なすことができます。具体的には、コンシューマーがメッセージを消費できない場合、メッセージが理由もなく失われるのを防ぐために、メッセージはブローカーにロールバックされます。

バックオフ キューとは異なり、再試行キューは通常、複数の再試行レベルに分割されます。通常、各再試行レベルには再配信の遅延もあります。再試行回数が増えるほど、配信の遅延が大きくなります。

たとえば、メッセージが初めて消費されず、再試行キュー Q1 に入ります。 Q1 の再配信遅延は 5 秒で、メッセージは 5 秒後に再配信されます。

メッセージが再度消費されなかった場合、再試行キュー Q2 に入ります。 Q2 の再配信遅延は 10 秒で、メッセージは 10 秒後に再度配信されます。

同様に、再試行回数が増えるほど、再配信にかかる時間は長くなります。したがって、上限を設定する必要があります。再試行回数がこの制限を超えると、メッセージは配信不能キューに入れられます。

再試行キューと遅延キューには同じポイントがあり、どちらも遅延レベルを設定する必要があります。それらの違いは、遅延キュー アクションは内部でトリガーされるのに対し、再試行キュー アクションは外部のコンシューマー側によってトリガーされる点です。遅延キューは 1 回だけ動作しますが、再試行キューの動作範囲は後方に渡されます。

消費パターン

消費モードはプッシュモードとプルモードに分かれています。

• プッシュ モードは、ブローカーがメッセージをコンシューマー エンドにアクティブにプッシュすることを意味します。これにより、リアルタイムのパフォーマンスが向上しますが、サーバーからプッシュされたメッセージがコンシューマー エンドに過負荷をかけないようにするために、特定のフロー制御メカニズムが必要になります。
• プル モードとは、コンシューマーがブローカーに積極的に (通常は時間指定または定量指定の) メッセージをプルするように要求することを意味します。リアルタイムのパフォーマンスはプッシュ モードよりも劣りますが、プルされるメッセージの量は、独自の処理能力に応じて制御できます。

放送視聴

一般的に、メッセージ配信モードには、ポイントツーポイント (P2P) モードとパブリッシュ/サブスクライブ (Pub/Sub) モードの 2 つがあります。

• ポイントツーポイント モードの場合、メッセージは消費されるとキューに保存されなくなるため、メッセージ コンシューマーは消費されたメッセージを消費できません。キューは複数のコンシューマーをサポートできますが、メッセージは 1 つのコンシューマーによってのみ消費されます。
• パブリッシュ/サブスクライブ モデルは、コンテンツ ノードにメッセージをパブリッシュおよびサブスクライブする方法を定義します。このコンテンツ ノードはトピックと呼ばれます。トピックは、メッセージ配信の仲介者と考えることができます。メッセージ パブリッシャーはトピックにメッセージをパブリッシュし、メッセージ サブスクライバーはトピックからのメッセージをサブスクライブします。

トピックにより、メッセージのサブスクライバーとパブリッシャーは互いに独立した状態を保つことができ、接触なしでメッセージの配信を保証できます。パブリッシュ/サブスクライブ モードは、1 対多のメッセージのブロードキャストに使用されます。

RabbitMQ は典型的なポイントツーポイント モデルですが、Kafka は典型的なパブリッシュ サブスクライブ モデルです。

ただし、RabbitMQ では、スイッチ タイプを設定することでパブリッシュ サブスクライブ モードを実装し、ブロードキャスト消費の効果を実現できます。 Kafka はポイントツーポイント方式で消費することもできます。コンシューマ グループの概念は、キューの概念と完全に同じと見なすことができます。

ただし、比較すると、Kafka はメッセージ バックトラッキング機能があるため、RabbitMQ よりもブロードキャスト消費のサポートが強力です。

メッセージのバックトラッキング

通常、メッセージは消費された後に処理され、それ以上消費できなくなります。メッセージ バックトラッキングは正反対で、メッセージが消費された後でも、以前に消費されたメッセージを消費できることを意味します。

メッセージに関する一般的な問題は「メッセージの損失」です。通常、メッセージが失われた原因がメッセージ ミドルウェアの欠陥によるものか、ユーザーによる誤用によるものかを追跡するのは困難です。

メッセージミドルウェア自体にメッセージバックトラッキング機能がある場合は、バックトラッキング消費を通じて「失われた」メッセージを再現し、問題の原因を突き止めることができます。

メッセージバックトラッキングの役割は、これだけにとどまりません。たとえば、インデックスのリカバリ、ローカル キャッシュの再構築にも使用でき、バックトラッキングを使用して一部のビジネス補償ソリューションを実装することもできます。

メッセージの蓄積 + 永続性

トラフィックのピークカットはメッセージミドルウェアの非常に重要な機能であり、この機能は実際にはメッセージ蓄積機能の恩恵を受けています。

ある意味では、メッセージ ミドルウェアにメッセージを蓄積する機能がない場合、それは適切なメッセージ ミドルウェアとは見なされません。

メッセージの蓄積は、メモリ蓄積とディスク蓄積に分かれています。

• RabbitMQ は典型的なメモリベースのスタックですが、これは絶対的なものではありません。特定の条件がトリガーされると、メモリ内のメッセージをディスクにページングするページング アクションが実行されます (ページング アクションはスループットに影響します)。または、遅延キューを直接使用してメッセージを直接ディスクに永続化します。
• Kafka は典型的なディスクベースのストレージであり、すべてのメッセージはディスクに保存されます。

一般的に、ディスクの容量はメモリの容量よりもはるかに大きくなります。ディスク型スタッキングの場合、スタッキング容量はディスク全体のサイズになります。

別の観点から見ると、メッセージの蓄積は、メッセージ ミドルウェアに冗長なストレージ機能も提供します。 The New York Times の事例を引用すると、Kafka をストレージ システムとして直接使用します。

メッセージ追跡

分散アーキテクチャ システムにおけるリンク トレーシング (Trace) については、誰もが理解しておく必要があります。メッセージミドルウェアの場合、メッセージリンクトラッキング（以下、メッセージトラッキング）も同様に重要です。最も一般的な理解は、メッセージがどこから来たのか、どこに保存されているのか、どこに送信されるのかを知ることです。

この機能に基づいて、送信または消費されたメッセージのリンク追跡サービスを提供し、問題を迅速に特定してトラブルシューティングすることができます。

メッセージのフィルタリング

メッセージ フィルタリングとは、確立されたフィルタリング ルールに従って、指定されたカテゴリのメッセージを下流のユーザーに提供することを指します。

Kafka を例にとると、異なるカテゴリのメッセージを異なるトピックに送信することで、特定のメッセージ フィルタリングを実現できます。また、Kafka はパーティションに従って同じトピック内のメッセージを分類することもできます。

ただし、より厳密な意味でのメッセージ フィルタリングは、特定のフィルタリング ルールに従って特定の方法で特定のメッセージをフィルタリングすることです。

Kafka を例にとると、メッセージのフィルタリングは、クライアントが提供する Consumer Interceptor インターフェースまたは Kafka Stream の Filter 機能を通じて実行できます。

マルチテナント

マルチテナント技術とも呼ばれます。これは、ユーザー間のデータの分離を確保しながら、マルチユーザー環境で同じシステムまたはプログラム コンポーネントの共有を実現するために主に使用されるソフトウェア アーキテクチャ テクノロジです。

RabbitMQ はマルチテナント テクノロジーをサポートできます。各テナントは VHost によって表されます。VHost は本質的には、独自のキュー、スイッチ、バインディング関係などを備えた独立した小さな RabbitMQ サーバーであり、独自の独立した権限を持ちます。

VHost は物理マシン内の仮想マシンのようなものです。インスタンス間の論理的な分離を提供し、さまざまなプログラムのデータを安全かつ機密に保管できるようにします。同じ RabbitMQ 内の複数のクライアントを区別し、キューやスイッチなどの名前の競合を回避できます。

マルチプロトコルサポート

メッセージは情報の伝達者です。プロデューサーとコンシューマーの両方が、伝達する情報を理解するためには (プロデューサーはメッセージの構築方法を知る必要があり、コンシューマーはメッセージの解析方法を知る必要があります)、メッセージを統一された形式で記述する必要があります。この統一された形式はメッセージ プロトコルと呼ばれます。

有効なメッセージには特定の形式が必要であり、形式のないメッセージは意味がありません。

一般的なメッセージ レベルのプロトコルには、AMQP、MQTT、STOMP、XMPP などがあります (メッセージ フィールドの JMS は、プロトコルというよりも仕様です)。サポートするプロトコルが多ければ多いほど、その適用範囲は広くなり、汎用性が高まります。

たとえば、RabbitMQ は MQTT プロトコルをサポートしているため、IoT アプリケーションで活用できます。一部のメッセージ ミドルウェアは、Kafka など、独自のプライベート プロトコルに基づいて動作します。

多言語サポート

多くの企業では、テクノロジー スタック システムには、C/C++、Java、Go、PHP などの複数のプログラミング言語が含まれます。メッセージ ミドルウェア自体には、アプリケーション分離の機能があります。さらに複数のクライアント言語をサポートできれば、この機能の有効性はさらに拡大します。

クロス言語サポートのレベルは、メッセージ ミドルウェアの人気を間接的に反映します。

フロー制御

送信者と受信者の間の速度の不一致に対処するために、受信アプリケーションの読み取り速度がそれに適応できるように送信速度を抑制する速度マッチング サービスが提供されます。一般的なフロー制御方法には、ストップアンドウェイト、スライディングウィンドウ、トークンバケットなどがあります。

メッセージの順序

名前が示すように、メッセージが順序どおりに並んでいることを確認することを意味します。この機能の非常に一般的なアプリケーション シナリオは CDC (Change Data Chapture) です。

MySQL を例に挙げてみましょう。送信する Binlog の順序が間違っていると、たとえば、本来は 1 を加算してから 2 を乗算するデータが、順序を間違えて送信された結果、2 を乗算してから 1 を加算するようになり、データの不整合が発生します。

安全機構

Kafka バージョン 0.9 以降では、ID 認証と権限制御という 2 つのセキュリティ メカニズムが追加されました。

• ID 認証とは、クライアントとブローカー間、ブローカー間、ブローカーと ZooKeeper 間の接続認証を含む、クライアントとサーバー間の接続の ID 認証を指します。現在、SSL や SASL などの認証メカニズムがサポートされています。
• 権限制御とは、メッセージまたは Kafka クラスター操作の権限制御を含む、クライアントの読み取りおよび書き込み操作の権限制御を指します。権限制御はプラグイン可能であり、外部認証サービスとの統合をサポートします。

RabbitMQ では、ID 認証 (TLS/SSL、SASL) と権限制御 (読み取りおよび書き込み操作) のセキュリティ メカニズムも提供されます。

メッセージの冪等性

メッセージがプロデューサーとコンシューマー間で確実に送信されるようにするために、通常、次の 3 種類の配信保証があります。

• メッセージが失われるのは最大で 1 回ですが、繰り返し送信されることはありません。
• 少なくとも 1 回はメッセージが失われることはありませんが、重複する可能性があります。
• 正確に 1 回とは、各メッセージが 1 回だけ送信されることを意味します。

ほとんどのメッセージ ミドルウェアでは、「最大 1 回」と「少なくとも 1 回」の 2 つの送信保証のみが提供されます。 3 番目は一般に達成が困難であり、したがってメッセージの冪等性も保証するのが困難です。

Kafka ではバージョン 0.11 以降、冪等性とトランザクションが導入されました。 Kafka のべき等性とは、単一のパーティションと単一のセッションに対する単一のプロデューサーのべき等性を指します。

トランザクションは、複数のパーティションへのアトミック書き込みを保証できます。つまり、複数のパーティションに書き込まれたメッセージはすべて成功するか、すべてロールバックされます。これら 2 つの機能を組み合わせることで、Kafka EOS (Exactly Once Semantic) 機能を実現できます。

しかし、グローバル冪等性を考慮する場合、上流と下流、つまり関連するビジネスレベルからも総合的に考慮する必要があります。べき等性処理自体も、ビジネス レベルで考慮する必要がある重要な問題です。

下流のコンシューマー レベルを例にとると、コンシューマーがメッセージを消費した後にメッセージを確認する時間がない場合に例外が発生する可能性があります。回復後、コンシューマーは元のメッセージを再度消費する必要があります。このタイプのメッセージの冪等性は、メッセージ ミドルウェア レベルでは保証できません。

グローバルな冪等性を確保したい場合は、注文番号を一意の識別子として使用したり、下流に重複排除テーブルを設定したりするなど、それを保証するための外部リソースをさらに導入する必要があります。

トランザクションメッセージ

トランザクション自体はよく知られた用語です。トランザクションは、トランザクションの開始 (Begin Transaction) からトランザクションの終了 (End Transaction) までの間に実行されるすべての操作で構成されます。

トランザクションをサポートするメッセージ ミドルウェアは数多くあります。 Kafka と RabbitMQ の両方がこれをサポートしています。ただし、これら 2 つのトランザクションは、プロデューサー上で発生するメッセージのトランザクションを指し、送信が成功したか失敗したかのいずれかになります。

メッセージ ミドルウェアは分散トランザクションを実装する手段として使用できますが、グローバル分散トランザクション機能は提供しません。

次の表は、Kafka と RabbitMQ の機能の概要比較と追加説明です。

パフォーマンス

機能は、メッセージ ミドルウェアを選択する際の重要な基準ですが、唯一の基準ではありません。場合によっては、機能性よりもパフォーマンスの方が重要になることがあります。さらに、パフォーマンスと機能性は矛盾することがよくあります。ケーキを食べて、それを残しておくことはできません。

冪等性とトランザクション機能を有効にすると、Kafka のパフォーマンスが低下します。 rabbitmq_tracing プラグインを有効にすると、RabbitMQ のパフォーマンスも大きく影響を受けます。

パフォーマンスとは何を意味しますか?

メッセージ ミドルウェアのパフォーマンスは、通常、そのスループットを指します。機能面では RabbitMQ の方が Kafka よりも優れていますが、Kafka のスループットは RabbitMQ よりも 1 ～ 2 桁高くなります。

一般的に、単一の RabbitMQ マシンの QPS は数万ですが、単一の Kafka マシンの QPS は数十万レベル、さらには数百万レベルに維持できます。

注: メッセージ ミドルウェアのスループットは常にハードウェア レベルによって制限されます。ネットワーク カードの帯域幅を例に挙げます。 1 台のマシン上の 1 枚のネットワーク カードの帯域幅が 1 Gbps の場合、数百万のスループットを達成するには、メッセージ本体のサイズが (1Gb/8)/100W、つまり約 134B を超えてはなりません。

つまり、メッセージ本体のサイズが 134B を超えると、数百万のスループットを達成することは不可能になります。この計算方法はメモリやディスクにも適用できます。

パフォーマンス指標とは何ですか?

レイテンシは重要なパフォーマンス指標ですが、メッセージ ミドルウェアの分野では見落とされがちです。これは、メッセージ ミドルウェアが一般的に使用されるシナリオでは、適時性に対する要件がそれほど高くないためです。タイムリーさが必要な場合は、RPC を使用して実現できます。

メッセージ ミドルウェアには、メッセージを蓄積する機能があります。メッセージの蓄積が大きいほど、エンドツーエンドの遅延は長くなります。同時に、遅延キューは一部のメッセージ ミドルウェアの主要な機能でもあります。では、なぜメッセージ ミドルウェアのレイテンシ問題に注意を払う必要があるのでしょうか?

メッセージ ミドルウェアはシステムを分離できます。低レイテンシのメッセージ ミドルウェアの場合、上流のプロデューサーはメッセージを送信した後すぐに戻ることができ、コンシューマーはより迅速にメッセージを取得できるようになります。蓄積がない場合、全体的な上流アプリケーションと下流アプリケーション間のカスケードアクションをより効率的にすることができます。

即時性が高いシナリオではメッセージ ミドルウェアの使用は推奨されませんが、使用するメッセージ ミドルウェアのレイテンシが優れている場合は、システム全体のパフォーマンスが大幅に向上します。

信頼性 + 可用性

メッセージの損失は、メッセージ ミドルウェアを使用する際に必ず直面する問題点です。その背後にあるメッセージの信頼性も、メッセージ ミドルウェアの品質を測定する上で重要な要素です。特に金融決済の分野では、メッセージの信頼性が特に重要です。

しかし、信頼性について話すときは、可用性についても話さなければなりません。 2つの違いに注意してください:

• メッセージ ミドルウェアの信頼性とは、メッセージが失われないことがどの程度保証されるかを指します。
• メッセージ ミドルウェアの可用性は、障害なく実行される時間の割合を指し、通常は 9 で測定されます。

狭い観点から見ると、分散システム アーキテクチャは一貫性プロトコル理論の応用と実装です。メッセージの信頼性と可用性は、メッセージ ミドルウェアの背後にある一貫性プロトコルにも依存します。

• Kafka の場合、PacificA に似た一貫性プロトコルを使用し、ISR (In-Sync-Replica) を使用して複数のレプリカ間の同期を確保し、強力な一貫性セマンティクス (Acks を通じて実装) をサポートします。
• 対応する RabbitMQ は、ミラーリングされたリング キューを通じて複数のコピーと強力な一貫性のセマンティクスを実現します。

複数のレプリカにより、マスター ノードに異常な障害が発生した後でも、スレーブが新しい​​マスターとして昇格し、可用性を確保するために引き続きサービスを提供できるようになります。

Kafka はもともとログ処理用に設計されたため、高いデータ信頼性を必要としないという悪い印象が残っていました。ただし、バージョンのアップグレードと最適化により、信頼性が大幅に向上しました。詳細についてはKIP101を参照してください。

現在、RabbitMQは主に金融決済の分野で利用されており、Kafkaは主にログ処理やビッグデータなどで利用されています。RabbitMQのパフォーマンスが継続的に向上し、Kafkaの信頼性がさらに向上することで、それぞれがこれまで得意としていなかった分野でシェアを獲得できると考えています。

同期ディスク フラッシュはコンポーネントの信頼性を高める効果的な方法であり、メッセージ ミドルウェアも例外ではありません。 Kafka と RabbitMQ はどちらも同期ディスクフラッシュをサポートできます。

しかし、著者は同期ディスク フラッシュについていくつか疑問を持っています。ほとんどのシナリオでは、コンポーネントの信頼性は、同期ディスク フラッシュなどのパフォーマンスを極端に低下させる操作ではなく、マルチコピー メカニズムによって保証されるべきです。

ここで言及する必要があるもう 1 つの側面は拡張性です。ここではこれを可用性の次元に狭く要約します。メッセージ ミドルウェアの拡張性により、その可用性と範囲が拡張されます。たとえば、前述の RabbitMQ は、プラグイン拡張実装に基づいて複数のメッセージ プロトコルをサポートしています。

クラスターの展開に関しては、Kafka の水平スケーラビリティにより、基本的に線形の容量増加を実現できます。 LinkedIn の実践紹介では、1,000 台を超えるデバイスが展開されている Kafka クラスターがあることが述べられています。

運用・保守管理

メッセージミドルウェアを使用する過程では、クライアント側とサーバー側の両方でさまざまな異常な状況が避けられません。では、それらをタイムリーかつ効果的に監視し、修復するにはどうすればよいでしょうか?

ビジネス ラインのトラフィックには、特に電子商取引の分野では、山と谷があります。では、特にプロモーション中に効果的な能力評価を実施するにはどうすればよいでしょうか?電源が蹴飛ばされたり、ネットワークケーブルが引き抜かれたりといった事故が後を絶ちません。マルチサイト アクティブ/アクティブを効果的に実装するにはどうすればよいでしょうか?

これらはすべて、メッセージ ミドルウェアの派生製品である運用および保守管理と切り離すことはできません。運用保守管理は、申請、レビュー、監視、アラーム、管理、災害復旧、展開など、さらに細分化することもできます。

申し込みや審査もわかりやすいです。ソースでリソースを管理および制御すると、アプリケーションの使用仕様を効果的に修正できるだけでなく、監視と連携してトラフィック統計とトラフィック評価を適切に実行できます。

一般的に、アプリケーションとレビューは企業の内部システムと高度に統合されており、オープンソース製品の使用には適していません。

監視とアラートも比較的理解しやすいです。メッセージ ミドルウェアの使用状況を包括的に監視すると、システムのベンチマーク データを提供できるだけでなく、異常な状況が検出されたときにアラートを発して、運用、保守、開発担当者による迅速な介入を容易にすることもできます。

メッセージ ミドルウェアでは、一般的な監視項目 (ハードウェア、GC など) に加えて、エンドツーエンドのレイテンシ、メッセージ監査、メッセージの蓄積などにも注意を払う必要があります。

• RabbitMQ の場合、最もオーソドックスな監視および管理ツールは rabbitmq_management プラグインですが、コミュニティには AppDynamics、Collectd、DataDog、Ganglia、Munin、Nagios、New Relic、Prometheus、Zenoss など、優れた製品も数多くあります。
• Kafka もこの点では同様に優れており、Kafka Manager、Kafka Monitor、Kafka Offset Monitor、Burrow、Chaperone、Confluent Control Center などの製品、特に Cruise は、自動化された運用と保守の機能も提供できます。

容量拡張、ダウングレード、バージョンアップグレード、クラスターノードの展開、トラブルシューティングなど、管理ツールの適用は切り離せません。完全な管理ツールセットを使用すると、変更が発生した場合に半分の労力で 2 倍の結果を達成できます。

障害は大きく、または小さい場合があります。一般に、いくつかのアプリケーションの異常、または機械の停電、ネットワークの異常、ディスクの損傷などの単一マシンの障害があります。単一のコンピュータールームの複数のコピーは、これらの障害を処理するのに十分です。

コンピュータールームが失敗した場合、遠隔災害復旧が関係します。重要なポイントは、データを効果的に複製する方法です。 Kafkaについては、MirrormarkerやUreplicatorなどの製品を参照できます。Rabbitmqについては、フェデレーションとシャベルを参照できます。

コミュニティの強みと生態系の開発

JavaやPythonなどの現在人気のあるプログラミング言語の場合、使用中にいくつかの例外に遭遇した場合、基本的に検索エンジンの助けを借りてそれらを解決できます。

メッセージミドルウェアにも同じことが当てはまります。 「珍しい」メッセージミドルウェアを選択すると、いくつかの面で簡単に使用できるかもしれませんが、バージョンの更新は遅く、困難な問題に遭遇するとコミュニティからサポートを得ることは困難であり、トラブルに深く深くなるかもしれません。

それどころか、強力な更新力を持つ「人気のある」メッセージミドルウェアを選択した場合、以前の欠陥を迅速に補うだけでなく、テクノロジーの迅速な発展に適応していくつかの新しい機能を変更することもできます。

運用および保守管理の側面では、KafkaとRabbitmqには、コミュニティと生態系の急速な発展の恩恵を受ける一連のオープンソース監視および管理製品があると述べました。

メッセージングミドルウェアの選択における誤解の概要

選択誤解

メッセージミドルウェアを選択する前に、自分自身に質問することができます：メッセージミドルウェアが本当に必要ですか？

この問題を把握した後、あなた自身に質問をし続けることができます：あなたは自分でメッセージのミドルウェアのセットを維持する必要がありますか？

コストを節約するために、多くの新興企業は、メッセージミドルウェアに関連するクラウドサービスを直接購入することを選択します。彼らはメッセージの送信と受信に焦点を合わせるだけで、残りは外注することができます。

多くの人々は、独自のメッセージミドルウェアを開発する衝動を抱いています。 JavaのArrayBlockingQueueを単純にカプセル化するか、ファイル、データベース、Redisなどの基礎となるストレージカプセル化に基づいてメッセージミドルウェアを作成できます。

基本的なコンポーネントとして、メッセージミドルウェアは想像ほど単純ではありません。また、エコシステム全体を管理および操作するために、サポートする一連の製品が必要です。

自己研究はまた、引き渡しの問題につながります。ドキュメントが不完全で操作が標準化されていない場合、新人にとって悪夢のような体験になります。

独自の製品を開発する必要がありますか？ KPIからプレッシャーにさらされていない場合は、まず次の2つの質問を検討できます。

• 現在市場に出回っているメッセージのミドルウェアは、現在のビジネスニーズを満たすことができませんか？
• チームには、自己研究をサポートするのに十分な能力、人材、財源、エネルギーがありますか？

多くの人々は、メッセージミドルウェアを選択する際にインターネット上の多くの比較記事を参照していますが、プロフェッショナリズム、厳密さ、政治的スタンスを検証する必要があるため、これらの記事は懐疑的な態度で検討する必要があります。

たとえば、一部の記事では、特定のメッセージミドルウェアを制限やシナリオなしで最適なものとして直接定義します。

一部の記事では、メッセージミドルウェアバージョンとテスト環境を指定することなく、機能的およびパフォーマンス比較分析を行います。そのような記事は捨てることができます。

メッセージミドルウェアは、川を横切るポニーのようなもので、正しいものを選択することが最も重要なことです。これは自分のビジネスニーズに沿っている必要があり、テクノロジーはビジネスに役立つはずです。一般的に言えば、関数やパフォーマンスなど、前のセクションで説明した6つの次元に従って、1つずつスクリーニングできます。より深い決定は、あなたがその魂を把握できるかどうかにあります。

私の意見では、rabbitmqはルーティングに関するものであり、カフカはストリーミングに関するものです。彼らの基本を理解することは、あなたが正しいメッセージミドルウェアを選択できるようにするために特に重要です。

メッセージミドルウェアを選択するときは、パフォーマンスや機能を盲目的に追求することを避ける必要があります。パフォーマンスを最適化し、機能を再開発できます。

機能とパフォーマンスのいずれかを選択する必要がある場合は、一般的に言えば、機能拡張よりもパフォーマンスの最適化の余地が少ないため、パフォーマンスを優先する必要があります。ただし、長期的には、エコロジーはパフォーマンスと機能よりも重要です。

信頼性の誤解

多くの場合、信頼性に関して誤解があります。人々は、情報の絶対的な信頼性を保証する製品を見つけたいと考えています。残念ながら、この世界には絶対的なものは何もありません。私たちはできるだけ完璧になるように努力することしかできません。

メッセージの信頼性を可能な限り確保するために、メッセージミドルウェア自体だけに頼るだけでなく、上流と下流にも依存するだけでは不十分です。生産、サービス、消費の3つの側面から努力をする必要があります。

ミドルウェアのメッセージを選択する際のもう1つの考慮事項は、チーム自身のテクノロジースタックを可能な限り密接に適合させることです。悪いメッセージミドルウェア、悪いプログラマだけのようなものはありませんが、Scalaで書かれたKafkaを深く掘り下げるよりも、Cスタックチームがphxqueueを深く掘り下げる方がはるかに簡単です。

メッセージミドルウェアは非常にシンプルです。1つは送信、1つのストア、もう1つは消費します。最高のメッセージミドルウェアはありません。最も適切なメッセージミドルウェアのみです。