究極のパフォーマンスを追求するために、Kafkaには11の主要な最適化があります

Kafka はパフォーマンスを最適化するためにどのような対策を講じましたか?これは Kafka の面接でよくある質問であり、面接官がこの質問をすることは難しくありません。インターネット上には、「Kafka はなぜこんなに速いのか?」など、この問題を説明する関連記事も多数あります。以前にも主要な公開アカウントによって再投稿されています。私はこれらの記事を読みましたが、よく書かれています。問題は、重要なポイントのいくつかを列挙するだけで、詳細を説明されていないことです。この記事に記載されている重要なポイントは、オンラインで見つけられるもの以上のものです。この記事を読んだ後、面接中に関連する質問に遭遇した場合、面接官に好印象を与えることができると思います。

[[271473]]

バッチ処理

従来のメッセージ ミドルウェアのメッセージの送信と消費は、通常、単一メッセージです。プロデューサーの場合、最初にメッセージを送信し、次にブローカーがメッセージを受信したことを示す ACK を返します。これにより、2 つの RPC が生成されます。コンシューマーの場合、最初にメッセージの受信を要求し、次にブローカーがメッセージを返し、最後にメッセージが消費されたことを示す ACK を送信します。これにより、3 つの RPC が生成されます (一部のメッセージ ミドルウェアはこれを最適化し、ブローカーが戻ったときに複数のメッセージを返します)。 Kafka はバッチ処理を使用します。プロデューサーはメッセージのバッチを集約し、2 つの RPC を実行してブローカーにメッセージを保存します。この処理を完了するには、元々多数の RPC が必要でした。 1,000 件のメッセージを送信する必要があり、各メッセージのサイズが 1 KB であると仮定します。従来のメッセージ ミドルウェアでは 2,000 個の RPC が必要ですが、Kafka ではこれらの 1,000 個のメッセージを 1 つの 1 MB メッセージにパッケージ化し、2 回の RPC でタスクを完了できます。この改善はかつては「不正行為」行為とみなされていました。しかし、今日ではマイクロバッチの概念が普及しており、他のメッセージ ミドルウェアもそれに追随し始めています。

クライアントの最適化

バッチ処理の概念を継承して、プロデューサー クライアントの新しいバージョンでは、以前の単一スレッドを廃止し、メイン スレッドと送信者スレッドのデュアル スレッドを採用しています。メイン スレッドはメッセージをクライアント キャッシュに配置する役割を担い、Sender スレッドは複数のメッセージをバッチに集約してキャッシュからメッセージを送信する役割を担います。一部のメッセージ ミドルウェアは、ブローカーに直接メッセージをスローします。

ログ形式

Kafka のログ形式は、バージョン 0.8 以降、v0、v1、v2 の 3 つの変更が行われました。

ログエンコーディング

Kafka の特定のログ形式 (上図を参照) を理解している場合は、基本的なキーと値に加えて、ログ (レコードまたはメッセージ) 自体にもいくつかの他のフィールドがあることがわかります。もともと、これらの追加フィールドは固定サイズに応じて一定量のスペースを占有していました (上図の左を参照)。最新バージョンの Kafka では可変長フィールド Varint と ZigZag エンコーディングが使用され、これらの追加フィールドが占有するサイズが効果的に削減されています。ログ（メッセージ）ができるだけ小さいと、ネットワーク伝送の効率が高くなり、ログの保存効率が向上し、ソートのパフォーマンスが向上します。

メッセージ圧縮

Kafka は複数のメッセージ圧縮方法 (gzip、snappy、lz4) をサポートしています。メッセージを圧縮すると、ネットワークの転送量とネットワーク I/O が大幅に削減され、全体的なパフォーマンスが向上します。メッセージ圧縮は、時間をスペースと交換する最適化方法です。レイテンシに関して特定の要件がある場合は、メッセージを圧縮することはお勧めしません。

インデックスを作成する

各ログ セグメント ファイルは 2 つのインデックス ファイルに対応しており、主にメッセージ検索の効率を向上させるために使用され、パフォーマンスを向上させる方法でもあります (具体的な内容については、本書の第 5 章で詳しく説明されています)。

パーティション

多くの人はこの要素を無視するでしょう。実際、パーティショニングはパフォーマンスを向上させる非常に効果的な方法でもあります。この方法の効果は、前述のログのエンコードやメッセージの圧縮よりも明白です。パーティショニングは他の分散コンポーネントにも広く関係しています。パーティショニングによってパフォーマンスが向上する理由については、ここでは基本的な知識については詳しく説明しません。ただし、パーティションを盲目的に増やしても、必ずしもパフォーマンスが向上するわけではないことに注意してください。興味のある学生は、この記事「Kafka トピックのパーティション数が多いほど、スループットは高くなりますか?」をお読みください。

一貫性

Kafka のパフォーマンス最適化対策に関する情報のほとんどは、一貫性について言及していません。 Paxos、Raft、Gossip などの一般的な一貫性プロトコルはよく知られていますが、Kafka は Pacific-A に同様のアプローチを採用することで異なるアプローチを採用しています。これは「スナップショット」アプローチではありませんが、このモデルを使用するとソートの効率が向上します。具体的な詳細については、「Kafka で Pacific-A を Raft に置き換えることの実現可能性分析と利点と欠点」のような記事で後ほど整理する予定です。

シーケンシャル書き込み

オペレーティング システムは、先読み (比較的大きなディスク ブロックを事前にメモリに読み込む) や後書き (多数の小さな論理書き込み操作を 1 つの大きな物理書き込み操作にマージする) テクノロジなど、線形読み取りと書き込みの詳細な最適化を実行できます。 Kafka は、ファイル追加方式でメッセージを書き込むように設計されています。つまり、新しいメッセージはログ ファイルの末尾にのみ追加でき、書き込まれたメッセージの変更は許可されません。この方法は典型的な順次ディスク書き込み操作であるため、Kafka がストレージ メディアとしてディスクを使用する場合でも、ディスクが実現できるスループットを過小評価してはなりません。

ページキャッシュ

Kafka のパフォーマンスがなぜこれほど高いのでしょうか?この問題に直面したとき、多くの人は前述のディスクへの順次書き込みを思い浮かべるでしょう。実際、順次ディスク書き込みの前にページ キャッシュ (PageCache) 層の最適化も行われます。

ページ キャッシュは、ディスク I/O 操作を削減するためにオペレーティング システムによって実装される主要なディスク キャッシュです。具体的には、ディスク内のデータをメモリにキャッシュし、ディスクへのアクセスをメモリへのアクセスに変換します。パフォーマンスの違いを補うために、最近のオペレーティング システムでは、メモリをディスク キャッシュとして使用することにますます「積極的」になっており、使用可能なメモリをすべてディスク キャッシュとして使用することさえあります。そのため、メモリが再利用されてもパフォーマンスの低下はほとんどなく、ディスクへのすべての読み取りと書き込みは統合されたキャッシュを経由します。

プロセスがディスク上のファイルの内容を読み取る準備ができると、オペレーティング システムはまず、読み取るデータがあるページがページ キャッシュ内にあるかどうかを確認します。存在する場合（ヒット）、データは直接返されるため、物理ディスク上の I/O 操作が回避されます。ヒットがない場合、オペレーティング システムはディスクへの読み取り要求を開始し、読み取られたデータ ページをページ キャッシュに保存してから、データをプロセスに返します。同様に、プロセスがディスクにデータを書き込む必要がある場合、オペレーティング システムは、データに対応するページがページ キャッシュ内にあるかどうかも検出します。そうでない場合は、まず対応するページをページ キャッシュに追加し、最後に対応するページにデータを書き込みます。変更されたページはダーティ ページになり、オペレーティング システムはデータの一貫性を維持するために適切なタイミングでダーティ ページ内のデータをディスクに書き込みます。

プロセスの場合、プロセス内での処理に必要なデータをキャッシュします。ただし、このデータはオペレーティング システムのページ キャッシュにもキャッシュされる可能性があるため、同じデータが 2 回キャッシュされる可能性があります。また、Direct I/O を使用しない限り、ページ キャッシュを無効にすることは困難です。さらに、Java を使用したことがある人なら、一般的に次の 2 つの事実を知っています。オブジェクトのメモリ オーバーヘッドは非常に大きく、通常は実際のデータ サイズの数倍かそれ以上であり、スペースの使用率が低いということです。ヒープ内のデータ量が増加するにつれて、Java のガベージ コレクションはますます遅くなります。これらの要素に基づくと、ファイル システムを使用してページ キャッシュに依存する方が、インプロセス キャッシュやその他の構造を維持するよりも明らかに優れています。少なくとも、プロセスの内部キャッシュの消費を節約でき、オブジェクトの使用をコンパクトなバイトコードに置き換えることで、さらに多くのスペースを節約することもできます。この方法では、GC によるパフォーマンスの問題を心配することなく、32GB のマシンで 28GB ～ 30GB のメモリを使用できます。さらに、Kafka サービスを再起動してもページ キャッシュは有効なままですが、インプロセス キャッシュは再構築する必要があります。また、これにより、ページ キャッシュとファイル間の一貫性の維持がオペレーティング システムに任されるため、コード ロジックが大幅に簡素化され、インプロセス メンテナンスよりも安全で効率的になります。

Kafka はページ キャッシュを広範に使用します。これは、Kafka が高いスループットを実現するための重要な要素の 1 つです。メッセージは最初にページ キャッシュに書き込まれますが、その後はオペレーティング システムが特定のディスク フラッシュ タスクを担当します。

ゼロコピー

かなり前に「ゼロコピーとは何か」という記事を公開しました。 Zero Copy についてご存じない方は、ぜひご覧ください。 Kafka は、消費効率を向上させるためにゼロコピー テクノロジーを使用します。前述のように、Kafka はまずメッセージをページ キャッシュに書き込みます。コンシューマーがメッセージを読み取るときにページ キャッシュにアクセスできる場合は、ページ キャッシュから直接読み取ることができるため、ディスクからページ キャッシュへのコピーのオーバーヘッドが削減されます。さらに、読み取りと書き込みの概念については、書き込み増幅と読み取り増幅が何であるかをさらに理解できます。

添付

ディスク IO プロセスは次の図のようになります。

詳細な分析については、「Linux IO ディスクの概要ノート」を参照してください。

最後に

この記事に記載されている Kafka パフォーマンス最適化の重要なポイントは、面接で Kafka 関連の問題に遭遇したときに自分の強みを示すための資本となります。学ばなければならず、習得しなければならない