Kafkaのスケーリング：高スループットと低レイテンシのための戦略

Kafkaのスケーリングとは、レイテンシ、コンシューマーラグ、ブローカーの負荷を制御不能にすることなくスループットを向上させることを意味します。ほとんどのスケーリング作業は、パーティション、プロデューサーのバッチ処理、コンシューマーの並列処理、ブローカーリソース、レプリケーション設定に帰着します。

「Kafkaを高速化する」ための単一のスイッチはありません。まずボトルネックを見つけ、実際にクラスターを制限しているパイプラインの部分を調整する必要があります。

Kafkaのスケーラビリティの基盤を理解する

Kafkaのスケーラビリティは、いくつかのコアコンセプトに基づいています。

ブローカー： Kafkaはトピックパーティションをブローカー間で分散するため、ストレージ、ネットワーク、CPU負荷を共有できます。
パーティション： パーティションは順序と並列処理の単位です。パーティションを増やすと、プロデューサーとコンシューマーの並列処理をより多く許可できます。
レプリケーション： 各パーティションにはリーダーとフォロワーレプリカがあります。レプリケーションは可用性を向上させますが、ディスクとネットワークの作業が追加されます。
クライアント： プロデューサーとコンシューマーの設定は、ブローカーの設定と同じくらい重要であることがよくあります。

高スループットのための戦略

Kafkaで高スループットを達成するには、主に並列処理を最大化し、データフローを最適化することに重点を置きます。

効果的なパーティショニング戦略を選択する

パーティションの数と設計はスループットにとって重要です。一般的に、パーティションが多いほど並列処理が向上しますが、収穫逓減や潜在的な欠点もあります。

1つのトピックが飽和状態になった場合、パーティション数を増やします。 パーティションを増やすと、書き込みと読み取りの負荷をより多くのブローカーとコンシューマーに分散できます。
ホットパーティションを回避するキーを選択します。 tenant_idのようなキーは、テナントが類似している場合は問題ないかもしれませんが、1つの巨大なテナントが1つのパーティションに過負荷をかける可能性があります。その場合は、複合キーまたは異なるトピック設計が必要になる場合があります。
軽率に過剰なパーティションを作成しないでください。 パーティションが多すぎると、メタデータ、ファイルハンドル、リーダー選出作業、コンシューマーリバランス時間が増加します。

たとえば、ordersトピックがregionのみでキー設定されており、トラフィックの80％がus-eastである場合、1つのパーティションがホットになる可能性があります。customer_idやregion.customer_idなどのキーは、アプリケーションが必要とする順序を維持しながら、トラフィックをより均等に分散できます。

プロデューサー設定を調整する

プロデューサーの設定を最適化すると、書き込みスループットが大幅に向上します。

acks： acks=allは、適切なmin.insync.replicasと組み合わせると最強の耐久性を提供しますが、レイテンシが追加される可能性があります。acks=1は、リーダーのみが書き込みを確認するため、より高速です。acks=0は最速ですが、ブローカーによる確認応答はありません。
batch.sizeとlinger.ms： バッチサイズを大きくすると、リクエストのオーバーヘッドが削減されます。小さなlinger.msは、プロデューサーがバッチを満たす時間を与えますが、待機時間が追加されます。
圧縮： lz4、snappy、またはzstdは、ネットワークとディスクの負荷を軽減できます。圧縮はCPUを使用するため、実際のメッセージ形状でテストしてください。
max.request.size： 正当なバッチまたはレコードに必要な場合にのみ、これを増やしてください。message.max.bytesやトピックレベルのmax.message.bytesなどのブローカー側の制限も確認してください。

ブローカーリソースとスレッドを調整する

ブローカー設定は、データ処理の効率に直接影響します。

num.network.threads： クライアントや他のブローカーからのネットワークリクエストを処理するスレッドを制御します。
num.io.threads： ディスクI/Oとリクエスト処理作業に使用されるスレッドを制御します。
num.partitions： 新しく作成されたトピックのデフォルトのパーティション数を設定します。既存のトピックのサイズは変更しません。
log.segment.bytes： ログセグメントのサイズを制御します。セグメントサイズは、保持クリーンアップ、コンパクション動作、ファイル管理に影響します。

これらの設定は、メトリクスを手元に置いて変更してください。ディスクが飽和状態の場合、スレッドを増やしてもクラスターは修正されません。CPUが利用可能な状態でネットワークリクエストキューが増加している場合、スレッドの調整が役立つ可能性があります。

低レイテンシのための戦略

Kafkaの低レイテンシは、多くの場合、プロデューサーからコンシューマーへのメッセージ配信の遅延を最小限に抑えることを意味します。

低レイテンシのためにコンシューマーを調整する

コンシューマーは、配信パイプラインの最終ステップです。

fetch.min.bytes： 値を小さくするとデータが早く返されますが、より多くのフェッチリクエストが作成されます。
fetch.max.wait.ms： 値を小さくすると、トラフィックが少ない場合の待機時間が短縮されます。
コンシューマーグループのサイズ： コンシューマーグループは、割り当てられたパーティションの数まで、トピックを並列に処理できます。パーティション数を超える余分なコンシューマーは、そのトピックに対してアイドル状態になります。
処理時間： 低速なダウンストリームデータベース書き込み、HTTP呼び出し、または大量の変換は、Kafka自体が正常であっても、しばしばラグを引き起こします。

ネットワーク距離を短縮する

プロデューサー、ブローカー、コンシューマー間のネットワークレイテンシは重要な要素です。

可能な場合は、プロデューサー、ブローカー、レイテンシに敏感なコンシューマーを近くに配置してください。リージョン間のKafkaトラフィックは、レイテンシと障害モードを追加します。マルチリージョン配信が必要な場合は、1つの低レイテンシクラスターを離れたネットワークに拡張するのではなく、レプリケーションまたはデータ移動の設計問題として扱ってください。

ブローカーをリソースプレッシャーから遠ざける

低レイテンシは、安定したブローカーに依存します。CPU、ディスクI/O待機、ページキャッシュ動作、ネットワーク飽和、リクエストハンドラーのアイドル比率、アンダーレプリケーションパーティションを監視してください。ブローカーが過負荷の場合、クライアントのチューニングは短時間しか症状を隠しません。

レプリケーションとフォールトトレランスのバランス

レプリケーションは主にフォールトトレランスのためですが、パフォーマンスとスケーリングに影響します。

レプリケーションファクター： レプリケーションファクター3は、単一のレプリカよりもブローカーの損失に耐えられるため、本番トピックでは一般的です。
min.insync.replicas： acks=allの場合、プロデューサーが成功を確認する前に、書き込みを確認する必要がある同期レプリカの数を制御します。
ISRの健全性： 同期レプリカセットの縮小は警告サインです。多くの場合、低速なディスク、ネットワークの問題、または過負荷のブローカーを示しています。

各変更の前後を監視する

継続的な監視は、ボトルネックを特定し、パフォーマンスを調整するために不可欠です。

ブローカーのCPU、ディスクI/O、ネットワークスループット、リクエストレイテンシ、パーティションスループット、プロデュースエラー率、アンダーレプリケーションパーティション、コンシューマーラグを追跡します。Kafkaはこれらの多くをJMXを通じて公開しており、チームは一般的にPrometheusとGrafana、またはKafka固有のプラットフォームを使用して収集します。

一度に1つの意味のある変更を行ってください。パーティションを増やす場合は、リバランスの影響とホットパーティションの動作を測定します。プロデューサーのバッチ処理を変更する場合は、平均スループットだけでなく、レイテンシパーセンタイルとエラー率を測定します。

まとめ

Kafkaをボトルネックから外側に向かってスケーリングします。パーティションの分散とクライアントのバッチ処理から始め、次にコンシューマーラグ、ブローカーのディスクとネットワークの負荷、レプリケーションの健全性を確認します。適切にスケーリングされたKafkaクラスターは、単に大きいだけではありません。バランスの取れたパーティション、予測可能なクライアント動作、および障害に対する十分な余裕があります。