Kubernetes CPUスロットリング：応答時間のサイレント・キラー

現在、 Kubernetes上でミッションクリティカルなアプリケーションを実行している企業組織の大部分は、マルチテナント環境でそれを行っています。これらのマルチテナント環境は、テナントのワークロードの消費を規制したり、チャージバックに制限を使用したりする制限の設定に依存しています。一部の開発会社では、アプリケーションのベンチマーク・テスト用にCPUやGPUの制限を設定することもあります。

CPUスロットリング（物理CPUコア上のタスクのスケジューリング率が誤って減少し、多くの場合、アプリケーションの応答時間が望ましくない増加）は、この設計の意図しない結果です。次の例を見てみましょう。

上記の図では、コンテナのCPU使用率はわずか25%であるため、サイズ縮小の候補として当然に挙げられます。

しかし、コンテナのサイズを縮小した後（コンテナのCPU使用率は50％と、まだ高くない）、応答時間は4倍になりました。

このケースでは、何が起こっているのでしょうか。コンテナにCPU制限を構成すると、CPUスロットリングが発生し、アプリケーションの応答時間が逆に遅くなり、スロットリングの問題が発生する可能性があります。基盤となるノードに十分なリソースがあっても、コンテナのワークロードが適切に設定されていないため、引き続きスロットルされます。さらに、スロットリングの性能への影響は、基盤となる物理プロセッサー（Intel、AMD、NVIDIA）によって異なる場合があります。長い応答時間は、長いCPUスロットリングの期間と直接的な相関関係にあり、これがまさにKubernetesが機能するように設計された方法です。

これをもう少し明確に示すため、CPU制限を200ミリ秒に設定し、その制限が基盤となるLinuxシステムのグループ・クォーターに変換されると想像してください。デフォルトの施行期間はわずか100ミリ秒であるため、コンテナは一度に20ミリ秒のCPU（CPUタイム・スライスと呼ばれます）しか使用できません。タスクが20ミリ秒を超えると、スロットルされ、タスクの完了に4倍の時間がかかります。

この動作に基づいて、スロットリングによる応答時間の増加によりアプリケーションのパフォーマンスが低下し、問題を見つけるためのトラブルシューティングを開始します。

小規模なデプロイメントを実行している場合は、スロットルを手動でトラブルシューティングできる場合があります。

まず、 kubectlなどのツールを使用して、影響を受けるポッドを特定します。次に、ポッドのリソース要求と制限を確認し、それらが適切に設定されていることを確認します。コンテナ内で実行され、スロットルを引き起こしている可能性のあるリソースを大量に消費するプロセスをチェックし、CPU使用率と制限を分析します。

CPUスロットリングが続く場合は、水平ポッドの自動スケーリングを検討して、ワークロードをより多くのポッドに分散するか、クラスターのノードのリソースを調整して、要求を満たすようにします。継続的にリソース設定を監視し、ファイン・チューニングして性能を最適化し、さらなるスロットルの問題を防ぎます。

大規模なデプロイメントでは、Podをさらに追加するにつれて、このアプローチが拡張したり永続化したりする可能性は低くなります。

CPUスロットリングは、応答時間とCPUスロットリングの間に直接的な相関関係があるため、重要なアプリケーション・パフォーマンス・メトリクスです。これはユーザーにとって素晴らしいニュースです。KubernetesとOpenShiftから直接このメトリクスを取得できるからです。

アプリケーションの応答時間を短く抑え、CPUをスロットルさせず、高いパフォーマンスのアプリケーションを維持するためには、まず、CPUスロットリングが発生している場合、CPUコア使用率だけに依存することはできないことを理解する必要があります。アプリケーションの性能に影響を与えるすべての分析とリソースの依存関係を考慮する必要があります。IBM® Turbonomicは、これらの考慮事項を分析プラットフォームに組み込んでいます。

コンテナの適正化におけるアクションを決定する際、Turbonomicは以下の4つの側面を継続的に分析します。

1. CPU制限
2. CPU要求
3. メモリー制限
4. メモリー要求

Turbonomicは、スロットルのリスクを軽減し、アプリケーションがスムーズに実行できるようにするCPU制限を決定することができます。これはすべて、プラットフォームがトレードオフを分析および管理するための一要素としてCPUスロットリングを追加することによるものです。CPUスロットリングの次元を追加することで、アプリケーションの応答時間が短縮されます。

これに加えて、Turbonomicはポッドを移動しクラスターを拡張するためのアクションを生成します。周知の通り、これはフル・スタックの課題です。顧客はKPIを確認し、「どのサービスが制限されているか」と質問することができます。また、各サービスのCPUスロットリングの履歴を理解し、各サービスがアプリケーションの応答時間と直接的に関連付けられていることを思い出すことができるため、システムのパフォーマンスを把握する貴重な時間枠が得られます。

Kubernetesの文脈では、Turbonomicの主なメリットの1つは、顧客がマルチテナント・プラットフォーム・ストラテジーを再設計するのではなく、プラットフォーム・ストラテジーの意図しない結果を迅速に特定して修復できることです。TurbonomicはCPUスロットリングのメトリクスを監視できるだけでなく、CPUリミットのサイズを自動的に調整し、スロットリングを管理可能なレベルまで下げることもできます。

IBM Turbonomic は、クラウドの支出とパフォーマンスを同時に最適化するのに役立ちます。また、重要なアクションをリアルタイムかつ人間の介入なしで継続的に自動化し、スタックのあらゆる層でコンピューティング、ストレージ、ネットワークのリソースを最も効率的な形でアプリケーションに事前に割り振ります。