重要

このページの日本語コンテンツは古くなっている可能性があります。最新の英語版コンテンツをご覧になるには、こちらをクリックしてください。

専用クラスターのパフォーマンスおよび拡張

Confluent Cloud 専用クラスター上で実行されている Apache Kafka® アプリケーションのパフォーマンス全体に影響する可能性がある多くの要因があります。コンシューマーラグ、クライアントスロットリング、およびプロデューサーのレイテンシとともにクラスター負荷をモニタリングして、アプリケーションのパフォーマンスを向上させる方法の手掛かりを見つけたり、クラスター拡張が正しい解決法なのかどうかを判断したりする必要があります。

アプリケーションのモニタリングの詳細については、「Monitoring Your Event Streams: Tutorial for Observability Into Apache Kafka Clients(ブログ)」をお読みください。

高いクラスター負荷値の解釈

Cluster load は、0 から 100 までのパーセンテージの値です。0% はクラスター上に負荷がないことを示し、100% はクラスターが完全に飽和状態であることを表します。一般的に、クラスター上の負荷の値が高いほど、アプリケーションのレイテンシやクライアントスロットリングが高くなります。クラスター負荷が 80% を超える場合は、レイテンシが高くなったり、スロットリングがある程度高くなるはずです。

負荷を下げるためにクラスターを拡張できますが、その前にクラスター負荷の時系列グラフを確認して、クラスター負荷の変動の履歴を把握する必要があります。クラスター負荷へのアクセス方法の詳細については、「クラスター負荷メトリック」を参照してください。

../_images/ccloud-cluster-load.png

クラスター負荷の例

このグラフを見るときに、クラスター負荷 70% は、たまに発生するスパイクまたはワークロードに対して正常な高い値である場合は許容範囲と見なします。ただし、アプリケーションのワークロードパターンの変化による負荷のスパイクに対応するために追加の処理能力がクラスターに必要になる場合、またはクラスターに新しいワークロードが追加される場合、70% の負荷は高すぎる可能性があります。この場合は、クラスターの拡張が正しい解決法になるでしょう。

一般的に、専用クラスターを拡張することでワークロードの処理能力が向上し、多くの場合、Kafka アプリケーションのパフォーマンスの向上に役立ちます。さらに、クラスター負荷が低いほどアプリケーションのレイテンシが改善される可能性があります。

専用クラスターを拡張してもパフォーマンス問題が解決されない場合は、クラスターを元のサイズに 縮小 できます。

高いコンシューマーラグの確認

コンシューマーラグ メトリックは、コンシューマーがログで遅れているパーティションのレコード件数を示します。データ生成レートが消費レートを超える場合、コンシューマーグループはラグを測定します。コンシューマーラグが大きくなると、クライアント側、Kafka サーバー側、または両方に問題がある可能性があります。

../_images/cloud-consumer-lag-detail.png

コンシューマーラグの例

サーバー側の問題によりコンシューマーラグが大きくなっているかどうかを判断するには、まず クラスター負荷メトリック を使用して、クラスターが過負荷になっていないことを確認します。クラスター負荷メトリックでクラスターの負荷が高い(70% を超える)ことが示されている場合は、クラスターの拡張がコンシューマーラグの解決に役立つと考えて問題ありません。

クラスターの負荷が高くない場合は、クラスター上のパーティションの数を確認します。パーティションにより、クラスター全体のワークロードが並列処理されます。経験上、並列処理の利点を得るには最低でも(CKU あたり)6 ~ 10 パーティション必要ですが、ワークロードによって必要なパーティションの数は増減する可能性があります。並列処理の改善について詳しくは、「最適化およびチューニング」を参照してください。

クラスターの負荷が高くなく、クラスター上に推奨されている数以上のパーティションがあってもコンシューマーラグが大きくなっている場合は、コンシューマーアプリケーションで並列処理が十分に行われていない可能性があります。コンシューマーを追加すると、この問題の解決に役立つ場合があります。

クライアントアプリケーションのスロットルの確認

スロットルは、クラウドサービスの処理で普通に行われることです。Confluent Cloud クラスターは、割り当てられている処理能力に基づいてクラスターが処理するように構成されているレートを超えると、クライアントアプリケーションをスロットリングします。このスロットリングにより、クラスターが停止して壊滅的な状況になる可能性がある追加使用を防ぐことができます。スロットルは、クライアントが十分な時間待機してサーバーが稼働時間を短縮することなくリクエストを処理できるように、Kafka サーバーと Kafka コンシューマーおよびプロデューサーの間でネゴシエートされます。

プロデューサーやコンシューマーがスロットリングされているかどうかを可視化するクライアント側とプロデューサーおよびコンシューマーのメトリクスの詳細については、「モニタリング」および Confluent Platform ドキュメントの「プロデューサーのメトリクス」セクションにある produce-throttle-time-avgproduce-throttle-time-max の説明を参照してください。

スロットリングの原因がサーバーの問題かクライアントの問題かを判断

クライアントスロットリングがクライアント側とサーバー側のどちらの問題であるかを判断するには、「Confluent Cloud の専用クラスターのクラスター負荷メトリック」を参照してください。クラスター負荷メトリックでクラスターの負荷が高いか高まっていることが示されている場合は、クラスターの拡張 によってスロットルが減ると考えて問題ありません。

スロットリングの特定の原因として評価することが重要なその他のサーバー側の特性は、受信量、送信量、およびリクエストレートです。

専用クラスターのスループットとリクエストレートは、そのクラスターに割り当てられている CKU の数によって制限されます。アプリケーションが多くのスループットを消費し、クラスターで現在処理できない数のリクエストを実行している場合は、クラスターの拡張によって問題を解決できる可能性があります。

ただし、クラスターがスロットリングされており、サーバー側の原因を特定できない場合は、クライアント側の実装がスロットリングの原因である可能性があります。たとえば、ワークロードのバランスが取れていない、つまり、1 つまたはいくつかのパーティションでトラフィックの大半に対応し、クラスターの残りの部分が十分に活用されていない可能性があります。Confluent Cloud は絶えずクラスターのバランスをモニタリングし、ワークロードの分散を自動的に最適化します。均等ではないパーティション割り当て戦略などのクライアント側のアクセスパターンにより、Confluent Cloud が最適なバランスを見つけられないことがあります。

Kafka とのやり取りを可能な限り最適に行うために、最高のスループットが推奨されるようにクライアント側アプリケーションを適切に設計してください。

プロデューサーアプリケーションのレイテンシのモニタリング

プロデューサーでレイテンシが発生していることを示すメトリクスもあります。具体的には、buffer-available-bytes(=0)bufferpool-wait-time の増加はプロデューサーのレイテンシを示します。

クラスター負荷メトリック が高く、プロデューサーのバッファ が高い場合は、CKU の追加によってクラスターを拡張すると、プロデューサーのレイテンシが改善されます。クラスターの拡張後もレイテンシが改善されない場合は、前のセクションの クライアントアプリケーション を参照してください。