Kafka で適切なパーティション数を選択するにはどうすればよいでしょうか?正しいものを選びましたか?

[[336169]]

この記事はWeChatの公開アカウント「Porter to Architecture」から転載したもので、著者はcocodroidです。この記事を転載する場合は、公開アカウントを構成するポーターに連絡してください。

トピックにいくつのパーティションを設定すべきかという問題に直面することがよくありますが、どのように設定するか、どのように評価するかがわからない場合があります。あるいは、現在の Kafka クラスターの特定のビジネス トピックにはパーティションがいくつあるのか、必要なパーティションの数を知るにはどうすればよいのか、より適切なパーティションの数を選択するにはどうすればよいのか、といった質問をされるかもしれません。

1. ビジネスシナリオと非ビジネス条件を組み合わせる

では、適切なパーティション数をどのように選択すればよいのでしょうか?

特定のビジネスに関する具体的な分析。

ただし、初期段階では、実際のビジネス シナリオ (メッセージの総数、メッセージの生成または消費の頻度、必要なスループットなど)、ソフトウェア条件、ハードウェア条件、負荷条件などの条件に基づいて、トピックに設定できるパーティションの数を大まかに評価できます。

2. ストレステストツールを使用して最適なパーティション数を見つける

Kafka は、Kafka クラスターをテストするためのスクリプトも公式に提供しています。現在提供されているハードウェア条件をストレス テスト用にテストして、現在のマシン環境でサポートできるパーティションの数を調べ、可能な限り最適なソリューションを実現できます。

プロデューサーパフォーマンステストスクリプト: kafka-producer-perf-test.sh

コンシューマーパフォーマンステストスクリプト: kafka-consumer-perf-test.sh

トピックのパーティション数を設定した後、送信されるメッセージの合計数、単一メッセージのサイズ、スループット、ACK、コンシューマー スレッドの数など、さまざまなパラメータを選択できます。ストレス テストの後、テスト レポートを取得できます。レポートには、50%/90%/95%/99% のメッセージ処理時間、平均処理時間、1 秒あたりのメッセージ送信スループット、1 秒あたりにプルされるメッセージのバイト サイズ/数、消費量の合計、再バランス時間、メッセージ数/メッセージ サイズで計算されたスループットなどのデータが含まれます。

パーティション数を適切に増やすとスループットが向上しますが、一定のしきい値を超えるとスループットも低下します。運用環境でスループットに関して特定の要件がある場合は、運用マシンのハードウェア条件下でストレス テストを実行し、最適なパーティション数を決定できます。

3. スループットの向上は必ずしもパーティションの数に関係するわけではない

Kafka プロデューサーの場合、各パーティションへのデータの書き込みは並列で実行できます。 Kafka コンシューマーの場合、各パーティションは 1 つのコンシューマー スレッドによってのみ消費されるため、コンシューマー グループの消費の並列性はパーティションの数によって異なります。理論的には、パーティションの数が多いほど、スループットが高くなるようです。

しかし、これは本当にそうなのでしょうか?

メッセージ ミドルウェア Kafka のスループットはパーティションにのみ関係するわけではありません。

メッセージの書き込み (生成) のスループットは、メッセージ サイズ、メッセージの圧縮方法、メッセージの送信方法 (同期または非同期)、メッセージ確認タイプ ack、レプリケーション係数などに関係します。

同様に、メッセージ消費のスループットは、ビジネス ロジックなどの消費速度に関係します。

4. パーティションの数はオペレーティングシステムに関係します

パーティションはファイル記述子を占有し、プロセスで使用できるファイル記述子は限られているため、パーティションの数を無制限に増やすことはできません。

一般的に、比較的多数のパーティションを設定する場合は、システムの最大の記述子ファイルを超えていないかどうかに特に注意する必要があります。これはシステム構成を変更することで実現できますが、ファイル ハンドルにもオーバーヘッドがあるため、できる限り避ける必要があります。

5. メッセージ書き込みパーティション戦略に注意する

消費がどのパーティションに書き込まれるかがわかります。デフォルトでは、または場合によっては、書き込むパーティションはキーに基づいて計算されます。このとき、キーと強く関連付けられているアプリケーションが使用シナリオに影響を与えるかどうかを考慮する必要があります。

たとえば、一部のアプリケーション シナリオでは、特定のパーティション内のメッセージのみを順序付けることが必要になる場合があります。パーティションの数を調整すると、この使用シナリオに影響が出る可能性があります。

したがって、私たちは通常、今後 2 年以内に目標スループットを満たすために、より適切な数のパーティションを構成するように努めます。

アプリケーションがキーと弱く関連付けられていれば、実際の状況に基づいて将来的にパーティションの数を増やすことができます。

6. パーティションの数はシステムの可用性に影響します

Kafka は、マルチコピー メカニズムを通じてクラスターの高可用性と高信頼性を実現します。各パーティションには少なくとも 1 つ以上のコピーがあり、各コピーは異なるブローカー ノードに存在し、リーダー コピーのみが外部にサービスを提供します。

Kafka クラスター内のすべてのレプリカは自動的に管理され、すべてのレプリカのデータはある程度同期できます。ブローカーに障害が発生すると、リーダー レプリカが配置されているブローカー ノード上のすべてのパーティションが一時的に使用できなくなります。

この時点で、クラスター内のフォロワー コピーはリーダー コピーを再選出します。プロセス全体は Kafka コントローラーによって処理され、クラスター上のパーティションは一時的に使用できなくなります。パーティションの数が多すぎると、使用できない時間枠が大きくなります。

7. パーティションが増えると、消費時間も増えます

パーティションの数が多いほど、Kafka が正常に起動およびシャットダウンするまでの時間が長くなります。

同時に、トピック パーティションの数が増えると、ログのクリーンアップにかかる時間が増加し、削除にも時間がかかります。これは古いバージョンではより顕著でしたが、新しいバージョンでは改善されています。

8. パーティション数の理論的な参考設定値

通常、パーティションの数はブローカー ノードの数の整数倍として構成できます。たとえば、ブローカー ノードの数が 3 の場合、パーティションの数は 3、6、または 9 に設定できます。

ただし、ブローカー ノードの数が数十、数百、数千と膨大な場合には適していません。一般的に、BAT レベルでない限り、これも比較的まれです。必要に応じて、パーティションの数を選択する際に、ラックの導入やその他の参照要素をさらに考慮することができます。

9. 実際の状況を具体的に分析し、盲目にならないでください

最後に、後からパーティションの数を増やす場合には、それが必要か合理的かに注意してください。筆者は次のようなシナリオを目にしたことがあります。ログは消費後に es に書き込まれますが、メッセージの蓄積が深刻であるため、パーティションの数を 6 から 12 に増やします。この時点では、蓄積状況はあまり改善されず、さらに悪化する可能性があります (たとえば、同じログ ファイル内のログ データが不連続、つまり順序​​付けられている)。最終的に、唯一のオプションはトピックを削除し、元のパーティション数をリセットすることです。

システムの主なボトルネックは es の書き込み機能にあるため、消費速度が遅く、大量のログ メッセージが蓄積されます。

したがって、現在の主な問題 (ボトルネックなど) を分析し、パーティションの数を恣意的または盲目的に設定しないようにすることが重要です。

参考図書：「カフカを徹底的に理解する」