【译】カフカプロデューサースティッキーパーティション分割

最近、多くのこと少し怠惰な、まだ持っ翻訳：Apacheのカフカはスティッキーパーティショナでプロデューサーの改善と一緒に暮らすために使用

システム時間のメッセージ・フローは、カフカの性能にとって重要です。メッセージ間カフカプロデューサー応答間隔にメッセージを送信：プロデューサに特にに関して、プロデューサエンド遅延（レイテンシ）は、通常のように定義されます。諺にように、時間はお金です。我々は常に、可能な限り遅延を低減システムがより速く実行できるようにしたいです。メッセージが速い生産スピードで送信した場合、システム全体が恩恵を受けることができます。

各カフカのトピックは、複数のパーティションを含んでいます。プロデューサーは、トピックにメッセージを送信すると、それは最初にどのパーティションに送信されるように、このメッセージを確認する必要があります。同時にパーティションが、我々は同じに複数のメッセージを送信する場合、そのプロデューサーは、バルク包装（バッチ）が送信中にこれらのメッセージを使用することができます。バッチ処理のオーバーヘッドがあります。この1では、バッチそれぞれのメッセージは、彼らの「力」を貢献していきますバッチは、オーバーヘッドに小さな、その後、メッセージのバッチ大きい貢献である場合。一般的に言って、プロデューサーの原因となりますバッチの小端部は、それによって全体的な待ち時間を押し上げ、より深刻な影響キューバックログ（キューイング）を引き起こし、より多くの要求を生成します。

バッチサイズが閾値（batch.size）又は時間バッチ蓄積メッセージに達したときにバッチが「完成」又はlinger.msとみなされる超え「READY」プロデューサーとlinger.msのbatch.sizeパラメータが終了しています。linger.msデフォルト値は0ミリ秒である一方、batch.sizeのデフォルトは、16キロバイトです。値または交差linger.ms batch.size時間と、システムはすぐにバッチを送信します。

一見すると、セットlinger.ms = 0のみ可能性の高いバッチにつながることが1つのメッセージのみが含まれています。しかし、それは実際にはそうではありません。linger.ms = 0であっても、プロデューサー複数のメッセージはまだ限り、彼らは非常に短い期間で生産され、同じパーティションのために運命づけられているように、バッチにパッケージ化されます。システムは、各PRODUCE要求を処理するためにいくつかの時間がかかりますが、システムがすべてのメッセージを処理できないと、それがバッチ内部にそれらを置くためです。

バッチ分割戦略（分割戦略）を形成する方法を決定する際の因子。複数のメッセージが同じパーティションに送信されない場合は、中のバッチに入れることはできません。幸い、カフカは、ユーザーがパーティショナ実装クラスによって提供された適切なパーティション計画を選択することができます。パーティショナインタフェースは、メッセージごとにパーティションを割り当てる責任があります。デフォルトのポリシーは、先のパーティションのキーメッセージをハッシュ化されますが、何回もメッセージが（nullにまたはキー）キーを指定されていません。このとき、Apacheのカフカのデフォルトポリシーは、メッセージはラウンドロビン方式で各パーティションに送られ、2.4以前のテーマにすべてのパーティションを再利用されます。残念ながら、この戦略は、遅延が増加します実際の使用で、非常に悪いのパッケージです。

メッセージがキーパーティション化戦略の効率は非常に低く、前に与えられた小さなバッチが増加遅延につながる可能性があります。バージョンにおけるコミュニティ2.4紹介スティッキーパーティション化戦略（スティッキー・パーティション化戦略）。戦略は大幅に遅延の間に指定されたパーティションへのメッセージを減らすことができ、新たな戦略です。

スティッキー分割戦略

粘性パーティ（スティッキーパーティション分割）小ロット分散問題へのキーメッセージのないソリューションの主なアイデアは、すべての非キーメッセージを送信する単一のパーティションを選択することです。バッチがいっぱいになるか、「完了」状態のパーティションは、粘着性のパーティションは、ランダムに別のパーティションを選択し、パーティションに固執しようとしたら - いわゆるスティックをこのパーティションに。我々は全体の実行時間を伸ばしたら、プロデューサーでも遅延を低減しながら、割り当てプロセスは、常に大量のバッチの形成を確保することであったので、この方法では、メッセージがではなく、回避の傾きに各パーティション、パーティションに均等に投稿されました小ロット。簡単に言えば、以下のようにプロセス：

このパーティションは、粘着性を達成するために、カフカ2.4バージョンパーティション分割インターフェースはonNewBatchと呼ばれるメソッドを追加しました。このメソッドを使用すると、パーティションのプロデューサーを変更したいときに粘着性である新しいバッチで作成された前任者が呼び出されます（スティッキーパーティション）があります。プロデューサーのデフォルトのパーティションはDefaultPartitionerは、この機能を実現します。

基本的なテスト：プロデューサーエンド遅延

パフォーマンスの改善が効果を定量化することでなければなりません。（：公式サイトほとんどTrogdorの説明、私は下のブログのプレゼンテーションを書き込むための時間を持っている翻訳）テストプロデューサーエンド遅延を含む、基本的なテストの様々なを実行するために使用カフカはTrogdorの者と呼ばれるテストフレームワークを提供します。私はProduceBenchテストを実行するために城と呼ばれるテストスイートを使用していました。これらのテストは、プログラムで3一緒に3ブローカー、プロデューサー1のクラスタ上で実行されています。

次のパラメータを使用したテストのほとんど。あなたは、コンフィギュレーション城を変更するデフォルトのタスクのパラメータを置き換えることができます。いくつかのテストがわずかに異なる提供され、後者は明示的に言及されます。

テストの期間	12分
ブローカーの数	3
生産者の数	1-3
複製因子	3
トピック	4
`linger.ms`	0
`acks`	`all`
`keyGenerator`	`{"type":"null"}`
`useConfiguredPartitioner`	`true`
スロットルには紅潮しません（`skipFlush`）	`true`

最高のテスト結果を得るために、我々は、trueにuseConfiguredPartitionerとskipFlushを設定する必要があります。これはプロデューサーの使用DefaultPartitionerが分割戦略を実行していることを確認し、決定するbatch.sizeとlinger.msパラメータにバッチを送信するかどうかでしょう。もちろん、あなたは確かにnullにするKeyGeneratorセットにしたいないので、何のニュースキー。

前回の無修正DefaultPartitionerの重量と比較して、ほとんどのテストでは、遅延は、以前のバージョンよりも低かったことを示しています。遅延は、新しいテスト結果を用いて、毎秒1000件のメッセージの割合でパーティション16に関連するプロデューサー3にメッセージを送信することを値パーセンタイル99を比較する場合は特に示しているプロデューサーの前にパーティ遅延の粘度半分の。次のようにテスト結果は以下のとおりです。

パーティションの数としては、遅延効果がより顕著に減少しています。小ロット性能のかなりの数の構造よりも大きなバッチ構造の数が少ない：これが私たちの以前の憶測と一致しています。我々のテストでは、16本差にパーティションの数は明らかにされています。

次のテストは不変プロデューサ側の負荷を維持するが、パーティションの数を増加します。16、64および128パーティションの試験結果を次の図に示すように、結果は、パーティションの数が急速に低下するように前に遅延分割戦略。でも、パーティション16、99パーセンタイル遅延の平均値は、パーティのさらに1.5倍の粘度があります。

Linger.msキー・パフォーマンス・テストや各種メッセージ

前述したように、待機中のlinger.msは人為的に遅延を増加させます。粘性の目標は、この遅延のパーティションを防止し、具体的なアプローチは、すべてのメッセージがバッチに送信されます置くことで、より高速なバッチを埋めます。0より粘性linger.ms値より大きいと一緒に使用パーティが著しく比較的低いスループット環境での待ち時間を低減することができます。linger.ms = 1000は、遅延のパーティション分割戦略の99のパーセンタイル値の結果は、前五倍の増加を示しながら、私たちのプロデューサーテストは、毎秒1000件のメッセージを送信するプログラムを開始しました。ショーテストの結果下図ProduceBench：

送信がキーメッセージのプロデューサーでない場合は、パーティの粘度は、効果的にクライアントのパフォーマンスを向上させることができます。同時にプロデューサーがメッセージを送信し、何のキーキーメッセージがない場合、パフォーマンスがどのようにでしょうか？私たちは、ランダムにいくつかの非主要なメッセージと混合し、同時にメッセージにキーを生成し、テストを実行し、結果はこの指標の遅れに有意な差は認められませんでした。

このテストシナリオでは、私は、混合メッセージはキーとキーの自由を持ってチェックしました。これは、パック良く見えますが、キー値はスティッキーパーティを無視し、その収入は明白ではありませんので。図に示すの中央値は3の結果は、遅延値パーセンタイル99で実行されます。テスト結果から、遅延には有意な変化がなかったので、中央値は、効果的に典型的なテストの実行結果を特徴付けることが可能です。

ランダムハイスループットで生成された第2テストシナリオキー。パーティションの実現は少し粘着性のコードの変更を必要とするので、私たちは、新たな増加はロジック遅延に影響を与えないことを保証しなければなりません。そしてそこでそこにパックする必要はありませんか粘性挙動はほとんど現れ遅延を検索し、結果の前に正常です。以下に示すように、ランダムなテストの主な中央値の結果。

シーケンシャルキー+スーパーマルチパーティションのシナリオ - 最後に、私が使用スティッキーパーティションのシーンのために最も適さないテストと思います。新しいロジックが新しいバッチが作成され、主に発生し、このシーンは、ほぼ各メッセージのバッチを作成しているので、私たちは、この遅延はプッシュしませんチェックする必要があるため。下に示すような結果は、遅延に有意な差を示しません。

テスト中のCPU使用率

テスト中に、我々は、パーティションが粘り対策CPUの使用率を低減することが可能であることに気づきました。

3人のプロデューサーは毎秒万のメッセージの割合でパーティション16にメッセージを送信する際に、例えば、我々は有意な減少のCPU使用率を観察しました。2つの図は、ノードの各列のためのCPU使用率を表します。各ノードは、両方のプログラムがプロデューサーブローカープロセスを実行して実行します。すべてのノード線は重なっています。スループット向上とテストシナリオのパーティションの数を減少させ、我々はまた、CPUの減少を観察しました。

概要

粘性パーティの主な目的は、不要な待ち時間を排除する、バッチの総数を減らすために、バッチあたりのメッセージの数を増加させることです。メッセージ増加するバッチは、バッチの数が少なくなると、メッセージあたりのコストが低減されます。粘着性のパーティション化戦略を使用してより高速なメッセージを送ることができます。テストデータは、この戦略は確かに遅れがキーメッセージではなく、パーティションの数は、効果がより顕著に向上させる際に減らすことができることを実証しました。加えて、粘着性の分割戦略の使用は、通常、CPUの使用量を減少させます。プロデューサーのパーティションを「スタック」と効果的に伝送性能を向上させることが可能プロデューサー、少数の大規模なバッチ方式を送信します。

一方、クールな事は次のとおりです。デフォルトでこの粘着性のパーティションは、箱から出して、追加設定なしでバージョン2.4に統合します！