ApacheActiveMQとKafka

1. 概要

分散アーキテクチャでは、通常、アプリケーションはアプリケーション間でデータを交換する必要があります。 一方では、これは互いに直接通信することによって行うことができます。 一方、高可用性とパーティションの許容範囲に到達し、アプリケーション間の結合を緩めるには、メッセージングが適切なソリューションです。

したがって、複数の製品から選択できます。 Apache Foundationは、ActiveMQとKafkaを提供します。これらは、この記事で相互に比較します。

2. 一般的な事実

2.1. Active MQ

Active MQは、従来のメッセージブローカーの1つであり、アプリケーション間のデータ交換を安全で信頼できる方法で保証することを目的としています。少量のデータを処理するため、明確に定義されたメッセージに特化しています。フォーマットとトランザクションメッセージング。

この「クラシック」エディションの他に、Active MQArtemisという別のエディションがあることに注意する必要があります。 この次世代ブローカーはHornetQに基づいており、そのコードは2015年にRedHatによってApacheFoundationで利用可能になりました。 Active MQ Webサイトでは、次のように言われています。

Artemisが「クラシック」コードベースと同等の機能レベルに達すると、ActiveMQの次のメジャーバージョンになります。

したがって、比較のために、両方のエディションを検討する必要があります。 「Active MQ」および「Artemis」という用語を使用して、これらを区別します。

2.2. Kafka

Active MQとは対照的に、 Kafkaは、大量のデータを処理するための分散システムです。従来のメッセージングだけでなく、次の目的にも使用できます。

• ウェブサイトの活動追跡
• メトリック
• ログ集計
• ストリーム処理
• イベントソーシング
• コミットログ

これらの要件は、マイクロサービスを使用して構築された典型的なクラウドアーキテクチャの出現により非常に重要になっています。

2.3. JMSの役割とメッセージングの進化

Javaメッセージサービス（JMS）は、JavaEEアプリケーション内でメッセージを送受信するための一般的なAPIです。 これはメッセージングシステムの初期の進化の一部であり、今日でも標準となっています。 Jakarta EEでは、 JakartaMessagingとして採用されました。 したがって、コアコンセプトを理解することが役立つ場合があります。

• Java-ネイティブですがベンダーに依存しないAPI
• ベンダー固有の通信プロトコルを実装するためのJCAリソースアダプターの必要性
• メッセージ宛先モデル：
  • キュー（ P2P ）は、複数のコンシューマーの場合でもメッセージの順序付けと1回限りのメッセージ処理を保証します
  • パブリッシュ/サブスクライブパターンの実装としてのTopics（ PubSub ）。これは、複数のコンシューマーがトピックへのサブスクリプション期間中にメッセージを受信することを意味します。
• メッセージ形式：
  • ブローカーが扱う標準化されたメタ情報としてのHeaders（優先度や有効期限など）
  • プロパティは、コンシューマーがメッセージ処理に使用できる標準化されていないメタ情報です。
  • ペイロードを含むBody – JMSは5種類のメッセージを宣言しますが、これはAPIの使用にのみ関連し、この比較には関連しません。

ただし、進化はオープンで独立した方向に進みました。コンシューマーとプロデューサーのプラットフォームから独立し、メッセージングブローカーのベンダーからも独立しています。独自の宛先モデルを定義するプロトコルがあります。

• AMQP –ベンダーに依存しないメッセージング用のバイナリプロトコル–汎用ノードを使用します
• MQTT –組み込みシステムおよびIoT向けの軽量バイナリプロトコル–トピックを使用
• STOMP –ブラウザからでもメッセージングを可能にするシンプルなテキストベースのプロトコル–は一般的な宛先を使用します

もう1つの開発は、クラウドアーキテクチャの普及を通じて、「ファイアアンドフォーゲット」の原則に従って大量のデータを処理するために、以前は信頼性が高かった個々のメッセージの送信（「従来のメッセージング」）を追加することです。 Active MQとKafkaの比較は、これら2つのアプローチの代表的な例の比較であると言えます。 たとえば、Kafkaの代わりにNATSを使用できます。

3. 比較

このセクションでは、Active MQとKafkaのアーキテクチャと開発の最も興味深い機能を比較します。

3.1. メッセージの宛先モデル、プロトコル、およびAPI

Active MQは、キューおよびトピックのJMSメッセージ宛先モデルを完全に実装し、AMQP、MQTT、およびSTOMPメッセージをそれらにマップします。 たとえば、STOMPメッセージは、Topic内のJMSBytesMessageにマップされます。 さらに、 OpenWire をサポートしているため、Active MQへの言語間のアクセスが可能です。

Artemisは、標準のAPIおよびプロトコルとは独立して独自のメッセージ宛先モデルを定義し、それらをこのモデルにマッピングする必要もあります。

• メッセージはアドレスに送信されます。このアドレスには、一意の名前、ルーティングタイプ、および0個以上のキューが付けられます。
• ルーティングタイプは、メッセージがアドレスからそのアドレスにバインドされたキューにルーティングされる方法を決定します。 定義されている2つのタイプがあります。
  • ANYCAST ：メッセージはアドレス上の単一のキューにルーティングされます
  • MULTICAST ：メッセージはアドレス上のすべてのキューにルーティングされます

Kafkaはトピックのみを定義します。これは、異なるブローカーに配置できる複数のパーティション（少なくとも1つ）とレプリカで構成されます。 トピックを分割するための最適な戦略を見つけることは挑戦です。 次の点に注意する必要があります。

• 1つのメッセージが1つのパーティションに分散されます。
• 順序付けは、1つのパーティション内のメッセージに対してのみ保証されます。
• デフォルトでは、後続のメッセージはトピックのパーティション間でラウンドロビン方式で配布されます。
• メッセージキーを使用する場合、同じキーを持つメッセージは同じパーティションに配置されます。

Kafkaには独自のAPIがあります。 JMS用リソースアダプタもありますが、概念は完全には互換性がないことに注意する必要があります。 AMQP、MQTT、およびSTOMPは公式にはサポートされていませんが、AMQPおよびMQTT用のコネクタがあります。

3.2. メッセージのフォーマットと処理

Active MQは、ヘッダー、プロパティ、および本文（上記のとおり）で構成されるJMS標準メッセージ形式をサポートします。 ブローカーはすべてのメッセージの配信状態を維持する必要があるため、スループットが低下します。 JMSでサポートされているため、コンシューマーは宛先からメッセージを同期的にプルしたり、ブローカーによってメッセージを非同期的にプッシュしたりできます。

Kafkaはメッセージ形式を定義していません—これは完全にプロデューサーの責任です。 メッセージごとの配信状態はなく、コンシューマーとパーティションごとのオフセットだけです。 オフセットは、最後に配信されたメッセージのインデックスです。 これは高速であるだけでなく、プロデューサーに問い合わせることなくオフセットをリセットすることでメッセージを再送信することもできます。

3.3. SpringとCDIの統合

JMSはJava/Jakarta EE標準であるため、Java /JakartaEEアプリケーションに完全に統合されています。 そのため、Active MQとArtemisへの接続はアプリケーションサーバーによって簡単に管理されます。 Artemisでは、組み込みブローカーを使用することもできます。 Kafkaの場合、管理対象接続は、リソースアダプターforJMSまたはEclipseMicroProfileReactiveを使用している場合にのみ使用できます。

Springには、 JMS と、 AMQP 、 MQTT、、およびSTOMPが統合されています。 Kafkaもサポートされています。 Spring Bootを使用すると、 Active MQ 、 Artemis、、およびKafkaに組み込みブローカーを使用できます。

4. Active MQ/ArtemisおよびKafkaのユースケース

以下の点から、どの製品をいつ使用するのが最適かについての方向性がわかります。

4.1 Active MQ/Artemisのユースケース

• 1日に処理するメッセージの数はごくわずかです
• 高レベルの信頼性とトランザクション性
• オンザフライのデータ変換、ETLジョブ

4.1Kafkaのユースケース

• 大量のデータを処理する
  • リアルタイムデータ処理
  • アプリケーションアクティビティの追跡
  • ロギングとモニタリング
• データ変換なしのメッセージ配信（可能ですが、簡単ではありません）
• トランスポート保証なしのメッセージ配信（可能ですが、簡単ではありません）

5. 結論

これまで見てきたように、Active MQ / ArtemisとKafkaの両方に目的があり、したがって正当化されます。 適切なケースに適切な製品を選択するには、それらの違いを知ることが重要です。 次の表で、これらの違いを簡単に説明します。