[[336169]]

この記事は、cocodroid氏が執筆したWeChat公式アカウント「建築のポーター」からの転載です。転載の許可については、「建築のポーター」公式アカウントまでお問い合わせください。

特定のトピックに対して適切なパーティション数を決定するという問題に直面することはよくありますが、設定方法や結果の評価方法がわからない場合もあります。また、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 のスループットはパーティションにのみ関係するわけではありません。

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

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

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

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

多数のパーティションを設定する場合は、システムの最大ファイル記述子サイズを超えないように注意してください。システム設定を変更することは可能ですが、ファイルハンドルにもオーバーヘッドが発生するため、可能な限り変更は避けてください。

5. メッセージ書き込みのパーティション分割戦略に注意してください。

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

例えば、一部のアプリケーションシナリオでは、特定のパーティション内でのみメッセージを順序付けすることが求められる場合があります。パーティション数が調整されると、このユースケースに影響が出る可能性があります。

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

キーとの関連が弱いアプリケーションの場合、実際の状況に応じて将来的にパーティション数を増やすことができます。

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

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

Kafka クラスター内のすべてのレプリカは自動的に管理され、すべてのレプリカ間で一定レベルのデータ同期が確保されます。ブローカーに障害が発生すると、リーダーレプリカを含むブローカーノード上のすべてのパーティションが一時的に利用できなくなります。

この時点で、クラスター内のフォロワーレプリカはリーダーレプリカを再選出します。このプロセス全体はKafkaコントローラーによって処理され、クラスター上のパーティションは一時的に利用できなくなります。パーティションが多すぎる場合、この利用不可期間は長くなります。

7. パーティションが増えると、処理時間も長くなります。

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

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

8. パーティション数の理論的な基準設定

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

ただし、ブローカーノードの数が数十、数百、数千と非常に多い場合は、この方法は適していません。BATレベルの運用でない限り、このようなケースは一般的に稀です。必要に応じて、ラックスペースの確保など、パーティション数を選択する際に更なる考慮事項を考慮する必要があります。

9. それぞれの状況を個別に分析し、性急な決断を避けます。

最後に、後からパーティションを追加する場合は、それが本当に必要か、あるいは合理的かに注意する必要があります。ログが消費されElasticsearchに書き込まれているにもかかわらず、深刻なメッセージのバックログが発生しているというシナリオを目にしたことがあります。そこで、パーティション数を6から12に増やしました。しかし、この時点ではバックログの状況は改善されず、むしろ悪化する可能性があります（例えば、同じログファイル内のログデータが連続していない、つまり順序​​が崩れているなど）。最終的には、トピックを削除し、元のパーティション数に戻す必要があります。

システムの主なボトルネックとなっているのは Elasticsearch の書き込み機能であり、これが消費速度の低下を引き起こし、大量のログ メッセージが蓄積される原因となっています。

そのため、現時点での主な問題点（ボトルネックなど）を分析することが重要であり、パーティション数を恣意的または盲目的に設定しないように留意することが重要です。

参考書籍: *Kafkaを理解する*