Kafkaの独創的な高性能設計の1つ

[[420235]]

これは、Kafka に関するシリーズ「Mastering MQ」の 4 番目の記事です。最初の 3 つの記事を見逃した場合は、次のリンクからご覧いただけます。

パート1：カフカの謎を解く

パート 2: Kafka アーキテクチャ設計の Ren 子午線と Du 子午線

パート 3: Kafka ストレージ選択の秘密

第3回では、Kafkaがストレージソリューションとして「ログファイル」を選択した理由と、その背景にある「ディスクシーケンシャル書き込み＋スパースインデックス」という独創的な設計思想を深く分析しました。

ただし、Kafka は単一のマシンで毎秒数十万のスループットを達成でき、そのパフォーマンス最適化方法はそれをはるかに上回ります。

Kafka の高性能設計は包括的であると言えます。プロデューサーからブローカー、そしてコンシューマーに至るまで、Kafka はあらゆる細部を最適化するために多大な考慮を払い、最終的にこのような極めて優れたパフォーマンスを実現しました。

この記事では、まず高パフォーマンス設計の考え方を確立できるように支援し、次に Kafka の高パフォーマンス設計ソリューションを詳しく見ていきたいと思います。最終的には、すべての知識ポイントをより体系的に把握し、その設計哲学を理解していただければ幸いです。

1. 高性能設計を理解するにはどうすればよいでしょうか?

とりあえず Kafka を脇に置いて、高パフォーマンス設計の本質を理解してみましょう。

高並行性開発の経験を持つ学生は、スレッドプール、マルチレベルキャッシュ、IO 多重化、ゼロコピーなどの技術的な概念にすでに精通しています。しかし、これらの技術的手段の本質は何でしょうか?

これは実際には体系的な問題です。少なくとも、CPU とストレージから始めてオペレーティングシステムレベルまで深く掘り下げて、基礎となる実装メカニズムを理解し、それを下から上へとレイヤーごとに解読して接続する必要があります。

しかし、より高い視点から見ると、高性能設計は常に「コンピューティングと IO」の原則に基づいて、可能な最適化ポイントを考慮する必要があると思います。

「コンピューティング」次元のパフォーマンス最適化方法は何ですか?方法は2つしかありません:

1. より多くのコアがコンピューティングに参加できるようにします。たとえば、シングルスレッドの代わりにマルチスレッドを使用したり、単一のマシンの代わりにクラスターを使用したりします。

2. 計算量を削減します。たとえば、グローバルスキャンの代わりにインデックスを使用したり、非同期ではなく同期を使用したり、トラフィックのフローを制限して要求処理の量を減らしたり、より効率的なデータ構造とアルゴリズムを採用したりします。

「IO」次元におけるパフォーマンス最適化の方法を見てみましょう。思考を助けるために、Linux システムの IO スタック図を使用できます。

図1: LinuxシステムのIOスタック図

ご覧のとおり、IO アーキテクチャ全体が階層化されています。アプリケーション、オペレーティングシステム、ディスクなど、さまざまなレベルからパフォーマンスの最適化を検討できます。これらすべての対策は、ほぼ次の 2 つの側面に集中しています。

1. IO を高速化します。たとえば、ランダム書き込みの代わりにディスクのシーケンシャル書き込みを使用する、BIO の代わりに NIO を使用する、機械式ハードディスクの代わりにパフォーマンスの優れた SSD を使用するなどです。

2. IO 操作の数または IO データの量を削減します。たとえば、システムキャッシュまたは外部キャッシュを使用し、ゼロコピーテクノロジを使用して IO コピーの数を減らし、バッチ読み取りと書き込み、およびデータ圧縮を行います。

以上の内容は、高性能設計の「道」として理解することができます。もちろん、数百語で明確に説明することはできません。私はむしろ出発点であり、別の観点から高並行性を検討し、特定の方向に向けて全員に何らかのガイダンスを提供します。

誰もが「コンピューティングと IO」という 2 つの最も重要な点を理解し、これら 2 つのポイントを基礎としてとらえると、これら 2 つの次元でどのようなパフォーマンス最適化手法が存在するかを検討できるようになります。彼らの原則は何ですか?そうすることで、高性能設計の謎を層ごとに解き明かし、信頼できる知識体系を形成できます。

この分析方法は、Kafka だけでなく、Redis、ES など、私たちがよく知っている他の高性能アプリケーションシステムの研究にも使用できます。

2. Kafka の高性能設計の概要

高性能設計の考え方を念頭に置いて、Kafka 自体に戻って分析してみましょう。

前述したように、Kafka には少なくとも 10 の独創的な設計による幅広いパフォーマンス最適化手法があります。これらのメソッドはコンピューティングと IO という 2 つの次元から関連付けることができますが、すべてを覚えておくのは簡単な作業ではないようです。

これは別のトピックにつながります。これらの最適化手法を接続するには、どのようなコンテキストを選択すればよいのでしょうか。

前の記事で分析したように、Kafka、RocketMQ、その他のメッセージキューの本質は、「1 つの送信、1 つの保存、1 つの消費」です。

このメインラインに完全に従って構造化ソートを行うことができます。この考えに基づいて、Kafka の高性能設計の次のような全体像が形成されました。 Kafka の代表的な 12 のパフォーマンス最適化手法を、メッセージの生成、メッセージの保存、メッセージの消費という 3 つのモジュールに従って分類しました。

図2: Kafkaの高性能設計の概要

このパノラマ画像を使って、各メソッドの背後にある一般原則を一つずつ分析し、カフカの設計哲学を解釈してみたいと思います。

III.メッセージ生成のパフォーマンス最適化方法

まずは制作メッセージから始めましょう。以下はプロデューサー側が使用する 4 つの最適化対策です。

1. メッセージを一括送信する

メッセージキューとして、Kafka は明らかに IO 集約型のアプリケーションです。ディスク IO (ブローカーはメッセージを永続化する必要がある) に加えて、ネットワーク IO (プロデューサーからブローカー、ブローカーからコンシューマー、すべてがネットワーク経由でメッセージを送信する必要がある) にも直面します。

前の記事で指摘したように、ディスクのシーケンシャル IO の速度は実際には非常に高速であり、ランダムメモリの読み取りと書き込みに劣りません。このように、ネットワーク IO は Kafka のパフォーマンスのボトルネックになります。

このような背景から、Kafka ではメッセージをバッチで送信する方法を採用しています。複数のメッセージをパーティションごとにグループ化し、メッセージセットを一度に送信するため、ネットワーク転送のオーバーヘッドが大幅に削減されます。

これは一般的な方法のように思えるかもしれませんが、実際には Kafka のスループットが大幅に向上します。そして、その繊細さはそれをはるかに超えています。以下の最適化手法はこれに密接に関連しています。

2. メッセージの圧縮

メッセージ圧縮の目的は、ネットワーク伝送帯域幅をさらに削減することです。圧縮アルゴリズムに関しては、一般的に、データ量が多いほど、圧縮効果は高くなります。

初期段階でのバッチ送信により、Kafka のメッセージ圧縮メカニズムが真価を発揮します (圧縮の本質は、複数のメッセージの繰り返し性に依存します)。単一のメッセージを圧縮する場合と比較して、複数のメッセージを同時に圧縮すると、データ量が大幅に削減され、ネットワークの伝送速度が大幅に向上します。

この記事では、Kafka でサポートされている 3 つの圧縮アルゴリズム (gzip、snappy、lz4) のパフォーマンスを比較します。 20,000 件のメッセージのテスト結果は次のとおりです。

図3: 圧縮効果の比較、出典: https://www.jianshu.com/p/d69e27749b00

全体的に、gzip は圧縮効果が最も高くなりますが、生成に時間がかかります。総合的に比較すると、lz4 が最高のパフォーマンスを発揮します。

実際、メッセージを圧縮すると、ネットワーク IO が削減されるだけでなく、ディスク IO も大幅に削減されます。バッチメッセージはブローカーのディスクに保存されるときに圧縮されたままなので、最終的にはコンシューマー側で解凍されます。

このエンドツーエンドの圧縮設計は実は非常に巧妙で、ディスクへの書き込みの効率が大幅に向上します。

3. 効率的なシリアル化

Kafka メッセージのキーと値はどちらもカスタムタイプをサポートします。対応するシリアライザーとデシリアライザーを提供するだけで済みます。そのため、ユーザーは実際の状況に応じて高速かつコンパクトなシリアル化方式（ProtoBuf、Avro など）を選択して、実際のネットワーク伝送量とディスクストレージ量を削減し、スループットをさらに向上させることができます。

4. メモリプールの再利用

前述のように、プロデューサーはメッセージをバッチで送信するため、メッセージはまずプロデューサーのメモリに書き込まれ、バッファリングされます。複数のメッセージがバッチを形成する場合、バッチはネットワークを介してブローカーに送信されます。

バッチが送信された後も、データのこの部分はプロデューサーの JVM メモリ内に残ります。参照がないので、JVM によってリサイクルできます。

しかし、JVM GC 中に Stop The World プロセスが必ず発生することは誰もが知っています。最も高度なガベージコレクターを使用した場合でも、作業スレッドが一時的に停止することは避けられず、Kafka などの同時実行性の高いシナリオではパフォーマンスに確実に影響します。

このような背景から、Kafka の優れたメモリプールメカニズムを紹介します。その本質は接続プールやスレッドプールと同じで、再利用性を向上させ、頻繁な作成と解放を減らすことです。

具体的にはどのように実装されるのでしょうか?実際、それは非常に単純です。プロデューサーは 64 MB などの固定サイズのメモリブロックを占有し、その 64 MB を M 個の小さなメモリブロックに分割します (たとえば、小さなメモリブロックのサイズは 16 KB です)。

新しいバッチを作成する必要がある場合、メモリプールから 16 KB のメモリブロックを直接取り出し、そこにメッセージを継続的に書き込むことができますが、最大書き込み量は 16 KB です。その後、バッチはブローカーに送信されます。このとき、メモリブロックはバッファプールに戻されて再利用を継続することができ、ガベージコレクションはまったく行われません。最終的なプロセスを下の図に示します。

図4: Kafka 送信プロセス

プロデューサー側の上記の 4 つの高性能設計を理解した後、誰もが疑問に思うはずです。従来のデータベースやメッセージミドルウェアは、クライアントを軽量化し、サーバーを重量級に設計し、クライアントをアプリケーションとサーバー間のインターフェイスとしてのみ機能させようとしています。

しかし、Kafka は逆のアプローチを取り、独自の設計アプローチを採用しています。ブローカーにメッセージを送信する前に、メッセージパーティションのルーティング、チェックサムの計算、メッセージの圧縮など、クライアント側で多くの作業を行う必要があります。これにより、ブローカーの計算負荷が効果的に分散されます。

最良のデザインは存在せず、最も適したデザインだけが存在することが建築の原点であることがわかります。