カフカを理解するのに役立つ9つの写真

現在、あらゆる企業がインターネット システムで Kafka を使用しています。 Kafka は、分散を解決し、システムのスループットを向上させるための最良の疎結合ソリューションの 1 つであると思われます。

私は約 6 年前に Kafka を使い始めました。当時、私はAerohiveで働いていました。企業の WiFi デバイスによってもたらされる大量のログを処理するために、従来のメッセージング システム RabbitMQ と ActiveMQ では対応しきれなくなっています。

この時（2012年）、Kafka が誕生し、完璧なソリューションを提供しました。

重要なポイント:

• メッセージキューとその利点を説明する
• Kafka のコンポーネント (ブローカー、プロデューサー、コンシューマー、コンシューマー グループ) について説明します。
• Kafka がなぜ高速なのかを説明する

メッセージングシステムとは何ですか?

Kafka を理解する前に、Message Queue が何であるか分からない場合は、それを追加する必要があります。すでにご存知の場合は、次の段落に進んでください。

> モーデン分散システム

上図のように、メッセージキューは 2 つのシステム間でメッセージを送受信、保存するミドルウェアです。その外観には次のような利点があります。

• 分離: 両者が同じインターフェース制約に準拠している限り、両者の処理を独立して拡張または変更できます。
• 冗長性: メッセージ キューは処理が完了するまでデータを保持するため、データ損失のリスクを回避できます。多くのメッセージ キューで採用されている「挿入、取得、削除」パラダイムでは、キューからメッセージを削除する前に、処理システムは、データが安全に保存されるように、メッセージが処理されたことを明確に示す必要があります。使い終えてください。
• スケーラビリティ: メッセージ キューは処理を分離するため、追加の処理を追加するだけで、メッセージがキューに登録され処理される頻度を簡単に増やすことができます。
• 柔軟性とピーク処理: トラフィックの急激な増加に直面してもアプリケーションは機能し続ける必要がありますが、このようなバーストは標準的ではありません。ピーク時のトラフィックを処理できる能力に基づいてリソースを投資することは、大きな無駄であることは間違いありません。メッセージ キューを使用すると、予期しない過負荷要求によって重要なコンポーネントが完全にクラッシュすることなく、突然のアクセス圧力に耐えることができます。
• 回復力: システムの一部に障害が発生しても、システム全体に影響が及ぶことはありません。メッセージ キューはプロセス間の結合を減らすため、メッセージを処理するプロセスがハングアップした場合でも、キューに追加されたメッセージはシステムの復元後に引き続き処理できます。
• 順序の保証: ほとんどのユースケースでは、データが処理される順序が重要です。ほとんどのメッセージ キューは最初に順序付けられており、データが特定の順序で処理されることが保証されます。 (Kafka はパーティション内のメッセージの順序を保証します)
• バッファリング: システムを通るデータフローの速度を制御および最適化し、生成および消費されるメッセージの処理速度の不一致を解決するのに役立ちます。
• 非同期通信: 多くの場合、ユーザーはメッセージをすぐに処理することを望まなかったり、その必要がありません。メッセージ キューは、ユーザーがメッセージをキューに入れてもすぐには処理できない非同期処理メカニズムを提供します。必要な数のメッセージをキューに入れて、必要に応じて処理します。

同時に、最大の欠点は複雑さであり、利点はまったく無視できるほど小さいと思います。

Kafka はどのように機能しますか?

Kafka の場合、スタンドアロンの観点から見ると、これらにはプロデューサー、コンシューマー、ブローカーが含まれます。

• プロデューサーはブローカーの固定トピックにメッセージを送信する責任がある
• ブローカーはトピックのセットを維持し、そのトピック内のパーティションを管理します。
• ブローカーの対応するトピックからメッセージを抽出する責任を負うコンシューマー

> Kafka コンポーネント

図に示すように、異なるプロデューサーは複数のトピックの複数のパーティションにメッセージを送信でき、コンシューマーもさまざまなトピックから消費できます。

生産者と消費者は完全に分離されています。

この設計では、分離、柔軟性、ピーク処理能力、順序保証、非同期通信が完全に実現されています。

Kafka は分散環境でどのように機能しますか?

1. クラスター

複数のプロキシとレプリカ。

• レプリカ、パーティションレプリカ、パーティションの高可用性を確保
• リーダー、レプリカ、プロデューサー、コンシューマーの役割は、リーダーとのみ相互作用します。
• リーダー内のデータを複製するフォロワー内の役割。

Kafka はどのようにして冗長性、回復性、高可用性を確保するのでしょうか?

レプリケーションにより、一部のノードに障害が発生した場合でも高可用性が実現します。

• プロデューサーは引き続きメッセージを公開できます
• 消費者は引き続きメッセージを受信できます。強力で一貫性のあるデータ レプリケーションを保証するためのスキームには、プライマリ バックアップ レプリケーションとクォーラム ベース レプリケーションの 2 つがあります。どちらの制度もリーダーを選出する必要があり、他のメンバーはフォロワーとして行動します。すべての書き込み操作はリーダーに送信され、リーダーはメッセージをフォロワーに送信します。

クォーラムベースのレプリケーションでは、Zookeeper、Google Spanner などの Raft や Paxos などのアルゴリズムを使用できます。2n + 1 ノードの場合、最大 n 個のノード障害を許容できます。

メッセージが正常に受信された後にのみ、プライマリ データベースに基づくレプリケーションと、他のプライマリ データベースおよびバックアップに対する書き込み操作が成功します。 n 個のノードの場合、Microsoft の PacifiaA のように、最大​​で n-1 個のノード障害を許容できます。

どちらの方法にも長所と短所があります。

• クォーラム ベースのアプローチでは、書き込みが正常に返されるために一部のノードのみが必要であるため、クォーラム ベースのレイテンシはプライマリ バックアップよりも優れている可能性があります。
• 同じ数のノードの場合、プライマリ バックアップ ベースのレプリケーションは、より多くのノード障害に耐えることができ、1 つのノードがアクティブである限り正常に動作します。
• 2 つのノードでは、プライマリ バックアップによってフォールト トレランスを実現できますが、クォーラム ベースのアプローチでは少なくとも 3 つのノードが必要です。

Kafka は 2 番目のアプローチであるマスター スレーブ モードを採用しています。これは主にフォールト トレランスに基づいており、2 つのノードの場合でも高可用性を提供できます。

ノードが遅い場合はどうなりますか?

まず、これは非常にまれにしか起こりません。このような状況が発生した場合は、タイムアウト パラメータを設定して状況に対処できます。

Kafka のレプリケーションはパーティションごとに機能します。

たとえば、上の図には、ブローカーが 4 つ、トピックが 1 つ、パーティションが 2 つあります。複製係数は 3 です。プロデューサーがメッセージを送信すると、topic1-part1 パーティションなどのパーティションが選択され、そのパーティションのリーダーにメッセージが送信されます。broker2、broker3 がメッセージをプルし、メッセージがプルされた後、スレーブがマスターに ack を送信します。今回はマスターはこのログのみをコミットします。

このプロセス中、プロデューサーには 2 つのオプションがあります。

• 1 つは、すべてのレプリカが正常に取得され、プロデューサー ディスクが正常な応答を受信するまで待機することです。
• もう 1 つは、リーダーが正常に書き込み、正常な応答が得られるまで待つことです。

最初の方法では、異常が発生した場合でもメッセージが失われないことが保証されますが、遅延は短縮されます。後者の待機時間は大幅に改善されましたが、異常な状況が発生すると、リーダーがハングする前にスレーブ サーバーは最新のメッセージを取得できなくなります。この場合、メッセージが失われる可能性があります。

2. 顧客基盤

コンシューマーは自身にコンシューマー グループ名を付け、トピックに公開された各レコードは、サブスクライブしている各コンシューマー グループの 1 つのコンシューマー インスタンスに配信されます。コンシューマー インスタンスは、別のプロセスまたは別のマシン上に存在できます。

すべてのコンシューマー インスタンスが同じコンシューマー グループを持つ場合、レコードはコンシューマー インスタンス間で効果的に分散されます。

すべてのコンシューマインスタンスが異なるコンシューマグループを持っている場合、各レコードはすべてのコンシューマプロセスにブロードキャストされ、正式なファイルが形成されます。

つまり、コンシューマー グループが Kafka エコシステムにおける実際のコンシューマーです。

3. コントローラー

上の写真は、2015 年の Kafka コントローラーの設計です。コントローラーと ZK は共同で Kafka の高レベル アーキテクチャを構築し、主に次のタスクを実行します。

• ブローカーと消費者の動的な参加と離脱を管理します。
• 負荷分散をトリガーします。ブローカーまたはコンシューマーが参加または離脱すると、負荷分散アルゴリズムがトリガーされ、コンシューマー グループ内の複数のコンシューマーのサブスクリプション負荷分散が行われます。
• 各パーティションの消費関係と消費情報を維持します。

Kafka はなぜこんなに速いのでしょうか?

Kafka には、大量のネットワーク データがディスクに保存され (プロデューサーからブローカーへ)、ディスク ファイルがネットワーク経由で送信される (ブローカーからコンシューマーへ) プロセスがあります。

このプロセスのパフォーマンスは、Kafka の全体的なスループットに直接影響します。

1. ゼロコピー

上図の左側には、従来の 4 つのコピーと 4 つのコンテキスト スイッチが表示されています。

• まず、ファイルデータはシステムコール（DMAコピー）を通じてカーネル状態バッファに読み込まれます。
• 次に、アプリケーションはメモリ状態バッファのデータをユーザー状態バッファ（CPUコピー）に読み込みます。
• 次に、ユーザー プログラムは、ソケット経由でデータを送信するときに、ユーザー ステータス バッファー データを読み取ります。カーネル状態バッファにコピー（CPUコピー）
• 最後に、データは DMA コピーを介して NIC バッファにコピーされます。同時に、4 つのコンテキスト スイッチが伴います。

上の図の右側では、Kafka は Linux 2.4 以降のカーネル sendfile システム コールを使用してゼロ コピーを実装しています。

• データはDMA経由でカーネルステータスバッファにコピーされる
• CPUコピーなしでDMA経由でNICバッファに直接コピーされます。

sendfile 呼び出しにより、ファイル読み取りネットワーク転送全体が完了するため、プロセス全体でコンテキスト スイッチは 2 回のみとなり、パフォーマンスが大幅に向上します。

正確に言うと、Kafka のデータ転送は TransportLayer を通じて完了し、そのサブクラス PlaintextTransportLayer は Java NIO の FileChannel の transferTo メソッドと transferFrom メソッドを通じてゼロ コピーを実装します。

2. シーケンシャルアクセス

> 比較する

上記のグラフは、ディスクから順番に読み取る場合でも、メモリベースのランダム アクセスよりもシーケンシャル アクセスの方が大きな利点があることを示しています。

Kafka のすべてのメッセージは追加され、ディスクへの順次アクセスを確保するために、メッセージの途中からの書き込みや削除は行われません。

たとえシーケンシャルな読み書きであっても、小さな IO 操作が多すぎるとディスクのボトルネックが発生し、今度はランダムな読み書きになります。

Kafka の戦略は、メッセージを集約し、バッチで送信してディスク アクセスを最小限に抑えることです。したがって、Kafka トピックとパーティションの数は多すぎないようにする必要があります。

通常、トピック/パーティションが 64 を超えると、Kafka のパフォーマンスは大幅に低下します。

3. セグメントログ

• Kafka はこのトピックを使用してメッセージを管理します。各トピックには複数の部分が含まれており、各部分は論理ログに対応し、複数の部分で構成されます。
• 各セグメントには複数のメッセージが格納されます。その論理位置によってメッセージ ID が決まります。つまり、メッセージ ID はメッセージの保存場所に直接配置できるため、ID から場所への追加のマッピングが回避されます。
• 各セクションはメモリ内のインデックスに対応し、各セグメントの最初のメッセージのオフセットを記録します。
• パブリッシャーが特定のトピックに送信したメッセージは、複数の部分に均等に分散され（ランダムに、またはユーザーが指定したコールバック関数に従って）、ブローカーはパブリッシュされたメッセージを受信し、対応する部分の最後のセグメントにメッセージを追加します。セグメント上のメッセージ数が設定された値に達するか、メッセージの公開時間がしきい値を超えると、セグメント上のメッセージはディスクにフラッシュされ、ディスクにフラッシュされたメッセージのサブスクライバーのみがメッセージをサブスクライブできるようになります。セグメントが一定のサイズに達すると、そのセグメントにはそれ以上のデータは書き込まれなくなり、エージェントは新しいセグメントを作成します。

このパーティション分割とインデックス設計により、データの読み取り効率が向上するだけでなく、データ操作の並列性も向上します。

4. 高性能ブローカー

Broker における Kafka の設計も、Kafka が非常に高速である理由の 1 つです。

まず、クライアントから送信されたすべてのリクエストがアクセプタに送信されます。デフォルトでは、エージェントには 3 つのスレッドが存在します。これら 3 つのスレッドはプロセッサと呼ばれます。

受信者はクライアントのリクエストに対して何の処理も実行せず、リクエストを直接カプセル化します。これらのハンドラーに socketChannel を送信してキューを形成します。

送信方法はポーリングです。つまり、最初に最初のプロセッサに送信し、次に 2 番目、3 番目のプロセッサに送信し、最後に最初のプロセッサに戻ります。コンシューマー スレッドがこれらの socketChannels を使用すると、プル リクエストが取得され、これらのプル リクエストにデータが付随します。

デフォルトでは、スレッド プールには 8 つのスレッドがあります。これらのスレッドは、リクエストの処理と解析に使用されます。要求が書き込み要求の場合、ディスクに書き込まれます。読み取られた場合、結果が返されます。ハンドラーは応答から応答データを読み取り、それをクライアントに返します。

これは Kafka の 3 層ネットワーク アーキテクチャです。

したがって、Kafka を強化および調整する必要がある場合は、プロセッサを追加し、スレッド プール内の処理スレッドを増やすことで効果を得ることができます。プロセッサが要求を非常に速く生成し、それらをタイムリーに処理するのに十分なスレッドがない場合は、要求と応答は実質的にキャッシュ効果になります。

要約する

この記事が、Kafka とそのコンポーネント、そしてなぜこれほど高いパフォーマンスを実現できるのかについて理解し、予備的な理解を深めるのに役立つことを願っています。

Kafka は、ストリーミングなど、現代の高並行性システム アーキテクチャにおいて重要な役割を果たしており、現在も急速に発展を続けています。

この記事では、概念と単純な設計原則の観点からのみ Kafka について説明します。ただ習得するだけでは十分ではありません。

より詳細な分析が必要な場合は、公式ドキュメントを参照してください。

読んでくれてありがとう！