Amazon MSK クラスターの 1 つ以上のブローカーの CPU 使用率が高い場合のトラブルシューティング方法を教えてください。

解決策

Amazon MSK クラスターの合計 CPU 使用率は、以下の合計として計算されます。

• CpuUser というメトリックで定義されるユーザースペースにおける CPU の割合
• CpuSystem によって定義されるカーネルスペース内の CPU の割合

クラスターの CPU の 40% が使用できるように、CPU の合計使用率を 60% 未満に抑えることがベストプラクティスです。Apache Kafka は、必要に応じてクラスター内のブローカー間で CPU 負荷を再分散できます。たとえば、ブローカーの障害が発生した場合、Amazon MSK は利用可能な CPU を使用してパッチなどの自動メンテナンスを実行できます。

Amazon MSK クラスターの CPU 使用率が高いのは、以下のいずれかの理由が考えられます。

• 送受信トラフィックが多い。
• ブローカーあたりのパーティション数を超過すると、クラスターが過負荷になる。
• T インスタンスタイプを使用している。

送受信トラフィックが多い

クラスターへの送受信トラフィックをモニタリングするには、Amazon CloudWatch メトリクスの BytesInPerSec と BytesOutPerSec メトリクスを使用します。ブローカーのこれらのメトリクスの値が高いか、偏っている場合は、ブローカーの CPU 使用率が高い可能性があります。

ボリュームの大きいトピックのパーティション分散が不均一な場合、ブローカーのトラフィックが高くなることがあります。または、プロデューサがデータをすべてのパーティションに均等に分散しません。この問題を解決するには、プロデューサーパーティションキーを確認し、クラスター構成を更新してください。次に、あるパーティションが他のパーティションよりも多くのデータを取得しないようにパーティションキーを設定します。

また、コンシューマーグループがオフセットを頻繁にコミットすると、トラフィック量が多くなる可能性があります。オフセットコミットからのトラフィックはブローカーに影響します。この問題を解決するには、コンシューマーグループの数を減らすか、使用されているインスタンスのサイズをアップグレードしてください。

ブローカーあたりのパーティション数が推奨値を超えている

ブローカーあたりのパーティション数が推奨値を超えると、クラスターが過負荷になります。クラスターが過負荷になると、次のアクションを実行できなくなります。

• クラスター構成の更新。
• クラスターの Apache Kafka バージョンの更新。
• クラスターをより小さいブローカータイプに更新すること。
• AWS Secrets Manager のシークレットを SASL/SCRAM 認証のあるクラスターに関連付けること。

パーティションが多すぎると、CPU 使用率が高くなり、パフォーマンスが低下する可能性があります。

この問題を解決するには、次の手順を実行します。

• 古いトピックや未使用のトピックを削除して、パーティション数を推奨制限内に収めてください。未使用のトピックを特定するには、トピックレベルのモニタリングを有効にし、トピックレベルで BytesInPerSec と BytesOutPerSec のメトリクスを確認して、トピックにトラフィックが流れているかどうかを確認します。流れるトラフィックがない場合は、その未使用のトピックを削除できます。
• ブローカーのインスタンスタイプを、必要なパーティションの数に対応できるタイプにスケールアップします。また、ブローカーをさらに追加し、パーティションを再割り当てしてください。

注: パーティションを再割り当てするには、kafka-reassign-partitions コマンドを実行する必要があります。Amazon MSK は、ブローカーを追加しても自動的にパーティションを再割り当てしません。

T インスタンスタイプを使用している

T インスタンスタイプは、いくつかのバースト可能な機能を備えたベースラインのパフォーマンスを備えています。これらのインスタンスでは、20% の CPU 使用率というベースラインパフォーマンスを実現できます。この値を超えると、インスタンスタイプは CPU クレジットの使用を開始します。使用率が 20% 未満の場合、CPU クレジットが蓄積されます。

Amazon CloudWatch のバースト可能なインスタンスの CPU クレジットバランスメトリクスを必ずモニタリングしてください。

T インスタンスタイプで実行されるすべてのクラスターのベースライン CPU 使用率とクレジットバランスをモニタリングします。CPU 使用率がベースラインを超えていて、使用できるクレジットがこれ以上残っていない場合、クラスターのパフォーマンスに問題が生じます。

その他の考えられる原因

クライアントへの接続数が多い

次の CloudWatch メトリクスのいずれかが急増すると、ブローカー CPU 使用率が増加する可能性があります。

• ConnectionCount
• ConnectionCreationRate
• ConnectionCloseRate

この問題をトラブルシューティングするには、CloudWatch でこれらのメトリクスをモニタリングしてください。次に、必要に応じて接続数を減らすか、ブローカータイプをスケールアップします。

Amazon MSK はブローカーの障害を検出し、そこから回復する場合

Amazon MSK がブローカーの障害を検出し、パッチなどの自動メンテナンス操作を実行すると、CPU 使用率が増加します。Amazon MSK がクラスター操作を完了するとすぐに、CPU 使用率は通常の使用レベルに低下します。

ユーザーがブローカータイプの変更またはバージョンアップグレードを要求した

ユーザーがブローカリータイプの変更またはバージョンアップグレードを要求すると、Amazon MSK は一度に 1 つのブローカーをオフラインにするローリングワークフローをデプロイします。リードパーティションのあるブローカーがオフラインになると、Apache Kafka はパーティションリーダーを再割り当てして、クラスター内の他のブローカーに作業を再分配します。これらのブローカーの CPU 使用率をモニタリングし、運用上のイベントに耐えられる十分な CPU ヘッドルームがクラスターにあることを確認してください。

データ分散が偏っているため、1 つ以上のブローカーの CPU 使用率が高くなっている

データ分散が偏っているため、1 つ以上のブローカーの CPU 使用率が高くなっている可能性があります。たとえば、6 つのブローカーのうち 2 つのブローカーに書き込みを行い、それらのブローカーの消費量が最も多い場合、その CPU 使用率が高くなります。この問題に対処するには、クラスター全体にパーティションが適切に分散されるように、必ずラウンドロビン方式を使用してください。

Apache Kafka クラスターコントローラーがクラスター全体にパーティションを分散する方法を確認するには、次のコマンドを実行します。

bin/kafka-topics.sh -bootstrap-server $MYBROKERS --describe --topic my-topic

出力例:

Topic:my-topic    PartitionCount:7 ReplicationFactor:3 Configs:
    Topic: my-topic    Partition: 0 Leader: 1 Replicas: 1,3,2 Isr: 1,3,2
    Topic: my-topic    Partition: 1 Leader: 2 Replicas: 2,1,3 Isr: 2,1,3
    Topic: my-topic    Partition: 2 Leader: 3 Replicas: 3,2,1 Isr: 3,2,1
    Topic: my-topic    Partition: 3 Leader: 1 Replicas: 1,2,3 Isr: 1,2,3
    Topic: my-topic    Partition: 4 Leader: 2 Replicas: 2,3,1 Isr: 2,3,1
    Topic: my-topic    Partition: 5 Leader: 3 Replicas: 3,1,2 Isr: 3,1,2

オープンモニタリングを有効にした

Prometheus でオープンモニタリングをオンにしていて、スクレイプ間隔が短い場合、生成されるメトリクスの数が多くなり、CPU 使用率が増加する可能性があります。この問題を解決するには、スクレイプ間隔を長くしてください。Amazon MSK クラスターのパフォーマンスを維持するために、1 ブローカー・1 分あたり 1 スクレイプを超えないことがベストプラクティスです。デフォルトでは、スクレイプ間隔は 10〜15 秒ごとに発生します。