9枚の写真、カフカがZookeeperを放棄した理由

[[394712]]

最近、Confluent コミュニティが記事を公開しました。この記事では主に、Kafka の将来のバージョン 2.8 で Zookeeper が廃止されることについて説明されており、これは Kafka ユーザーにとって重要な改善点です。以前は、Kafka をデプロイするときに Zookeeper をデプロイする必要がありましたが、現在は Kafka のみをデプロイすれば済みます。 [1]

1. Kafka の紹介

Apache Kafka は最初に Linkedin によって開発され、後に Apack Foundation に寄贈されました。

Kafka は分散ストリーム処理プラットフォームとして正式に定義されており、高いスループット、永続性、水平スケーラビリティを備えているため広く使用されています。現在、Kafka には次の特定の機能があります。

メッセージキュー、Kafka には、システム分離、トラフィックピークの削減、バッファリング、非同期通信などのメッセージキューの機能があります。
分散ストレージシステムである Kafka は、メッセージを永続化し、複数のコピーを使用してフェイルオーバーを実装できるため、データストレージシステムとして使用できます。
リアルタイムデータ処理のために、Kafka は、リアルタイムデータを処理する機能を持つ Kafka Streams や Kafka Connect などのデータ処理に関連するいくつかのコンポーネントを提供します。

次の図はKafkaのメッセージモデルを示しています。[2]

上の図を通して、Kafka のいくつかの主要な概念を紹介します。

プロデューサーとコンシューマー: メッセージキュー内のプロデューサーとコンシューマー。プロデューサーはキューにメッセージをプッシュし、コンシューマーはキューからメッセージをプルします。
コンシューマーグループ: 同じトピックの異なるパーティションからのメッセージを並行して消費できるコンシューマーのコレクション。
ブローカー: Kafka クラスター内のサーバー。
トピック: メッセージカテゴリ。
パーティション: トピックの物理的なグループ化。トピックにはパーティションを設定できます。各パーティション内のメッセージには、オフセットとして順序付けられた ID が割り当てられます。各コンシューマーグループには、パーティションを消費するコンシューマーが 1 つだけ存在します。

2. Kafka と Zookeeper の関係

Kafka のアーキテクチャを下図に示します。図からわかるように、Kafka には Zookeeper の協力が必要です。それで、それらはどのように連携するのでしょうか?

下の写真をご覧ください。

図からわかるように、Kafka の作業には Zookeeper の協力が必要です。それで、それらはどのように連携するのでしょうか?

下の写真をご覧ください。

2.1 登録センター

2.1.1 ブローカー登録

上図からわかるように、ブローカー分散展開では、統一管理のために登録センターが必要です。 Zookeeper は、ブローカーサービスリスト (/brokers/ids) を保存するために専用のノードを使用します。

ブローカーが起動すると、Zookeeper に登録要求が送信されます。 Zookeeper は、/brokers/ids の下に /brokers/ids/[0...N] などのブローカーノードを作成し、ブローカーの IP アドレスとポートを保存します。

このノードは一時ノードです。ブローカーがダウンすると、この一時ノードは自動的に削除されます。

2.1.2 トピック登録

Zookeeper はトピックに個別のノードも割り当て、各トピックは /brokers/topics/[topic_name] の形式で Zookeeper に記録されます。

トピックのメッセージは複数のパーティションに保存され、これらのパーティションとブローカー間の対応も Zookeeper に保存する必要があります。

パーティションは複数のコピーで保存されます。上図の赤いパーティションはリーダーコピーです。リーダーレプリカが配置されているブローカーに障害が発生した場合、パーティションはリーダーを再選出する必要があり、これは Zookeeper によって実行される必要があります。

ブローカーが起動されると、ブローカー ID が対応するトピックノードのパーティションリストに登録されます。

次のコマンドを使用して、xxx という名前のトピックとパーティション番号 1 の情報を確認します。

 [root@master] /brokers/topics/xxx/partitions/1/state を取得します
{ "controller_epoch" :15、 "leader" :11、 "version" :1、 "leader_epoch" :2、 "isr" :[11,12,13]}

ブローカーが終了すると、Zookeeper は対応するトピックのパーティションリストを更新します。

2.1.3 消費者登録

コンシューマーグループも Zookeeper に登録され、Zookeeper は関連データを保存するためにコンシューマーグループにノードを割り当てます。ノードパスは /consumers/{group_id} で、次に示すように 3 つの子ノードがあります。

このようにして、Zookeeper はパーティションとコンシューマーの関係、およびパーティションのオフセットを記録できます。 [3]

2.2 負荷分散

ブローカーが Zookeeper に登録されると、プロデューサーはブローカーノードに基づいてブローカーサービスリストの変更を認識し、動的な負荷分散を実現します。

コンシューマーグループ内のコンシューマーは、トピックノード情報に基づいて特定のパーティションからメッセージをプルし、負荷分散を実現できます。

実際、次の図に示すように、Kafka は Zookeeper に大量のメタデータを保存します。

ブローカー、トピック、パーティションの数が増えるにつれて、保存されるデータの量はますます大きくなります。

3. コントローラの紹介

前のセクションの説明から、Kafka は Zookeeper に大きく依存していることがわかります。 Kafka は Zookeeper なしでは独立して実行できません。では、Kafka は Zookeeper とどのようにやり取りするのでしょうか?

次の図に示すように: [4] Kafkaクラスターでは、ブローカーがZookeeperと対話するコントローラーとして選出されます。 Kafka クラスター全体のすべてのパーティションとレプリカのステータスを管理する役割を担います。他のブローカーは、コントローラーノード上のデータの変更を監視します。

コントローラーの選択は Zookeeper に依存します。選出が成功すると、Zookeeper は一時的なノード / コントローラーを作成します。

管理者の具体的な責任は次のとおりです。

パーティションの変更を監視する

たとえば、パーティションのリーダーに障害が発生すると、コントローラはパーティションの新しいリーダーを選出します。パーティションの ISR セットで変更が検出されると、コントローラはすべてのブローカーにメタデータを更新するように通知します。トピックがパーティションを追加すると、コントローラーがパーティションの再割り当てを担当します。

トピック関連の変更を監視する
ブローカー関連の変更を監視する
クラスターメタデータ管理

次の図は、コントローラー、Zookeeper、ブローカー間の相互作用の詳細を示しています。

コントローラーが正常に選出されると、Zookeeper クラスターからメタデータの完全なセットが取得され、ControllerContext が初期化され、このメタデータがコントローラーノードにキャッシュされます。トピックパーティションの追加など、クラスターが変更されると、コントローラーはローカルキャッシュデータを変更するだけでなく、この変更情報を他のブローカーと同期する必要もあります。

コントローラーは、Zookeeper イベント、スケジュールされたタスクイベント、およびその他のイベントを監視した後、これらのイベントを順番に LinkedBlockingQueue に一時的に保存し、イベント処理スレッドが順番に処理します。これらのプロセスのほとんどは Zookeeper とのやり取りを必要とし、コントローラーは独自のメタデータを更新する必要があります。

4. Zookeeper の問題

Kafka 自体は分散システムですが、それを管理するには別の分散システムが必要であり、間違いなく複雑さが増します。

4.1 運用と保守の複雑さ

Zookeeper を使用する場合、Kafka を導入する際に 2 つのシステムを導入する必要があり、Kafka の運用保守担当者は Zookeeper の運用保守能力を備えている必要があります。

4.2 コントローラのトラブルシューティング

Kafaka は、Zookeeper と対話するために単一のコントローラーノードに依存します。このコントローラーノードに障害が発生した場合は、ブローカーから新しいコントローラーを選択する必要があります。下の図に示すように、新しいコントローラーは broker3 になります。

新しいコントローラーが正常に選出されると、初期化のために Zookeeper からメタデータが再度取得され、他のすべてのブローカーに ActiveControllerId を更新するように通知する必要があります。古いコントローラーは、リスニング、イベント処理スレッド、およびスケジュールされたタスクをシャットダウンする必要があります。パーティションの数が非常に多い場合、このプロセスには非常に時間がかかり、このプロセス中は Kafka クラスターは動作できません。

4.3 パーティションのボトルネック

パーティションの数が増えると、Zookeeper に保存されるメタデータの量が増加し、Zookeeper クラスターへの負荷が増加します。一定のレベルに達すると監視の遅延が増加し、Kafka の動作に影響します。

したがって、単一の Kafka クラスターによって実行されるパーティションの数がボトルネックになります。そして、これはまさに一部のビジネスシナリオで必要なことです。

5. アップグレード

アップグレード前とアップグレード後のアーキテクチャ図を比較すると、次のようになります。

KIP-500 は、以前のコントローラーを Quorum コントローラーに置き換えます。クォーラム内の各コントローラーノードはすべてのメタデータを保存し、KRaft プロトコルを通じてレプリカの一貫性を確保します。この方法では、クォーラムコントローラーノードに障害が発生した場合でも、新しいコントローラーの移行は非常に高速になります。

公式紹介によれば、アップグレード後、Kafka は数百万のパーティションを簡単にサポートできるようになります。

Kafkaチームは、Raftプロトコル（略してKRaft）を介してデータを同期する方法であるKafka Raftメタデータモードと呼んでいます。

Kafka のユーザーベースは非常に大きいため、サービスを停止せずにアップグレードする必要があります。

現在、Zookeeper を削除する Kafka コード KIP-500 がトランクブランチに送信されており、将来の 2.8 バージョンでリリースされる予定です。

Kafaka はバージョン 3.0 で Zookeeper Controller および Quorum Controller と互換性を持たせ、ユーザーがグレースケールテストを実行できるようにする予定です。 [5]