重要
このページの日本語コンテンツは古くなっている可能性があります。最新の英語版コンテンツをご覧になるには、こちらをクリックしてください。
最適化およびチューニング¶
単体テストおよび統合テスト が完了したら、サービス目標に応じて、アプリケーションのベンチマークテストを実行し、最適化を行ってパフォーマンスをチューニングすることができます。
ベンチマークテスト¶
ベンチマークテストは重要です。Confluent Cloud 向けの Kafka アプリケーションの開発に必要な構成パラメーターに、万能な推奨値はないからです。適切な構成は、ユースケース、有効化した他の機能、データプロファイルなどの影響を常に受けます。デフォルト以外の設定を使用して Kafka クライアントをチューニングする場合は、ベンチマークテストを実行する必要があります。サービス目標に関係なく、アプリケーションが持つパフォーマンスの特性について理解することをお勧めします。スループットやレイテンシのために最適化する必要がある場合には特に重要になります。ベンチマークテストは、パーティション数やプロデューサーおよびコンシューマーのプロセス数を適切に決定するための計算にも活用できます。
まず、Kafka ツールの kafka-producer-perf-test と kafka-consumer-perf-test を使用して、帯域幅を測定します。librdkafka をラップする JVM 以外のクライアントについては、rdkafka_performance インターフェイスを使用できます。この 1 回目の結果では、アプリケーションロジックによる影響を除外した、Confluent Cloud インスタンスへのベースラインのパフォーマンスが得られます。これらの perf ツールでは スキーマレジストリ がサポートされていないことに注意してください。
次に、アプリケーションをテストします。はじめに、デフォルトの Kafka 構成パラメーターを使用して、デフォルト値について十分に理解します。
特定のプロデューサーのベースラインの入力パフォーマンスの特性を、そのプロデューサーからアップストリームへの依存関係を取り除くことにより決定します。アップストリームのソースからデータを受信するのではなく、高い出力速度で独自の模擬データを生成するようにプロデューサーを変更して、データ生成がボトルネックにならないようにします。本稼働環境のパフォーマンスをより正確に表す結果が得られるように、模擬データは、本稼働環境で使用されるデータのタイプを反映したものにしてください。または、模擬データを使用する代わりに、本稼働環境データのコピーや本稼働環境データをクレンジングしたものをベンチマークテストに使用することを検討してください。
圧縮についてテストする場合は、模擬データ の生成方法にご注意ください。模擬データが非現実的で、部分文字列が繰り返されていたり、ゼロが埋め込まれていたりすると、本稼働環境で見られるであろう圧縮パフォーマンスよりも高い結果になることがあります。
- 単一サーバーで単一プロデューサーのクライアントを実行し、Kafka プロデューサーの使用可能な JMX メトリクスを使用して、結果のスループットを測定します。サーバーにおけるプロデューサーのプロセス数を増やしながらプロデューサーのベンチマークテストを繰り返し実行することで、最高のスループットが得られる 1 サーバーあたりのプロデューサーのプロセス数を判断することができます。
- 同じような方法で、特定のコンシューマーのベースラインの出力パフォーマンスを決定します。単一サーバーで単一コンシューマーのクライアントを実行し、サーバーにおけるコンシューマーのプロセス数を増やしながらそのテストを繰り返し実行することで、最高のスループットが得られる 1 サーバーあたりのコンシューマーのプロセス数を判断します。
- サービス目標を反映するさまざまな順列の構成パラメーターに対し、ベンチマークテストを実行します。一部の構成パラメーターに焦点を置きます。システム全体への影響を正確に理解することなくパラメーターをデフォルト値から検出し変更したりするのを避ける必要があります。
スループットとレイテンシの要件を満たす設定が見つかるまで、設定をチューニングし、テストを実行し、結果を観察してもう一度チューニングするという作業を繰り返します。
ベンチマークテストでパーティション数について検討するときには、こちらのブログ記事 を参照してください。
サービス目標の決定¶
わずか数秒で Kafka クライアントアプリケーションを起動し、Confluent Cloud で稼働させることができますが、本稼働環境に移行する前に、アプリケーションをチューニングする必要があります。ユースケースが異なれば、サービス目標を決定付ける一連の要件も異なるので、自分のサービス目標が何であるかを以下から決定する必要があります。
サービス目標を明確にするときには、以下の条件について考慮する必要があります。
- Kafka アプリケーションで対応するユースケース。
- アプリケーション要件とビジネス要件。これらは、ユースケースを満たすために失敗できない要素です。
- Kafka がビジネスのパイプラインにどのように適合するか。
最適化すべきメトリクスはどれかという問題に答えを出すことは簡単ではありませんが、元のビジネスユースケースと主要な目標についてチームで話し合うことが重要です。これには以下の 2 つの理由があります。
すべての目標を同時に最大限に実現することはできません。スループット、レイテンシ、永続性、可用性の間には、トレードオフがときどきあります。スループットとレイテンシの間にパフォーマンスのトレードオフが存在することが多いこと、場合によっては永続性と可用性の間にもトレードオフが存在することは知られているのではないでしょうか。システム全体について検討していると、どの目標も単独では検討できないことに気付くはずです。そのため、このドキュメントでは、この 4 つのサービス目標を総合的に検討しています。これらの目標の 1 つを最適化すると、他の目標が完全に失われるという意味ではありません。すべてのサービス目標が相互に関係しているので、同時にすべてを最大化することはできないという意味に過ぎません。
最適化するサービス目標を決定し、それらの目標を達成できるように Kafka 構成パラメーターをチューニングする必要があります。また、ユーザーがシステムに期待する内容を理解して、ユーザーのニーズを満たすように Kafka を最適化する必要があります。時間を取って以下の質問に答えてください。
"高スループット" を実現するために最適化しますか。スループットとは、プロデューサーからブローカー、またはブローカーからコンシューマーにデータが移動する速度のことです。
ユースケース: 1 秒あたりに数百万回の書き込みを行うアプリケーション。Kafka の設計上、大量のデータを書き込むことは難しいことではありません。従来のデータベースやキー値ストアを使用して大量のデータを書き込むより高速です。こうしたデータの書き込みは、簡素なハードウェアで実現できます。
"低レイテンシ" を実現するために最適化しますか。レイテンシとは、メッセージのエンドツーエンド（プロデューサーからブローカー、コンシューマーへ）の移動にかかる時間のことです。
ユースケース: チャットアプリケーション。このアプリケーションでは、メッセージの受信者は、可能な限り短いレイテンシでメッセージを受け取る必要があります。 その他の例としては、ユーザーがネットワーク内の友達からの投稿をフォローするインタラクティブなウェブサイトや、モノのインターネット（IoT）用のリアルタイムのストリーム処理などが含まれます。
"高永続性" を実現するために最適化しますか。高永続性とは、コミットされたメッセージが失われないことを保証するものです。
ユースケース: Kafka をイベントストアとして使用したイベントストリーミングマイクロサービスパイプライン。ミッションクリティカルなビジネスコンテンツ用にイベントストリーミングソースとなんらかの永続ストレージ（Amazon S3 など）を統合するユースケースもあります。
"高可用性" を実現するために最適化しますか。高可用性とは、予期しない障害が発生した場合のダウンタイムを最小化するものです。
ユースケース: 常に稼働状態でなければならないアプリケーション。できる限り迅速に障害から回復するように Kafka を最適化する必要があります。