Google Cloud Managed Service for Kafka デプロイのベンチマークとスケーリングを行う方法
Abhi Sharma
Strategic Cloud Engineer, Google Cloud
Blake DuBois
Data Architect, Google Cloud
※この投稿は米国時間 2025 年 6 月 14 日に、Google Cloud blog に投稿されたものの抄訳です。
意思決定やアプリケーション開発にリアルタイム データを活用している企業では、堅牢かつスケーラブルなストリーミング プラットフォームが必要になりますが、その主なソリューションとして Apache Kafka をご利用いただけます。
Kafka は、メッセージ キューやエンタープライズ メッセージング システムのように、アプリケーションによるレコード ストリームのパブリッシュおよびサブスクライブを可能にする分散ストリーミング プラットフォームです。このプラットフォームは、従来のメッセージング システムにはなかった高スループット、永続ストレージ、リアルタイム処理などの機能を備えています。しかし、Kafka クラスタのデプロイ、管理、スケーリングは容易ではありません。こうした問題を解決するのが、Google Cloud の Managed Service for Apache Kafka です。この Kafka のマネージド サービスは、オープンソース対応で移植性があるうえ、操作しやすく安全です。そのためユーザーは、インフラストラクチャの管理、ソフトウェアのアップグレード、スケーリングについて心配することなく、ストリーミング アプリケーションの構築とデプロイに集中できます。また、BigQuery、Cloud Storage、Dataflow などの他の Google Cloud データサービスとも統合されているため、最適なパフォーマンスを実現できます。
Apache Kafka 自体は高性能ですが、最適なパフォーマンスを実現するには、慎重なチューニングとベンチマークが必要です。この投稿では、デプロイを最適化して、スループットとレイテンシを向上させるための実践的なガイドを提供します。
注: Apache Kafka と bash スクリプトの概要を理解されていることを前提としています。Apache Kafka の紹介と概要については、Apache Software Foundation のウェブサイトをご覧ください。bash の概要については、Geeks for Geeks のチュートリアルをご覧ください。
Kafka プロデューサ、コンシューマ、レイテンシのベンチマーク
Kafka デプロイのベンチマークは、そのパフォーマンス特性を理解し、ご利用になっているアプリケーションの要件を満たせることを確認するために不可欠です。ベンチマークでは、プロデューサとコンシューマの構成を最適化しながら行う体系的なテストに基づいて、スループットやレイテンシなどの指標を詳しく分析します。ベンチマークはトピックレベルとアプリケーション レベルで行われますが、トピックレベルでは、各トピックに対して繰り返し実施することが重要です。
スループットとレイテンシを重視した最適化
Apache Kafka バンドルには、プロデューサとコンシューマのパフォーマンスおよびレイテンシを評価するための 2 つのユーティリティ（ kafka-producer-perf-test.sh と kafka-consumer-perf-test.sh）が含まれています。
注: ここではツールの使用目的が伝わる構成値を使用していますが、実際のワークロードを反映した構成（メッセージ サイズやメッセージ レートなど）を使用することをおすすめします。
このツールは、指定された数のメッセージをトピックに送信してプロデューサの動作をシミュレートしながら、スループットとレイテンシを測定します。このとき次のフラグが使用されます。
-
topic（必須）: ターゲットの Kafka トピックを指定
-
num-records（必須）: 送信するメッセージの合計数を設定
-
record-size（必須）: 各メッセージのサイズをバイト単位で定義
-
throughput（必須）: 1 秒あたりに送信されるメッセージ数で目標スループットを設定（スロットリングを無効にするには「-1」を使用）
-
producer-props:
-
bootstrap.servers（必須）: Kafka ブートストラップ サーバーまたはブローカー アドレスのカンマ区切りのリスト。
-
acks（省略可）: ブローカーに要求する確認応答レベルを制御（0、1、または all）。ブローカーからの応答が不要な場合は「0」、リーダー ブローカーからの応答が必要な場合は「1」、すべてのブローカーからの応答が必要な場合は「all」をそれぞれ指定。デフォルト値は「all」。
-
batch.size（省略可）: メッセージの最大バッチサイズ（バイト）。デフォルト値は 16 KB。
-
linger.ms（省略可）: バッチがメッセージで満たされて送信するまでの最大待機時間。デフォルト値は 0 ミリ秒。
-
compression.type（省略可）: none、gzip、snappy、lz4、zstd のいずれか。デフォルト値は none。
サンプルのコードブロック #1: Kafka プロデューサのパフォーマンス テスト
重要な考慮事項
最も重要なプロパティは acks、batch.size、linger.ms、compression です。これらは、プロデューサのスループットとレイテンシに直接影響するためです。適切な設定はアプリケーションによって異なりますが、次のベースライン構成をおすすめします。
-
acks:「acks=1」の場合、リーダー ブローカーからの確認応答のみが必要になる。この設定により、すべてのリーダーとフォロワーからの確認応答を必要とする場合を除き、最適なパフォーマンスが得られる。
-
batch.size: 10000 B（10 KB）は、最初に設定するベースラインに適した値。バッチサイズを大きくすると、プロデューサは 1 回のリクエストでより多くのメッセージを送信できるようになるため、オーバーヘッドが軽減される。
-
linger.ms: 10 ミリ秒は、ベースラインに適した値。0～50 ミリ秒の範囲で試すことができる。この待機時間を大きくすると、レイテンシが増加する可能性がある。
-
compression: compression を使用してスループットをさらに高め、レイテンシを短縮することが推奨される。
このツールは、Kafka トピックからメッセージを取得してコンシューマの動作をシミュレートしながら、達成されたスループットとレイテンシを測定します。主なプロパティは次のとおりです。
-
topic（必須）: メッセージの取得元となる Kafka トピックを指定。
-
bootstrap-server（必須）: Kafka ブートストラップ サーバーまたはブローカー アドレスのカンマ区切りリスト。
-
messages（必須）: 使用するメッセージの合計数。
-
group（省略可）: コンシューマ グループ ID。
-
fetch-size（省略可）: 1 回のリクエストで取得するデータの最大量。デフォルト値は 1,048,576 バイト（1.04 MB）。
サンプルのコードブロック #2: Kafka コンシューマのテスト
重要な考慮事項
最適なコンシューマ スループットを実現するには、チューニングする際に fetch-size プロパティが重要になります。デフォルトの fetch-size 構成は、主にデータ消費とスループットのニーズによって決まります。小さいメッセージの場合は最大 1 MB、大きいメッセージの場合は 1～50 MB の範囲になります。さまざまなフェッチサイズが、アプリケーションの応答性とスループットの両方に与える影響を分析することをおすすめします。これらのテストを注意深く記録し、結果を確認することで、パフォーマンスの制限を特定し、それに応じて設定を調整できます。
スループットとレイテンシをベンチマークする方法
プロデューサのベンチマーク
Kafka プロデューサのスループットとレイテンシを測定するためにテストを実施する際、重要となるパラメータは batch.size（メッセージ バッチの最大サイズ）と linger.ms（バッチが満たされて送信するまでの最大待機時間）です。このベンチマークでは、耐久性とパフォーマンスのバランスを取るために、acks を 1（リーダー ブローカーからの確認応答）に設定することをおすすめします。これにより、プロデューサで達成できるスループットとレイテンシを推測するのに役立ちます。メッセージ サイズは 1 KB で一定に保たれています。
分析とテスト結果
-
バッチサイズの影響: バッチサイズを大きくすると、一般的にはスループット（メッセージ/秒および MB）が高くなります。バッチサイズを 1 KB から 10 KB に増やすと、スループットが大幅に向上します。しかし、さらにバッチサイズを 100 KB に増やしても、スループットはそれほど向上しません。これは最適なバッチサイズがあることを示しており、その最適な値を超えてバッチサイズを増やしても、スループットはさほど高まらないということです。
-
待機時間の影響: 100 KB のバッチサイズで待機時間を 10 ミリ秒から 100 ミリ秒に増やすと、スループットが 117,187 メッセージ/秒から 111,524 メッセージ/秒へとわずかに低下しました。この結果から、このシナリオでは、待機時間を長くしてもスループットの最大化にはつながらない場合があることがわかります。
-
レイテンシに関する考慮事項: レイテンシは、バッチサイズが大きいほど長くなる傾向があります。この理由は、より大きなバッチが、送信前のメッセージで満たされるのを待つ時間が長くなるからです。これは、batch_size を 10 KB から 100 KB に増やした場合にはっきりと確認できます。
これらのテスト結果から、Kafka プロデューサを構成する際に、慎重なチューニングが重要であることがわかります。目標とするスループットとレイテンシを実現するには、batch.size と linger.ms の最適なバランスを見つけることが重要です。
コンシューマのベンチマーク
コンシューマのパフォーマンスを評価するために、kafka-consumer-perf-test を使用して、フェッチサイズを体系的に変更しながら一連のテストを実施しました。
分析とテスト結果
-
フェッチサイズがスループットに与える影響: この結果から、fetch.size とコンシューマのスループットの間に強い相関関係があることが明らかになりました。フェッチサイズを大きくすると、メッセージ スループット（メッセージ/秒）とデータ スループット（MB）の両方が大幅に向上しています。これは、フェッチサイズを大きくすると、コンシューマが 1 回のリクエストでより多くのメッセージを取得できるようになるため、頻繁なリクエストのオーバーヘッドが減り、データ転送の効率が高まるためです。
-
収穫逓減: fetch.size を大きくすると、通常はスループットが向上しますが、100 MB を超えると収穫逓減が発生します。100 MB と 500 MB のスループットには大きな差がないため、フェッチサイズをさらに増やしても、あまりメリットを得られなくなるポイントがあることがわかります。
Google Managed Service for Apache Kafka のスケーリング
さらなるテストを行って、マネージド Kafka クラスタの最適な構成を検討しました。この演習では、メッセージ サイズを 1 KB、バッチサイズを 10 KB、トピックのパーティション数を 1,000、レプリケーション数を 3 に設定しています。結果は次のとおりです。
マネージド Kafka クラスタを効果的にスケールすることは、要件の増加に合わせて最適なパフォーマンスを確保するために不可欠です。適切なクラスタ構成を確認するために、プロデューサ スレッド、vCPU、メモリの数を変えてテストを実施しました。テスト結果から、vCPU とメモリを 3 vCPU / 12 GB から 12 vCPU / 48 GB に増やす垂直スケーリングによって、リソース使用率が大幅に向上することがわかりました。プロデューサ スレッドを 2 つにすると、cluster_byte_in_count 指標は 2 倍になり、CPU 使用率は 24% から 56% に増加しました。スループット要件は重要な役割を果たします。12 vCPU / 48 GB で、プロデューサ スレッドを 2 つから 4 つに変更すると、cluster_bytes_in_count がほぼ 2 倍になりました。また、スループットを向上させると CPU とメモリの使用率が上昇する可能性があるため、ボトルネックを回避するためにリソース使用率をモニタリングする必要もあります。つまり、マネージド Kafka サービスのパフォーマンスを最適化するには、特定のワークロードとリソースの制約に合わせて、クラスタの垂直スケーリングとスループット要件のバランスを慎重に調整する必要があるということです。
希望に沿った Kafka クラスタを構築する
内容をまとめると、Google Cloud Managed Service for Apache Kafka のデプロイを最適化するのに必要なのは、プロデューサとコンシューマの動作についての十分な理解、慎重なベンチマーク、戦略的なスケーリングです。リソース使用率を積極的にモニタリングし、特定のワークロードの需要に合わせて構成を調整すれば、マネージド Kafka クラスタで、リアルタイムのデータ ストリーミング アプリケーションに必要な高スループットと低レイテンシを実現できます。
さらに詳しい情報については、以下のリンクからリソースとドキュメントをご覧ください。
ー Google Cloud、戦略的クラウド エンジニア、Abhi Sharma
ー Google Cloud、データ アーキテクト、Blake DuBois
