Kafka を使用したマルチクラスターのデプロイメントとレプリケーションをマスターする

Apache Kafka の概要と一般的な使用例、マルチクラスター展開を拡張するための現在のツール、およびマルチクラスター展開を簡素化する接続ソリューション。 目次 カフカとは何ですか？ カフカとKubernetes マルチクラスター Kafka の場合 マルチクラスターKafka ストレッチ クラスター - 同期レプリケーション 接続されたクラスター - 非同期レプリケーション 結論 カフカとは何ですか？ 一般に単に として知られる Apache Kafka は、Apache Software Foundation によって管理されているオープンソースのイベント ストリーミング プラットフォームです。最初に で考案された Apache Kafka は、 、 、 によって共同作成され、その後 2011 年にオープンソース プロジェクトとしてリリースされました Kafka LinkedIn Jay Kreps Neha Narkhede Jun Rao 。 Wiki ページ 現在、Kafka は、リアルタイム データ フィードを処理するように設計された最も人気のあるイベント ストリーミング プラットフォームの 1 つです。これは、スケーラブルでフォールトトレラントな高性能ストリーミング データ パイプラインを構築するために広く使用されています。 Kafka の用途は拡大し続けており、添付の画像では上位 5 つのケースが によってうまく説明されています。 Brij Pandey 簡単な入門書として、Kafka プラットフォームのコンポーネントとそれらがどのように機能するかを理解することが重要です。 Kafka は分散イベント ストリーミング プラットフォームとして機能し、リアルタイム データ フィードを効率的に処理するように設計されています。これは、パブリッシュ/サブスクライブ メッセージング モデルに基づいて動作し、分散型のフォールト トレラント アーキテクチャに従っています。これは、「トピック」と呼ばれる、永続的で順序付けられ、分割されたレコードのシーケンスを維持します。プロデューサーはこれらのトピックにデータを書き込み、コンシューマーはそこから読み取ります。これにより、データのプロデューサーとコンシューマー間の分離が可能になり、複数のアプリケーションが同じデータ ストリームを独立して消費できるようになります。 Kafka の主要なコンポーネントは次のとおりです。 Kafka はデータをトピックに編成します。各トピックはレコードのストリームであり、トピック内のデータは複数のパーティションに分割されます。各パーティションは、順序付けられた レコードのシーケンスです。パーティションを使用すると、複数の Kafka ブローカー間でデータを分散できるため、水平方向のスケーラビリティと並列処理が可能になります。 トピックとパーティション: 不変の : プロデューサーは、Kafka トピックにデータを書き込むアプリケーションです。これらは特定のトピックにレコードを公開し、そのレコードはトピックのパーティションに保存されます。プロデューサーはレコードを特定のパーティションに明示的に送信したり、Kafka がパーティショニング戦略を使用してパーティションを決定できるようにしたりできます。 プロデューサー : コンシューマは、Kafka トピックからデータを読み取るアプリケーションです。これらは 1 つ以上のトピックをサブスクライブし、割り当てられているパーティションからレコードを消費します。コンシューマ グループは使用量をスケールするために使用され、トピック内の各パーティションはグループ内の 1 つのコンシューマのみが使用できます。これにより、複数のコンシューマーが並行して作業して、同じトピックの異なるパーティションからのデータを処理できるようになります。 コンシューマ : Kafka はサーバーのクラスターとして実行され、各サーバーはブローカーと呼ばれます。ブローカーは、プロデューサーとコンシューマーからの読み取りおよび書き込みリクエストを処理し、トピック パーティションを管理する責任があります。 Kafka クラスターには、負荷を分散しフォールト トレランスを確保するために複数のブローカーを含めることができます。 ブローカー : 耐障害性とデータ耐久性を実現するために、Kafka ではトピック パーティションのレプリケーションを構成できます。各パーティションには複数のレプリカを含めることができ、1 つのレプリカをリーダーとして指定し、他のレプリカをフォロワーとして指定します。リーダー レプリカはそのパーティションに対するすべての読み取りおよび書き込みリクエストを処理し、フォロワーは同期を保つためにリーダーからのデータを複製します。リーダー レプリカを持つブローカーに障害が発生した場合、フォロワーの 1 つが自動的に新しいリーダーになり、継続的な運用が保証されます。 パーティション/レプリケーション : Kafka は、各パーティションのオフセットの概念を維持します。オフセットは、パーティション内のレコードの一意の識別子を表します。消費者は現在のオフセットを追跡し、障害や再処理が発生した場合に中断したところから消費を再開できるようにします。 オフセット管理 : Kafka 自体の一部ではありませんが、ZooKeeper はメタデータを管理し、Kafka クラスター内のブローカーを調整するためによく使用されます。これは、リーダーの選出、トピックとパーティションの情報、および消費者グループの調整の管理に役立ちます。 [注: 採用される予定です] ZooKeeper Zookeeper メタデータ管理ツールは間もなく段階的に廃止され、 内部管理メタデータ用のプロトコルである または KRaft が Kafka Raft 全体として、Kafka の設計とアーキテクチャにより、Kafka は、大量のリアルタイム データ ストリームを処理するための、拡張性が高く、耐障害性があり、効率的なプラットフォームになっています。これは多くのデータ駆動型アプリケーションやデータ インフラストラクチャの中心的なコンポーネントとなり、データ統合、イベント処理、ストリーム分析を促進します。 典型的な Kafka アーキテクチャは次のようになります。 Kafka クラスタリングとは、複数の Kafka ブローカーをグループとして一緒に実行して Kafka クラスターを形成する手法を指します。クラスタリングは Kafka アーキテクチャの基本的な側面であり、スケーラビリティ、耐障害性、高可用性などのいくつかの利点を提供します。 Kafka クラスターは、大規模なデータ ストリームを処理し、障害が発生した場合でもシステムが確実に動作し続けるようにするために使用されます。 クラスターでは、Kafka トピックはスケーラビリティと並列性を実現するために複数のパーティションに分割されます。各パーティションは、線形に順序付けされた不変のレコードのシーケンスです。したがって、パーティションを使用すると、クラスター内の複数のブローカーにデータを分散できます。 最小の Kafka クラスターは 3 つの Kafka ブローカーで構成され、それぞれが別のサーバー (仮想または物理) 上で実行できることに注意してください。 3 ノードのガイダンスは、ブローカーに障害が発生した場合のスプリット ブレイン シナリオを回避するのに役立ちます。 カフカとKubernetes Kafka を採用する企業が増えるにつれ、Kubernetes に Kafka をデプロイすることへの関心も高まっています。 実際、Dynatrace による最新の 大規模組織の 40% 以上が 内でオープンソース メッセージング プラットフォームを実行しており、その大部分が Kafka であることを示しています。 Kubernetes in the Wild レポート 2023 では、 Kubernetes 。 ソース 同じレポートでは、「Kubernetes はクラウドの『オペレーティング システム』として台頭しつつある」という大胆な主張も行っています。 したがって、Kafka 管理者は、Kafka と Kubernetes の間の相互作用と、それらを規模に合わせて適切に実装する方法を理解することが不可欠です。 マルチクラスター Kafka の場合 単一の Kubernetes クラスター セットアップで Kafka クラスターを実行するのは非常に簡単で、理論上は必要に応じてスケーラビリティが可能になります。ただし、本番環境では、画像が少し曖昧になる場合があります。 Kafka と Kubernetes では、 という用語の使用を区別する必要があります。 Kubernetes デプロイメントでは、接続されたノードのグループ (Kubernetes クラスターと呼ばれます) を指定するために 用語も使用されます。 Kafka ワークロードが Kubernetes にデプロイされると、最終的には Kubernetes クラスター内で Kafka クラスターが実行されることになりますが、ここでの説明により関連しますが、復元力、パフォーマンス、データ主権のために、複数の Kubernetes クラスターにまたがる Kafka クラスターが存在する場合もあります。等 クラスター クラスターという そもそも、Kafka はマルチテナント設定向けに設計されていません。技術的に言えば、Kafka は Kubernetes 名前空間やリソース分離などの概念を理解していません。特定のトピック内では、複数のユーザー グループ間でセキュリティ アクセス制限を適用する簡単なメカニズムはありません。 さらに、バッチ アプリケーションとリアルタイム アプリケーションなど、ワークロードが異なれば、更新頻度やスケール要件も異なる場合があります。 2 つのワークロードを 1 つのクラスターに結合すると、悪影響が生じたり、必要以上に多くのリソースが消費されたりする可能性があります。 データ主権と規制遵守により、特定の地域またはアプリケーションでのデータとトピックの共存に制限が課される場合もあります。 もちろん、回復力も複数の Kafka クラスターの必要性の背後にある強力な原動力です。 Kafka クラスターはトピックの耐障害性を考慮して設計されていますが、それでもクラスター全体の壊滅的な障害に備えて計画する必要があります。このような場合、完全に複製されたクラスターが必要なため、適切な事業継続計画が可能になります。 ワークロードをクラウドに移行している企業、またはハイブリッド クラウド戦略を採用している企業の場合、リスクを伴う全面的な Kafka 移行ではなく、複数の Kafka クラスターをセットアップし、時間をかけて計画的にワークロードの移行を実行することをお勧めします。 これらは、実際に企業が相互に対話する必要がある複数の Kafka クラスターを作成する必要がある理由のほんの一部です。 マルチクラスターKafka 複数の Kafka クラスターを相互に接続するには、1 つのクラスターのキー項目を他のクラスターにレプリケートする必要があります。これらには、トピック、オフセット、メタデータが含まれます。 Kafka の用語では、この重複はミラーリングとみなされます。マルチクラスタ設定には 2 つのアプローチが可能です。 または ストレッチ クラスター 接続クラスター。 ストレッチクラスター - 同期レプリケーション ストレッチ クラスターは、複数の物理クラスターにわたって「ストレッチ」された論理クラスターです。トピックとレプリカは物理クラスター全体に分散されますが、それらは論理クラスターとして表現されるため、アプリケーション自体はこの多重性を認識しません。 ストレッチ クラスターは強い一貫性を持ち、管理が容易です。アプリケーションは複数のクラスターの存在を認識しないため、接続されたクラスターと比較して、ストレッチ クラスターにデプロイするのが簡単です。 ストレッチ クラスターの欠点は、クラスター間の同期接続が必要なことです。これらはハイブリッド クラウドの展開には理想的ではなく、「スプリット ブレイン」シナリオを回避するには少なくとも 3 つのクラスターのクォーラムが必要です。 接続されたクラスター - 非同期レプリケーション 一方、接続クラスターは、複数の独立したクラスターを接続することによって展開されます。これらの独立したクラスターは、異なるリージョンまたはクラウド プラットフォームで実行でき、個別に管理されます。 接続されたクラスター モデルの主な利点は、他のクラスターが独立して実行されるため、クラスター障害が発生した場合でもダウンタイムが発生しないことです。各クラスターは、その特定のリソースに合わせて最適化することもできます。 接続されたクラスターの主な欠点は、クラスター間の非同期接続に依存していることです。クラスター間でレプリケートされるトピックは「コピーオンライト」ではなく、 これにより、非同期ミラーリング プロセス中にデータ損失が発生する可能性があります。 最終的な整合性に依存します。 さらに、接続されたクラスター間で動作するアプリケーションは、複数のクラスターを認識できるように変更する必要があります。 この難問の解決策に取り組む前に、Kafka クラスター接続を可能にする市販の一般的なツールについて簡単に説明します。 オープンソース Kafka 自体には、Mirror Maker と呼ばれるミラーリング ツールが付属しています。 Mirror Maker は、組み込みのプロデューサーを介して、異なるクラスター間でトピックを複製します。このようにして、個々のプロセスを中断することなく、結果整合性を保ちながらクラスター間でデータが相互レプリケートされます。 Mirror Maker のコンセプトはシンプルですが、Mirror Maker を大規模にセットアップすることは IT 組織にとって非常に困難な場合があることに注意することが重要です。 IP アドレス、命名規則、レプリカの数などの管理は正しく行う必要があります。正しく行わないと、トピックが無限に複製される、いわゆる「無限レプリケーション」が発生し、最終的にクラッシュにつながる可能性があります。 Mirror Maker のその他の欠点は、更新の許可/禁止リストの動的な構成が欠如していることです。また、Mirror Maker はトピック プロパティを適切に同期しないため、レプリケートするトピックを追加または削除するときに、大規模な運用上の悩みの種になります。 Mirror Maker 2 はこれらの課題のいくつかを解決しようとしていますが、多くの IT ショップはまだ Mirror Maker を正しくセットアップするのに苦労しています。 Kafka レプリケーション用のその他のオープンソース ツールには、Salesforce の Mirus、Uber の uReplicator、 のカスタマイズされた Flink などがあります。 Netflix 商用ライセンス オプションの場合、Confluent は Confluent Replicator と Cluster Linking の 2 つのオプションを提供します。 Confluent Replicator は本質的に、クラスター間でトピック データをコピーするための高性能かつ復元力の高い方法を提供する Kafka Connect コネクタです。クラスター リンクは、内部で開発されたもう 1 つの製品で、トピック オフセットを維持しながらマルチリージョン レプリケーションをターゲットとしています。 それでも、クラスター リンクは、データがネットワーク境界を越え、パブリック トラフィック パスを通過する必要がある非同期レプリケーション ツールです。ここまでで明らかなように、Kafka レプリケーションは大規模な運用アプリケーションにとって重要な戦略であり、問題はどのオプションを選択するかです。 想像力豊かな Kafka 管理者は、アプリケーションのパフォーマンスと復元力の要件に応じて、接続されたクラスターとストレッチ クラスター、またはこれらのデプロイメントの組み合わせが必要になる可能性があることにすぐに気づきます。 ただし、気が遠くなるのは、クラスター構成をセットアップし、複数のクラスターにわたる大規模なクラスター構成を管理するという指数関数的な課題です。この悪夢を解決するもっとエレガントな方法は何でしょうか? Avesha の 両方の長所を活かす簡単な方法です。 KubeSlice は、クラスターまたは名前空間間に直接 を作成することにより、Kafka クラスター間の個別の接続を手動で構成する必要性を排除します。 KubeSlice は、 サービス接続 の核となるのは、クラスター間に安全な同期レイヤー 3 ネットワーク ゲートウェイを作成することです。アプリケーションまたは名前空間レベルで分離されます。これをセットアップすると、Kafka 管理者は任意のクラスターに Kafka ブローカーを自由にデプロイできるようになります。 KubeSlice 各ブローカーは、ブローカー自体が別のクラスター上にある場合でも、スライスを介して結合されている他のすべてのブローカーと同期接続できます。これにより、ブローカー間にストレッチ クラスターが効果的に作成され、強い整合性と低い管理オーバーヘッドという利点が得られます。 ケーキも食べてね！ Mirror Maker をクラスターにデプロイしたい場合は、クラスター間の接続が KubeSlice に委任されているため、最小限の労力でこれを行うことができます。したがって、Kafka アプリケーションは、同じデプロイメント内で同期 (速度、復元力) と非同期 (独立性、スケール) レプリケーションの利点を享受でき、必要に応じて機能を組み合わせることができます。これは、オンプレミスのデータセンター、パブリック クラウド、またはハイブリッド設定におけるこれらの組み合わせに当てはまります。 最も優れた点は、KubeSlice が無停止で展開できることです。つまり、既に展開されているツールをアンインストールする必要がありません。 を確立し、その に Kafka デプロイメントを追加するだけです。 スライス スライス 結論 このブログでは、Apache Kafka の概要を説明し、より一般的な使用例のいくつかについて触れました。複数のクラスターにわたって Kafka デプロイメントを拡張するために利用できる現在のツールを取り上げ、それぞれの利点と欠点について説明しました。最後に、この記事では Kubeslice についても紹介しました。これは、Kafka のマルチクラスター展開を簡素化し、大規模な複数クラスターにわたる Kafka レプリケーションの構成に伴う問題を解決する新しいサービス接続ソリューションです。 読者にとって役立つリンクがいくつかあります。 (KubeSlice が導入される前) AWS で Kafka を実行するベストプラクティスの古いブログ KubeSlice のガイド付きセットアップ GKE への Kafka のデプロイ こちらでも公開しております。