KubeMQ が Kafka の代わりとなるのはなぜですか?

[51CTO.com クイック翻訳]このような複雑な操作を実装するには、すべてのリクエストとアラートを追跡するための何らかのタイプのサービス「ポストオフィス」が必要です。この目標を達成するためのツールがメッセージ キューです。

メッセージ キューは、分散アプリケーションの異なるサービス間、または異なるアプリケーション間の仲介役として機能する特殊なアプリケーションです。アプリケーション サービスを相互に分離し、受信者が利用可能かどうかに関係なくメッセージが処理されるようにします。メッセージ キューは、すべてのメッセージが最終的に正常に受信されることを保証します。

メッセージ キューの一般的な使用例は次のとおりです。

• 異なるアプリケーション間の非同期処理。
• 異なるコンポーネント間の信頼性の高い通信が重要なマイクロサービス ベースのアプリケーション。
• トランザクションの順序と制限。
• バッチ処理の合理化された効率の恩恵を受けることができるデータ処理操作。
• 突然の予期しない需要の変化に対応するために拡張する必要があるアプリケーション。
• アプリケーションは、クラッシュや予期しない障害から回復できるだけの回復力を備えている必要があります。
• 長時間実行されるプロセスによるリソース消費を制限します。

メッセージ キューの分野ではベンダーが不足することはありません。 Amazon Web Services、Microsoft Azure、Google Cloud などの大規模なクラウド プラットフォームには、それぞれ独自の製品 (AWS Simple Queue Service、Azure の Service Bus、Google の Pub/Sub) があります。 RabbitMQ、Apache の ActiveMQ、Kafka などのスタンドアロンの汎用メッセージ ブローカーもあります。

この記事では、KubeMQ と呼ばれる最新の Kubernetes ネイティブ メッセージ キューを紹介し、Kubernetes 上ですでに Kafka を使用している組織が KubeMQ からどのようなメリットを得ることができるかを説明します。

Apache Kafkaとは

KubeMQ の価値を完全に理解するには、まず時間をかけて Kafka を理解する必要があります。 Kafka はもともと LinkedIn のエンジニアによって LinkedIn ユーザーのアクティビティを追跡するためのソフトウェア バスとして作成されました。その後、オープンソース製品としてリリースされ、現在、Kafka は Apache Software Foundation によって開発および管理されています。

Apache によれば、Fortune 100 企業の 80% 以上が Kafka を信頼し、使用しています。オープンソースであるにもかかわらず、幅広いイベントプロデューサーとコンシューマーに接続できる、非常にスケーラブルなシステムとして知られています。データ ストリームを使用して複雑な機能を実行するように構成でき、制限されたネットワーク環境でも適切に動作します。 Kafka はいくつかの商用サービスも提供しており、オンライン ユーザー コミュニティで幅広いサポートが受けられます。たとえば、AWS は Confluent と同様にマネージド Kafka を提供しています。

Kafka の制限

採用率が高いにもかかわらず、Kafka はメッセージ キュー システムとして必ずしも最適な選択肢であるとは限りません。モノリシック アーキテクチャを備えており、ローカル クラスターまたはハイエンドのマルチ VM セットアップに適しています。 Kafka に必要なメモリとストレージの量を考えると、テスト用にスタンドアロン ワークステーション上でマルチノード クラスターを迅速に起動するのは難しい場合があります。

つまり、Kafka をインフラストラクチャに統合するために必要な複雑な要素をすべてうまくまとめるのは簡単ではありません。これは、Kubernetes ベースのアーキテクチャに特に当てはまります。

次の図に示すように、Kubernetes 上の Kafka デプロイメントにはさまざまな可動部分があります。基本的な Kubernetes クラスターの基盤となるコンピューティング、ネットワーク、およびストレージ インフラストラクチャを構成することに加えて (ローカルに実装する場合)、すべての Kafka パーツをインストールし、Helm などのパッケージ マネージャーと統合する必要もあります。これらのコンポーネントには、Kafka ブローカーとトピックを管理するための ZooKeeper や Mesos などのオーケストレーターを含めることができます。注意が必要なその他の領域には、依存関係、ログ記録、パーティション分割などがあります。1 つの要素でも欠落していたり​​、誤って構成されていたりすると、何も機能しません。Kafka を正常にデプロイするのは簡単な作業ではありません。

​​​

Kubernetes アーキテクチャ上の Kafka

Kubernetes クラスターに新しい Kafka ノードを追加するには、最適なリソース使用率を維持するために複雑な手動バランス調整が必要です。そのため、信頼性の高いバックアップおよびリカバリ戦略を管理および確保する簡単な方法はありません。多数のノードで実行されている Kafka クラスターを災害から保護することは容易ではありません。データがポッドの外部に保存され、オーケストレーターが障害が発生したポッドを自動的に再起動する Kubernetes クラスターとは異なり、Kafka にはそのようなネイティブのフェイルセーフ メカニズムはありません。

最後に、Kafka/ZooKeeper/Kubernetes デプロイメントを効果的に監視するには、サードパーティのツールが必要です。

KubeMQとは

Kube MQ は、Kubernetes を念頭に置いてゼロから構築されたメッセージング サービスです。コンテナ アーキテクチャのベスト プラクティスに従い、KubeMQ はステートレスかつ一時的になるように設計されています。つまり、KubeMQ ノードは、そのライフサイクル全体を通じて一定で、予測可能かつ再現可能な状態を維持します。構成の変更が必要な場合は、ノードがシャットダウンされ、置き換えられます。

この再現性により、Kafka とは異なり、KubeMQ にはゼロ構成セットアップが付属しており、インストール後に構成を微調整する必要がありません。

KubeMQ は、最も幅広いメッセージング パターンに対応するように設計されています。これは、以下をサポートするメッセージ ブローカーおよびメッセージ キューです。

• 永続性の有無にかかわらず Pub/Sub
• リクエスト/応答（同期、非同期）
• 最大1回の配送
• 少なくとも1回の配達
• ストリーミングモード
• RPC

対照的に、Kafka は永続性とストリーミングを備えた Pub/Sub のみをサポートします。 Kafka は RPC および要求/応答パターンをまったくサポートしていません。

リソース使用量の点では、KubeMQ はフットプリントが最小で Kafka よりも優れています。 KubeMQ Docker コンテナは 30 MB のスペースしか占有しません。フットプリントが小さいため、フォールト トレラントなセットアップと簡素化された展開が可能になります。 Kafka とは異なり、ローカル ワークステーション上の小規模な開発 Kubernetes 環境に KubeMQ を追加するのは非常に簡単です。しかし同時に、KubeMQ は、数百のオンプレミス ノードとクラウド ホスト ノードで実行されるハイブリッド環境に展開できるほどスケーラブルです。この容易な導入の中心となるのは、Kubernetes の kubectl に似た、KubeMQ のコマンドライン インターフェース ツールである kubemqctl です。

KubeMQ が Kafka より優れているもう 1 つの領域は、その速度です。 Kafka は Java と Scala で記述されていますが、KubeMQ は Go で記述されており、高速な操作が保証されています。社内ベンチマークでは、KubeMQ は 100 万件のメッセージを Kafka よりも 20% 高速に処理しました。

KubeMQ の「構成不要」の側面に戻ると、開発者が作成する必要があるオブジェクトはチャネルだけです。ブローカー、エクスチェンジ、コーディネーターについては忘れてください。KubeMQ の Raft が ZooKeeper の代わりにこれらすべてを実行します。

監視の観点から見ると、Prometheus と Grafana を介したダッシュボードは KubeMQ と完全に統合されているため、サードパーティの可観測性ツールを手動で統合するという余分な作業を行う必要はありません。ただし、KubeMQ のツールとのネイティブ統合により、次のような既存のログ記録および監視ソリューションを引き続き使用できます。

• 監視用のFluentd、Elastic、Datadog
• Loggly、ログ記録用
• トレース用のJaegerとOpen Tracing

Kafka は Cloud Native Computing Foundation (CNCF) 環境のネイティブな部分ではないため、CNCF ツールとの統合は通常サポートされておらず、手動で構成する必要があります。

適切に設定すれば、Kubernetes との優れた互換性で知られるオープンソースの gRPC リモート プロシージャ コール システムを介して接続できます。 Kafka 独自の接続メカニズムでは、必ずしも同等の結果が得られるとは限りません。

Kafka から KubeMQ への透過的な移行

KubeMQ の導入と操作の容易さに加えて、既存の Kafka セットアップを KubeMQ に移植することも簡単です。

これを実行するには、開発者は KubeMQ Kafka コネクタを使用することから始めることができます。 KubeMQ ターゲットおよびソース コネクタは、Kafka からのメッセージを変換するように構成されています。大まかに言えば、KubeMQ ソース コネクタはサブスクライバーとして機能し、Kafka ソース トピックからのメッセージを消費し、メッセージを KubeMQ メッセージ形式に変換してから、メッセージを内部ログに送信します。 KubeMQ ターゲット コネクタは、変換されたメッセージを含む出力ログをサブスクライブし、メッセージを Kafka のターゲット トピックに送信します。高レベルのアーキテクチャを次の図に示します。

​​​

Kafka と KubeMQ の統合

さらに、Kafka でサポートされているすべてのメッセージング パターンは KubeMQ でもサポートされます。たとえば、Kafka は永続性とストリーミングを備えた Pub/Sub のみをサポートします。 KubeMQ は、Pub/Sub (永続性ありまたはなし)、要求/応答 (同期、非同期)、少なくとも 1 つの配信、ストリーミング モード、および RPC をサポートするメッセージ キューおよびメッセージ ブローカーです。したがって、Kafka から KubeMQ に移行するときに、アプリケーション コードをリファクタリングしたり、複雑なロジックの変更に適応したりする必要はありません。

やっと

ほとんどのワークロードでは、KubeMQ の組み込みのシンプルさ、軽量さ、およびコンテナファーストの統合により、Kafka よりも優れたパフォーマンスが実現します。さらに、実質的に構成が不要なため、管理とセットアップにかかる時間が大幅に短縮されます。前述したように、移行は簡単です。

KubeMQ は無料でダウンロードでき、6 か月間の無料開発トライアルが付属しています。 OpenShift を使用する場合、KubeMQ は Red Hat Marketplace で入手できます。また、GCP、AWS、Azure、DigitalOcean などの主要なクラウド環境でも動作します。

[51CTOによる翻訳。パートナーサイトに転載する場合は、元の翻訳者と出典を51CTO.comとして明記してください。