Kubernetes 上の Kafka のマルチクラスター展開を簡素化

翻訳者 |李睿

レビュー |チョンロウ

Apache Kafka (Kafka とも呼ばれる) は、Apache Software Foundation によって管理されているオープン ソースのイベント ストリーミング プラットフォームです。 Apache Kafka はもともと LinkedIn で考案され、Jay Kreps、Neha Narkhede、Jun Rao によって作成され、2011 年にオープン ソース プロジェクトとしてリリースされました。

現在、Kafka はリアルタイム データ ソースを処理するための最も人気のあるイベント ストリーミング プラットフォームの 1 つになっています。スケーラブルでフォールト トレラントな高性能ストリーミング データ パイプラインの構築に広く使用されています。

Kafka の使用事例は絶えず拡大しており、上位 5 つの使用事例は Brij Pandey によって添付のグラフでわかりやすく示されています。

簡単な紹介として、Kafka プラットフォームのコンポーネントとその動作を理解することが重要です。

Kafka は、リアルタイムのデータ フィードを効率的に処理するように設計された分散イベント ストリーミング プラットフォームです。これは、パブリッシュ/サブスクライブ メッセージング モデルに基づいて動作し、分散型でフォールト トレラントなアーキテクチャに従います。 「トピック」と呼ばれる、永続的で順序付けされ、分割されたレコードのシーケンスを維持します。プロデューサーはこれらのトピックに関するデータを書き込み、コンシューマーはそこからデータを読み取ります。これにより、データプロデューサーとコンシューマー間の分離が可能になり、複数のアプリケーションが同じデータストリームを独立して使用できるようになります。

Kafka の主要コンポーネントは次のとおりです。

• トピックとパーティション: Kafka はデータをトピックに整理します。各トピックはレコードのストリームであり、トピック内のデータは複数のパーティションに分割されます。各パーティションは、順序付けられた不変のレコードのシーケンスです。パーティショニングにより、データを複数の Kafka ブローカーに分散できるようになり、水平方向のスケーラビリティと並列処理が可能になります。
• プロデューサー: プロデューサーは、Kafka トピックにデータを書き込むアプリケーションです。特定のトピックにレコードを公開し、そのレコードをトピックのパーティションに保存します。プロデューサーは、レコードを特定のパーティションに明示的に送信したり、パーティション分割戦略を使用して Kafka がパーティションを決定できるようにしたりできます。
• コンシューマー: コンシューマーは、Kafka トピックからデータを読み取るアプリケーションです。 1 つ以上のトピックをサブスクライブし、割り当てられたパーティションからレコードを消費します。コンシューマー グループは消費量をスケールするために使用され、トピック内の各パーティションはグループ内の 1 つのコンシューマーによってのみ消費されます。これにより、複数のコンシューマーが同じトピックの異なるパーティションからのデータを並行して処理できるようになります。
• ブローカー: Kafka はサーバーのクラスターとして実行され、各サーバーはブローカーと呼ばれます。ブローカーは、プロデューサーとコンシューマーからの読み取りおよび書き込み要求を処理し、トピック パーティションを管理する役割を担います。 Kafka クラスターには、負荷を分散してフォールト トレランスを確保するために複数のブローカーを含めることができます。
• パーティショニング/レプリケーション: フォールト トレランスとデータの耐久性を実現するために、Kafka ではトピック パーティションのレプリケーションを構成できます。各パーティションには複数のレプリカを含めることができ、1 つのレプリカがリーダーとして指定され、他のレプリカはフォロワーとして指定されます。リーダー レプリカはそのパーティションのすべての読み取りおよび書き込み要求を処理し、フォロワー レプリカは同期を維持するためにリーダー レプリカからデータをコピーします。リーダー レプリカのブローカーに障害が発生した場合、フォロワー レプリカの 1 つが自動的に新しいリーダー レプリカになり、継続的な操作が保証されます。
• オフセット管理: Kafka は各パーティションのオフセットの概念を維持します。オフセットは、パーティション内のレコードの一意の識別子を表します。消費者は現在のオフセットを追跡し、障害や再処理が発生した場合に中断したところから消費を再開できるようにします。
• ZooKeeper : Kafka 自体の一部ではありませんが、ZooKeeper はメタデータを管理し、Kafka クラスター内のブローカーを調整するためによく使用されます。リーダーの選出、トピックとパーティションの情報を容易にし、コンシューマー グループの調整を管理します。 [注: Zookeeper メタデータ管理ツールはまもなく Kafka Raft に置き換えられます (Kraft は内部メタデータ管理用のプロトコルです)]

全体として、Kafka の設計とアーキテクチャにより、大量のリアルタイム データ ストリームを処理できる、スケーラビリティ、耐障害性、効率性に優れたプラットフォームが実現します。これは、多くのデータ駆動型アプリケーションやデータ インフラストラクチャのコア コンポーネントとなり、データ統合、イベント処理、ストリーミング分析を促進します。

典型的な Kafka アーキテクチャを次の図に示します。

Kafka クラスタリングとは、複数の Kafka ブローカーをグループとして一緒に実行し、Kafka クラスターを形成することを指します。クラスタリングは Kafka のアーキテクチャの基本的な側面であり、スケーラビリティ、フォールト トレランス、高可用性など、さまざまな利点をもたらします。 Kafka クラスターは、大規模なデータ ストリームを処理し、障害が発生した場合でもシステムが継続して実行されるようにするために使用されます。

クラスターでは、スケーラビリティと並列処理を実現するために、Kafka トピックは複数のパーティションに分割されます。各パーティションは、線形に順序付けられた不変のレコードのシーケンスです。したがって、パーティショニングにより、クラスター内の複数のブローカーにデータを分散できるようになります。

最小限の Kafka クラスターは 3 つの Kafka ブローカーで構成され、各ブローカーは個別のサーバー (仮想または物理) で実行できることに注意することが重要です。 3 ノード ガイドは、プロキシ障害が発生した場合にスプリット ブレイン状況を回避するためのものです。

Kafka と Kubernetes

Kafka を採用する企業が増えるにつれて、Kubernetes に Kafka を導入することへの関心が高まっています。

実際、Dynatrace の最近の 2023 Kubernetes In the Wild レポートによると、大規模組織の 40% 以上がオープンソース メッセージング プラットフォームを Kubernetes で実行しており、その大部分は Kafka です。

このレポートでは、「Kubernetes はクラウド コンピューティングの『オペレーティング システム』になりつつある」とも大胆に宣言しています。

したがって、Kafka 管理者は、Kafka と Kubernetes 間の相互作用と、これらの相互作用を適切に実装する方法を理解する必要があります。

マルチクラスタ Kafka の事例

単一の Kubernetes クラスター セットアップで Kafka クラスターを実行するのは非常に簡単で、理論的には必要に応じて拡張可能です。ただし、制作段階では画像が少しぼやけることがあります。

クラスターという用語の使用は、Kafka と Kubernetes では区別する必要があります。 Kubernetes デプロイメントでは、Kubernetes クラスターと呼ばれる接続されたノードのグループを指定するためにクラスターという用語も使用されます。 Kafka ワークロードを Kubernetes にデプロイすると、Kubernetes クラスター内で実行される Kafka クラスターが作成されますが、この説明に関連して、回復力、パフォーマンス、データ主権などのために、複数の Kubernetes クラスターにまたがる Kafka クラスターを作成することも可能です。

まず第一に、Kafka はマルチテナント設定用に設計されていません。技術的な面では、Kafka は Kubernetes 名前空間やリソース分離などの概念を理解しません。特定のテーマ内の複数のユーザー グループ間で安全なアクセス制限を適用する簡単なメカニズムはありません。

さらに、バッチ アプリケーションとリアルタイム アプリケーションなど、ワークロードによって更新頻度やスケール要件が異なる場合があります。 2 つのワークロードを 1 つのクラスターに結合すると、悪影響が生じたり、必要以上に多くのリソースが消費されたりする可能性があります。

データ主権とコンプライアンスにより、特定の地域またはアプリケーション内でのデータと主題の共存に制限が課されることもあります。

もちろん、回復力は複数の Kafka クラスターの背後にあるもう 1 つの強力な推進力です。 Kafka クラスターはトピックのフォールト トレランスを実現するように設計されていますが、クラスター全体の壊滅的な障害に備える必要があります。この場合、完全に複製されたクラスターの必要性が適切なビジネス継続性計画をサポートします。

ワークロードをクラウドに移行している企業やハイブリッド クラウド戦略を採用している企業では、リスクを冒して Kafka を全面的に移行するのではなく、複数の Kafka クラスターを設定し、時間をかけて計画的なワークロード移行を実行することをお勧めします。

実際には、多くの企業は、いくつかの理由から、相互にやり取りする必要がある複数の Kafka クラスターを作成する必要があることに気づきます。

マルチクラスタ Kafka

複数の Kafka クラスターを相互に接続するには、1 つのクラスターのキー項目を別のクラスターに複製する必要があります。これらには、トピック、オフセット、メタデータが含まれます。 Kafka の用語では、このレプリケーションはミラーリングと呼ばれます。

マルチクラスター設定を実装する方法には、ストレッチ クラスターと接続クラスターの 2 つがあります。

クラスターのスケーリング: 同期レプリケーション

ストレッチ クラスターは、複数の物理クラスターにまたがって「ストレッチ」された論理クラスターです。トピックとレプリカは物理クラスター全体に分散されますが、論理クラスターとして表されるため、アプリケーション自体はこの多様性を認識しません。

ストレッチ クラスターは一貫性が強く、管理が容易です。アプリケーションは複数のクラスターの存在を認識しないため、結合されたクラスターよりもストレッチ クラスターにデプロイする方が簡単です。

ストレッチ クラスタリングの欠点は、クラスター間の同期接続が必要になることです。これらはハイブリッド クラウドの展開には適しておらず、 「スプリット ブレイン」状況を回避するために少なくとも 3 つのクラスターのクォーラムが必要です。

クラスターへの接続: 非同期レプリケーション

接続されたクラスターは、複数の独立したクラスターを接続することによって展開されます。これらの独立したクラスターは、異なるリージョンまたはクラウド プラットフォームで実行でき、個別に管理できます。

接続されたクラスター モデルの主な利点は、他のクラスターが独立して動作するため、クラスターに障害が発生した場合でもダウンタイムが発生しないことです。各クラスターは、特定のリソースに合わせて最適化することもできます。

接続されたクラスターの主な欠点は、クラスター間の非同期接続に依存することです。クラスター間で複製されるトピックは「コピーオンライト」ではなく、最終的な一貫性に依存します。これにより、非同期ミラーリング プロセス中にデータが失われる可能性があります。

さらに、接続されたクラスター間で動作するアプリケーションは、複数のクラスターを認識するように変更する必要があります。

この問題を解決する前に、Kafka クラスター接続をサポートする市場で一般的なツールを簡単に紹介しましょう。

オープンソースの Kafka には、Mirror Maker と呼ばれるミラーリング ツールが付属しています。

Mirror Maker は、組み込みのジェネレーターを使用して、異なるクラスター間でトピックを複製します。このようにして、データはクラスター全体に複製され、最終的な一貫性が維持されますが、個々のプロセスは中断されません。

Mirror Maker のコンセプトはシンプルですが、大規模に設定することは IT 組織にとって非常に難しい場合があることに注意することが重要です。 IP アドレス、命名規則、レプリカの数などを正しく管理する必要があります。そうしないと、トピックが無限に複製され、最終的に破損につながる、いわゆる「無限複製」が発生する可能性があります。

Mirror Maker のもう 1 つの欠点は、許可/禁止更新リストの動的な構成が欠けていることです。また、Mirror Maker はサブジェクトのプロパティを正しく同期しないため、複製するサブジェクトを追加または削除するときに大規模な操作を行うことが困難になります。 Mirror Maker はこれらの課題の一部に対処しようとしていますが、多くの IT ショップは依然として Mirror Maker を適切にセットアップするのに苦労しています。

Kafka レプリケーション用のその他のオープンソース ツールには、Salesforce の Mirus、Uber の uReplicator、Netflix のカスタム Flink などがあります。

商用ライセンス オプションとして、Confluent は Confluent Replicator と Cluster Linking の 2 つのオプションを提供しています。 Confluent Replicator は、本質的には、クラスター間でトピック データを複製するための高性能で回復力のある方法を提供する Kafka Connect コネクタです。 Cluster Linking は、トピック オフセットを保持しながらマルチリージョン レプリケーションを可能にすることを目的とした、社内で開発されたもう 1 つの製品です。

それでも、Cluster Linking は非同期レプリケーション ツールであり、データはネットワーク境界を越えてパブリック トラフィック パスを通過する必要があります。

今では、Kafka レプリケーションが大規模な本番アプリケーションにとって重要な戦略であることが明らかになっているはずです。問題は、どのオプションを選択するかということです。

想像力豊かな Kafka 管理者は、アプリケーションのパフォーマンスと回復力のニーズに応じて、接続されたクラスターとストレッチされたクラスターの両方、またはこれらのデプロイメントの組み合わせが必要になる可能性があることにすぐに気付くでしょう。

ただし、クラスター構成を設定し、複数のクラスターにわたって大規模に管理することは、困難であるどころか、はるかに困難です。この問題を解決するよりエレガントな方法はありますか?

答えはイエスです！

Avesha の KubeSlice は、両方の長所を活かすシンプルな方法です。 KubeSlice では、クラスターまたは名前空間間に直接のサービス接続を作成することで、Kafka クラスター間の個別の接続を手動で構成する必要がなくなります。

KubeSlice は、本質的に、アプリケーション レベルまたは名前空間レベルで分離し、クラスター間に安全で同期されたレイヤー 3 ネットワーク ゲートウェイを作成します。これが設定されると、Kafka 管理者は任意のクラスターに Kafka ブローカーを自由にデプロイできるようになります。

各ブローカーは、ブローカー自体が異なるクラスター上にある場合でも、スライスを介して接続されている他のすべてのブローカーと同期接続されています。これにより、ブローカー間でストレッチ クラスターが効果的に作成され、強力な一貫性と低い管理オーバーヘッドの利点が得られます。

結論

Mirror Maker をクラスターに導入したい場合、クラスター間の接続が KubeSlice に委任されるため、最小限の労力で導入できます。その結果、Kafka アプリケーションは、同じデプロイメントで同期 (速度、回復力) と非同期 (独立性、スケール) のレプリケーションの両方の利点を享受でき、必要に応じてこれらの機能を組み合わせることができます。これは、オンプレミス データ センター、パブリック クラウド、ハイブリッド設定のあらゆる組み合わせに適用されます。

KubeSlice は非中断型のデプロイメントであるため、デプロイされたツールをアンインストールする必要はありません。スライスを設定し、そのスライスに Kafka デプロイメントを追加するだけです。

この記事では、Apache Kafka の概要を簡単に説明し、より一般的な使用例のいくつかについて説明します。また、複数のクラスターにわたって Kafka デプロイメントをスケーリングするために現在利用可能なツールを紹介し、各ツールの長所と短所についても説明します。最後に、この記事では、Kafka のマルチクラスター展開を簡素化し、複数のクラスター間で大規模な Kafka レプリケーションを構成する際の煩わしさを解消する新しいサービス接続ソリューションである Kubeslice を紹介します。

原題: Kubernetes での Kafka マルチクラスター デプロイメント: 簡素化!、著者: Ray Edwards