レイテンシのための最適化¶

Apache Kafka® では、大量のデータに対して非常に低いエンドツーエンドのレイテンシを実現できます。これは、Kafka に生成されたレコードをコンシューマーでフェッチするまでにかかる時間が短いことを意味します。

専用クラスターを使用する場合は、CKU を追加することでレイテンシを削減できます。エンドツーエンドのレイテンシに影響を与えるその他の可変要素としては、クライアントアプリの実装、パーティショニングとキーの戦略、生成と消費のパターン、ネットワークレイテンシ、QoS などがあります。Confluent Cloud のクラスターは、既に低レイテンシを実現するように構成されています。また、レイテンシを削減するようにクライアントアプリケーションを構成する方法も多数あります。

『Configure Kafka to Minimize Latency』（ブログ記事）は、ストリーミングアプリケーションのレイテンシを測定して改善するための包括的なガイドです。また、『Optimizing Your Apache Kafka Deployment』（ホワイトペーパー）では、レイテンシ、スループット、永続性、可用性のトレードオフについて詳しく説明されています。

主要な概念と構成¶

「スループットのための最適化」のページで説明している Kafka 構成パラメーターの多くのデフォルト設定は、レイテンシのために最適化されています。このため、通常はこれらの構成パラメーターを調整する必要はありません。このページでは、主要なパラメーターの機能について説明しています。

このページの構成パラメーターには、広範囲の値が指定できるものがあります。設定できる値は、必要な要件や、メッセージの平均サイズ、パーティション数といったその他の要因、さらには環境内で生じる他のさまざまな差によって影響を受けます。したがって、ベンチマークテストを行うとアプリケーションおよび環境の構成の検証に役立ちます。

パーティションの数¶

Confluent ガイドラインで、パーティションの数を選択する方法が説明されています。パーティションは Kafka の並列処理の単位であるため、パーティションの数を増やすとスループットが向上する場合があります。

パーティション数を増やすとレイテンシが大きくなるというトレードオフがあります。ブローカーの各ペア間で共有される複数のパーティションの複製に時間がかかり、その結果、メッセージがコミットされたと見なされるまでにかかる時間が長くなる場合があります。メッセージはコミットされるまで消費できないので、最終的にエンドツーエンドのレイテンシが長くなる可能性があります。

メッセージのバッチ処理¶

プロデューサーは自動的にメッセージをバッチ処理します。つまり、メッセージを収集して、まとめて送信します。これらのバッチが満杯になるまでの時間が短ければ、データを Confluent Cloud に生成する処理のレイテンシも短くなります。デフォルトでは、プロデューサーはレイテンシが低くなるようにチューニングされています。構成パラメーター linger.ms が 0 に設定されているので、送信データがあれば、プロデューサーはすぐにそのデータを送信します。この場合、バッチ処理が無効になるわけではありません。メッセージは常にバッチに入れて送信されますが、（プロデューサーがメッセージを送信するより速く、プロデューサーにメッセージを渡さない限り）バッチにメッセージが 1 つしか入っていないことがあります。

圧縮¶

圧縮を有効にする必要があるかどうか検討してください。通常、圧縮を有効にすると、必要な CPU サイクルは増えますが、ネットワーク帯域幅の使用量は減少します。一方、圧縮を無効にすると、CPU サイクルを節約できますが、ネットワーク帯域幅の使用量は増加します。圧縮のパフォーマンスによっては、compression.type=none を使用して圧縮を無効にし、CPU サイクルを節約することを検討できますが、優れた圧縮コーデックを使用すればレイテンシを削減できる可能性があります。

プロデューサーの受領応答¶

リクエストが完了したと見なすために受け取らなければならない受領応答の数として、プロデューサーが Confluent Cloud クラスターのリーダーブローカーに求める数をチューニングできます。

注釈

プロデューサーへのこの受領応答は、メッセージがコミットされたと見なされるときの受領応答とは異なります。

リーダーブローカーの応答が早いほど、プロデューサーは早く次のバッチのメッセージの送信に進むことができるので、プロデューサーのレイテンシが削減します。プロデューサーの acks 構成パラメーターを使用して、必要な受領応答の数を設定できます。デフォルトは acks=1 です。これは、すべてのレプリカがメッセージを受信するより前にリーダーブローカーがプロデューサーに応答することを意味します。アプリケーションの要件によっては、acks=0 を設定して、プロデューサーがプロデューサーリクエストに対するブローカーからの応答を待機しないようにすることができます。ただし、その場合は、プロデューサーが認識することなくメッセージが失われる可能性があります。

コンシューマーのフェッチ¶

プロデューサーのバッチ処理の概念と同様に、Confluent Cloud のリーダーブローカーからの各フェッチでコンシューマーが受け取るデータ量を調整して、低レイテンシが実現されるようにコンシューマーをチューニングすることができます。デフォルトでは、コンシューマーの構成パラメーターの fetch.min.bytes は 1 に設定されます。これは、データが 1 バイトでもあればすぐにフェッチリクエストに応答することを意味します。データがない場合は、構成パラメーター fetch.max.wait.ms が経過するまでデータの到着を待機した後にフェッチリクエストがタイムアウトします。この 2 つの構成パラメーターを同時に検討することで、フェッチリクエストのサイズ（fetch.min.bytes）またはフェッチリクエストの実行時間（fetch.max.wait.ms）を決定できます。

ローカルテーブルの使用¶

Kafka イベントストリーミングアプリケーションまたは ksqlDB を使用する場合は、アプリケーションの内部にパフォーマンスを向上できる要素がいくつかあります。大規模なテーブル検索を低い処理レイテンシで実行する必要がある場合は、ローカルのストリーム処理を使用できます。一般的な方法は、Kafka Connect を使用して、リモートデータベースを Kafka のローカルで使用できるようにすることです。そうすることで、Kafka Streams API または ksqlDB を利用して、高速で効率的なこのようなテーブルとストリームのローカル結合を実行できるので、アプリケーションでレコードごとにリモートデータベースにネットワーク経由でクエリを実行する必要がなくなります。ローカルのステートストアで各テーブルの最新のステートを追跡できるので、このような結合を行う際の処理レイテンシとリモートデータベースの負荷が削減されます。

トポロジーの最適化¶

Kafka Streams アプリケーションは、プロセッサートポロジーに基づいて構築されています。このトポロジーは、並列処理のためにパーティション化されたデータを処理できるストリームプロセッサーノードを表すグラフです。アプリケーションによっては、再パーティショントピックに基づいて、地味ではあるものの不要なデータシャッフルが発生する場合があります。このために正確性の問題が生じることはありませんが、パフォーマンスには悪影響がある可能性があります。パフォーマンスへの悪影響を回避するために、構成パラメーター topology.optimization を設定して、イベントストリーミングアプリケーション用にトポロジー最適化を有効にすることができます。トポロジーの最適化を有効にすると、再パーティショントピックを介して保管およびパイプされる再シャッフルストリームの量を減らすことができます。

レイテンシを最適化するための構成のまとめ¶

プロデューサー¶

linger.ms=0 （デフォルトは 0）
compression.type=none （デフォルトは none、つまり圧縮なし）
acks=1 （デフォルト: all - Kafka 3.0 より前: 1）

コンシューマー¶

fetch.min.bytes=1 （デフォルトは 1）

ストリーム¶

StreamsConfig.TOPOLOGY_OPTIMIZATION: StreamsConfig.OPTIMIZE （デフォルトは StreamsConfig.NO_OPTIMIZATION）
ストリームアプリケーションにはプロデューサーとコンシューマーが組み込まれているので、これらの推奨構成についても確認してください。