Kubernetesキャパシティ設計実践：HPA/VPA/Cluster Autoscalerを衝突させない運用術

Kubernetes は「自動でスケールするから安心」と思われがちですが、実運用では逆です。HPA、VPA、Cluster Autoscaler（CA）の設定が噛み合わないと、スケールアウトと再スケジューリングが衝突し、レイテンシ悪化やコスト増大を引き起こします。

本記事では、3つのオートスケーリング機構を同時運用する際の設計ポイントを、障害対応目線で整理します。

1. 役割分担を明確にする

まず前提として、各コンポーネントの責務を固定します。

  • HPA: Pod 数を短期的に増減
  • VPA: Pod あたりの requests/limits を中長期で最適化
  • CA: ノード数を増減

この役割分担が曖昧だと、同じ問題を複数レイヤーで同時に解こうとして不安定化します。特に Web/API ワークロードでは、HPA を主軸、VPA は recommendation 中心で始めるのが安全です。

2. requests/limits が崩れていると全て失敗する

HPA の CPU 指標は requests 基準で計算されます。requests が不正確だと、HPA の判断もズレます。最初にやるべきは次です。

  1. 過去 2 週間の実使用量を可視化
  2. p95 使用量を requests の初期値に設定
  3. limits は requests の 1.5〜2 倍で開始

極端に低い requests は「見かけの高負荷」を作り、不要スケールを誘発します。逆に高すぎる requests は CA の過剰増設を招きます。

3. HPA 指標選定の実践

CPU だけで運用すると、I/O 待ちや外部 API 待ちのボトルネックを見逃します。推奨は複合指標です。

  • CPU Utilization（基本）
  • メモリ使用率（リーク監視）
  • RPS あたりレイテンシ（SLO 接続）
  • Queue 長（非同期処理）

autoscaling/v2 では複数メトリクスを扱えるため、最初から設計しておくと後で楽です。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api
  minReplicas: 3
  maxReplicas: 30
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 60
    - type: Pods
      pods:
        metric:
          name: http_requests_per_second
        target:
          type: AverageValue
          averageValue: "80"

4. スケール挙動を安定化する

HPA は設定次第で「増えすぎ・減りすぎ」を起こします。behavior を入れて振動を抑えます。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

behavior:
  scaleUp:
    stabilizationWindowSeconds: 0
    policies:
      - type: Percent
        value: 100
        periodSeconds: 60
  scaleDown:
    stabilizationWindowSeconds: 300
    policies:
      - type: Percent
        value: 20
        periodSeconds: 60

スケールアップは素早く、スケールダウンは慎重に、が基本です。障害時の復旧速度と平常時コストのバランスを取りやすくなります。

5. VPA の安全な導入順序

VPA をいきなり Auto で入れると、Pod 再作成が頻発し、ピーク時間帯に影響することがあります。次の順序を推奨します。

  1. Off で recommendation だけ収集
  2. 2〜4週間データ蓄積
  3. 非クリティカルなバッチ系から Auto 開始
  4. API 系は Initial または手動反映を継続

この段階導入にすると、VPA が既存 SLO を壊すリスクを抑えられます。

6. HPA と VPA の衝突回避

同一 Deployment で CPU/Memory の両方を HPA と VPA が同時に強く制御すると、調整ループが競合します。現場では次の運用が現実的です。

  • HPA: レプリカ数を制御（主）
  • VPA: requests 最適化（従）
  • クリティカルサービスは VPA recommendation を人間レビューして反映

また、メモリで OOM が起こるサービスは、HPA より先にアプリ側リーク調査を優先します。スケールで隠すと後で必ず再発します。

7. Cluster Autoscaler の盲点

CA は Pending Pod を見てノードを増やしますが、以下の条件で期待通り動きません。

  • PDB が厳しすぎて eviction できない
  • NodeSelector/taint 制約で配置先がない
  • requests が過大で BinPacking 不可能

スケールしない時の確認手順を runbook 化しておくと、夜間障害で迷いません。

  1. Pending Pod の events を確認
  2. CA logs で scale-up decision を確認
  3. node group の上限値と quota を確認
  4. Pod 制約（affinity/taint/tolerations）を確認

8. 典型障害シナリオと対処

シナリオA: 突発トラフィックで 5xx 増加

  • 兆候: CPU 90%超、pod 起動待ち
  • 対処: HPA minReplicas を一時引き上げ、イメージ pull 最適化、readiness 調整
  • 恒久策: 予測ピーク前の scheduled scaling を導入

シナリオB: コスト急増

  • 兆候: ノード数だけ増えて利用率低い
  • 対処: requests 見直し、scaleDown stabilization 調整、CA consolidate 有効化
  • 恒久策: ワークロード別の node pool 分離

シナリオC: 断続的なタイムアウト

  • 兆候: CPU 余裕あり、レイテンシ悪化
  • 対処: 外部依存（DB/Redis/API）をトレースで確認
  • 恒久策: HPA 指標に queue 長・レイテンシを追加

9. 実運用のメトリクスセット

運用ダッシュボードには、最低限次を置きます。

  • HPA current/desired replicas
  • Pod 起動時間（image pull + readiness）
  • Pod Pending 数と理由
  • Node 利用率（CPU/Memory）
  • CA scale up/down イベント数
  • 5xx 率と p95 latency

このセットがあると「スケーラが原因か、アプリが原因か」を 5 分以内で切り分けられます。

10. 段階的チューニング手順（4週間）

Week 1: ベースライン計測

  • 現行 requests/limits と実使用量を比較
  • HPA 閾値を仮設定（CPU 60%）

Week 2: 振動抑制

  • behavior 追加
  • scaleDown window を 300s 前後で調整

Week 3: 指標追加

  • RPS/queue 指標を導入
  • アラートを SLO 連動へ変更

Week 4: コスト最適化

  • idle 時の minReplicas 見直し
  • node pool の統廃合

この 4 週間を回すだけでも、無駄スケールと障害時復旧の両方が改善します。

11. 導入チェックリスト

  • requests/limits が実使用量に基づいている
  • HPA に behavior を設定済み
  • VPA は recommendation 期間を経て適用している
  • CA の上限値・quota・制約を定期点検している
  • SLO 指標とスケーリング指標を接続している
  • 典型障害シナリオの runbook がある

Kubernetes のスケーリングは、機能を有効にするだけでは安定しません。役割分担、指標設計、調整ループの制御、そして runbook をセットで整えることで、初めて「自動化が味方になる」状態を作れます。