スケーリングと自己修復｜クラウドインフラ

🎓 レベル：発展　|　重要度：A（必須）

📎 前提：Pod・Deployment・ReplicaSet　|　関連：コストとスケーリングの考え方・キャパシティと信頼性設計

要点（BLUF）

自己修復は2層。ReplicaSet が「Pod数」を保ち、**ヘルスチェック（probe）**が「Podの中身が健全か」を保つ。不健全なら再起動・振り分け除外する。
liveness probe＝「生きてるか（ダメなら再起動）」、readiness probe＝「受付可能か（ダメならトラフィックを止める）」。役割が違う。
HPA（Horizontal Pod Autoscaler）が、CPU等の指標に応じてPod数を自動増減する。クラウドの水平スケール（コストとスケーリングの考え方）をK8sで実現する部品。

概念 ── 「数」と「中身」の両方を守る

ReplicaSet は「3つ動いている」を守りますが、3つとも内部でフリーズしているかもしれません。プロセスは生きているのに応答しない——これを検知できないと、利用者にはエラーが届きます。そこで K8s は**ヘルスチェック（probe）**で中身の健全性も監視します。

flowchart TB
    subgraph heal["自己修復の2層"]
      rs["ReplicaSet：Pod数を保つ（外形）"]
      probe["Probe：Podの中身が健全か（内実）"]
    end
    probe -->|"liveness 失敗"| restart["コンテナを再起動"]
    probe -->|"readiness 失敗"| drain["Serviceの振り分けから外す"]

仕組み① ── liveness と readiness

probe	問い	失敗時の動作
liveness	プロセスは生きて応答するか	コンテナを再起動
readiness	今リクエストを受けられるか	Service の振り分けから外す（再起動はしない）
startup	起動完了したか	起動が遅いアプリの誤殺を防ぐ

肝は readiness と liveness の違い。起動直後やDB接続待ちの間は「生きてるが受付不可」。ここで liveness を厳しくすると起動中に殺され続ける。受付可否は readiness、生死は liveness と役割を分けます。

# Deployment の containers 内
livenessProbe:
  httpGet: { path: /healthz, port: 80 }
  initialDelaySeconds: 10     # 起動直後は猶予
  periodSeconds: 10
readinessProbe:
  httpGet: { path: /ready, port: 80 }
  periodSeconds: 5

仕組み② ── HPA（水平オートスケール）

HPA はメトリクス（CPU使用率など）を監視し、Pod数を min と max の間で自動調整します。負荷が上がれば増やし、収まれば減らす。調整ループ（Kubernetesの全体像（宣言的・調整ループ））の応用です。

flowchart LR
    metric["メトリクス（CPU平均）"] --> hpa["HPA：目標と比較"]
    hpa -->|"超過なら増やす"| up["replicas 増"]
    hpa -->|"下回れば減らす"| down["replicas 減"]
    up --> metric
    down --> metric

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web
  minReplicas: 2              # 可用性の床
  maxReplicas: 10             # 暴走の天井
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 60

HPA が CPU を読むには Metrics Server（または相当）がクラスタに要ります（要最新確認）。Pod数でなくノード自体を増減する Cluster Autoscaler と組み合わせると、計算資源そのものも弾力化します。

なぜ自己修復＋オートスケールなのか

人手を介さず立て直すため：probe による再起動・振り分け除外で、障害が利用者に届く前に処理する。SRE の自己修復（キャパシティと信頼性設計）の中核。
無駄なく弾力化するため：HPA でピークにだけ台数を増やし、谷では減らす。従量課金（コストとスケーリングの考え方）の利点を引き出す。
requests が前提：HPA も Scheduler も requests（Pod・Deployment・ReplicaSet）を基準にする。未設定だと正しくスケール判断できない。

⚠️ よくある誤解・落とし穴

「liveness を厳しく設定」→ 起動が遅い/一時的に詰まったPodを再起動し続け、かえって不安定に。startup probe と猶予で守る。
「readiness を付けない」→ 起動途中・過負荷のPodにトラフィックが流れエラーに。受付可否は readiness で必ず制御。
「HPA の max を無制限に近く」→ 障害や攻撃で青天井に増殖し課金事故（コストとスケーリングの考え方）。天井と予算アラートを。
「requests 未設定で HPA」→ 使用率の基準がなく機能しない。requests を必ず設定。
「アプリがステートフルなのに水平スケール」→ 状態を抱えるPodは増やせない。状態を外（ConfigMap・Secret・ボリュームのPV・外部DB）へ。

対応ラボ

cloud-infra-study/labs/04-05_hpa.yaml ＋ 04-05_probes_patch.yaml（Deployment に liveness/readiness を付け、HPA を定義。負荷をかけて Pod 数が増えるのを観察。Metrics Server 必要・kind/minikube で）。