Kafka の原則: 図解された Kafka アーキテクチャの原則

[[392023]]

これは[Code Brother]によるKafkaシリーズの2番目の記事です。 Code Brotherは、Kafkaを原理、実践、ソースコードの観点から深く分析し、実践します。このシリーズには、[原則]、[実践]、[ソースコード]が含まれます。これは [Principles] の 2 番目の記事であり、主に Kafka のアーキテクチャと実装の原則について説明します。

読者は、前回の記事「Kafka のパフォーマンス: Kafka がなぜ「高速」なのか?」を参照できます。

今日は、Kafka のアーキテクチャと実装の原則について詳しく説明します。 [Code Brother] では、アーキテクチャと詳細から始めて、鮮明な図を使用して Kafka の実装原理を詳しく説明します。

多くの学生は、これまでに Kafka の原則に関連する多くの記事を読んだことがあると思いますが、それらを読むと「すごい」という気持ちと情熱が溢れ、いつもさまざまな「すごい」技術を学んだと感じています。しかし、多くの学生はこのことを明確に認識していないことがよくあります。中途半端な面接官に対処するには、記事と面接の質問を暗記するだけで十分です。経験豊富な面接官に会ったり、実際の戦闘に参加したりしても、多くの概念や実装についてまだ不明瞭な点があるかもしれません。

そこで、[Code Brother]は、Kafka を半分しか理解していない多くの学生が Kafka の実装原理の理解を深められるように、Kafka を説明することにしました。

同時に、読者は Kafka の構成と組み合わせて Kafka の実装原理を理解することが推奨されます。 Kafka には多数の構成があり、これも Kafka の高いスケーラビリティの表れです。多くの学生は、Kafka の設定を簡単に変更しようとしません。したがって、これらの構成の背後にある実装原則を理解することは、実際に Kafka をどのように使用し、最適化するかを理解するのに役立ちます。インタビューやロケット製作ができ、実際にロケットを製作することもできます。

Kafka 設定手順のリンク: https://kafka.apache.org/documentation

この記事の主な内容は次のとおりです。

内容が多すぎることと、一歩踏み込みすぎてトラブルを引き起こすことを恐れたため、[コードブラザー]は記事を3つの部分に分割することにしました。この記事では、上の写真の「オレンジ」の部分についてのみ説明します。

この記事から学べること:

• Kafka アーキテクチャ設計の哲学と原則
• カフカにおける飼育係の役割
• Kafka コントローラーの実装原則
• Kafka ネットワークの原則

冒頭挨拶

できるだけ多くの製品を作成するようにしてください。他の人があなたを理解するための窓となる作品を持つことは重要です。可能であれば、公開アカウントまたは自分用のブログを開設して、日々の観察や考えを記録しましょう。最初は暗記が雑然としていて非論理的かもしれませんが、粘り強く続ければ、間違いなく大きな価値が生まれます。

建築

Kafka アーキテクチャを理解するということは、Kafka のさまざまなコンポーネントの概念と、それらのコンポーネント間の関係を理解することを意味します。まず、各コンポーネントと簡単な説明を簡単に見てみましょう。

暗記しようとしないでください。

プロデューサー:メッセージを送信するプロデューサー。プロデューサーはメッセージを作成し、それを Kafka に送信する責任を負います。

消費者:メッセージを受信する当事者。コンシューマーは Kafka に接続してメッセージを受信し、対応するビジネス ロジック処理を実行します。

コンシューマー グループ:コンシューマー グループには 1 人以上のコンシューマーを含めることができます。マルチパーティション + マルチコンシューマー モードを使用すると、ダウンストリーム データの処理速度が大幅に向上します。同じコンシューマー グループ内のコンシューマーは、メッセージを繰り返し消費しません。同様に、異なるコンシューマー グループのコンシューマーは、メッセージを送信するときに互いに影響を与えません。 Kafka は、コンシューマー グループを通じてメッセージ P2P モードとブロードキャスト モードを実装します。

ブローカー: サービス プロキシ ノード。 Broker は Kafka のサービス ノード、つまり Kafka のサーバーです。

トピック: Kafka 内のメッセージはトピックに分割されます。プロデューサーは特定のトピックにメッセージを送信し、コンシューマーはトピックからのメッセージをサブスクライブして消費する責任を負います。

パーティション:トピックは論理的な概念であり、複数のパーティションに分割できます。各パーティションは 1 つのトピックにのみ属します。同じトピックの下にある異なるパーティションに含まれるメッセージは異なります。パーティションは、ストレージ レベルで追加可能なログ ファイルと見なすことができます。メッセージがパーティション ログ ファイルに追加されると、特定のオフセットが割り当てられます。

オフセット:オフセットは、パーティション内のメッセージの一意の識別子です。 Kafka はこれを使用して、パーティション内のメッセージの順序を確保します。ただし、オフセットはパーティションにまたがりません。つまり、Kafka はトピックの順序ではなくパーティションの順序を保証します。

レプリケーション:レプリケーションは、Kafka がデータの高可用性を確保する方法です。 Kafka の同じパーティション内のデータは、複数のブローカー上に複数のコピーとして存在できます。通常、プライマリ コピーのみが外部に対して読み取りおよび書き込みサービスを提供します。プライマリコピーが配置されているブローカーがクラッシュしたり、ネットワーク異常が発生したりした場合、Kafka はコントローラーの管理下にある新しいリーダーコピーを再選択して、外部に読み取りおよび書き込みサービスを提供します。

レコード:実際に Kafka に書き込まれ、読み取ることができるメッセージ レコード。各レコードにはキー、値、タイムスタンプが含まれます。

一度理解すれば、覚えられます。

私たちはそれらを理解して覚えておくべきです。

生産者と消費者

プロデューサー-コンシューマーは、中間コンポーネントを追加することでプロデューサーとコンシューマーを切り離す設計パターンです。プロデューサーは中間コンポーネントにデータを生成し、コンシューマーはデータを消費します。

ちょうど65番兄さんが学生時代に小芳さんにラブレターを書いたときのように、ここでは65番兄さんがプロデューサー、ラブレターがメッセージ、小芳さんが消費者です。しかし、時々小芳がいなかったり忙しかったりして、65番兄さんは小芳の手に直接ラブレターを渡すのが恥ずかしくて、手紙を小芳の引き出しに押し込んだ。引き出しは中央のコンポーネントです。

プログラムでは、通常、この中間コンポーネントとして Queue を使用します。複数のスレッドを使用してキューにデータを書き込むことができ、他のコンシューマー スレッドが順番にキュー内のデータを読み取って消費します。モデルは以下のとおりです。

プロデューサー-コンシューマー モデルは、中間層を追加することでプロデューサーとコンシューマーを分離し、スケーリングを容易にするだけでなく、非同期で呼び出してメッセージをバッファリングします。

分散キュー

その後、65 兄さんと Xiaofang さんは別々の場所に住むようになりました。 65 兄さんは歓渡で一生懸命働き、その間、小芳さんは上海で買い物に出かけました。そのため、あいまいな手紙を郵便局を通じて送ることしかできませんでした。このようにして、兄弟65、郵便局、小坊が分散されます。兄弟65は郵便局に手紙を送りました。小芳は郵便局から65番兄さんが書いた手紙を受け取り、戻ってゆっくりと読みました。

Kafka のメッセージ プロデューサーは Producer です。上流のコンシューマー プロセスは、Kafka クライアントを追加して Kafka プロデューサーを作成し、ブローカーにメッセージを送信します。ブローカーは、リモート サーバー上のクラスターにデプロイされた Kafka サーバー プロセスです。ダウンストリーム コンシューマー プロセスでは、キュー内のメッセージを継続的に消費するために Kafka Consumer API が導入されています。

Kafka Consumer は Poll モードを使用するため、Consumer はメッセージを積極的にプルする必要があります。そのため、Xiaofang は定期的に郵便局に行って手紙を受け取ることしかできません (まあ、主導権は確かに Xiaofang の手中にあります)。

テーマ

65 番の兄弟は 1 日に数通の手紙を書いていますが、郵便局は彼だけにサービスを提供することはできません。しかし、郵便局の損失を補うことはできない。つまり、郵便局は誰でも手紙を送ることができる場所なのです。送り主は宛名（件名）を書くだけで、郵便局は両者の間にチャネルを持っているため、手紙を送受信することができます。

Kafka トピックはキューに相当し、ブローカーはすべてのキューがデプロイされるマシンです。ビジネスごとに異なるトピックを作成できます。プロデューサーは、所属するビジネスのトピックにメッセージを送信し、対応するコンシューマーはメッセージを消費して処理できます。

パーティション

65 番兄弟はあまりにも多くの手紙を書いたため、1 つの郵便局では対応できなくなり、郵便会社はさらにいくつかの郵便局を建設する必要がありました。ブラザー65は、プライバシーレベルに応じて手紙を分類し（ゾーニング戦略）、異なる郵便局から発送しました。

同じトピックに対して複数のパーティションを作成できます。理論的には、パーティションの数が多いほど同時実行性が高くなります。 Kafka は、メッセージの偏りや異なるブローカー間の負荷の大きな差を回避するために、パーティション戦略に従って、異なるブローカー ノードにパーティションを可能な限り均等に分散します。パーティションが多ければ多いほど良いです。結局のところ、郵便会社が多すぎると、すべてを管理することはできません。具体的な理由については、[Code Brother]の前回の記事「Kafka のパフォーマンス: Kafka はなぜ「速い」のか?」を参照してください。

インスタンス

交通渋滞や郵便トラックのガソリン切れなど、郵便局に問題が発生するのを防ぐためです。その結果、65兄さんの曖昧な手紙は小芳さんに送ることができず、65兄さんは夜中に遠隔でキーボードの上にひざまずくことになった。郵便局は、65番兄さんの手紙を数部コピーして複数の一般郵便局に送ることに決めました。そうすれば、営業している郵便局が1つでもある限り、小芳さんは65番兄さんの手紙を受け取ることができるのです。

Kafka はパーティションのレプリカを使用して、高いデータ可用性を確保します。各パーティションに対して指定された数のレプリカが確立されます。 Kafka は、ブローカーのダウンタイムによりすべてのレプリカが利用できなくなるのを防ぐために、同じパーティションのレプリカが可能な限り異なるブローカー ノードに分散されるようにします。 Kafka は、パーティションの複数のレプリカの 1 つをプライマリ レプリカ (リーダー) として選択します。プライマリ レプリカは外部に読み取りおよび書き込みサービスを提供し、レプリカ (フォロワー) はリーダーのデータをリアルタイムで同期します。

複数の消費者

ああ、65 兄弟の手紙があちこちに飛び交っています。小芳さんは毎日郵便局に行って、一つずつ開けなければなりません。 65番兄さんの書いた手紙は長くて臭いので、小芳さんは大忙しで汗だくです。そこで小芳は、さまざまな郵便局に行って手紙を受け取るクローンをすぐに複数作成し、ようやく買い物に行く余分な時間を捻出できるようになりました。

ブロードキャストメッセージ

郵便局は最近、カスタマイズされたポストカードのサービスを開始しました。誰でもポストカードをデザインできますが、同じ人が受け取ることができるポストカードの種類は 1 つだけです。 65 ブラザーはたくさんのものをデザインし、かわいい女の子全員に配布しました。女の子たちはそれを要求しに来ることができます。美女たちが変身したアバターも受け取れますが、同じアイデンティティを持つ複数のアバターが受け取れるポストカードは 1 種類のみです。

Kafka は、コンシューマー グループを通じてブロードキャスト モードのメッセージ サブスクリプションを実装します。つまり、異なるグループのコンシューマーは、お互いに影響を与えることなくメッセージを繰り返し消費でき、同じグループのコンシューマーが全体を構成します。

最終的に、次のように Kafka の全体的なアーキテクチャが完成しました。

動物園の飼育員

Zookeeper は、分散構成サービス、同期サービス、分散サービスの名前登録機能を提供できる、成熟した分散調整サービスです。あらゆる分散システムでは、タスクを調整する方法が必要です。 Kafka は ZooKeeper を使用して構築された分散システムです。しかし、独自のタスク調整メカニズムが組み込まれた他のテクノロジー (Elasticsearch や MongoDB など) もあります。

Kafka はブローカー、トピック、パーティションのメタデータ情報を Zookeeper に保存します。 Zookeeper 上に対応するデータ ノードを確立し、ノードの変更を監視することにより、Kafka は Zookeeper を使用して次の機能を実行します。

• Kafka コントローラーリーダー選出
• Kafka クラスターのメンバーシップ管理
• トピック構成管理
• パーティションレプリカ管理

Zookeeper の下で Kafka によって作成されたノードを見ると、これらの関連する機能が一目でわかります。

コントローラ

コントローラーはブローカーから選出され、パーティション リーダーとフォロワーの管理を担当します。パーティションのリーダー レプリカに障害が発生した場合、コントローラーはパーティションの新しいリーダー レプリカを選択する責任を負います。パーティションの ISR (In-Sync Replica) セットで変更が検出されると、コントローラはすべてのブローカーにメタデータ情報を更新するように通知する役割を担います。 kafka-topics.sh スクリプトを使用してトピックのパーティション数を増やす場合でも、パーティションの再割り当てはコントローラーが担当します。

Kafka でのコントローラーの選択は Zookeeper に依存します。コントローラーに対して正常に実行されたブローカーは、Zookeeper に一時的な (EPHEMERAL) ノード /controller を作成します。

選挙プロセス

ブローカーが起動すると、/controller ノードの brokerid 値を読み取ろうとします。 brokerid 値が -1 と等しくない場合は、別のブローカーが正常にコントローラー ノードになり、現在のブローカーが積極的に選出を放棄したことを意味します。 /controller ノードが存在しないか、brokerid 値が異常な場合、現在のブローカーは /controller ノードを作成しようとします。このとき、他のブローカーも同時にこのノードを作成しようとする可能性があります。ノードを正常に作成したブローカーのみがコントローラーになり、ノードの作成に失敗したブローカーは選出に失敗したことを示します。各ブローカーは、現在のコントローラーの brokerid 値をメモリに保存します。これは、activeControllerId として識別できます。

成し遂げる

コントローラーは、Zookeeper 内のノード データを読み取り、コンテキスト (コントローラー コンテキスト) を初期化し、ノードの変更を管理し、コンテキストを変更します。また、これらの変更情報を他の共通ブローカー ノードと同期する必要があります。コントローラーは、スケジュールされたタスクまたはリスナー モードを通じて Zookeeper 情報を取得します。イベントリスニングによりコンテキスト情報が更新されます。図に示すように、コントローラもプロデューサー-コンシューマー実装モードを採用しています。コントローラーは、Zookeeper の変更をイベントの形式でイベント キューに送信します。キューは LinkedBlockingQueue です。イベント コンシューマー スレッド グループは、消費イベントを消費し、対応するイベントを各ブローカー ノードに同期します。このキュー FIFO モードはメッセージの順序を保証します。

責任

コントローラはブローカー クラスタ全体のマネージャとして選出され、すべてのクラスタ情報とメタデータ情報を管理します。その責任には以下が含まれます。

自然なオフライン、ダウンタイム、ネットワークの到達不能によって発生するクラスターの変更を含む、ブローカー ノードのオンラインとオフラインを処理します。コントローラは、クラスタ メタデータをタイムリーに更新し、クラスタの変更をすべてのブローカー クラスタ ノードに通知する必要があります。

トピックを作成したり、トピック パーティションを拡張したりする場合、コントローラーはパーティション レプリカを割り当て、トピック パーティション レプリカのリーダー選出を主導する役割を担います。

クラスター内のすべてのレプリカとパーティションのステート マシンを管理し、ステート マシンの変更イベントを監視して、対応するアクションを実行します。 Kafka パーティションとレプリカ データは、ステート マシン方式で管理されます。パーティションとレプリカの変更により、ステート マシンの状態が変更され、対応する変更イベントがトリガーされます。

65 ブラザー：ステートマシンって、すごく複雑そうですね。

コントローラーは、クラスター内のすべてのレプリカとパーティションのステート マシンを管理します。 「ステートマシン」という用語に惑わされないでください。ステートマシンを理解するのは簡単です。まずモデルを理解します。つまり、これが何についてのものであり、どのようなモデルについてのものであるかを理解し、次にモデルの状態が何であるか、モデルの状態間でどのように変換するか、変換中に対応する変更イベントを送信するかを理解します。

Kafka のパーティションとレプリカの状態マシンはシンプルです。まず、これらがそれぞれ Kafka Topic のパーティションとレプリカを管理するために使用されることを理解しましょう。ステータスも非常に単純で、CRUD であり、具体的には次のようになります。

パーティションステートマシン

PartitionStateChange はトピックのパーティションを管理します。次の 4 つの状態があります。

1. NonExistentPartition: このステータスは、パーティションが作成されていないか、作成後に削除されたことを示します。
2. NewPartition: パーティションは作成された直後はこの状態になります。この状態では、パーティションにレプリカが割り当てられていますが、リーダーは選出されておらず、ISR リストもありません。
3. OnlinePartition: このパーティションのリーダーが選出されると、この状態になります。
4. OfflinePartition: パーティションのリーダーがクラッシュすると、この状態に移行します。

これらの状態がどのように変化するか、また状態が変化したときにコントローラーがどのような操作を実行するかを視覚的に確認するために、図を使用しましょう。

レプリカステートマシン

ReplicaStateChange (レプリカ ステータス) は、パーティションのレプリカ情報を管理し、次の 4 つの状態を持ちます。

1. NewReplica: トピックとパーティションの割り当てを作成すると、レプリカが作成されます。この時点では、レプリカはフォロワーになるためのステータス変更要求のみを受信できます。
2. OnlineReplica: レプリカがパーティションの割り当てられたレプリカになると、そのステータスは有効な OnlineReplica である OnlineReplica に変わります。
3. OfflineReplica: レプリカがオフラインになると、この状態になります。これは通常、ブローカーがダウンしているときに発生します。
4. NonExistentReplica: レプリカが正常に削除されると、レプリカは NonExistentReplica 状態になります。

レプリカ状態間の変化を次の図に示します。コントローラーは状態が変化すると対応するアクションを実行します。

ネットワーク

Kafka のネットワーク通信モデルは、NIO の Reactor マルチスレッド モデルに基づいて設計されています。新しい接続を処理するための Acceptor スレッドが含まれています。アクセプターには、ソケット要求を選択して読み取る N 個のプロセッサ スレッドと、要求を処理して応答する、つまりビジネス ロジックを処理する N 個のハンドラー スレッドがあります。以下は KafkaServer のモデル図です。

後続の Kafka ソースコード記事では、[Code Brother] がソースコードの観点からこれらの原則をコードに具体的に実装する方法について説明します。どうぞお楽しみに。