Three Misunderstandings of Kubernetes HPA and Guidelines for Avoiding Pits

クラウドコンピューティングがもたらすメリットの一つに弾力性があります。Kubernetes はクラウドネイティブなシナリオにおいて水平方向の自動スケーリング機能 (HPA) を提供し、リアルタイムの指標に基づいてアプリケーションをスケールアウト/スケールインできます。しかし、HPA の実際の動作は直感的な期待と異なる場合があり、認識の誤りが生じることがあります。本稿では、EDAS のユーザーが HPA を使用する際によく遭遇する 3 つの認識の誤りをまとめます。

誤解 1：HPA にスケールアウトのデッドゾーンが存在する

現象：Request=Limit の場合で、目標使用率が 90% を超えると、正常にスケールアウトできない。

原因分析：HPA には許容範囲 (デフォルトで 10%) が存在します。指標の変化が許容範囲内の場合、HPA はそのスケーリング操作を無視します。目標使用率が 90% の場合、実際の使用率が 81% から 99% の間は HPA に無視されます。

落とし穴回避ガイド：Request=Limit の場合、目標使用率を高めに設定しすぎないことでスケールアウトのデッドゾーンを回避してください。また、パッシブなスケールアウトには一定の遅延時間があるため、トラフィックの急増に対応できるよう、より大きなバッファを確保しておくことが重要です。

誤解 2：使用率の計算方式を誤解し、HPA のスケールアウトが期待と一致しない

現象：Limit>Request の場合、50% の使用率を設定しているのに、使用量が Limit の 50% に達する前にスケールアウトが発生する。

原因分析：HPA はリソース要求 (Request) に基づいて使用率を計算します。Limit>Request の場合、実際の使用率は 100% を超えることがあります。

落とし穴回避ガイド：重要なアプリケーションには Request=Limit を設定し、リソースの専有使用を確保してください。リソース共有を許容できるアプリケーションには、目標使用率を高く設定しすぎないでください。クラスターリソースが逼迫している場合、過剰にリソースを使用する Pod が強制終了され、サービス中断につながる可能性があります。

誤解 3：スケーリング動作が常に遅れ、スケールアウト/スケールインの挙動が期待と一致しない

現象：指標が急激に上昇しても HPA は即座にスケールアウトせず、数回に分けてスケールアウトが行われ、指標が最終的に安定したときのインスタンス数も期待値と異なる。

原因分析：HPA の設計アーキテクチャ上、スケールアウト/スケールインは常に遅延を伴います。スケーリング動作は弾性動作と許容範囲の複合作用を受けます。弾性動作はスケーリングレートを制限し、一度に目標インスタンス数までスケールアウト/スケールインすることはありません。一方、許容範囲は指標の小さな変化を無視するため、複数回のスケールアウトが発生するシナリオでは、最終的なインスタンス数が当初の計算値と異なる可能性があります。

落とし穴回避ガイド：以下を参照して HPA の動作原理を理解し、適切なスケーリング動作を設定してください。

HPA の動作メカニズム

認識の誤りを解消する前に、HPA の動作メカニズムを整理する必要があります。

図に示すように、HPA コントローラーの柔軟機能は主に 4 つのステップに分かれます。

1. HPA リソースをモニターする。HPA リソースが作成されるか、HPA の設定が変更されると、HPA コントローラーは即座に感知し、調整を行います。

2. Metrics API から対応するメトリクスデータを取得する。Metrics Server は以下の 3 種類に分類されます。

a. Kubernetes MetricServer：コンテナレベルの CPU/メモリ使用量を提供します。

b. カスタム MetricServer：Kubernetes クラスターのカスタムリソースからメトリクスデータを提供します。

c. 外部 MetricServer：Kubernetes クラスターの外部からメトリクスデータを提供します。

3. 各指標項目がそれぞれ目標インスタンス数を計算し、最終的にすべての目標インスタンス数の最大値を現在のワークロードの目標インスタンス数として採用します。

4. 対応するワークロードを調整します。

ステップ 2 から 4 は 15 秒ごとに実行されます。周期を変更する場合は、KCM の設定パラメーター --horizontal-pod-autoscaler-sync-period を調整してください。

データソース

前述の図に示すように、HPA は現在 5 つの指標ソースと 3 つのメトリクスサービス (MetricsServer) を提供しています。簡単に紹介します。

1. Resource：Pod レベルの CPU/メモリ使用量を提供します。

2. ContainerResource：コンテナレベルの CPU/メモリ使用量を提供します。

3. Object：Kubernetes クラスター内の任意のリソースに関する指標を提供します。

4. Pods：Kubernetes クラスター内の Pod に関する指標を提供します。

5. External：Kubernetes クラスター外部のメトリクスデータを提供します。

補足として、Kubernetes をセルフビルドするシナリオでは、これら 3 つの MetricsServer を追加でインストールする必要があり、いずれも KCM の外部で動作します。下表に、各 Kubernetes クラスターでの MetricsServer のデプロイメント状況をまとめます。

指標の計算方式

HPA は 3 種類の目標値タイプを提供します。

1. 合計値 (Value)

2. 平均値 = 合計値 / 現在のインスタンス数

3. 使用率 = 平均値 / リソース要求

補足として、使用率はリソース要求 (Request) に基づいて計算されるため、リソース要求を設定しないと HPA は正常に動作しません。

下図は、5 つの指標ソースがサポートする目標値タイプを示しています。すべての指標ソースが平均値をサポートしていることがわかります。

単一指標の目標インスタンス数の計算ルールは以下の通りです。

許容範囲の概念が導入されています。これは、目標値付近の小規模なジッターを許容して無視できるというものです。このパラメーターが必要な理由は、指標値が常に変動する値であり、小さな変化を無視しないとアプリケーションの継続的なスケールアウト/スケールインを引き起こし、システム全体の安定性に影響を与える可能性が高いためです。

下図に示すように、指標値が許容範囲 (ピンク色のエリア) に収まっている場合、目標インスタンス数は現在のインスタンス数と等しくなります。許容範囲の上限と下限は、それぞれ目標値の 0.9 倍と 1.1 倍です。

複数の指標ルールが設定されている場合、最終的な目標インスタンス数のルールは以下の通りです。

一言でまとめると、単一指標の変動は無視され、複数指標間では最大値が採用され、最終的なインスタンス数は下限と上限の間に収まります。

スケーリング動作

場合によっては、メトリクスデータに頻繁かつ顕著なジッターが発生します。下図に示すように、指標のジッターや断続的なトラフィック低下により使用率が低下することがあります。指標の変動幅が許容範囲を超えている場合でも、アプリケーションの安定性の観点からスケールインは期待しません。この問題を解決するため、HPA はスケーリング動作を制御する設定を導入しました。これは HPA (autoscaling/v2beta2) で導入され、Kubernetes クラスターのバージョン >=1.18 が必要です。

HPA のスケーリング動作は、スケールアウト動作とスケールイン動作に分かれます。動作は以下の 3 つの要素で構成されます。

• 安定化ウィンドウ：安定化ウィンドウは過去の期間に計算された目標インスタンス数を参照し、極値を選択して最終結果とすることで、一定のタイムウィンドウ内でシステムが安定することを保証します。スケールアウトでは最小値を採用し、スケールインでは最大値を採用します。

• ステップポリシー：一定期間内のインスタンス数の変化範囲を制限します。ステップタイプ、ステップ値、期間の 3 つの要素で構成されます。なお、ここでの期間の概念は前述の安定化ウィンドウとは異なります。ここでの期間は、インスタンス数の変化を計算するためにどれだけ遡るかを定義するものです。

• 選択ポリシー：複数のステップポリシーの計算結果から選択するために使用されます。最大値、最小値、無効の 3 つのポリシーをサポートします。

まとめ

ここまでで、HPA の動作メカニズムをおおむね理解できました。HPA を適切に活用することで、リソースの使用率を効果的に向上できます。この過程でいくつかの注意点をまとめました。これらのポイントを覚えておくことで、HPA 使用時に「落とし穴を効果的に回避」できます。

1. HPA の設計アーキテクチャ上、パッシブな指標応答によるスケーリングのみ可能です。このモードではスケーリング遅延が必ず発生します。現在、Alibaba Cloud コンテナサービスは予測機能を備えた AHPA を導入しており、スケーリング遅延を効果的に低減できます。

2. HPA の使用率計算方式はリソース要求 (Request) に基づいています。実際の使用率や目標使用率が 100% を超えることは正常な動作です。高い目標使用率を設定するには、クラスターリソースを適切に計画し、関連するリスクを評価する必要があります。

3. HPA の許容範囲の概念は指標変動によるシステム振動の問題を軽減できますが、同時にスケールアウトのデッドゾーンの問題も生じるため、運用担当者が回避する必要があります。

4. HPA の設計アーキテクチャは多様な指標タイプの機能拡張を可能にしており、対応する MetricsServer を開発/インストールする必要があります。たとえば、EDAS はユーザーにマイクロサービスの RT および QPS 指標を提供します。

5. HPA にはスケーリング動作が存在し、対応するパラメーターを設定しなくてもデフォルトの動作があります。スケールアウト動作の安定化ウィンドウはデフォルトで 0 です。ノイズデータによりアプリケーションが頻繁にスケールアウトされる場合、短いスケールアウト安定化ウィンドウを設定して急激なノイズを回避できます。

6. 単一の HPA は複数の指標の柔軟設定をサポートします。1 つのアプリケーションに複数の HPA を設定しないでください。相互に影響し合い、アプリケーションに障害を引き起こす可能性があります。

クラウドネイティブなシナリオでは、弾力性はより豊かになり、弾力性の指標もビジネスに合わせてカスタマイズできます。アプリケーション PaaS プラットフォーム (エンタープライズ向け分散アプリケーションサービス EDAS など) は、クラウドベンダーのコンピューティング、ストレージ、ネットワーキングにおける基盤技術機能を組み合わせ、クラウドの利用コストを低減できます。ただし、ビジネスアプリケーションには (ステートレス/設定とコードのデカップリングなどの) 課題もあります。より広い視点から見れば、これはクラウドネイティブ時代のアプリケーションアーキテクチャの課題です。しかし、アプリケーションがよりクラウドネイティブになればなるほど、クラウド技術の恩恵をより身近に受けられるようになります。