安価なマシン 3 台で 1 秒あたり 200 万回の書き込みを実現! Kafka はなぜこんなに速いのでしょうか?

Kafka のメッセージはディスクに保存またはキャッシュされます。一般的に、ディスク上のデータの読み書きはアドレス指定に時間がかかるためパフォーマンスが低下すると考えられていますが、実際には、Kafka の特徴の 1 つはスループットが高いことです。

通常のサーバーの場合でも、Kafka は 1 秒あたり *** の書き込み要求を簡単にサポートでき、ほとんどのメッセージ ミドルウェアを上回ります。この機能により、Kafka はログ処理などの大量データ シナリオでも広く使用されるようになります。

Kafka のベンチマーク テストについては、Apache Kafka ベンチマーク テスト (クリックすると元のテキストが表示されます)「1 秒あたり 200 万回の書き込み (安価なマシン 3 台)」を参照してください。

 http://ifeve.com/benchmarking-apache-kafka-2-million-writes-second-three-cheap-machines/

以下は、データの書き込みと読み取りの観点から、Kafka がなぜ高速なのかを分析したものです。

データの書き込み

Kafka は受信したすべてのメッセージをハードディスクに書き込み、データが失われることはありません。書き込み速度を最適化するために、Kafka は順次書き込みと MMFile (メモリマップファイル) の 2 つのテクノロジを使用します。

シーケンシャル書き込み

ディスクの読み取りと書き込みの速度は、ディスクの使用方法、つまり、順次読み取りと書き込みか、ランダム読み取りと書き込みかによって異なります。シーケンシャルな読み書きの場合、ディスクのシーケンシャルな読み書き速度はメモリの速度と同等です。

ハードディスクは機械的な構造であるため、読み取りと書き込みのたびにアドレス指定→書き込みのプロセスが発生しますが、その中でもアドレス指定は「機械的な動作」であり、最も時間がかかります。

したがって、ハードドライブはランダム I/O を最も嫌い、シーケンシャル I/O を最も好みます。ハードディスクの読み取りと書き込みの速度を上げるために、Kafka はシーケンシャル I/O を使用します。

さらに、Linux には、先読み、後書き、ディスク キャッシュなど、ディスクの読み取りと書き込みに対する多くの最適化機能があります。

これらの操作がメモリ内で実行される場合、Java オブジェクトのメモリ オーバーヘッドが非常に大きくなり、ヒープ メモリ データが増加すると Java GC 時間が非常に長くなります。

ディスク操作を使用すると、次の利点があります。

• ディスクの順次読み取りおよび書き込み速度は、メモリのランダム読み取りおよび書き込み速度を上回ります。
• JVM の GC 効率が低く、メモリ使用量が多くなります。ディスクを使用するとこの問題を回避できます。
• システムのコールド リスタート後も、ディスク キャッシュは引き続き使用できます。

次の図は、Kafka がデータを書き込む方法を示しています。各パーティションは実際にはファイルです。メッセージを受信した後、Kafka はファイルの末尾 (破線部分) にデータを挿入します。

この方法には欠陥があり、データを削除する方法がないため、Kafka はデータを削除しません。すべてのデータが保持されます。各コンシューマーには、どのデータが読み取られたかを示すために、トピックごとにオフセットがあります。

2 人の消費者:

• Consumer1 には、それぞれ Partition0 と Partition1 に対応する 2 つのオフセットがあります (トピックごとに 1 つのパーティションがあると仮定)。
• Consumer2 には Partition2 に対応するオフセットがあります。

このオフセットはクライアント SDK によって保存され、Kafka のブローカーはその存在を完全に無視します。

通常、SDK はそれを Zookeeper に保存するので、コンシューマーに Zookeeper アドレスを提供する必要があります。

データを削除しないとハードディスクが確実にいっぱいになるため、Kakfa ではデータを削除するための 2 つの戦略を提供しています。

• 時間ベース
• パーティションファイルサイズに基づく

具体的な設定については、設定ドキュメントを参照してください。

メモリマップファイル

ハードディスクにデータを順次書き込んでも、ハードディスクのアクセス速度がメモリに追いつきません。そのため、Kafka のデータはハードディスクにリアルタイムで書き込まれません。最新のオペレーティング システムのページング ストレージを最大限に活用してメモリを活用し、I/O 効率を向上させます。

メモリマップファイル（以下、mmap と呼びます）もメモリマップファイルに変換されます。 64 ビット オペレーティング システムでは、通常 20G のデータ ファイルを表すことができます。その動作原理は、オペレーティング システムのページを直接使用して、ファイルを物理メモリに直接マッピングすることです。

マッピングが完了すると、物理メモリ上の操作がハードディスク (適切な場合はオペレーティング システム) に同期されます。

mmap を通じて、プロセスはハードディスクの読み取りと書き込みと同じようにメモリ (もちろん、仮想マシンのメモリ) の読み取りと書き込みを行います。仮想メモリがメモリのサイズをカバーするので、メモリのサイズを心配する必要はありません。

このアプローチを使用すると、ユーザー空間からカーネル空間へのコピーのオーバーヘッドを排除することで、大幅な I/O の改善を実現できます。 (ファイルの Read を呼び出すと、まずデータがカーネル空間メモリに格納され、次にユーザー空間メモリにコピーされます)

しかし、明らかな欠陥もあります。それは信頼性の低さです。 mmap に書き込まれたデータは、実際にはハードディスクに書き込まれません。オペレーティング システムは、プログラムがアクティブに Flush を呼び出したときにのみ、データをハード ディスクに書き込みます。

Kafka は、アクティブにフラッシュするかどうかを制御するためのパラメーター producer.type を提供します。

• Kafka が mmap に書き込んだ直後にフラッシュし、その後 Producer に戻る場合、同期 (Sync) と呼ばれます。
• Kafka が mmap に書き込んだ後、Flush を呼び出さずにすぐに Producer に戻る場合、非同期 (Async) と呼ばれます。

データの読み取り

Kafka はディスクの読み取り時にどのような最適化を行いますか?

Sendfile に基づくゼロコピーの実装

従来のモードでは、ファイルを転送する必要がある場合、具体的なプロセスの詳細は次のとおりです。

• Read 関数を呼び出すと、ファイル データがカーネル バッファーにコピーされます。
• Read 関数が戻り、ファイル データがカーネル バッファーからユーザー バッファーにコピーされます。
• 書き込み関数は、ファイル データをユーザー バッファーからソケットに関連付けられたカーネル バッファーにコピーするために呼び出されます。
• データはソケット バッファーから関連するプロトコル エンジンにコピーされます。

上記の詳細は、ネットワーク ファイル転送の従来の読み取り/書き込み方法です。このプロセスでは、ファイル データは実際に 4 つのコピー操作を受けることがわかります。

ハードディスク -> カーネルバッファ -> ユーザーバッファ -> ソケット関連バッファ -> プロトコルエンジン

Sendfile システム コールは、上記の複数のコピーを減らし、ファイル転送のパフォーマンスを向上させる方法を提供します。

カーネル バージョン 2.1 では、ネットワーク経由および 2 つのローカル ファイル間のデータ転送を簡素化するために Sendfile システム コールが導入されました。

Sendfile を導入すると、データのコピーが削減されるだけでなく、コンテキストの切り替えも削減されます。

 sendfile(ソケット、ファイル、長さ);

操作手順は以下のとおりです。

• Sendfile システム コールでは、ファイル データがカーネル バッファーにコピーされます。
• 次に、カーネル バッファーからカーネル内のソケット関連バッファーにコピーします。
• ***ソケット関連のバッファをプロトコル エンジンにコピーします。

従来の読み取り/書き込み方式と比較して、カーネル バージョン 2.1 で導入された Sendfile では、カーネル バッファーからユーザー バッファーへのファイル コピー、そしてユーザー バッファーからソケット関連バッファーへのファイル コピーが削減されました。

カーネル バージョン 2.4 以降では、ファイル記述子の構造が変更され、Sendfile がより単純な方法で実装されたため、コピー操作がさらに 1 つ削減されました。

Apache、Nginx、Lighttpd などの Web サーバーには、Sendfile 関連の設定があります。 Sendfile を使用すると、ファイル転送のパフォーマンスが大幅に向上します。

Kafka はすべてのメッセージを 1 つずつファイルに保存します。コンシューマーがデータを必要とする場合、Kafka はファイルの読み取りおよび書き込み方法として mmap を使用してファイルをコンシューマーに直接送信し、それを Sendfile に直接渡します。

バッチ圧縮

多くの場合、システムのボトルネックとなるのは CPU やディスクではなく、ネットワーク IO です。特に、広域ネットワークを介してデータセンター間でメッセージを送信する必要があるデータ パイプラインの場合はそうです。

データ圧縮は CPU リソースを少量消費しますが、Kafka の場合はネットワーク IO をより重視する必要があります。

• 各メッセージは圧縮されますが、圧縮率は比較的低いため、Kafka では各メッセージを個別に圧縮するのではなく、複数のメッセージをまとめて圧縮するバッチ圧縮を使用します。
• Kafka では再帰的なメッセージ集約が可能で、メッセージのバッチを圧縮形式で送信し、コンシューマーによって解凍されるまでログ内で圧縮されたままにすることができます。
• Kafka は、Gzip や Snappy 圧縮プロトコルを含む複数の圧縮プロトコルをサポートしています。

要約する

Kafka の速度の秘密は、すべてのメッセージをファイルのバッチに変換し、適切なバッチ圧縮を実行し、ネットワーク IO 損失を削減し、mmap を通じて I/O 速度を向上させることです。

データを書き込む場合、最後に 1 つのパーティションが追加されるため、速度が最も速くなります。データを読み込む際、Sendfileで強制的に直接出力します。