Container Service for Kubernetes:CPU バーストパフォーマンス最適化ポリシーの有効化

メリット

CPU 使用率は、コンテナーの健全性を監視するための主要なメトリックです。クラスター管理者は、通常これをもとに CPU 制限を設定します。秒単位のメトリックと比較して、ミリ秒単位の CPU 使用率は、ピークや短期的な変動をより明確に示します。以下のグラフでは、秒単位で測定された CPU 使用率（紫線）は、4 コアを大きく下回っているように見えますが、ミリ秒単位（緑線）では、一部の期間において 4 コアを超える使用率が観測されます。CPU 制限を 4 コアに設定した場合、スロットルによりスレッドが一時停止され、応答遅延（RT）が増加します。これは、ロングテール RT 問題の主な原因です。

次の図は、4 コアノード上で CPU 制限が 2 に設定された Web サービスコンテナーにおける CPU リソース割り当てを示しています。左側は通常の動作を、右側は CPU バーストを有効化後の動作を表します。

CPU バーストは、CPU 需要が急激に増加する状況でも有効です。たとえば、サービストラフィックが急増した場合、ack-koordinator は数秒以内に CPU ボトルネックを解消し、ノード全体の負荷を安全に保ちます。

適用範囲/利用シーン

CPU バーストの典型的なユースケースは以下のとおりです。

• CPU 使用率が大部分の時間、CPU 制限を下回っているにもかかわらず、スロットルが発生し、アプリケーションのパフォーマンスに悪影響を与えている場合。CPU バーストを有効化することで、コンテナーはバースト時に蓄積された CPU 時間を利用できます。これにより、スロットルが解消され、サービス品質が向上します。

• コンテナーが起動時および初期読み込み時に高 CPU を使用し、読み込み完了後に CPU 使用率が低く安定する場合。CPU バーストを有効化すれば、過剰に高い CPU 制限を設定する必要がなくなります。コンテナーは起動時に余分な CPU 時間を利用できるため、起動が高速化します。

検証手順

1. 以下の YAML を用いて、apache-demo.yaml というファイルを作成します。

   CPU バーストのアノテーションを metadata フィールド内に追加し、この Pod に対して CPU バーストを有効化します。

   apiVersion: v1
   kind: Pod
   metadata:
     name: apache-demo
     annotations:
       koordinator.sh/cpuBurst: '{"policy": "auto"}'   # CPU バーストを有効化します。
   spec:
     containers:
     - command:
       - httpd
       - -D
       - FOREGROUND
       image: registry.cn-zhangjiakou.aliyuncs.com/acs/apache-2-4-51-for-slo-test:v0.1
       imagePullPolicy: Always
       name: apache
       resources:
         limits:
           cpu: "4"
           memory: 10Gi
         requests:
           cpu: "4"
           memory: 10Gi
     nodeName: $nodeName # 実際のノード名に置き換えてください。
     hostNetwork: False
     restartPolicy: Never
     schedulerName: default-scheduler

2. テストアプリケーションとして Apache HTTP Server をデプロイします。

   kubectl apply -f apache-demo.yaml

3. wrk2 を用いてリクエストを送信します。

   # オープンソースの wrk2 ツールをダウンロードおよび展開します。詳細については、https://github.com/giltene/wrk2 をご参照ください。
   # Apache イメージでは Gzip 圧縮が有効化されており、サーバー側のリクエスト処理をシミュレートします。
   # ロードテストを実行します。$target_ip_address を Apache Pod の IP アドレスに置き換えてください。
   ./wrk -H "Accept-Encoding: deflate, gzip" -t 2 -c 12 -d 120 --latency --timeout 2s -R 24 http://$target_ip_address:8010/static/file.1m.test

   説明

   • コマンド内のターゲットアドレスを、Apache Pod の IP アドレスに置き換えてください。

   • -R パラメーターを変更することで、QPS の負荷を調整できます。

結果分析

以下の表は、Alibaba Cloud Linux およびコミュニティ版 CentOS における、CPU バーストの有効／無効時のパフォーマンス比較を示しています。

• すべて無効：CPU バーストポリシーが none に設定されています。

• すべて有効：CPU バーストポリシーが auto に設定されています。

これらの結果から、以下のことがわかります。

• CPU バーストを有効化すると、p99 RT メトリックが大幅に向上します。

• CPU バーストを有効化すると、CPU スロットルが大幅に低減します。一方、Pod の平均 CPU 使用率はほぼ変化しません。

以前の ack-slo-manager プロトコルで CPU バーストを使用していました。ack-koordinator へのアップグレード後も引き続き機能しますか？

以前の Pod アノテーションでは alibabacloud.com/cpuBurst を使用していました。ack-koordinator は、この旧プロトコルを完全にサポートしています。シームレスにアップグレードできます。

ack-koordinator は、以下のプロトコルバージョンと互換性があります。

CPU バーストを有効化した後も、なぜ CPU スロットルが発生するのですか？

主な原因と対処法は以下のとおりです。

• 構成の構文に誤りがあると、CPU バーストが有効化されません。修正および検証については、「高度な構成」をご参照ください。

• CPU 使用率が cfsQuotaBurstPercent の制限に達した場合、CPU リソースが不足しているためにスロットルが発生することがあります。

  アプリケーションの実際のニーズに合わせて、CPU のリクエストおよび制限値を調整してください。

• CPU バーストは、2 つの cgroup パラメーター（cpu.cfs_quota_us および cpu.cfs_burst_us）を調整します。「高度な構成」をご参照ください。cpu.cfs_quota_us は、ack-koordinator がスロットルを検出した後にのみ更新されるため、わずかな遅延があります。cpu.cfs_burst_us は設定値から即座に更新されるため、応答が速くなります。

  最も良い結果を得るには、Alibaba Cloud Linux を使用してください。

• cpu.cfs_quota_us の調整には保護機構があり、全体的な安全性のウォーターマークしきい値として sharePoolThresholdPercent が設定されます。全体の使用率が過度に高くなると、個々の Pod による干渉を防ぐため、cpu.cfs_quota_us が初期値にリセットされます。

  アプリケーションの実際の状況に応じて、適切なマシンの安全性しきい値を設定し、高マシン使用率がアプリケーションのパフォーマンスに影響を与えないようにしてください。

CPU バーストポリシーを有効化するには、Alibaba Cloud Linux を使用する必要がありますか？

ack-koordinator の CPU バーストは、Alibaba Cloud Linux および CentOS のすべてのオープンソースカーネルで動作します。ただし、Alibaba Cloud Linux の使用を推奨します。そのカーネル機能により、ack-koordinator はより細かい粒度で CPU 弾力性を提供できます。詳細については、「cgroup v1 インターフェイスを用いた CPU バーストの有効化」をご参照ください。

CPU バーストを有効化した後、アプリケーションが異なるスレッド数を報告するのはなぜですか？

これは、CPU バーストの動作メカニズムが、特定のアプリケーションがシステムリソースを取得する方法と競合するためです。ack-koordinator は、CPU バーストを実装する際に、コンテナーの基盤となる cgroup パラメーターである cpu.cfs_quota_us を動的に調整します。この値は、現在のスケジューリングサイクル内でコンテナーが利用可能な CPU 時間クォータを表します。ack-koordinator は、アプリケーションの負荷に応じてこのクォータを動的にスケールします。

Java の Runtime.getRuntime().availableProcessors() など、多くのアプリケーションは、利用可能な CPU コア数を計算するために、cpu.cfs_quota_us を直接読み取ります。そのため、CPU クォータが動的に調整されると、アプリケーションが取得するコア数も変化し、スレッドプールサイズなど、この値に依存するパラメーターが不安定になります。

代わりに、アプリケーションは、Pod の仕様（spec）で定義された固定の limits.cpu 値に依存するようにしてください。

1. 環境変数を注入： resourceFieldRef を用いて、Pod の limits.cpu 値をコンテナーに環境変数として注入します。

   env: 
     - name: CPU_LIMIT 
       valueFrom: 
         resourceFieldRef: 
           resource: limits.cpu

2. アプリケーションコードを更新： スレッドプールサイズの計算および設定時に、起動ロジックを変更して、まず CPU_LIMIT を読み取るようにします。これにより、CPU バーストによるクォータの変更があっても、安定的かつ信頼性の高い動作が保証されます。