Kafka の設計原則の詳細な説明

Kafka コア コントローラ

Kafka クラスターには 1 つ以上のブローカーがあり、そのうちの 1 つがコントローラー (Kafka コントローラー) として選出され、クラスター全体のすべてのパーティションとレプリカのステータスを管理する役割を担います。

• パーティションのリーダー レプリカに障害が発生した場合、コントローラーはパーティションの新しいリーダー レプリカを選択する責任を負います。
• パーティションの ISR セットで変更が検出されると、コントローラはすべてのブローカーにメタデータ情報を更新するように通知する役割を担います。
• kafka-topics.sh スクリプトを使用してトピックのパーティション数を増やす場合、コントローラーは新しいパーティションを他のノードに表示できるようにする責任を負います。

コントローラ選出メカニズム

Kafka クラスターが起動すると、ブローカーがクラスター全体を管理するコントローラーとして自動的に選出されます。選出プロセスでは、クラスター内の各ブローカーが Zookeeper 上に /controller 一時ノードを作成しようとします。 Zookeeper は、ブローカーが 1 つだけ正常に作成されるようにし、このブローカーがクラスターのマスター コントローラーになります。このコントローラー ロールのブローカーがダウンすると、Zookeeper の一時ノードは消えます。クラスター内の他のブローカーは、この一時ノードをリッスンし続けます。一時ノードが消えたことに気付いた場合、彼らは再び一時ノードを作成するために競争するでしょう。これが上で述べた選挙の仕組みです。 Zookeeper は、1 つのブローカーが新しいコントローラーになることを保証します。

• ブローカー関連の変更を監視します。ブローカーの追加と削除の変更を処理するには、Zookeeper の /brokers/ids/ ノードに BrokerChangeListener を追加します。
• トピック関連の変更を監視します。トピックの追加と削減の変更を処理するために、Zookeeper の /brokers/topics ノードに TopicChangeListener を追加します。トピックの削除アクションを処理するには、Zookeeper の /admin/delete_topics ノードに TopicDeletionListener を追加します。

Zookeeper からトピック、パーティション、ブローカーに関連するすべての最新情報を読み取り、それに応じて管理します。トピック内のパーティション割り当ての変更を監視するには、すべてのトピックに対応する Zookeeper の /brokers/topics/[topic] ノードに PartitionModificationsListener を追加します。

クラスターのメタデータ情報を更新し、他の共通ブローカー ノードと同期します。

パーティションレプリカリーダー選出メカニズム

コントローラーは、パーティション リーダーが配置されているブローカーがクラッシュしたことを感知します (コントローラーは多数の zk ノードを監視しており、ブローカーが稼働していることを感知できます)。コントローラーは、各パーティションのレプリカ リストから最初のブローカーをリーダーとして選択します。もちろん、このブローカーも ISR リストに含まれている必要があります。

消費者消費メッセージのオフセット記録メカニズム

各コンシューマーは、その消費パーティションのオフセットを Kafka の内部トピック __consumer_offsets に定期的に送信します。送信時のキーは consumerGroupId+トピック+パーティション番号、値は現在のオフセット値です。 Kafka はトピック内のメッセージを定期的にクリーンアップし、最終的に最新のデータを保持します。 __consumer_offsets は高同時実行リクエストを受信する可能性があるため、Kafka はデフォルトで 50 個のパーティションを割り当てます (offsets.topic.num.partitions で設定可能)。これにより、マシンを追加することで高同時実行に耐えることができます。

消費者再調整メカニズム

コンシューマーの再バランスとは、コンシューマー グループ内のコンシューマーがクラッシュした場合、そのコンシューマーに割り当てられているパーティションが他のコンシューマーに自動的に与えられることを意味します。再起動すると、一部のパーティションが復元されます。

注: 再バランスは、サブスクライブでパーティションの消費が指定されていない場合にのみ適用されます。パーティションが割り当て消費を通じて指定されている場合、Kafka は再バランスを行いません。

次のような状況は消費者の再調整を引き起こす可能性がある。

• 消費者がいるサービスが再起動またはクラッシュした
• トピックに動的にパーティションを追加する
• 消費者団体はより多くのトピックを購読している

リバランスプロセス

フェーズ1: グループコーディネーターの選定

グループ コーディネーター: 各コンシューマー グループは、グループ コーディネーターとしてブローカーを選択します。ブローカーは、コンシューマー グループ内のすべてのコンシューマーのハートビートを監視し、それらがダウンしているかどうかを判断し、コンシューマーの再バランス調整を有効にする責任を負います。

コンシューマー グループ内の各コンシューマーが起動すると、対応するグループ コーディネーター GroupCoordinator を見つけてネットワーク接続を確立するために、Kafka クラスター内のノードに FindCoordinatorRequest リクエストが送信されます。

グループコーディネーターの選択方法: 次の式を使用して、コンシューマーによって消費されたオフセットを送信する __consumer_offsets のパーティションを選択できます。このパーティションのリーダーに対応するブローカーは、このコンシューマー グループのコーディネーターです。

式: hash(コンシューマーグループID) % __consumer_offsets トピック内のパーティション数

フェーズ2: 消費者グループに参加する JOIN GROUP

コンシューマ グループに対応する GroupCoordinator を正常に見つけたら、コンシューマ グループに参加する段階に入ります。この段階で、コンシューマーは GroupCoordinator に JoinGroupRequest リクエストを送信し、応答を処理します。次に、GroupCoordinator は、コンシューマー グループに参加する最初のコンシューマーをリーダー (コンシューマー グループ コーディネーター) として選択し、コンシューマー グループ情報をリーダーに送信します。リーダーは、パーティション プランの作成を担当します。

フェーズ3（同期グループ）

コンシューマー リーダーは GroupCoordinator に SyncGroupRequest を送信し、GroupCoordinator は各コンシューマーにパーティション スキームを送信します。指定されたパーティションのリーダー ブローカーに従って、ネットワークに接続し、メッセージを消費します。

消費者再バランスパーティション割り当て戦略

主なリバランス戦略には、範囲、ラウンドロビン、スティッキーの 3 つがあります。

Kafka は、コンシューマーとサブスクライブされたトピック間のパーティション割り当て戦略を設定するためのコンシューマー クライアント パラメーターの part.assignment.strategy を提供します。デフォルトの割り当て戦略は範囲です。

トピックに 10 個のパーティション (0 ～ 9) があり、次のものを消費するコンシューマーが 3 人いるとします。

1. 範囲戦略: パーティション番号で並べ替えます。 n = パーティション数/消費者数 = 3、m = パーティション数 % 消費者数 = 1 と仮定すると、最初の m 人の消費者にはそれぞれ n+1 個のパーティションが割り当てられ、次の (消費者数 - m) 人の消費者にはそれぞれ n 個のパーティションが割り当てられます。たとえば、パーティション 0 ～ 3 は 1 人のコンシューマーに割り当てられ、パーティション 4 ～ 6 は 1 人のコンシューマーに割り当てられ、パーティション 7 ～ 9 は 1 人のコンシューマーに割り当てられます。
2. ラウンドロビン戦略: ポーリング割り当て。たとえば、パーティション 0、3、6、9 は 1 つのコンシューマーに与えられ、パーティション 1、4、7 は 1 つのコンシューマーに与えられ、パーティション 2、5、8 は 1 つのコンシューマーに与えられます。
3. スティッキー戦略: リバランスを行う際には、次の 2 つの原則を満たす必要があります。

• パーティションはできる限り均等に分散する必要があります。
• パーティションの割り当ては、最後の割り当てと可能な限り同じに保たれます。

2 つの目標が矛盾する場合は、最初の目標が 2 番目の目標よりも優先されます。これにより、元のパーティション割り当て戦略を最大限に維持できます。

たとえば、最初の範囲割り当ての場合、3 番目のコンシューマーが切断すると、スティッキー戦略を使用した再割り当ての結果は次のようになります。

• 元の0〜3に加えて、消費者1にはさらに7が割り当てられます。
• 元の4〜6に加えて、消費者2は8と9も割り当てます。

プロデューサーメッセージ発行メカニズムの分析

1. 書き方

プロデューサーはプッシュ モードを使用してブローカーにメッセージを公開します。各メッセージは、ディスクへの順次書き込みであるパターンに追加されます (ディスクへの順次書き込みは、メモリへのランダム書き込みよりも効率的であり、Kafka のスループットを保証します)。

2. メッセージルーティング

プロデューサーがブローカーにメッセージを送信すると、パーティション分割アルゴリズムに基づいて、どのパーティションにメッセージを保存するかが選択されます。ルーティングのメカニズムは次のとおりです。1. パターンが指定されている場合は、それが直接使用されます。 2. パターンが指定されていないがキーが指定されている場合は、キー値をハッシュすることによってパターンが選択されます。 3. パターンもキーも指定されていない場合は、ポーリングによってパターンが選択されます。

3. 執筆プロセス

• プロデューサーはまずZookeeperの「/brokers/.../state」ノードからパーティションのリーダーを見つけます。
• プロデューサーはリーダーにメッセージを送る
• リーダーはメッセージをローカルログに書き込む
• フォロワーはリーダーからメッセージを取得し、ローカル ログに書き込み、リーダーに ACK を送信します。
• リーダーは、ISR 内のすべてのレプリカから ACK を受信した後、HW (最高水準点、最後にコミットされたオフセット) を増やし、プロデューサーに ACK を送信します。

HWとLEOの詳細な説明

HW は一般にハイ ウォーター マーク (HighWatermark の略) として知られています。パーティションに対応する ISR 内の最小の LEO (ログ終了オフセット) が HW として取得されます。消費者は最大で HW が配置されている位置までしか消費できません。さらに、各レプリカには HW があり、リーダーとフォロワーはそれぞれ自身の HW のステータスを更新する責任があります。リーダーが新たに書き込んだメッセージについては、消費者はそれをすぐに消費することはできません。リーダーは、メッセージが ISR 内のすべてのレプリカによって同期されるのを待機し、その後 HW を更新します。そうして初めて、メッセージは消費者によって消費されるようになります。これにより、リーダーが配置されているブローカーに障害が発生した場合でも、新しく選出されたリーダーからメッセージを取得できるようになります。内部ブローカーからの読み取り要求の場合、HW 制限はありません。

例えば、プロデューサーがブローカーにメッセージを生成する場合、ISR、HW、LEOのフロープロセスが

このことから、Kafka のレプリケーション メカニズムは、完全に同期したレプリケーションでも、完全に非同期のレプリケーションでもないことがわかります。実際、同期レプリケーションでは、メッセージがコミットされる前に、すべての作業中のフォロワーがレプリケーションを完了している必要があります。このレプリケーション方法はスループット レートに大きく影響します。非同期レプリケーションでは、フォロワーはリーダーからデータを非同期的にコピーします。データがリーダーによってログに書き込まれている限り、コミットされたとみなされます。この場合、フォロワーがコピーを完了しておらずリーダーより遅れており、リーダーが突然クラッシュすると、データが失われます。 Kafka の ISR の使用により、データが失われないこととスループット レートの間で適切なバランスが保たれます。

HWとLEOを組み合わせてacks=1の状況を確認する