Kafka の代替となる KubeMQ

[[429604]]

[51CTO.com クイック翻訳]昨今、インタラクティブなコンポーネントの増加により、アプリケーションはますます複雑になっています。最も基本的な支払いアプリケーションの場合でも、フロントエンド インターフェイスは、トランザクションをタイムリーに処理するために、さまざまなメッセージ送信をトリガーすることがよくあります。基盤となるネットワークや他のサービスが利用可能かどうかに関係なく、アプリケーション サービスは信頼性の高い方法で相互に通信する必要があると言えます。

このような複雑なバックグラウンド操作を実装するには、多くの場合、アプリケーションですべての受信要求とアラートを追跡するためのサービス「ポスト オフィス」が必要になります。ここでは、メッセージ キューを使用してこの目的を達成できます。特殊なアプリケーションとして、メッセージ キューは、分散アプリケーション内の異なるサービス間、または異なるアプリケーション間の仲介役として機能します。アプリケーションのサービスを相互に分離することで、受信者がオンラインかどうかに関係なくメッセージが処理され、最終的にメッセージ キューが受信されることが保証されます。

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

• 異なるアプリケーション間の非同期処理。
• さまざまなコンポーネント間の信頼性の高い通信を備えたマイクロサービス ベースのアプリケーションを実現します。
• トランザクションの優先順位付けとスロットリング。
• バッチ処理のメリットを享受できるさまざまなデータ処理操作。
• 突然の需要の変化に合わせて拡張できるアプリケーション。
• 堅牢性によりクラッシュや予期しない障害から回復できるアプリケーション。
• 長時間実行されるプロセスによるリソースの消費を制限します。

現在、メッセージ キュー分野には、Amazon Web Services、Microsoft Azure、Google Cloud など、多くの主要なクラウド プラットフォーム プロバイダーが存在します。対応する製品には、AWS Simple Queue Service、Azure Service Bus、Google の Pub/Sub などがあります。もちろん、RabbitMQ、Apache の ActiveMQ、Kafka などの独立した汎用メッセージ ブローカーもあります。

以下では、Kafka の代替として KubeMQ を紹介し、Kubernetes のネイティブ メッセージ キューとして Kubernetes に実装する方法と、アプリケーションがそれによってどのようなメリットを得られるかについて説明します。

Apache Kafka の紹介

KubeMQ の価値を詳しく知る前に、まずは Kafka について理解を深めましょう。もともと LinkedIn のエンジニアによって作成された Kafka は、LinkedIn ユーザーのアクティビティを追跡するためのソフトウェア バスとして使用できます。その後、オープンソース製品としてリリースされました。現在、Kafka は Apache Software Foundation によって開発および管理されており、Fortune 100 企業の 80% 以上で使用されています (https://kafka.apache.org/)。オープンソースであるだけでなく、拡張性も非常に高いシステムです。幅広いイベント プロデューサーとコンシューマーに接続することで、Kafka は、制限されたネットワーク環境でもデータ ストリームを消費し、複雑な機能を実行するように構成できます。同時に、Kafka は広範なオンライン ユーザー コミュニティのサポートにより、AWS と Confluent でそれぞれホストされる Kafka バージョンなど、さまざまな商用製品も提供しています。

Kafka の制限

採用率が非常に高いにもかかわらず、Kafka は必ずしもメッセージ キュー システムに最適な選択肢とは限りません。モノリシック アーキテクチャは、主にローカル クラスターまたは複雑な (ハイエンド) マルチ仮想マシン設定に適しています。 Kafka には大量のメモリとストレージスペースが必要であるため、テスト用にスタンドアロンワークステーション上でマルチノード クラスターを迅速に起動することは困難です。つまり、インフラストラクチャの複雑な部分、特に Kubernetes ベースの部分と Kafka を統合するのは簡単ではありません。

次の図は、さまざまな可動部分を持つ Kubernetes 上の Kafka デプロイメントを示しています。ローカルで実装する場合は、基本的な Kubernetes クラスターに基盤となるコンピューティング、ネットワーク、ストレージ インフラストラクチャを装備することに加えて、Kafka のすべての部分をインストールし、Helm などのパッケージ マネージャーと統合する必要もあります。これらのコンポーネントには、Kafka ブローカーとトピックを管理するための ZooKeeper や Mesos などのオーケストレーターが含まれます。さらに、依存関係、ログ記録、パーティション分割などの側面にも注意を払う必要があります。 1 つの要素に障害が発生したり、構成が誤っていたりすると、アプリケーション全体に問題が発生する可能性があると言っても過言ではありません。 Kafka を正常に導入するのは簡単ではないことがわかります。

Kubernetes アーキテクチャに基づく Kafka

同時に、最適なリソース使用率を実現するために、Kubernetes クラスターに新しい Kafka ノードを追加するときに、複雑な手動設定を通じてバランスを維持する必要があります。このため、簡単な方法では信頼性の高いバックアップおよびリカバリ戦略を管理および確保することができず、多数のノードを持つ Kafka クラスターで災害復旧を実装することは困難です。 Kubernetes クラスター内のデータはポッドの外部に保存されることが多く、オーケストレーターは障害が発生したポッドを自動的に起動しますが、Kafka にはそのようなネイティブの障害保護メカニズムがありません。

さらに、Kafka、ZooKeeper、Kubernetes のデプロイメントを効果的に監視するには、サードパーティのツールも使用する必要があります。

KubeMQ の紹介

メッセージング サービスとして、KubeMQ は Kubernetes を念頭に置いて構築されました。ステートレスかつ一時的な方法でコンテナ アーキテクチャのベスト プラクティスに従います。つまり、単一の KubeMQ ノードは、予測可能かつ再現可能な方法で、その存続期間を通じて一定のままになります。構成の変更が必要な場合は、ノードをシャットダウンして交換するだけです。ここでの再現性は Kafka とは異なることに注意してください。これは、KubeMQ にはゼロ構成セットアップが付属していることを意味します。つまり、インストールが完了した後に構成を調整する必要がないということです。

最も幅広いメッセージ モードに適応できるメッセージ ブローカーおよびキューとして、KubeMQ は次の側面をサポートできます。

• 永続性を備えた Pub/Sub
• 同期および非同期のリクエストと応答をサポート
• 少なくとも1回の配達
• さまざまなストリーミングモードをサポート
• RPCをサポート

対照的に、Kafka は永続性とストリーミングを備えた Pub/Sub をサポートするだけでなく、RPC や要求/応答モードもまったくサポートしていません。

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

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

KubeMQ の「構成不要」の側面では、開発者が作成する必要があるオブジェクトはチャネルのみです。 KubeMQ は ZooKeeper を Raft に置き換え、さまざまなエージェント、エクスチェンジ、オーケストレーターも排除します。

監視の観点からは、サードパーティの可観測性ツールを手動で統合することなく、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 コネクタを構成して、Kafka からのメッセージを具体的に変換することができます。具体的には、KubeMQ ソース コネクタはサブスクライバーとして使用され、Kafka ソース トピックからのさまざまなメッセージを消費し、それらを KubeMQ メッセージ形式に変換してから、メッセージを内部ログに送信します。 KubeMQ ターゲット コネクタは、変換されたメッセージを含む出力ログをサブスクライブし、これらのメッセージを Kafka のターゲット トピックに送信します。具体的なアーキテクチャを下図に示します。

Kafka と KubeMQ の統合

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

まとめ

現在、KubeMQ は無料でダウンロードでき、6 か月間の無料開発トライアルが付属しています。 OpenShift を使用している場合、KubeMQ は Red Hat Marketplace (https://marketplace.redhat.com/en-us) で入手できます。さらに、GCP、AWS、Azure、DigitalOcean などの主要なクラウド環境すべてに適用できます。

全体的に、ほとんどのメッセージング トラフィック負荷に対して、KubeMQ の組み込みのシンプルさ、軽量さ、およびコンテナ ファーストの統合により、Kafka よりも優れたパフォーマンスが得られます。同時に、ほとんど構成を必要としないため、ユーザーは管理、セットアップ、移行にかかる時間を大幅に節約できます。

原題: KubeMQ: Kafka の現代的な代替、著者: Michael Bogan

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