Kafka のパフォーマンス: Kafka がなぜ「高速」なのか?

[[388822]]

「Code Brother」による Redis シリーズの記事の 1 つ、「Redis Core: スピードの秘密」では、Redis のパフォーマンス最適化について詳しく説明しています。 Redis の「スピード」の内部秘密を、IO、スレッド、データ構造、エンコーディングなどの側面から深く分析します。 65番兄弟は深い感銘を受けました。 Kafka を学習する過程で、Kafka も優れたパフォーマンスを持つミドルウェアであることがわかりました。そこで彼は Brother Code に Kafka のパフォーマンス最適化について話すように依頼しました。そこで、ブラザーコードはこのパフォーマンスブログ投稿をカフカシリーズのオープニング作品として使うことにしました。

Kafka シリーズの記事をプレビューしますので、お楽しみに:

パフォーマンスについて説明することから、Kafka の旅を始めましょう。カフカの「スピード」の秘密を詳しく見てみましょう。 Kafka のパフォーマンス最適化のさまざまな手段を学習できるだけでなく、さまざまなパフォーマンス最適化方法論を抽出することもできます。これらの方法論は、私たち自身のプロジェクトにも適用でき、高性能なプロジェクトの作成に役立ちます。

関公 vs. 秦瓊

65: Redis と Kafka は機能が全く異なるミドルウェアです。それらは比較可能でしょうか?

「はい、この記事は「分散キャッシュの選択」や「分散ミドルウェアの比較」に関するものではありません。私たちは、これら 2 つの異なる分野のプロジェクトのパフォーマンス最適化に焦点を当て、優れたプロジェクトのパフォーマンス最適化の一般的な手段と、さまざまなシナリオの特別な最適化方法を検討します。

多くの人は多くのことを学び、多くのフレームワークを理解していますが、実際の問題に遭遇すると、知識が不足していると感じることがよくあります。これは、学習した知識が体系化されておらず、具体的な実装から効果的な方法論が抽出されていないことを意味します。

オープンソースプロジェクトを学習する上で非常に重要なポイントは、帰納法、つまりさまざまなプロジェクトの優れた実装を方法論にまとめ、それを自分の実践に適用することです。

冒頭挨拶

Ma Ge: 合理性、客観性、慎重さはプログラマーの特徴であり利点ですが、多くの場合、少し感情的かつ衝動的であることも必要であり、それによって意思決定を迅速化することができます。「悲観主義者は正しく、楽観主義者は成功する。」誰もが楽観的に問題を解決する人であることを願っています。

Kafka パフォーマンスの概要

非常に抽象的な観点から見ると、パフォーマンスの問題は次の 3 つのカテゴリに分類されます。

ネットワーク
ディスク
複雑

Kafka のようなネットワーク分散キューの場合、ネットワークとディスクが最適化の最優先事項となります。上記の抽象的な問題の場合、高い抽象度では解決策も非常に簡単です。

同時
圧縮
バッチ
キャッシュ
アルゴリズム

問題とアイデアがわかったところで、Kafka の役割を見てみましょう。これらの役割は最適化できるポイントです。

プロデューサー
ブローカ
消費者

はい、問題点、アイデア、最適化ポイントはすべてリストされています。これら 3 つの方向すべてにおいて、可能な限り改良することができます。この方法では、すべての実装が一目でわかります。 Kafka の実装を見なくても、最適化できる領域が 1 つまたは 2 つ考えられます。

それは考え方です。質問を提起 > 問題点をリストアップ > 最適化方法をリストアップ > 特定のエントリポイントをリストアップ > トレードオフと実装の改善。

これからは、最適化のポイントや方法を自分で考えてみるのも良いでしょう。完璧である必要はなく、実装が簡単かどうかを心配する必要もありません。ちょっとアイデアを考えてみましょう。

65 兄：いいえ、私はバカで怠け者です。直接私に伝えればいいですよ。私は無料でやる方が得意です。

「順番に書いてください」

Brother 65: Redis は純粋なメモリベースのシステムであり、Kafka もディスクの読み取りと書き込みを行う必要があります。どのように比較できるでしょうか?

ディスクへの書き込みが遅いのはなぜですか?

理由を知らずに結論だけを知ることはできません。この質問に答えるには、学校で学んだオペレーティングシステムの授業に戻る必要があります。 65 教科書はまだ持っていますか？さあ、ディスクの章に進み、ディスクの動作原理を確認しましょう。

65 兄：幽霊はまだそこにいるよ。コースが半分も終わらないうちに、その本はなくなってしまいました。試験中に視力が優れていなかったら、私はまだ卒業していなかったでしょう。

「古典的な写真をご覧ください:

ディスク IO を完了するには、シーク、回転、データ転送の 3 つのステップが必要です。

ディスク IO パフォーマンスに影響を与える要因は上記の 3 つのステップで発生するため、費やされる主な時間は次のとおりです。

シーク時間: Tseek は、読み取り/書き込みヘッドを正しいトラックに移動するために必要な時間を指します。シーク時間が短いほど、I/O 操作は高速になります。現在、ディスクの平均シーク時間は通常 3 ～ 15 ミリ秒です。
回転待ち時間: 回転とは、プラッターが回転し、要求されたデータを含むセクターを読み書きディスクの下部に移動するのに必要な時間を指します。回転遅延はディスクの速度に依存し、通常はディスクが 1 回転するのにかかる時間の 1/2 として表されます。たとえば、7200rpm ディスクの平均回転遅延は約 60*1000/7200/2 = 4.17ms ですが、15000rpm ディスクの平均回転遅延は 2ms です。
データ転送時間: Ttransfer は、要求されたデータの転送を完了するのに必要な時間を指します。これはデータ転送速度に依存し、その値はデータサイズをデータ転送速度で割った値に等しくなります。現在、IDE/ATA はインターフェースデータ転送速度 133MB/秒に達し、SATA II はインターフェースデータ転送速度 300MB/秒に達します。通常、データ転送時間は最初の 2 つの部分で消費される時間よりもはるかに短くなります。簡単な計算の場合は無視できます。

したがって、ディスクへの書き込み時にシークと回転を省略すると、ディスクの読み取りと書き込みのパフォーマンスが大幅に向上します。

Kafka は、ディスク書き込みパフォーマンスを向上させるために順次ファイル書き込みを使用します。ファイルを順番に書き込むと、ディスクのシークと回転の回数が大幅に減ります。磁気ヘッドはトラック上で動き回る必要がなくなり、高速で前進します。

Kafka の各パーティションは、順序付けられた不変のメッセージシーケンスです。新しいメッセージはパーティションの末尾に継続的に追加されます。 Kafka では、パーティションは単なる論理的な概念です。 Kafka はパーティションを複数のセグメントに分割します。各セグメントは物理ファイルに対応します。 Kafka は、順次ファイル書き込みであるセグメントファイルに追加します。

65 ブラザー：Kafka はなぜ追加書き込み方式を使用できるのですか？

「これは Kafka の性質に関係しています。Kafka と Redis を見てみましょう。簡単に言うと、Kafka は Queue であり、Redis は HashMap です。Queue と Map の違いは何でしょうか?

キューは FIFO であり、データは順序付けられます。 HashMap データは順序付けられておらず、ランダムに読み書きできます。 Kafka の不変性と秩序性により、Kafka は追加専用のアプローチを使用してファイルを書き込むことができます。

実際、上記の特性を満たす多くのデータシステムでは、追加書き込みを使用してディスクパフォーマンスを最適化できます。代表的な例としては、Redis の AOF ファイル、各種データベースの WAL (Write ahead log) メカニズムなどが挙げられます。

そのため、自社のビジネスの特性を明確に理解していれば、ターゲットを絞った最適化を行うことができます。

「ゼロコピー」

兄65: ハハ、インタビューでこれ聞かれたよ。答えが平均的なものなのは残念です。

ゼロコピーとは何ですか?

Kafka の観点から見ると、Kafka Consumer は Broker ディスクの読み取りからネットワーク経由で Consumer への送信まで、Broker ディスクに保存されているデータを消費し、そのプロセスにはどのようなシステムインタラクションが関係しているのでしょうか。 Kafka Consumer は Broker からデータを消費し、Broker は sendfile を使用してログを読み取ります。従来の IO モデルを使用する場合、疑似コードロジックは次のようになります。

ファイル読み込み(バッファ)
送信(バッファ)

図に示すように、従来の IO プロセスを使用すると、最初にネットワーク IO が読み取られ、次にディスク IO が書き込まれるため、実際にはデータを 4 回コピーする必要があります。

初回: ディスクファイルをオペレーティングシステムのカーネルバッファーに読み取ります。
2 回目: カーネルバッファー内のデータをアプリケーションバッファーにコピーします。
ステップ 3: アプリケーションバッファー内のデータをソケットネットワーク送信バッファーにコピーします。
4 回目: ソケットバッファー内のデータをネットワークカードにコピーし、ネットワーク経由でデータを送信します。

65 兄：ああ、オペレーティングシステムはそんなに愚かなのか？あちこちコピーするだけです。

「オペレーティングシステムが愚かなわけではありません。オペレーティングシステムは、各アプリケーションが独自のユーザーメモリを持つように設計されており、ユーザーメモリはカーネルメモリから分離されています。これは、プログラムとシステムのセキュリティのためです。そうしないと、各アプリケーションのメモリがあちこちに散らばってしまい、自由に読み書きできるようになります。

ただし、ゼロコピー技術、英語では Zero-Copy というものもあります。ゼロコピーとは、上記データのコピー回数を最小限に抑え、コピーの CPU オーバーヘッドとユーザーモードとカーネルモード間のコンテキスト切り替え回数を削減し、データ転送のパフォーマンスを最適化することを意味します。

ゼロコピーの一般的なアイデアは 3 つあります。

直接 I/O: データはカーネルを直接通過し、ユーザーアドレス空間と I/O デバイス間で転送されます。カーネルは、仮想ストレージの構成など、必要な補助作業のみを実行します。
カーネルとユーザー空間間のデータのコピーを回避する: アプリケーションがデータにアクセスする必要がない場合は、カーネル空間からユーザー空間へのデータのコピーを回避できます。
コピーオンライト: データを事前にコピーする必要はなく、変更が必要なときに部分的にのみコピーします。

Kafka は mmap と sendfile を使用してゼロコピーを実現します。それぞれ Java の MappedByteBuffer および FileChannel.transferTo に対応します。

ゼロコピーを実装するには、次のように Java NIO を使用します。

ファイルチャネル.transferTo()

このモデルでは、コンテキストスイッチの回数が 1 回に削減されます。具体的には、transferTo() メソッドは、DMA エンジンを介してブロックデバイスにデータを読み取りバッファに読み込むように指示します。このバッファは、ソケットへのステージングのために別のカーネルバッファにコピーされます。最後に、ソケットバッファーは DMA 経由で NIC バッファーにコピーされます。

レプリカの数を 4 個から 3 個に減らしましたが、これらのレプリカのうち CPU が関係するのは 1 個だけです。また、コンテキストスイッチの数も 4 から 2 に削減しました。これは大きな改善ですが、クエリゼロコピーはまだありません。後者は、Linux カーネル 2.4 以降と、収集操作をサポートするネットワークインターフェイスカードを実行している場合に、さらなる最適化として実装できます。下記の通りです。

前の例に基づいて、transferTo() メソッドを呼び出すと、デバイスは DMA エンジンを介してデータをカーネル読み取りバッファに読み取ります。ただし、収集操作を使用する場合、読み取りバッファとソケットバッファ間のコピーは行われません。代わりに、NIC には読み取りバッファへのポインタとオフセットおよび長さが与えられ、これは DMA によってクリアされます。 CPU はバッファのコピーにはまったく関与しません。

ゼロコピーの詳細については、この記事「ゼロコピーとそのアプリケーションの簡単な分析」をお読みください。

ページキャッシュ

プロデューサーがブローカーにメッセージを生成すると、ブローカーは pwrite() システムコール (Java NIO の FileChannel.write() API に対応) を使用して、オフセットに従ってデータを書き込みます。このとき、データはまずページキャッシュに書き込まれます。コンシューマーがメッセージを消費すると、ブローカーは sendfile() システムコール (FileChannel.transferTo() API に対応) を使用して、ページキャッシュからブローカーのソケットバッファーにデータをゼロコピーで転送し、ネットワーク経由で送信します。

リーダーとフォロワー間の同期は、上記のコンシューマーがデータを消費するプロセスに似ています。

カーネル内のフラッシャースレッドがスケジュールされ、sync()/fsync() が呼び出されると、ページキャッシュ内のデータがディスクに書き戻されます。プロセスがクラッシュしても、データの損失を心配する必要はありません。さらに、コンシューマーが消費したいメッセージがページキャッシュにない場合は、ディスクにアクセスしてメッセージを読み取り、隣接するブロックの一部を事前に読み取り、ページキャッシュに格納して次の読み取りを容易にします。

したがって、Kafka プロデューサーの生産率がコンシューマーの消費率とそれほど変わらない場合、ディスクアクセスをほとんど行わずに、ブローカーページキャッシュの読み取りと書き込みによって生産と消費のプロセス全体をほぼ完了できます。

ネットワークモデル

65 ブラザー：Javaプログラマーとしては、ネットワークは当然Nettyです。

「はい、Netty は JVM 分野の優れたネットワークフレームワークであり、高性能なネットワークサービスを提供します。ほとんどの Java プログラマーがネットワークフレームワークについて言及するとき、最初に思い浮かぶのは Netty です。Dubbo、Avro-RPC、その他の優れたフレームワークはすべて、基盤となるネットワーク通信フレームワークとして Netty を使用しています。

Kafka は RPC 用に独自のネットワークモデルを実装します。基礎となるレイヤーは Java NIO に基づいており、Netty と同じ Reactor スレッドモデルを使用します。

Reacotrモデルは主に3つの役割に分かれています

リアクター: IOイベントを対応するハンドラーに割り当てて処理します
アクセプタ: クライアント接続イベントを処理する
ハンドラ: 非ブロッキングタスクを処理する

従来のブロッキング IO モデルでは、各接続は独立したスレッドによって処理される必要があります。同時接続数が多いと、多くのスレッドが作成され、リソースが消費されます。ブロッキング IO モデルでは、接続が確立された後、現在のスレッドに読み取るデータがない場合、スレッドは読み取り操作でブロックされ、リソースが無駄になります。

従来のブロッキング IO モデルの 2 つの問題に対応するため、Reactor モデルはプーリングの考え方に基づいており、接続ごとにスレッドを作成することを回避します。接続が完了すると、ビジネス処理はスレッドプールに引き渡されます。 IO 再利用モデルに基づいて、すべての接続を待たずに、複数の接続が同じブロッキングオブジェクトを共有します。処理すべき新しいデータがある場合、オペレーティングシステムはプログラムに通知し、スレッドはブロッキング状態から抜け出し、ビジネスロジック処理を実行します。

Kafka は、Reactor モデルに基づいて多重化および処理スレッドプールを実装します。そのデザインは次のとおりです。

新しい接続を処理するための Acceptor スレッドが含まれています。アクセプターには、ソケット要求を選択して読み取る N 個のプロセッサスレッドと、要求を処理して応答する、つまりビジネスロジックを処理する N 個のハンドラースレッドがあります。

I/O 多重化により、複数の I/O ブロッキングを同じ選択ブロッキングに多重化できるため、システムはシングルスレッドの場合に複数のクライアント要求を同時に処理できます。その最大の利点は、システムのオーバーヘッドが低く、新しいプロセスやスレッドを作成する必要がないため、システムリソースのオーバーヘッドが削減されることです。

概要: Kafka Broker の KafkaServer 設計は、優れたネットワークアーキテクチャです。 Java ネットワークプログラミングについて学習したい、またはこのテクノロジを使用する必要がある学生は、ソースコードを読むことをお勧めします。「Code Brother」による今後の Kafka シリーズの記事でも、このソースコードの解釈について説明します。

バッチ処理と圧縮

Kafka プロデューサーはブローカーにメッセージを 1 つずつ送信しません。 Kafka を使用したことがある学生は、Producer に batch.size と linger.ms という 2 つの重要なパラメーターがあることを知っておく必要があります。これら 2 つのパラメーターは、プロデューサーのバッチ送信に関連しています。

Kafka Producer の実行プロセスを次の図に示します。

メッセージの送信は、次のプロセッサを順番に通過します。

シリアル化: キーと値の両方が、渡されたシリアライザーに従ってシリアル化されます。優れたシリアル化方法により、ネットワーク伝送の効率が向上します。
パーティション: デフォルトでは murmur2 アルゴリズムに従って、メッセージが書き込まれるトピックのパーティションを決定します。カスタムパーティショナーをプロデューサーに渡して、メッセージを書き込むパーティションを制御することもできます。
圧縮: デフォルトでは、Kafka プロデューサーでは圧縮は有効になっていません。圧縮により、プロデューサーからブローカーへの転送が高速化されるだけでなく、レプリケーション中の転送も高速化されます。圧縮により、スループットが向上し、待ち時間が短縮され、ディスク使用率が向上します。
蓄積: 蓄積は、その名前が示すように、メッセージを蓄積する機能です。各パーティションに対して Deque 両端キューを維持します。キューには送信するバッチデータが格納されます。蓄積は、データを一定の量まで蓄積するか、一定の有効期限内にデータをバッチで送信します。レコードはトピックのパーティションごとにバッファーに蓄積されます。プロデューサーのバッチサイズ属性に基づいてレコードをグループにグループ化します。トピック内の各パーティションには個別のアキュムレータ/バッファがあります。
グループ送信: レコードアキュムレータ内のパーティションのバッチは、送信先のエージェントごとにグループ化されます。バッチ内のレコードは、batch.size および linger.ms プロパティに基づいてブローカーに送信されます。レコードは、2 つの条件に基づいてプロデューサーによって送信されます。定義されたバッチサイズに達したとき、または定義された遅延時間に達したとき。

Kafka は、lz4、snappy、gzip など複数の圧縮アルゴリズムをサポートしています。 Kafka 2.1.0 は ZStandard を正式にサポートします - ZStandard は Facebook のオープンソース圧縮アルゴリズムで、超高圧縮率 (圧縮率) を提供するように設計されています。詳細については、zstd を参照してください。

プロデューサー、ブローカー、コンシューマーは同じ圧縮アルゴリズムを使用します。プロデューサーがブローカーにデータを書き込み、コンシューマーがブローカーからデータを読み取る場合、データを解凍する必要すらありません。最後に、コンシューマーがメッセージをポーリングするときにデータが解凍されるため、ネットワークとディスクのオーバーヘッドが大幅に削減されます。

パーティションの同時実行

Kafka のトピックは複数のパーティションに分割でき、各パーティションはデータの順序を保証するキューに似ています。同じグループ内の異なるコンシューマーが同時にパーティションを消費します。パーティションは、実際には Kafka の並列処理を調整するための最小単位です。したがって、パーティションを追加するごとに消費の同時実行性が増加すると言えます。

Kafka には優れたパーティション割り当てアルゴリズムである StickyAssignor があり、これによりパーティション割り当てが可能な限りバランスが取れ、各再配分の結果が以前の割り当て結果と可能な限り一致することが保証されます。この方法では、クラスター全体のパーティションが可能な限りバランスが取れており、各ブローカーとコンシューマーの処理が過度に偏ることがなくなります。

65 兄弟: では、パーティションの数が多いほど良いということですか?

"もちろん違います。

パーティションが増えると、開くファイルハンドルも増えます

Kafka ブローカーでは、各パーティションはファイルシステム内のディレクトリに対応します。 Kafka データログファイルディレクトリでは、各ログデータセグメントにインデックスファイルとデータファイルの 2 つのファイルが割り当てられます。したがって、パーティションの数が増えると、必要なファイルハンドルの数が大幅に増加するため、必要に応じて、オペレーティングシステムで開くことができるファイルハンドルの数を調整する必要があります。

クライアント/サーバーが使用するメモリが増える

クライアントプロデューサーには batch.size というパラメーターがあり、デフォルトは 16 KB です。各パーティションのメッセージをキャッシュし、いっぱいになったらバッチで送信します。これはパフォーマンスを向上できる設計のようです。ただし、このパラメータはパーティションレベルであるため、パーティションの数が増えるほど、キャッシュのこの部分に必要なメモリも増えることは明らかです。

高可用性の削減

パーティションの数が多いほど、各ブローカーに割り当てられるパーティションの数も多くなります。ブローカーがダウンすると、回復時間が非常に長くなります。

ファイル構造 Kafka メッセージはトピックによって分類されます。各トピックは互いに独立しており、相互に影響を与えません。各トピックは 1 つ以上のパーティションに分割できます。各パーティションには、メッセージデータを記録するログファイルがあります。

Kafka の各パーティションログは、サイズに応じて物理的に複数のセグメントに分割されます。

セグメントファイルの構成: インデックスファイルとデータファイルという 2 つの主要部分で構成されます。これら 2 つのファイルは互いに 1 つずつ対応しており、ペアで表示されます。サフィックス「.index」と「.log」は、それぞれセグメントインデックスファイルとデータファイルを表します。
セグメントファイルの命名規則: グローバルパーティションの最初のセグメントは 0 から始まり、後続の各セグメントファイル名は、前のセグメントファイルの最後のメッセージのオフセット値になります。最大値は 64 ビット長、19 桁で、0 で埋められていない桁です。

インデックスはスパースインデックスを使用するため、各インデックスファイルのサイズは制限されます。 Kafka は mmap を使用してインデックスファイルをメモリに直接マップするため、インデックスの操作にディスク IO は必要ありません。 mmap の Java 実装は MappedByteBuffer に対応します。

65 兄弟のメモ: mmap はメモリマッピングファイルの方法です。つまり、ファイルまたはその他のオブジェクトがプロセスのアドレス空間にマッピングされ、ファイルのディスクアドレスとプロセス仮想アドレス空間内の仮想アドレスの間に 1 対 1 のマッピング関係が実現されます。このようなマッピング関係を実装すると、プロセスはポインターを使用してこのメモリセクションの読み取りと書き込みを行うことができ、システムはダーティページを対応するファイルディスクに自動的に書き戻すため、読み取りや書き込みなどのシステムコール関数を呼び出さずにファイル操作が完了します。逆に、カーネル空間によってこの領域に加えられた変更はユーザー空間にも直接反映されるため、異なるプロセス間でのファイル共有が可能になります。

Kafka はバイナリ検索を最大限に活用して、オフセットに対応するメッセージの位置を見つけます。