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 使用率が高い可能性があります。着信トラフィックと発信トラフィックが多い原因には、次のようなものがあります。

• トラフィックの多いトピックのパーティション数は、ブローカーに均等に分散されません。または、プロデューサーがすべてのパーティションに均等にデータを送信していません。必ずプロデューサーパーティションキーを確認し、それに応じてクラスター構成を更新してください。必ず、あるパーティションが他のパーティションよりも多くのデータを取得しないようにパーティションキーを設定してください。
• コンシューマーグループは非常に頻繁にオフセットを行っています。オフセットコミットからのトラフィックはブローカーに影響します。このような場合、_consumer_offset トピックパーティションのリーダーであるブローカーの MessageInPerSec 値が非常に高いことがわかります。これは、コンシューマーグループオフセットがコミットされるパーティションです。この問題を解決するには、コンシューマーグループの数を減らすか、インスタンスのサイズをアップグレードしてください。

ブローカーごとのパーティション数を超えました

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

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

パーティションが多すぎると、CPU 使用率が高くなるため、パフォーマンスが低下します。つまり、トラフィックが少ない場合でも、各パーティションはある程度のブローカーリソースを使用します。この問題に対処するには、以下を試してください。

• 古いトピックや未使用のトピックを削除して、パーティション数を推奨制限内に収めてください。
• ブローカーのインスタンスタイプを、必要なパーティションの数に対応できるタイプにスケールアップします。また、ブローカーをさらに追加してパーティションを再割り当てしてみてください。

ブローカーを追加しても、パーティションは自動的に再割り当てされないことに注意してください。kafka-reassign-partitions コマンドを実行する必要があります。詳細については、クラスターサイズを変更した後のパーティションの再割り当てを参照してください。

T 型インスタンスを使用しています

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

Amazon CloudWatch の CPU クレジットバランスメトリクスを必ずモニタリングしてください。クレジットは獲得後にクレジット残高に蓄積され、使用するとクレジット残高から削除されます。クレジット残高には、インスタンスサイズによって決まる上限があります。この上限に達すると、新たに獲得したクレジットはすべて破棄されます。T2 Standard インスタンスタイプの場合、起動クレジットは制限にカウントされません。

CPUCreditBalance メトリクスで示される CPU クレジットは、インスタンスがベースラインの CPU 使用率を超えてバーストするために使用できます。インスタンスが実行されているとき、CPUCreditBalance のクレジットは期限切れになりません。T4g 、T3a 、または T3 インスタンスが停止しても、CPUCreditBalance 値は 7 日間持続します。7 日が経過すると、累積クレジットをすべて失います。T2 インスタンスが停止すると、CPUCreditBalance の値は保持されず、累積クレジットはすべて失われます。CPU クレジットメトリクスは 5 分間隔で表示されます。

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

その他の原因

• クライアントへの接続数が多い: 次の CloudWatch メトリクスのいずれかが急増すると、壊れた CPU 使用率が増加する可能性があります。この問題をトラブルシューティングするには、CloudWatch でこれらのメトリックスをモニタリングしてください。次に、必要に応じて接続数を減らすか、ブローカータイプをスケールアップします。
  • ConnectionCount
  • ConnectionCreationRate
  • ConnectionCloseRate
• 消費者グループの数が多い: コンシューマーグループの数が多い場合 (たとえば、1000 を超える)、ブローカーの CPU 使用量が増える可能性があります。コンシューマーグループがオフセットを頻繁にコミットしている場合も、CPU 使用率が高くなる可能性があります。この問題を解決するには、コンシューマーグループの数を減らすか、インスタンスのサイズをアップグレードしてください。
• Amazon MSK はブローカーの障害を検出し、そこから回復します。 この場合、Amazon MSK はパッチングなどの自動メンテナンス操作を実行するため、CPU 使用量が増加します。
• ユーザーがブローカータイプの変更またはバージョンアップグレードをリクエストしました。 この場合、Amazon MSK は一度に 1 つのブローカーをオフラインにするローリングワークフローをデプロイします。リードパーティションのあるブローカーがオフラインになると、Apache Kafka はパーティションリーダーを再割り当てして、クラスター内の他のブローカーに作業を再分配します。これらのブローカーの CPU 使用率を監視し、運用上のイベントに耐えられる十分なCPUヘッドルームがクラスターにあることを確認してください。
• データ分散が偏っているため、1 つ以上のブローカーの CPU 使用率が高くなっています。 たとえば、6 つのブローカーのうち 2 つのブローカーへの書き込みが最も多く使用されている場合、その 2 つの CPU 使用率が高くなります。この問題に対処するには、クラスター全体にパーティションが適切に分散されるように、必ずラウンドロビン方式を使用してください。topic describe コマンドを実行して、パーティションがクラスター全体にどのように分散されているかを確認します。出力は次のようになる場合があります。

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 使用率が増加します。この問題を解決するには、スクレイプ間隔を長くしてください。