HPA on AI2CORE - AI技術ブログ

Kubernetes HPA/VPA完全ガイド：本番環境で失敗しないオートスケーリング設計と実装

Sun, 08 Mar 2026 10:00:00 +0900

はじめに

Kubernetesを本番環境で運用する上で、適切なリソース管理とスケーリングは避けて通れない課題です。過剰なリソース割り当てはコストの無駄になり、不足していればパフォーマンス低下やサービス障害につながります。

本記事では、Kubernetesの自動スケーリング機能であるHorizontal Pod Autoscaler（HPA）とVertical Pod Autoscaler（VPA）について、基礎概念から本番環境での実践的な運用ノウハウまでを詳しく解説します。

HPAとVPAの違い

Horizontal Pod Autoscaler（HPA）

HPAは、Pod数を水平方向にスケールさせる機能です。負荷が増加するとPod数を増やし、負荷が減少するとPod数を減らします。

適用シーン：

ステートレスなWebアプリケーション
APIサーバー
ワーカープロセス

Vertical Pod Autoscaler（VPA）

VPAは、個々のPodのリソース要求（CPU/メモリ）を垂直方向に調整する機能です。実際の使用状況に基づいて、より適切なリソース割り当てを推奨・適用します。

適用シーン：

ステートフルなアプリケーション
データベースやキャッシュサーバー
バッチ処理ジョブ

HPA実践ガイド

基本的なHPA設定

まずはシンプルなCPUベースのHPAから始めましょう。

 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
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78


# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-api
  namespace: production
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web-api
  template:
    metadata:
      labels:
        app: web-api
    spec:
      containers:
      - name: web-api
        image: myregistry/web-api:v1.2.3
        resources:
          requests:
            cpu: 200m
            memory: 256Mi
          limits:
            cpu: 1000m
            memory: 512Mi
        ports:
        - containerPort: 8080
        readinessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 10
          periodSeconds: 5
---
# hpa.yaml
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-api-hpa
  namespace: production
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web-api
  minReplicas: 3
  maxReplicas: 50
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  - type: Resource
    resource:
      name: memory
      target:
        type: Utilization
        averageUtilization: 80
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
      - type: Percent
        value: 10
        periodSeconds: 60
    scaleUp:
      stabilizationWindowSeconds: 0
      policies:
      - type: Percent
        value: 100
        periodSeconds: 15
      - type: Pods
        value: 4
        periodSeconds: 15
      selectPolicy: Max

カスタムメトリクスを使ったHPA

CPUやメモリだけでなく、アプリケーション固有のメトリクスでスケーリングすることも可能です。

Prometheus Adapterの設定

 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
26
27
28


# prometheus-adapter-config.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: prometheus-adapter-config
  namespace: monitoring
data:
  config.yaml: |
    rules:
    - seriesQuery: 'http_requests_total{namespace!="",pod!=""}'
      resources:
        overrides:
          namespace: {resource: "namespace"}
          pod: {resource: "pod"}
      name:
        matches: "^(.*)_total$"
        as: "${1}_per_second"
      metricsQuery: 'sum(rate(<<.Series>>{<<.LabelMatchers>>}[2m])) by (<<.GroupBy>>)'
    
    - seriesQuery: 'request_queue_length{namespace!="",pod!=""}'
      resources:
        overrides:
          namespace: {resource: "namespace"}
          pod: {resource: "pod"}
      name:
        matches: "^(.*)$"
        as: "${1}"
      metricsQuery: 'avg(<<.Series>>{<<.LabelMatchers>>}) by (<<.GroupBy>>)'

カスタムメトリクスHPAの定義

 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
26
27
28
29


apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-api-custom-hpa
  namespace: production
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web-api
  minReplicas: 3
  maxReplicas: 100
  metrics:
  # リクエスト数ベースのスケーリング
  - type: Pods
    pods:
      metric:
        name: http_requests_per_second
      target:
        type: AverageValue
        averageValue: 1000  # Pod当たり1000 RPS
  # キュー長ベースのスケーリング
  - type: Pods
    pods:
      metric:
        name: request_queue_length
      target:
        type: AverageValue
        averageValue: 10  # Pod当たりキュー長10以下

外部メトリクスを使ったスケーリング

SQSキューやPub/Subサブスクリプションなど、外部システムのメトリクスに基づくスケーリングも可能です。

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


apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: queue-worker-hpa
  namespace: production
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: queue-worker
  minReplicas: 1
  maxReplicas: 50
  metrics:
  - type: External
    external:
      metric:
        name: sqs_queue_messages_visible
        selector:
          matchLabels:
            queue_name: "production-tasks"
      target:
        type: AverageValue
        averageValue: 20  # ワーカー当たり20メッセージ

HPAのスケーリング動作を制御するbehavior設定

Kubernetes 1.18以降では、behaviorフィールドでスケーリングの動作を細かく制御できます。

 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
26
27
28
29
30


behavior:
  scaleDown:
    # スケールダウン前の安定化期間（急な縮小を防ぐ）
    stabilizationWindowSeconds: 300
    policies:
    # 60秒ごとに最大10%減少
    - type: Percent
      value: 10
      periodSeconds: 60
    # または60秒ごとに最大2 Pod減少
    - type: Pods
      value: 2
      periodSeconds: 60
    # 複数ポリシーがある場合、最小の変更量を採用
    selectPolicy: Min
  
  scaleUp:
    # スケールアップは即座に反応
    stabilizationWindowSeconds: 0
    policies:
    # 15秒ごとに最大100%増加
    - type: Percent
      value: 100
      periodSeconds: 15
    # または15秒ごとに最大4 Pod増加
    - type: Pods
      value: 4
      periodSeconds: 15
    # 複数ポリシーがある場合、最大の変更量を採用
    selectPolicy: Max

VPA実践ガイド

VPAのインストール

1
2
3
4
5
6
7


# VPAコンポーネントのインストール
git clone https://github.com/kubernetes/autoscaler.git
cd autoscaler/vertical-pod-autoscaler
./hack/vpa-up.sh

# インストール確認
kubectl get pods -n kube-system | grep vpa

VPAの設定

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


apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: web-api-vpa
  namespace: production
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web-api
  updatePolicy:
    updateMode: "Auto"  # Off, Initial, Recreate, Auto
  resourcePolicy:
    containerPolicies:
    - containerName: web-api
      minAllowed:
        cpu: 100m
        memory: 128Mi
      maxAllowed:
        cpu: 4
        memory: 8Gi
      controlledResources: ["cpu", "memory"]
      controlledValues: RequestsAndLimits

VPAの動作モード

モード	説明	ユースケース
Off	推奨値の計算のみ。適用しない	初期検証、リソース分析
Initial	Pod作成時のみ適用	安全に導入したい場合
Recreate	Podを再作成して適用	ダウンタイム許容可能な場合
Auto	最適な方法で自動適用	本番環境での運用

VPAの推奨値を確認

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


# VPAの状態確認
kubectl describe vpa web-api-vpa -n production

# 出力例
Status:
  Recommendation:
    Container Recommendations:
    - Container Name: web-api
      Lower Bound:
        Cpu:     150m
        Memory:  180Mi
      Target:
        Cpu:     250m
        Memory:  320Mi
      Uncapped Target:
        Cpu:     250m
        Memory:  320Mi
      Upper Bound:
        Cpu:     500m
        Memory:  640Mi

HPAとVPAの併用

HPAとVPAを同じDeploymentに適用する場合、注意が必要です。両者がリソース設定を競合して変更すると、予期しない動作が発生する可能性があります。

推奨アプローチ1：VPAをOff/Initialモードで使用

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


# VPAは推奨値の計算のみ
apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: web-api-vpa
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web-api
  updatePolicy:
    updateMode: "Off"  # 自動適用しない
  resourcePolicy:
    containerPolicies:
    - containerName: web-api
      controlledResources: ["memory"]  # メモリのみVPAで管理

推奨アプローチ2：リソース種別で分担

 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
26
27
28
29
30
31
32
33
34
35
36


# VPAはメモリのみ管理
apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: web-api-vpa
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web-api
  updatePolicy:
    updateMode: "Auto"
  resourcePolicy:
    containerPolicies:
    - containerName: web-api
      controlledResources: ["memory"]  # CPUは管理しない
---
# HPAはCPUベースでスケーリング
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-api-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web-api
  minReplicas: 3
  maxReplicas: 50
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

本番環境での設計ベストプラクティス

1. 適切なリソースrequestsの設定

HPAはrequestsに対する使用率を計算します。requestsが不適切だと、スケーリングも不適切になります。

1
2
3
4
5
6
7
8
9


resources:
  requests:
    # 実際の平均使用量に近い値を設定
    cpu: 200m     # 観測された平均: 180m
    memory: 256Mi # 観測された平均: 220Mi
  limits:
    # バースト時の上限
    cpu: 1000m
    memory: 512Mi

2. Pod Disruption Budgetの設定

スケールダウン時にサービス断が発生しないよう、PDBを設定します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: web-api-pdb
  namespace: production
spec:
  minAvailable: 2  # または maxUnavailable: 1
  selector:
    matchLabels:
      app: web-api

3. Readiness Probeの最適化

新しいPodがトラフィックを受け入れる前に、十分なウォームアップ時間を確保します。

1
2
3
4
5
6
7
8


readinessProbe:
  httpGet:
    path: /health/ready
    port: 8080
  initialDelaySeconds: 30  # アプリ起動時間を考慮
  periodSeconds: 10
  successThreshold: 1
  failureThreshold: 3

4. スケーリングのテスト

本番投入前に、負荷テストでスケーリング動作を検証します。

1
2
3
4
5


# 負荷テストツール（k6）でのテスト例
k6 run --vus 100 --duration 10m load-test.js

# HPAの状態を監視
watch kubectl get hpa web-api-hpa -n production

トラブルシューティング

HPAが動作しない場合

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


# HPAの状態確認
kubectl describe hpa web-api-hpa -n production

# よくあるエラー
# 1. "unable to get metrics for resource cpu"
#    → metrics-serverが動作していない
kubectl get pods -n kube-system | grep metrics-server

# 2. "missing request for cpu"
#    → Podにresources.requestsが設定されていない

# 3. ScalingActive: False
#    → メトリクスが取得できていない
kubectl get --raw "/apis/metrics.k8s.io/v1beta1/pods" | jq

VPAの推奨が反映されない場合

1
2
3
4
5
6


# VPAコンポーネントの状態確認
kubectl logs -n kube-system -l app=vpa-recommender
kubectl logs -n kube-system -l app=vpa-updater

# Podのアノテーション確認
kubectl get pod  -o jsonpath='{.metadata.annotations}'

スケーリングが遅い場合

1
2
3
4
5
6
7
8


# HPAのscaleUp設定を調整
behavior:
  scaleUp:
    stabilizationWindowSeconds: 0  # 即座にスケールアップ
    policies:
    - type: Percent
      value: 200  # より積極的にスケール
      periodSeconds: 10

メトリクス収集とモニタリング

Prometheus + Grafanaでのダッシュボード

 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
26
27
28


# PrometheusRuleでアラート設定
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: hpa-alerts
  namespace: monitoring
spec:
  groups:
  - name: hpa.rules
    rules:
    - alert: HPAAtMaxReplicas
      expr: |
        kube_horizontalpodautoscaler_status_current_replicas
        == kube_horizontalpodautoscaler_spec_max_replicas
      for: 15m
      labels:
        severity: warning
      annotations:
        summary: "HPA {{ $labels.horizontalpodautoscaler }} is at max replicas"
        
    - alert: HPAScalingFailed
      expr: |
        kube_horizontalpodautoscaler_status_condition{condition="ScalingActive",status="false"} == 1
      for: 5m
      labels:
        severity: critical
      annotations:
        summary: "HPA {{ $labels.horizontalpodautoscaler }} scaling is inactive"

まとめ

Kubernetesのオートスケーリングを効果的に活用するためのポイントをまとめます：

HPAとVPAの使い分け：ステートレスなアプリにはHPA、ステートフルなアプリにはVPAが適している
適切なメトリクス選定：CPU/メモリだけでなく、アプリケーション固有のメトリクスも検討
behaviorによる動作制御：急激なスケーリングを防ぎ、安定した運用を実現
PDBとの組み合わせ：スケールダウン時のサービス断を防止
事前の負荷テスト：本番投入前にスケーリング動作を検証

オートスケーリングは設定して終わりではありません。定期的にメトリクスを確認し、実際の負荷パターンに合わせて調整を続けることが、効率的なKubernetes運用の鍵となります。

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

Tue, 03 Mar 2026 09:10:00 +0900

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 の判断もズレます。最初にやるべきは次です。

過去 2 週間の実使用量を可視化
p95 使用量を requests の初期値に設定
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 再作成が頻発し、ピーク時間帯に影響することがあります。次の順序を推奨します。

Off で recommendation だけ収集
2〜4週間データ蓄積
非クリティカルなバッチ系から Auto 開始
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 化しておくと、夜間障害で迷いません。

Pending Pod の events を確認
CA logs で scale-up decision を確認
node group の上限値と quota を確認
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 をセットで整えることで、初めて「自動化が味方になる」状態を作れます。