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の動作モード

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 <pod-name> -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のオートスケーリングを効果的に活用するためのポイントをまとめます：

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

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

Kubernetes運用で一番つらい事故は、クラスタが壊れるよりも「本来防げたはずのミスがそのまま本番へ入る」ことです。たとえば、latest タグのイメージが本番に入り再現不能になる、resources 未設定でノードが詰まる、privileged コンテナが混入する。これらは人の注意力だけに依存すると必ず再発します。

そこで有効なのが Admission Policy（入場制御）です。本記事では Kyverno を使って、現場で本当に運用できるポリシー群を段階導入する手順をまとめます。単なる「denyの例」ではなく、監査→警告→強制の移行、例外管理、CI連携まで含めて解説します。

1. なぜKyvernoなのか

OPA Gatekeeper も強力ですが、Kyvernoは以下の特徴があり、初期導入が比較的スムーズです。

• YAML中心で書ける（Rego学習コストを後回しにしやすい）
• validate / mutate / generate / verifyImages を一貫して扱える
• PolicyReportにより違反可視化がしやすい
• Pod SecurityやSupply Chain対策との相性が良い

「まずルールを回し始める」目的なら、Kyvernoは現実的な選択肢です。

2. 先に決めるべき設計原則

導入前に、以下だけは先に決めておきます。

1. 導入フェーズ: Audit → Enforce を基本にする
2. 責任分界: プラットフォームチームが共通ポリシー、各チームがアプリ固有例外
3. 例外の期限: 永久例外は禁止。期限付きで必ず棚卸し
4. 観測性: 違反数・対象Namespace・上位違反ルールをダッシュボード化

この原則なしにルールだけ増やすと、運用が破綻します。

3. 最小導入手順（30〜60分）

3.1 Kyvernoのインストール

1
2
3
4
5
6
7
8
9

helm repo add kyverno https://kyverno.github.io/kyverno/
helm repo update

helm upgrade --install kyverno kyverno/kyverno \
  -n kyverno --create-namespace \
  --set admissionController.replicas=2 \
  --set backgroundController.replicas=2 \
  --set cleanupController.replicas=1 \
  --set reportsController.replicas=1

本番では可用性のため、admission/backgroundは最低2レプリカ推奨です。

3.2 まずはAuditモードで3ルール

最初に効くルールは、次の3つです。

• イメージタグに latest を禁止
• CPU/Memory requests/limits必須
• privileged: true を禁止

例: latest タグ禁止

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

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: disallow-latest-tag
spec:
  validationFailureAction: Audit
  background: true
  rules:
    - name: validate-image-tag
      match:
        any:
          - resources:
              kinds:
                - Pod
      validate:
        message: "latestタグは禁止です。固定タグまたはdigestを使用してください。"
        foreach:
          - list: "request.object.spec.containers"
            deny:
              conditions:
                any:
                  - key: "{{ element.image }}"
                    operator: Matches
                    value: ".*:latest$"

3.3 レポートで現状把握

1
2
3

kubectl get policyreport -A
kubectl get clusterpolicy
kubectl describe clusterpolicy disallow-latest-tag

導入直後は違反が大量に出るのが普通です。ここで「Kyvernoが厳しすぎる」と判断しないでください。違反は“見えていなかった負債”です。

4. 実務で効くルールセット（具体例）

4.1 リソース未設定防止

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

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-resources
spec:
  validationFailureAction: Audit
  rules:
    - name: check-resources
      match:
        any:
          - resources:
              kinds: ["Pod"]
      validate:
        message: "全コンテナにrequests/limitsを設定してください。"
        pattern:
          spec:
            containers:
              - resources:
                  requests:
                    cpu: "?*"
                    memory: "?*"
                  limits:
                    cpu: "?*"
                    memory: "?*"

4.2 特権設定防止

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

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: disallow-privileged
spec:
  validationFailureAction: Enforce
  rules:
    - name: no-privileged
      match:
        any:
          - resources:
              kinds: ["Pod"]
      validate:
        message: "privilegedコンテナは禁止です。"
        pattern:
          spec:
            containers:
              - securityContext:
                  =(privileged): "false"

4.3 Digest固定の推奨（Supply Chain）

本来は digest 固定が理想です。移行期は Audit で始め、違反率が下がってから Enforce に切り替えます。

5. AuditからEnforceへ移行する基準

「何となく」で切り替えると炎上します。次の客観指標を使うと安全です。

• 直近14日で対象ポリシー違反率が5%未満
• 主要Namespace（prod/stg/shared）で違反ゼロ
• 例外申請フロー（Issue/PRテンプレート）が整備済み
• 当番がトラブル時に切り戻し手順を理解している

validationFailureAction を一括で上げるのではなく、ルール単位・Namespace単位で段階化するのがポイントです。

6. 例外運用のテンプレート

ポリシー導入で最も壊れるのは「例外管理」です。おすすめは以下。

• 例外は PolicyException で明示
• 期限（例: 14日）を必須にする
• チケット番号をannotationで必須化
• 期限切れを毎日バッチで通知

例外YAMLに expires と owner を必須化すると、放置率が一気に下がります。

7. CIに組み込んで“本番前に落とす”

クラスタ投入時に拒否されるより、PR段階で検知される方が開発体験は良いです。kyverno-cli をCIで実行します。

1

kyverno apply policies/ -r manifests/ --audit-warn

GitHub Actions例:

1
2
3
4

- name: Validate manifests with Kyverno
  run: |
    kyverno version
    kyverno apply ./policies -r ./k8s --audit-warn

これで「マージ後に初めて失敗する」パターンを減らせます。

8. よくある障害と対処

症状1: 正常なPodまで拒否される

• match条件が広すぎる可能性
• exclude で kube-system や監視系を一時除外
• まずAuditで影響範囲を確認してからEnforceへ

症状2: Admission timeoutでデプロイ遅延

• Kyvernoコンポーネントのリソース不足を確認
• policy数が多い場合、ルール統合とmatch最適化
• API Serverとのネットワーク遅延確認

症状3: レポートは出るが改善が進まない

• 違反上位3ルールに絞ってKPI化
• チーム別に違反件数を見える化
• 例外を期限付きに強制

9. 運用を続けるためのダッシュボード指標

最低限、以下を可視化してください。

• ルール別違反件数（7日移動平均）
• Namespace別違反件数
• Audit と Enforce の比率
• 期限切れ例外の件数
• deploy失敗要因のうちpolicy起因の割合

これを見ないと、ポリシーは「導入しただけ」で止まります。

10. 実践ロードマップ（最初の4週間）

• Week 1: Kyverno導入、3ルールをAuditで開始
• Week 2: 違反上位を改善、例外テンプレート導入
• Week 3: 一部NamespaceでEnforce化
• Week 4: CI連携完了、SLOに違反率を組み込み

4週間で「人頼みのレビュー文化」から「仕組みで防ぐ文化」へ移行できます。

まとめ

Kyverno導入の本質は、Kubernetesを縛ることではなく、再発するミスを設計で減らすことです。

• 最初はAuditで可視化
• 指標を持って段階的にEnforce
• 例外は期限付きで管理
• CIに前倒し検知を組み込む

この4点を守れば、ポリシーは“開発を止める壁”ではなく“事故を減らすガードレール”になります。まずは latest 禁止とリソース必須の2ルールから始めて、違反データを見ながら育てていきましょう。

「カラムを追加するだけだから大丈夫」──この油断が、本番障害の入口になります。Kubernetes のように複数バージョンの Pod が同時に存在する環境では、DB スキーマ変更はアプリ変更よりも慎重に扱う必要があります。

本記事では、Expand-Contract パターンを中心に、ゼロダウンタイムを目指すための具体手順を解説します。実際の運用では、DDLの速さより「互換性のある期間をどう作るか」が勝負です。

1. なぜKubernetesでDB移行が難しいのか

Kubernetesでは、ローリングアップデート中に新旧Podが混在します。つまり次の状態が同時に発生します。

• 新アプリは新スキーマを期待
• 旧アプリは旧スキーマしか知らない
• DBは1つしかない

このとき破綻するのが「破壊的変更を先に適用する」ケースです。たとえば旧カラムを即削除すると、旧Podがエラーを連発します。

2. 基本戦略：Expand → Migrate → Contract

ゼロダウンタイム移行の原則はこの3段階です。

1. Expand: 互換性を壊さない変更を先に入れる（新カラム追加など）
2. Migrate: アプリを段階的に切替え、データを移行する
3. Contract: 旧仕様を最終削除する（十分な監視後）

この順序なら、どの時点でも旧新どちらのアプリも動作可能にできます。

3. 具体例：users.full_name を first_name / last_name へ分割

3.1 Expand フェーズ

まず破壊的でないDDLを適用します。

1
2

ALTER TABLE users ADD COLUMN first_name text;
ALTER TABLE users ADD COLUMN last_name text;

この時点で旧アプリは full_name を使い続けられます。新アプリは新カラムに対応した実装を持っていても、まだ必須にしません。

3.2 アプリを「両対応」にする

書き込み時は両方へ保存（dual write）し、読み込み時は新カラム優先 + 旧カラムフォールバックにします。

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

def save_user_name(user_id: str, full_name: str):
    first, last = split_name(full_name)
    db.execute(
        """
        UPDATE users
        SET full_name = %s,
            first_name = %s,
            last_name = %s
        WHERE id = %s
        """,
        (full_name, first, last, user_id),
    )


def read_user_display_name(row):
    if row.first_name and row.last_name:
        return f"{row.first_name} {row.last_name}"
    return row.full_name

この両対応期間を作るのが、ゼロダウンタイムの本質です。

3.3 バックフィル（既存データ移行）

大規模テーブルでは一括更新を避け、チャンク更新します。

1
2
3
4
5
6
7

-- 疑似コードイメージ
UPDATE users
SET first_name = split_part(full_name, ' ', 1),
    last_name = split_part(full_name, ' ', 2)
WHERE id > :last_id
  AND id <= :last_id + 10000
  AND (first_name IS NULL OR last_name IS NULL);

ジョブ実装時のポイント:

• 1チャンクごとに commit
• 再開可能なチェックポイント（last_id）を保存
• 実行時間帯を制御（ピーク時間回避）

3.4 Contract フェーズ

全Podが新実装になり、フォールバックが不要と判断できたら旧カラム削除へ進みます。

1

ALTER TABLE users DROP COLUMN full_name;

削除は必ず最後です。ここを急ぐとロールバック不能になります。

4. マイグレーション実行方式の選び方

Kubernetesでは主に3パターンがあります。

A. CI/CDで先行実行（推奨）

デプロイ前に migration Job を走らせ、成功後にアプリを更新。

• メリット: 実行順序を固定しやすい
• デメリット: 長時間 migration の扱いが難しい

B. initContainer 実行

Pod起動時に migration を走らせる方式。

• メリット: 実装が単純
• デメリット: 複数Pod同時起動で競合しやすい

C. 専用 Migration Controller / Job

Argo Workflows などで明示的に管理。

• メリット: 大規模運用で監査しやすい
• デメリット: 初期構築コストが高い

中規模までなら A が最も事故が少ないです。

5. Alembic/Flyway運用の実務ポイント

5.1 1 migration = 1責務

「追加 + データ移行 + 削除」を1ファイルに詰め込むと失敗時に戻しづらくなります。Expand/Migrate/Contract を別 migration に分けて、各段階を検証可能にしてください。

5.2 lock timeout を設定する

DDL はロック待ちでアプリを止めることがあります。PostgreSQL なら lock_timeout を設定して、危険な待機を避けます。

1
2

SET lock_timeout = '5s';
ALTER TABLE ...;

失敗時は即中断し、メンテナンス時間帯に再実行する判断が可能です。

5.3 破壊的変更前に計測窓を設ける

旧カラム参照がゼロになったことを、メトリクスやログで一定期間確認してから削除します。目安として 7〜14日程度の観測期間を取ると安全です。

6. ロールバック戦略

ゼロダウンタイム設計では、ロールバック可能性を最初に決めます。

• Expand段階: ほぼ即ロールバック可能
• Migrate段階: dual write を維持していればロールバック可能
• Contract段階: 削除後は復元コスト高（バックアップ依存）

したがって、Contract 実施前に以下を満たす必要があります。

• 直近スナップショット取得済み
• 復元手順を演習済み
• 影響範囲（API・バッチ・BI）を棚卸し済み

7. 監視項目と成功判定

移行中は「成功したか」より「安全に進んでいるか」を見ます。

• APIエラー率（4xx/5xx）
• DBロック待ち時間
• スロークエリ件数
• migration ジョブ進捗（処理済み件数、残件数）
• 旧カラム参照回数

成功判定の例:

1. 新旧Pod混在中のエラー率に有意な悪化なし
2. バックフィル完了率100%
3. 旧カラム参照0が連続7日
4. Contract後24時間で異常なし

8. よくある失敗と回避策

失敗1: 非NULL制約を早く付けすぎる

バックフィル完了前に NOT NULL を付けると、旧データで失敗します。まずは nullable で追加し、データ移行後に制約追加が正解です。

失敗2: インデックス作成で書き込み停止

大きいテーブルで通常インデックス作成を行うとロックが重くなります。PostgreSQL では CREATE INDEX CONCURRENTLY を使って影響を下げます。

失敗3: migration の実行主体が複数

同時に2つのJobが走ると競合します。Kubernetes Job は排他制御（Lease/Lock）を持たせるか、CI側で単一実行を保証してください。

9. 実運用テンプレート：Migration Job と段階リリース

最後に、現場でそのまま使える最小テンプレートを示します。ポイントは「DDLを一気にやらない」「アプリ側フラグで読取切替を制御する」の2点です。

9.1 Migration Job（Expand専用）

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

apiVersion: batch/v1
kind: Job
metadata:
  name: users-expand-20260305
spec:
  backoffLimit: 0
  template:
    spec:
      restartPolicy: Never
      containers:
        - name: migrate
          image: ghcr.io/example/api:1.42.0
          command: ["bash", "-lc", "alembic upgrade 20260305_expand_users_name"]
          envFrom:
            - secretRef:
                name: api-db-secret

Expand 用 Job を分離しておけば、失敗時にアプリデプロイを止める判断が明確になります。backoffLimit: 0 にして「失敗を隠さない」運用にするのも実務で有効です。

9.2 段階リリース手順（例）

1. Expand Job 実行（DDLのみ）
2. アプリ v1（dual write + fallback read）を10%配信
3. エラー率・ロック待ちを30分監視
4. 50% → 100%へ段階拡大
5. バックフィル Job 実行
6. 旧参照ゼロ確認後に Contract 実施

Kubernetes では kubectl rollout status deployment/api -n prod を必ず監視に組み込み、配信完了判定を人間が明示的に確認する運用が安全です。

まとめ

KubernetesでのDBマイグレーションは、DDLテクニックだけでは成功しません。重要なのは、

• 互換性期間を意図的に作る
• 段階を分けて進める
• ロールバック可能性を先に設計する
• 監視で「削除してよい」根拠を取る

この4点です。Expand-Contract を守るだけで、移行の失敗率は目に見えて下がります。スキーマ変更は怖い作業ですが、手順化すれば再現可能な運用にできます。次回の変更から、ぜひこの流れで試してみてください。

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 をセットで整えることで、初めて「自動化が味方になる」状態を作れます。

Kubernetes で障害が起きたとき、技術力より先に問われるのは「順序」です。順序が崩れると、正しいコマンドを打っていても復旧が遅れます。逆に、判断フレームが決まっていれば、難しい障害でも被害を最小化できます。

本記事では、実運用で使える障害対応ランブックを、初動 15 分・復旧 60 分を目安に具体化します。対象は EKS/GKE/AKS を含む一般的な Kubernetes 本番環境です。

1. 最初の5分：人と情報の交通整理

まずやるべきは技術調査ではなく、交通整理です。

• インシデントの指揮者（IC）を1人決める
• ログ担当、メトリクス担当、アプリ担当を分ける
• Slack/Discord の専用チャンネルを作る
• 5分ごとの時系列ログ（タイムライン）を残す

この段階で「誰が何を見ているか」が曖昧だと、同じ調査を3人で繰り返し、誰も復旧判断をしない状態になります。ICは手を動かさず、意思決定に集中するのが基本です。

2. 5〜15分：影響範囲の特定

次に「どのユーザーに、どの機能で、何%の影響があるか」を確定します。

2-1. まず全体の健康状態

1
2
3

kubectl get nodes
kubectl get pods -A --field-selector=status.phase!=Running
kubectl get events -A --sort-by=.lastTimestamp | tail -n 50

見るポイント:

• Node が NotReady になっていないか
• 特定 namespace だけで CrashLoopBackOff が増えていないか
• 直近イベントに FailedScheduling や Back-off restarting failed container がないか

2-2. SLO/SLIから影響を数値化

「遅い気がする」ではなく、以下を数値で押さえます。

• エラー率（5xx / total）
• p95 / p99 レイテンシ
• リクエスト成功率
• 影響時間（何時何分から）

復旧優先順位は「売上影響」「決済影響」「ログイン影響」で並べると迷いにくいです。

3. 典型障害ごとの切り分けテンプレート

3-1. Podが再起動ループする

1
2

kubectl describe pod <pod-name> -n <ns>
kubectl logs <pod-name> -n <ns> --previous

判断軸:

1. アプリ起因（例: マイグレーション失敗、環境変数不足）
2. リソース起因（OOMKill, CPU スロットリング）
3. 依存先起因（DB接続失敗、外部APIタイムアウト）

OOMKill が見えたら、即座に requests/limits の見直し候補です。緊急回避として replicas を増やすより、まずメモリリークや一時的負荷スパイクの切り分けを優先します。

3-2. Podは生きているのに503が増える

1
2
3

kubectl get endpoints -n <ns>
kubectl describe svc <service> -n <ns>
kubectl get deploy <deploy> -n <ns> -o yaml | grep -n "readinessProbe\|livenessProbe"

よくある原因:

• readinessProbe が厳しすぎて endpoint から外れ続ける
• 依存先劣化で app は起動しているが実処理が詰まる
• HPA は増えているが、DB 接続プールが上限で飽和

このケースでは「Pod数が多いのにエラーが減らない」ので、アプリ外（DB、キュー、外部API）を疑うのが早いです。

3-3. 特定ノードでのみ障害

1
2
3

kubectl describe node <node>
kubectl top node
kubectl get pods -A -o wide | grep <node>

ノード隔離が必要なら、以下で新規スケジュールを止めます。

1
2

kubectl cordon <node>
kubectl drain <node> --ignore-daemonsets --delete-emptydir-data

drain は影響が大きい操作なので、IC の明示承認を挟むのが安全です。

4. 復旧アクションの優先順位（実務向け）

障害中は「恒久対策」を始めないこと。順番は固定します。

1. 被害抑制: feature flag で重い機能を止める
2. 暫定復旧: 直前の安定リビジョンへロールバック
3. 性能確保: replicas/HPA 一時調整、キュー消化速度調整
4. 恒久対策: 根本修正は障害収束後にPRで実施

4-1. ロールバックの型を決めておく

1
2
3

kubectl rollout history deployment/<deploy> -n <ns>
kubectl rollout undo deployment/<deploy> -n <ns> --to-revision=<rev>
kubectl rollout status deployment/<deploy> -n <ns>

ポイントは「戻す判断に迷わない基準」を事前に定義しておくことです。

• 5分間で 5xx > 2% 継続
• p95 が通常比 2倍超を 10分継続
• ログイン/決済失敗が監視閾値超え

基準がないと、誰も責任を取りたくなくて引き延ばしになります。

5. 事後対応（Postmortem）で必ず残すべきもの

障害対応の価値は、復旧速度だけではありません。再発率を下げて初めて完了です。

最低限残す項目:

• 発生時刻、検知時刻、復旧時刻
• ユーザー影響（件数、売上影響）
• 技術的原因（直接原因 / 背景要因）
• うまくいった対応、失敗した判断
• 再発防止のアクション（担当者・期限付き）

5-1. アクションを「監視」に落とす

「次は気をつける」は効果ゼロです。必ず機械化します。

例:

• CrashLoopBackOff > N件 を5分継続で即アラート
• DB接続待ち時間の p95 をダッシュボード化
• リリース直後30分は自動で高感度監視モード

6. そのまま使える障害対応チェックリスト

初動チェック（0〜15分）

• IC決定、連絡チャンネル作成
• 影響範囲（機能・ユーザー・売上）を数値化
• Node / Pod / Event の全体確認
• 直近デプロイ有無の確認

復旧チェック（15〜60分）

• 被害抑制（feature flag / トラフィック制御）
• ロールバック判断基準を満たすか確認
• 復旧後 15 分の再監視（再発確認）
• ユーザー向けステータス更新

事後チェック（24時間以内）

• Postmortem 作成
• 再発防止チケット発行
• 監視ルール・Runbook 更新

まとめ

Kubernetes 障害対応は、個人技で勝つゲームではありません。誰でも同じ順序で動ける運用設計が最も効きます。特に「初動の交通整理」「ロールバック基準の明文化」「事後の監視自動化」の3点は、復旧時間と再発率を同時に改善します。

次の障害が来たときに迷わないよう、今日のうちにこのランブックを自チーム用に1ページ化しておくことを強くおすすめします。

7. 障害を早く終わらせるための役割分担テンプレート

実際の現場では、技術調査よりコミュニケーションで詰まることが多いです。そこで、あらかじめ役割を固定しておくと復旧が速くなります。

• IC（Incident Commander）: 優先順位決定、Go/No-Go判断、対外連絡承認
• Ops Lead: クラスタ状態確認、ロールバック実行、インフラ変更の安全確認
• App Lead: アプリログ解析、機能フラグ切り替え、暫定パッチ判断
• Comms: 社内・顧客向けステータス更新、問い合わせ窓口統一

この分担があると、「調査担当が勝手に危険操作を実施する」「連絡が多重化して混乱する」といった二次被害を防げます。

8. よくあるアンチパターンと回避策

アンチパターン1: まず再デプロイしてしまう

原因が不明なまま再デプロイすると、証拠ログを失い再現不能になります。最低限 events と previous logs を保存してから操作します。

アンチパターン2: 「たぶん直った」でクローズする

復旧後 15 分の監視を省くと、同じ障害が波状的に再発します。復旧宣言は「指標が閾値内で安定した」ことを条件にします。

アンチパターン3: 障害後の改善が担当者依存

改善をドキュメント化せず担当者の記憶に任せると、同じ夜間障害を繰り返します。Runbook への反映までをインシデント完了条件に含めるべきです。

Kubernetes を導入した直後は「自動で効率化される」と期待されがちですが、実際には逆です。適切な運用ルールがないと、クラウド請求は静かに膨らみ続けます。

典型例は次の通りです。

• リクエスト/リミットが過大でノードが常時スカスカ
• 夜間トラフィック減少時も同じ台数を維持
• 開発環境が週末ずっと起動
• HPA が CPU しか見ておらず、キュー滞留を無視
• 過剰なストレージクラス（IOPS課金）を全環境で使用

本記事では、FinOps の考え方を用いて、Kubernetesコストを「見える化→改善→定着」の順に進める方法を解説します。

コスト削減の前に定義すべき指標

削減施策が失敗する理由は、目標が「安くする」しかないからです。最低でも次の 4 指標を定義します。

1. Unit Cost: 1リクエストあたりコスト / 1ジョブあたりコスト
2. Utilization: CPU・Memoryの実効使用率
3. Reliability: SLO 達成率（削減で品質を落とさない）
4. Waste Ratio: 予約/実使用の差分率

この4つを同時に追うと、単なるコストカットでなく「健全な最適化」になります。

ステップ1：可視化基盤を整える

1-1. Kubecost または OpenCost の導入

EKS/GKE/AKS いずれでも、namespace / deployment / label 単位で費用を把握できる状態にします。重要なのは team, service, env ラベルを強制することです。

推奨ラベル:

• cost-center
• owner
• environment（prod/stg/dev）
• criticality

ラベルがないと請求分析ができず、改善責任が曖昧になります。

1-2. 観測ダッシュボード

最初のダッシュボードは次を必須にします。

• Namespace別コスト（当日/前日比）
• Pod別 request/usage ギャップ
• ノード空き率（CPU、Memory）
• 時間帯別トラフィックとレプリカ数

ここまでで「どこが高いか」は見えます。次は「なぜ高いか」を潰します。

ステップ2：最も効果が高い改善施策

2-1. Right Sizing（最優先）

多くの環境で最大効果が出るのは request/limit の見直しです。VPA recommendation を参考に、まずは read-only で 2 週間観測します。

例:

• 現在: requests.cpu=1000m, 実使用 P95 が 220m
• 改善後: requests.cpu=300m

この1変更だけでノード数が 20〜35% 下がるケースがあります。

2-2. Cluster Autoscaler / Karpenter 最適化

オートスケーラーを入れていても、設定不備で縮退しないことが多いです。次をチェックします。

• scale down unneeded time が長すぎないか
• pod disruption budget が硬すぎないか
• daemonset が過剰にリソースを固定していないか

Karpenter なら Spot + On-Demand の比率制御を導入し、重要ワークロードのみ On-Demand 固定にします。

2-3. ワークロードの時間制御

開発・検証環境はスケジュール停止が有効です。平日 9:00-20:00 だけ稼働し、夜間/休日は scale to zero。

1
2

# 例: CronJobで夜間停止
kubectl scale deployment api-staging --replicas=0 -n staging

単純ですが、月額で大きく効きます。

2-4. HPA指標の改善

CPU のみでスケールすると、I/O 待ちやキュー詰まりを見逃します。Prometheus Adapter を使い、次の指標を追加します。

• queue length
• request latency P95
• in-flight request

結果として「必要な時だけ増やす」が実現し、過剰常時稼働を減らせます。

ステップ3：ストレージ/ネットワークの見直し

ストレージ

高IOPSディスクを全環境に使うのは典型的な浪費です。ワークロード特性でクラス分離します。

• DB本番: 高IOPS
• バッチ/開発: 標準クラス

スナップショット保持期間も要確認です。無制限保持は請求を圧迫します。

ネットワーク

クロスAZ通信量は見落とされがちです。チャットAPIや内部gRPCが高頻度だと、トラフィック課金が無視できません。依存サービスを同一AZに寄せる設計を検討します。

ガードレールを仕組み化する

最適化は一度で終わりません。再び膨らむので、CI/CD に制約を組み込みます。

• OPA/Gatekeeper で「requests未設定」を拒否
• ラベル欠落 (owner, cost-center) の manifest を reject
• 予算超過 namespace の新規デプロイを警告

さらに、週次で「Top Waste 10」を自動配信し、チームごとに改善オーナーを固定します。

実例：3か月で 32% 削減した手順

ある SaaS 環境（5クラスタ）で実施した順序は次の通りです。

1. 2週間の使用実績を収集
2. 上位20 deployment の rightsizing
3. staging/dev の時間停止
4. Spot 比率を 15% → 45% へ引き上げ
5. 高コストPVの棚卸し

結果:

• 月次コスト: -32%
• P95 レイテンシ: ほぼ維持
• インシデント増加: なし

ポイントは、SLO を維持しながら段階実施したことです。

よくある反論への回答

Q. 削減すると障害が増えるのでは？ A. いきなり下げると危険です。P95実績を基準に 10〜15% ずつ下げ、SLO と同時監視すれば安全に進められます。

Q. チームが協力しない A. コストを「共通責任」にすると進みません。namespaceごとに owner を明示し、改善期限を決めると動きます。

Q. どこから始めるべき？ A. Right Sizing と夜間停止です。最短で効果が出ます。

まとめ

Kubernetes コスト最適化は、節約テクニックの寄せ集めではありません。計測、改善、運用ガードレールをセットで回す FinOps プロセスです。

まずは「誰の、どのワークロードが、なぜ高いか」を可視化し、Right Sizing から着手してください。性能を落とさずにコストを下げる道筋は、思っているより現実的です。

実装テンプレート：無駄を自動検出する

可視化だけだと改善は進みません。週次で自動的に「無駄候補」を抽出してチームへ配信する仕組みを入れると、改善が継続します。

抽出ルール例:

• 7日平均で CPU 使用率 < 15% かつ request > 500m
• 夜間（0:00-6:00）にトラフィックほぼゼロなのに replicas > 1
• メモリ使用率 P95 < 40% が 14 日継続

このルールで候補を Slack/Discord に自動投稿し、オーナーと期限を付けるだけで改善率が上がります。

具体的なYAML見直し例

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

resources:
  requests:
    cpu: "250m"
    memory: "512Mi"
  limits:
    cpu: "500m"
    memory: "1Gi"

autoscaling:
  minReplicas: 1
  maxReplicas: 8
  targetCPUUtilizationPercentage: 65

ポイントは「requests を現実に寄せる」「limits を安全マージンに置く」「HPA で不足分だけ増やす」の3点です。

ガバナンス：コストを技術負債化させない

削減施策は放置すると必ず戻ります。そこで、リリースゲートに FinOps 観点を追加します。

• 新規サービスは cost label 必須
• request 未設定の Pod はデプロイ拒否
• 予算超過時は自動で注意喚起

さらに月次レビューで「削減額」だけでなく「SLO維持率」も一緒に報告することで、コスト最適化が品質改善と対立しない文化を作れます。

まとめ（実行順の再確認）

1. まず可視化（誰が何にいくら使っているか）
2. 次に Right Sizing と時間停止
3. 最後にガードレールをCI/CDに組み込む

この順番を守れば、短期の削減成果と中長期の運用安定を両立できます。

はじめに

先日閉幕した「KubeCon + CloudNativeCon Europe 2026」の熱気も冷めやらぬ中、この記事を執筆しています。今年のカンファレンスで最も注目を集め、キーノートから各セッションまで、あらゆる場所で議論の中心となっていたテーマは、間違いなくWebAssembly (Wasm) のKubernetesへのネイティブ統合と、それを支えるサイドカーレス・サービスメッシュの進化でした。

Kubernetesを運用する多くのエンジニアが、日々の業務で次のような課題に直面しているのではないでしょうか？

• 肥大化するコンテナイメージ: アプリケーションの依存関係が増えるにつれ、コンテナイメージは数百MBから数GBに達し、CI/CDパイプラインの実行時間、ストレージコスト、そしてコンテナの起動時間に悪影響を与えている。
• 「サイドカー税」の深刻化: マイクロサービスの数が増加するにつれ、各Podにインジェクトされるサービスメッシュのサイドカープロキシ（Envoyなど）が消費するCPUやメモリが無視できないレベルになっている。この「サイドカー税」は、クラスター全体のコストを押し上げる大きな要因です。
• 複雑化するセキュリティ管理: コンテナはOSの一部を同梱するため、OSレイヤーの脆弱性（CVE）スキャンとパッチ適用に追われる日々。攻撃対象領域（Attack Surface）も広くなりがちです。

もし、これらの課題に一つでも心当たりがあるなら、本記事はあなたのためのものです。KubeCon 2026で示された未来は、これらの長年の課題を根本から解決する可能性を秘めています。この記事では、Wasmとサイドカーレス・メッシュがどのように連携し、次世代のKubernetesエコシステムを形作っていくのか、具体的なコード例やアーキテクチャ図を交えながら、徹底的に解説していきます。

なぜこの技術・話題が重要なのか：背景と2つの大きな課題

この新しいトレンドを理解するためには、まず私たちが現在立っている場所、つまりコンテナとサイドカーモデルがなぜ成功し、そして今どのような壁にぶつかっているのかを振り返る必要があります。

コンテナ技術の成熟と新たなオーバーヘッド

DockerとKubernetesがクラウドネイティブの世界を切り拓いてから10年以上が経ち、コンテナはアプリケーションをパッケージングし、デプロイするためのデファクトスタンダードとなりました。しかし、その成功の裏で、いくつかの根深い課題が顕在化しています。

1. リソースオーバーヘッド: コンテナは軽量な仮想化技術ですが、ゼロオーバーヘッドではありません。各コンテナは、アプリケーションの実行に必要なライブラリやOSのユーザーランドの一部をイメージ内に含んでいます。これにより、同じライブラリがノード上の複数のコンテナで重複してメモリを消費し、イメージサイズも不必要に大きくなります。
2. 遅いコールドスタート: コンテナイメージのダウンロード、展開、そしてコンテナプロセスの起動には、数百ミリ秒から数秒の時間がかかります。これは、常時稼働するサービスでは問題になりにくいですが、FaaS（Function as a Service）やサーバーレス環境のように、リクエストに応じてスケールアウト・スケールインを頻繁に行うユースケースでは致命的なボトルネックとなります。
3. 広い攻撃対象領域: コンテナイメージに含まれるOSパッケージやライブラリは、それ自体が脆弱性の温床となり得ます。glibcやopensslといった基本的なライブラリにCVEが発見されれば、影響範囲の特定と修正に多大な労力を要します。

サービスメッシュの「サイドカー税」問題

マイクロサービスアーキテクチャの普及に伴い、サービス間の通信を制御・可視化するためのサービスメッシュ（IstioやLinkerdなど）が広く採用されるようになりました。その中心的なアーキテクチャが「サイドカーモデル」です。

サイドカーモデルは、アプリケーションコンテナの隣にプロキシコンテナ（Envoyなど）を配置し、全てのネットワーク通信をこのプロキシ経由で行わせることで、アプリケーションコードを変更することなく、mTLS、リトライ、サーキットブレーキング、詳細なテレメトリといった高度な機能を提供します。

このモデルは非常に強力ですが、大規模な環境では「サイドカー税 (Sidecar Tax)」と呼ばれる深刻な問題を引き起こします。

• リソース消費: クラスター内に数千のPodがあれば、数千のサイドカープロキシが起動します。これらが消費するCPUとメモリの合計は、アプリケーション本体が消費するリソースに匹敵、あるいはそれを上回ることも珍しくありません。
• レイテンシ増加: Pod内のアプリケーションとサイドカー間の通信は、localhostのネットワークスタックを経由します。これにより、マイクロ秒単位のわずかな遅延が積み重なり、サービス間通信全体のレイテンシを悪化させる可能性があります。
• 運用の複雑化: サイドカーのインジェクション、バージョンアップ、Podの起動・終了シーケンスの制御など、運用は複雑になりがちです。特に、サイドカーがアプリケーションより先に終了してしまうと、正常なトラフィックロスを引き起こすこともあります。

これらの課題に対する解決策として、クラウドネイティブコミュニティがたどり着いた答えが、WebAssemblyとサイドカーレス・アーキテクチャの融合なのです。

具体的な解決策：Wasm on Kubernetesとサイドカーレス・メッシュ

それでは、KubeCon 2026で示された次世代アーキテクチャの具体的な中身を見ていきましょう。これは2つの主要な技術要素から構成されています。

1. KubernetesにおけるWasmワークロードの実行

WebAssembly（Wasm）は、もともとWebブラウザでネイティブコードに近いパフォーマンスを実現するための技術でしたが、その「軽量・高速・セキュア・ポータブル」という特性がサーバーサイドでも高く評価されるようになりました。

Wasm/WASIとは？（簡単なおさらい）

• Wasm: 特定のCPUアーキテクチャに依存しない、ポータブルなバイナリフォーマットです。Go, Rust, C++, Python, Javaなど、多くの言語からコンパイルできます。
• WASI (WebAssembly System Interface): Wasmがサンドボックスの外側、つまりファイルシステムやソケット、環境変数といったシステムリソースと安全に対話するための標準インターフェースです。これにより、Wasmはブラウザの外でも安全に動作する汎用的な実行環境となりました。

KubernetesでのWasm実行の進化

数年前（2023-2024年頃）は、KubernetesでWasmを実行するにはKrustletのようなカスタムプロジェクトが必要で、実験的な取り組みでした。しかし2026年の現在、状況は大きく変わりました。containerdのrunwasi shimや、crunのようなOCIランタイムがWasmをネイティブサポートしたことで、Wasmはコンテナと並ぶ第一級のワークロードとして扱えるようになったのです。

これにより、私たちは使い慣れたPodリソースのruntimeClassNameフィールドを指定するだけで、Wasmワークロードをシームレスにデプロイできるようになりました。

コード例：WasmワークロードをデプロイするPodマニフェスト

以下は、Rustで書かれたシンプルなHTTPサーバーをWasmにコンパイルし、OCI準拠のコンテナレジストリにプッシュした後、Kubernetesにデプロイするためのマニフェストです。

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

# pod-wasm.yaml
apiVersion: v1
kind: Pod
metadata:
  name: wasm-hello-world-pod
  labels:
    app: hello-wasm
spec:
  # runtimeClassNameでWasmランタイムを指定するだけ。
  # このクラスは管理者が事前にRuntimeClassリソースとして定義しておく。
  runtimeClassName: wasmtime-crun
  containers:
    - name: hello-wasm-server
      # コンテナイメージと同様に、OCIアーティファクトとして格納されたWasmモジュールを指定
      image: myregistry.io/wasm-apps/hello-server:1.0.2
      ports:
        - containerPort: 8080
      # commandやenvもコンテナと同じように設定可能
      command: ["/app.wasm"]
      env:
        - name: GREETING
          value: "Hello from Wasm on Kubernetes!"

このマニフェストをkubectl apply -f pod-wasm.yamlでデプロイするだけで、Kubernetesは指定されたWasmランタイムを使ってPodを起動します。Podの管理、スケーリング、ネットワーキングは、全て既存のKubernetesの仕組みの上で行われます。

図解：コンテナ vs Wasm on Kubernetes

このアーキテクチャの違いを視覚的に理解しましょう。

【従来のコンテナワークロード】

+-------------------------------------------------------------+
|    Pod                                                      |
|  +-------------------------------------------------------+  |
|  |   Container (App + Libs + OS Userland)                |  |
|  +-------------------------------------------------------+  |
+-------------------^-----------------------------------------+
                    | (CRI)
+-------------------v-----------------------------------------+
|    Containerd     |   runc (OCI Runtime)                    |
+-------------------v-----------------------------------------+
|    Linux Kernel (Namespaces, Cgroups, Syscalls)             |
+-------------------------------------------------------------+

【新しいWasmワークロード】

+-------------------------------------------------------------+
|    Pod                                                      |
|  +-------------------------------------------------------+  |
|  |   Wasm Module (App Code Only)                         |  |
|  +-------------------------------------------------------+  |
+-------------------^-----------------------------------------+
                    | (CRI)
+-------------------v-----------------------------------------+
|    Containerd     |   crun / runwasi (Wasm OCI Runtime)     |
|                   +---------------------------------------+ |
|                   |           Wasm VM (Sandbox)           | |
+-------------------v--------------------^--------------------+
|    Linux Kernel (Minimal Syscalls via WASI)                 |
+-------------------------------------------------------------+

この図が示すように、WasmワークロードはOSのユーザーランドをほとんど含まず、Wasm VMという非常に薄いサンドボックス層の上で動作します。これにより、起動時間の短縮、リソース消費の削減、そしてセキュリティの向上が実現されます。

2. サイドカーレス・サービスメッシュとeBPF

Wasmがコンピューティング層の革新だとすれば、ネットワーキング層の革新を担うのがサイドカーレス・サービスメッシュです。このアーキテクチャは、IstioのAmbient MeshやLinkerd、Cilium Service Meshといったプロジェクトによって牽引されています。

サイドカーレス・アーキテクチャとは？

サイドカーレスは、その名の通り、各Podにサイドカープロキシを配置するモデルを廃止します。代わりに、ノード単位でプロキシ機能を共有するアプローチを取ります。

代表的なIstio Ambient Meshの実装では、以下の2つのコンポーネントが登場します。

1. ztunnel (Secure Tunnel): 各ノードにDaemonSetとしてデプロイされる軽量なL4プロキシ。mTLSの確立、L4のテレメトリ収集、L4のアクセス制御など、基本的な機能のみを担当します。
2. Waypoint Proxy: サービスアカウント単位（あるいはService単位）でデプロイされる、EnvoyベースのL7プロキシ。HTTPルーティング、リトライ、フォールトインジェクションといった高度なL7機能が必要なサービスに対してのみ、選択的に導入されます。

このアーキテクチャの鍵を握るのがeBPFです。

eBPFによる革命

eBPF (extended Berkeley Packet Filter) は、カーネルのコードを書き換えることなく、カーネル空間でカスタムプログラムを安全に実行できる革新的な技術です。サービスメッシュの文脈では、eBPFは以下のような役割を果たします。

• Podから発信される全てのTCPパケットをカーネルレベルで傍受します。
• パケットの宛先情報を元に、ztunnelにトラフィックをリダイレクトし、mTLSトンネルを確立させます。
• L7ポリシーが適用されるトラフィックの場合、さらにWaypoint Proxyにトラフィックをリダイレクトします。

これにより、アプリケーションやPodのネットワーク名前空間に一切手を加えることなく、透過的にサービスメッシュの機能を提供できるのです。

図解：サイドカーモデル vs サイドカーレスモデル

【サイドカーモデル】

  Node
+-----------------------------------------------------------------+
| Pod A                                 | Pod B                   |
| +-----------+   +-----------------+   | +-----------+   +-----+ |
| | App A     |<->| Envoy (Sidecar) |<----->| App B     |<->| ... | |
| +-----------+   +-----------------+   | +-----------+   +-----+ |
+-----------------------------------------------------------------+
  (リソース消費大、Pod内レイテンシ増)

【サイドカーレスモデル (Ambient Mesh)】

  Node
+-----------------------------------------------------------------+
|                                                                 |
|  Pod A                  Pod B                  Pod C            |
| +---------+            +---------+            +---------+       |
| |  App A  |            |  App B  |            |  App C  |       |
| +---------+            +---------+            +---------+       |
|      |                      |                      |             |
| <----|----------------------|----------------------|-------->    |
|      | (eBPFがトラフィックをリダイレクト)           |             |
| +----v------------------------------------------------v----+    |
| |             ztunnel (Node-level L4 Proxy)              |    |
| +--------------------------^-----------------------------+    |
|                            | (L7処理が必要な場合)               |
|                            +----------------------------->    |
|                                                     +--------------------+
|                                                     | Waypoint Proxy     |
|                                                     | (for ServiceAccount) |
|                                                     +--------------------+
+-----------------------------------------------------------------+
  (リソース効率◎、Pod内レイテンシなし)

このアーキテクチャにより、「サイドカー税」は劇的に削減され、運用も大幅に簡素化されます。

3. 究極の組み合わせ：Wasmフィルター + サイドカーレス・メッシュ

ここまで、コンピューティングのWasmとネットワーキングのサイドカーレスを個別に解説してきましたが、この2つが組み合わさることで、真の力が発揮されます。

サイドカーレス・メッシュのWaypoint Proxyは共有リソースであるため、ここにカスタムロジックを追加するのは慎重に行う必要があります。プロキシ自体を再起動すると、多くのサービスに影響が及ぶからです。

ここで登場するのがWasmフィルターです。Waypoint Proxyとして利用されるEnvoyは、Wasm VMを内蔵しており、カスタムロジックをWasmモジュールとして動的にロードし、リクエスト/レスポンス処理パイプラインに組み込むことができます。

• ユースケース:
  • カスタム認証・認可ロジック
  • APIキーの検証
  • リクエスト/レスポンスの変換
  • 高度なレートリミット
  • 独自のテレメトリデータの生成

これにより、プロキシを再起動することなく、安全かつ動的にサービスメッシュの機能を拡張できるようになります。開発者は、GoやRustといった好みの言語でビジネスロジックを書き、Wasmにコンパイルしてレジストリにプッシュするだけです。プラットフォームチームは、IstioのWasmPluginリソースを適用するだけで、そのカスタムロジックをプロダクション環境に展開できます。

コード例：カスタムヘッダーを追加するWasmフィルターの適用

以下は、特定のWaypoint Proxyに、リクエストヘッダーを追加する簡単なWasmフィルターを適用するためのWasmPluginマニフェストです。

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

# wasm-plugin.yaml
apiVersion: extensions.istio.io/v1alpha1
kind: WasmPlugin
metadata:
  name: add-custom-header
  namespace: default # ワークロードと同じNamespace
spec:
  # このWasmPluginを適用するワークロードを選択
  selector:
    matchLabels:
      # 'product-reviews'サービスアカウントに紐づくWaypoint Proxyに適用
      istio.io/waypoint-for: service-account
      service.istio.io/canonical-name: product-reviews
  # OCIレジストリ内のWasmモジュールを指定
  url: oci://myregistry.io/wasm-filters/add-header:2.1.0
  # Wasmモジュールに渡す設定
  pluginConfig:
    headerName: "X-Request-Source"
    headerValue: "istio-mesh"

このYAMLを適用するだけで、product-reviewsサービスへのトラフィックを処理するWaypoint Proxyは、指定されたWasmモジュールをダウンロードし、即座にリクエストパイプラインに組み込みます。ダウンタイムは一切発生しません。

メリットとデメリット

この新しいアーキテクチャがもたらす変化は計り知れませんが、もちろん銀の弾丸ではありません。メリットとデメリットを冷静に評価することが重要です。

メリット

• 劇的なリソース効率の向上: WasmによるPodの軽量化と、サイドカーレスによるメッシュの効率化は、クラスター全体のリソース消費を50%以上削減する可能性も秘めています。これは、クラウドコストの削減に直結します。
• 超高速な起動: Wasmのミリ秒単位のコールドスタート性能は、サーバーレス、バッチ処理、CI/CDジョブといった断続的なワークロードの実行効率を飛躍的に向上させます。
• 堅牢なセキュリティ: WasmのCapability-basedセキュリティモデルは、デフォルトで何も許可しない（Deny-by-default）サンドボックスを提供します。WASIを通じてファイルアクセスやネットワークなどの権限を明示的に付与する必要があり、攻撃対象領域を最小限に抑えられます。
• 真のポータビリティ: WasmはCPUアーキテクチャ（amd64, arm64）やOSに依存しません。一度Wasmにコンパイルすれば、ローカルのMacBookからクラウド上のLinuxサーバーまで、どこでも全く同じように動作します。
• 運用の簡素化: サイドカーのライフサイクル管理という複雑なタスクから解放されます。Wasmフィルターによる動的な機能拡張は、カナリアリリースやA/Bテストも容易にし、DevOpsの生産性を向上させます。

デメリットと考慮事項

• エコシステムの成熟度: 2026年時点でも、Wasmを取り巻く開発ツール、デバッグ、モニタリングのエコシステムは、コンテナに比べるとまだ発展途上です。特に、本番環境でのトラブルシューティングには新たな知識と経験が求められます。
• WASIの標準化と機能: WASIは急速に進化していますが、GPUへの直接アクセスや特定のカーネル機能の利用など、まだ全てのユースケースをカバーしているわけではありません。高度なハードウェア連携が必要なワークロードでは、依然としてコンテナが最適な選択肢となる場合があります。
• 学習コスト: Wasm特有のプログラミングモデル、eBPFの仕組み、サイドカーレス・メッシュのアーキテクチャなど、エンジニアチームが習得すべき新しい概念は少なくありません。
• パフォーマンスのトレードオフ: Wasm VMを介することによるオーバーヘッドは非常に小さいですが、ゼロではありません。レイテンシが極めて重要な金融取引システムや、純粋な計算性能が求められるHPC（High-Performance Computing）のような領域では、ネイティブバイナリと比較して性能を慎重に評価する必要があります。

現場で使える実践的なTips

この新しい技術を現場に導入する際に役立つ、いくつかの実践的なヒントを紹介します。

1. 段階的な導入から始める: 全てのワークロードをいきなりWasmに置き換えるのは現実的ではありません。まずは、新規に開発するステートレスなマイクロサービスや、起動速度がビジネス価値に直結するAPIエンドポイント、あるいはCI/CDパイプライン内のジョブなど、影響範囲の小さいところから試してみましょう。
2. ユースケースに応じたWasmランタイムの選定: KubernetesではRuntimeClassを通じて複数のWasmランタイムを併用できます。パフォーマンスを最優先するならwasmtimeベースのランタイム、AI/ML推論のような高度な機能が必要ならWasmEdgeといったように、ワークロードの特性に合わせて最適なランタイムを選択しましょう。
3. ローカルでのデバッグを徹底する: Wasmモジュールは、wasmtime runやwasmer runといったコマンドラインツールを使ってローカルで簡単に実行・デバッグできます。Kubernetesにデプロイする前に、ローカル環境で単体テストと基本的な動作確認を徹底することが、開発効率を上げる鍵です。
4. セキュリティを意識したWasmモジュール設計: Wasmモジュールをビルドする際は、WASIで要求する権限を最小限に絞り込みましょう。例えば、外部ネットワークへのアクセスが不要なモジュールには、ソケットの権限を与えないようにします。また、TrivyのようなセキュリティスキャナもWasmアーティファクトに対応し始めているため、CIプロセスにスキャンを組み込むことを推奨します。

まとめ

KubeCon 2026が示した未来は、もはや単なるコンセプトではありません。Wasmとサイドカーレス・メッシュの統合は、「コンテナのオーバーヘッド」と「サイドカー税」という、我々が長年抱えてきた課題に対する、現実的かつ強力なソリューションです。

このパラダイムシフトは、単なる技術の置き換えに留まりません。

• コンピューティング層では、Wasmがコンテナの不得意な領域（超高速起動、高密度集積、堅牢なセキュリティ）を補完し、ワークロードの選択肢を広げます。
• ネットワーキング層では、サイドカーレス・メッシュがリソース効率と運用性を劇的に改善します。
• そして、アプリケーション拡張層では、Wasmフィルターが安全で動的な機能追加を可能にし、プラットフォームとアプリケーションの境界をより柔軟にします。

もちろん、この移行には学習と試行錯誤が伴います。しかし、この変化の波を早期に捉え、自社のシステムやプロダクトにどう活かせるかを検討し始めることが、数年後の技術的な優位性を築く上で不可欠となるでしょう。

クラウドネイティブの旅は、新たな章に突入しました。さあ、一緒にこのエキサイティングな未来を探求していきましょう。