Alibaba の専門家による実践的な要約: Kafka アーキテクチャの原則

まず、Kafka のアーキテクチャ原則についていくつか質問してみましょう。

1. Kafka のトピックとパーティションは内部的にどのように保存されますか?それぞれの特徴は何ですか？

2. 従来のメッセージング システムと比較した Kafka の消費モデルの利点は何ですか?

3. Kafka はどのようにして分散データ ストレージとデータ読み取りを実現するのでしょうか?

1. Kafka アーキテクチャ図

1. Kafka用語の説明

Kafka アーキテクチャには、複数のプロデューサー、複数のブローカー、および複数のコンシューマーが存在します。各プロデューサーは複数のトピックに対応できますが、各コンシューマーは 1 つの ConsumerGroup にのみ対応できます。

Kafka アーキテクチャ全体は ZK クラスターに対応しており、クラスター構成の管理、リーダーの選出、コンシューマー グループの変更時の再バランス調整を行います。

名前

説明する

ブローカ

メッセージミドルウェア処理ノード、Kafkaノードはブローカーであり、1つ以上のブローカーがKafkaクラスターを形成できます。

トピック

トピック: Kafka はトピックに従ってメッセージを分類します。 Kafka クラスターに公開される各メッセージでは、トピックを指定する必要があります。

プロデューサー

メッセージプロデューサー、ブローカーにメッセージを送信するクライアント

消費者

メッセージコンシューマ、ブローカーからのメッセージを読み取るクライアント

消費者グループ

各コンシューマーは特定のコンシューマー グループに属します。メッセージは複数の異なるコンシューマー グループに送信できますが、メッセージを消費できるのはコンシューマー グループ内の 1 つのコンシューマーだけです。

パーティション

物理的には、トピックは複数のパーティションに分割され、各パーティションは順序付けられます。

2.トピックとパーティション

Kafka のすべてのメッセージにはトピックがあります。一般的に、アプリケーションで生成されるデータの種類ごとに異なるテーマを設定できます。通常、トピックには複数のメッセージ サブスクライバーが存在します。プロデューサーがトピックにメッセージを公開すると、トピックをサブスクライブしているコンシューマーはプロデューサーによって書き込まれた新しいメッセージを受信できます。

Kafka はトピックごとに分散パーティション ログ ファイルを保持し、各パーティションは Kafka ストレージ レベルでの追加ログです。このパーティションに公開されたメッセージはすべて、ログ ファイルの末尾に追加されます。パーティション内の各メッセージには、時系列順に単調に増加するシーケンス番号が割り当てられ、これがオフセットになります。オフセットは長い数値です。このオフセットを使用して、パーティション下の一意のメッセージを決定できます。順序はパーティションでは保証されますが、トピックでは保証されません。

上の図では、プロデューサーが送信先のパーティションを決定します。

1. キー値がない場合、ポーリングが実行されます。
2. キー値がある場合は、キー値をハッシュし、パーティション数の係数を取得して、同じキー値を持つメッセージが同じパーティションにルーティングされるようにします。キューに強力な順次一貫性が必要な場合は、すべてのメッセージを同じキーに設定できます。

3. 消費モデル

メッセージはプロデューサーから Kafka クラスターに送信された後、コンシューマーによって消費されます。一般的に言えば、消費モデルにはプッシュモデル（psuh）とプルモデル（pull）の2つがあります。

メッセージ ブローカーが消費ステータスを記録する、プッシュ モデルに基づくメッセージ システム。メッセージ ブローカーはメッセージをコンシューマーにプッシュした後、メッセージを消費済みとしてマークしますが、この方法では消費の処理セマンティクスを適切に保証できません。たとえば、コンシューマーにメッセージを送信した後、コンシューマー プロセスがハングアップしたり、ネットワーク上の理由によりメッセージが受信されなかったりします。コンシューマー エージェントで消費済みとしてマークすると、メッセージは失われます。プロデューサーがメッセージを受信した後に応答する方法を使用する場合、メッセージブローカーは消費ステータスを記録する必要があり、これは望ましくありません。プッシュが使用される場合、メッセージの消費速度はコンシューマー エージェントによって完全に制御されます。消費者がブロックされると、問題が発生します。

Kafka は、消費速度と進行状況を自ら制御するプル モデル (ポーリング) を採用しています。消費者は任意のオフセットに応じて消費することができます。たとえば、コンシューマーは、再処理のためにすでに消費されたメッセージを消費したり、最新のメッセージを消費したりすることができます。

4. ネットワークモデル

4.1 KafkaClient -- シングルスレッドセレクター

シングルスレッド モードは、同時接続数が少なく、ロジックが単純で、データ量が少ない場合に適しています。

Kafka では、コンシューマーとプロデューサーの両方が上記のシングルスレッド モードを使用します。このモードは Kafka サーバーには適していません。サーバー上のリクエスト処理プロセスは比較的複雑であり、スレッドのブロックが発生します。後続のリクエストが発生すると、それらを処理することができなくなり、大量のリクエストがタイムアウトして雪崩が発生します。サーバーでは、実行ロジックを処理するためにマルチスレッドを最大限に活用する必要があります。

4.2 Kafka--server -- マルチスレッドセレクター

Kafka サーバーはマルチスレッド セレクター モデルを使用します。アクセプターは別のスレッドで実行されます。読み取り操作用のスレッド プール内のすべてのスレッドは、セレクターに読み取りイベントを登録し、サーバーの読み取り要求のロジックを担当します。読み取りが成功すると、要求はメッセージ キューの共有キューに配置されます。次に、書き込みスレッド プールで、要求を取り出して論理処理を実行します。リクエスト スレッドがブロックされている場合でも、メッセージ キューからリクエストを取得して処理する後続の郡があります。書き込みスレッドで論理処理が完了したら、OP_WIRTE イベントが登録されるので、それに応答を送信する必要があります。

5.信頼性の高い分散ストレージモデル

Kafka の高信頼性モデルはレプリケーション メカニズムに依存しています。レプリケーションメカニズムにより、マシンがクラッシュしてもデータが失われることはありません。

5.1 高性能ログストレージ

Kafka トピックのすべてのメッセージは、パーティションの形式で複数のノードに分散して保存されます。同時に、Kafka マシンでは、各パーティションは実際にはログ ディレクトリに対応しており、ディレクトリの下には複数のログ セグメント (LogSegment) が存在します。 LogSegment ファイルは、「.index」ファイルと「.log」ファイルの 2 つの部分で構成され、それぞれセグメント インデックス ファイルとデータ ファイルを表します。これら 2 つのファイルのコマンド ルールは次のとおりです。パーティションの最初のセグメントは 0 から始まり、後続の各セグメント ファイル名は、前のセグメント ファイルの最後のメッセージのオフセット値になります。値のサイズは 64 ビット、長さは 20 桁で、数字がない場合はゼロで埋められます。以下に示すように、メッセージが 1000 個あり、各 LogSegment のサイズが 100 であると仮定すると、900 ～ 1000 のインデックスとログは次のようになります。

Kafka メッセージ データが大きすぎるため、すべてのインデックスを作成すると、スペースが占有され、時間が増加します。そのため、Kafka はスパース インデックスを選択し、インデックスをメモリに直接入力して部分クエリを高速化します。

データの読み取り方法について簡単に紹介します。 911 番目のデータを読み取る場合、最初のステップは、そのデータがどのセクションに属しているかを調べ、バイナリ検索を使用してそのデータが属するファイルを見つけることです。 0000900.index と 00000900.log を見つけたら、インデックスに移動して、インデックス (911-900) = 11 または 11 未満の最も近いインデックスを見つけます。ここでは、バイナリ検索により、インデックスが [10,1367] であることがわかります。次に、このインデックスの物理的な位置である 1367 を遡って、911 番目のデータを見つけます。

上記は、特定のオフセットを見つけるプロセスについて説明しています。ただし、ほとんどの場合、特定のオフセットを見つける必要はありません。順番に読むだけでいいのです。順次読み取りでは、オペレーティング システムはメモリとディスクの間にページ キャッシュを追加します。これは、通常行われる事前読み取り操作です。したがって、順次読み取り操作は非常に高速です。しかし、Kafka には問題があります。パーティションが多すぎると、ログ セグメントも多数存在します。書き込む際は、一括して書き込むため、実際にはランダムな書き込みになります。この時点でランダム I/O はパフォーマンスに大きな影響を与えます。したがって、一般的に言えば、Kafka にはパーティションが多すぎることはできません。この問題に対処するために、RocketMQ はすべてのログを 1 つのファイルに書き込み、順次書き込みに変換できます。特定の最適化により、読み取りを順次読み取りに近づけることもできます。

次のように考えてみてください: 1. なぜパーティションが必要なのでしょうか?つまり、トピックにパーティションを 1 つだけ含めることはできないのでしょうか? 2. ログをセグメント化する必要があるのはなぜですか?

5.2 コピーメカニズム

Kafka のレプリケーション メカニズムでは、複数のサーバー ノードが他のノードのトピック パーティションのログを複製します。クラスター内のノードに障害が発生すると、障害が発生したノードへのアクセス要求は他の正常なノードに転送されます (このプロセスは通常、リバランスと呼ばれます)。 Kafka の各トピックの各パーティションには、プライマリ コピーと 0 個以上のレプリカがあります。レプリカはプライマリ コピーとデータを同期させ、プライマリ コピーに障害が発生すると置き換えられます。

Kafka では、すべてのレプリカをプライマリ レプリカの置き換えに使用できるわけではないため、Kafka のリーダー ノードは ISR (In sync Replicas) セット (同期セットとも呼ばれます) を維持します。このセット内のレプリカは、次の 2 つの条件を満たす必要があります。

• ノードはZKとの接続を維持する必要がある
• 同期プロセス中、このコピーはプライマリコピーよりあまり遅れることはできません。

レプリカの完全なセットを識別するための AR (割り当てられたレプリカ) もあり、遅れているために削除されたレプリカのセットを示すために OSR が使用されるため、式は次のようになります。ISR = リーダー + それほど遅れていないレプリカ。 AR = OSR + ISR;

ここでは、2 つの用語について説明する必要があります。HW (ハイ ウォーター マーク) は、コンシューマーが確認できるこのパーティションの位置であり、LEO は各パーティションのログ内の最後のメッセージの位置です。 HW は、リーダーが配置されているブローカーに障害が発生した場合でも、メッセージが失われることなく、新しく選出されたリーダーからメッセージを取得できることを保証できます。

プロデューサーがリーダーにデータを送信するとき、データの信頼性のレベルは request.required.acks パラメータを通じて設定できます。

• 1 (デフォルト): これは、ISR のリーダーがデータを正常に受信して確認した後、プロデューサーが次のメッセージを送信することを意味します。リーダーがダウンすると、データが失われます。
• 0: プロデューサーはブローカーからの確認を待たずに次のメッセージのバッチを送信し続けることを意味します。この場合、データ伝送効率は最大になりますが、データの信頼性も最大になります。
• -1: プロデューサーは、ISR 内のすべてのフォロワーがデータの受信を確認するまで待機してから、最高の信頼性で送信が完了したと見なす必要があります。ただし、データが失われないことが保証されるわけではありません。たとえば、ISR にリーダーのみが存在する場合 (他のノードが zk から切断されているか、追いついていない場合)、状況は acks=1 になります。