デプロイ戦略（ローリング・ブルーグリーン・カナリア）

🎓 レベル：標準　|　重要度：A（必須）

📎 前提：CI/CDとは・パイプライン　|　関連：Pod・Deployment・ReplicaSet・監視とアラート設計

要点（BLUF）

目的は共通——ユーザーを止めず、問題が出たら素早く戻す。違いは「新旧をどう切り替えるか」と「リスクの取り方」。
ローリング＝少しずつ入れ替え（標準・省コスト）。ブルーグリーン＝新環境を別に用意し一気に切替（即ロールバック）。カナリア＝一部ユーザーに先行展開し様子見（最小リスク）。
選択軸は コスト・切替速度・ロールバック速度・リスク許容度。重要なのは「戻せること（ロールバック）を先に設計」。

概念 ── 3つの戦略

flowchart TB
    subgraph rolling["ローリング"]
      r["旧を1つずつ新に置換（常に最低数は稼働）"]
    end
    subgraph bg["ブルーグリーン"]
      b["旧（Blue）と新（Green）を並行用意 → LBで一気に切替"]
    end
    subgraph canary["カナリア"]
      c["新へ5%だけ流す → 問題なければ徐々に100%へ"]
    end

戦略	切替	ロールバック	コスト	リスク
ローリング	段階的	やや遅い（逆ローリング）	低（追加環境不要）	中（新旧混在）
ブルーグリーン	一気	即（LBを戻すだけ）	高（2環境分）	低
カナリア	段階的＋計測	即（少数だけ影響）	中	最低

仕組み ── それぞれの動き

ローリング：K8s の Deployment 既定（Pod・Deployment・ReplicaSet）。Podを少しずつ新へ。追加環境が要らず省コストだが、切替中は新旧が混在する（DBスキーマ互換などに注意）。

ブルーグリーン：現行（Blue）と同等の新環境（Green）をまるごと別に用意し、検証後にロードバランサ（Service・Ingress）を一気に Green へ向ける。問題が出たらLBを Blue に戻すだけで即ロールバック。Immutable Infrastructure（構成管理とImmutable Infrastructure）と好相性。コストは2環境分。

カナリア：新バージョンにごく一部（例：5%）のトラフィックだけ流し、エラー率・レイテンシ（監視とアラート設計）を見ながら段階的に拡大。問題があっても影響は少数に限定。メトリクス監視が前提で、自動で進める/戻す（プログレッシブデリバリ）も可能。

flowchart LR
    lb["ロードバランサ / ルーティング"] -->|"95%"| stable["安定版 v1"]
    lb -->|"5%"| canary["カナリア v2"]
    canary -->|"メトリクス良好"| promote["徐々に100%へ"]
    canary -->|"エラー増"| rollback["即ロールバック（少数だけ影響）"]

なぜ戦略を使い分けるのか

可用性を保つため：どの戦略も「全停止して入れ替え」を避ける。ユーザー影響を最小化する。
リスクとコストの釣り合いのため：重要・高トラフィックなサービスほどカナリア/ブルーグリーンで慎重に。小さなサービスはローリングで十分。
戻せる設計が本体：前進（デプロイ）より後退（ロールバック）の速さと確実さが信頼性を決める。エラーバジェット（SREとは・SLI/SLO/エラーバジェット）を守る最後の砦。

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

「ロールバックを後で考える」→ 最初に設計すべき本体。戻せないデプロイは危険。
「DBスキーマを破壊的に変更してローリング」→ 新旧混在中に旧コードが新スキーマで壊れる。後方互換な段階移行（expand and contract）で。
「カナリアなのにメトリクスを見ていない」→ それはただの部分公開。自動/手動の判定指標（エラー率・レイテンシ・メトリクス・ログ・トレース（3本柱））が必須。
「ブルーグリーンで状態を二重に持つ」→ DB等のステートは共有か慎重な移行が要る。状態は外部化（ConfigMap・Secret・ボリューム）。
「切替後すぐ旧環境を破棄」→ ロールバック余地が消える。一定期間は旧を残す。

対応ラボ

なし（戦略トピック）。ローリング更新の実挙動は Pod・Deployment・ReplicaSet の kubectl rollout ラボで観察できる。カナリアは Service の重み付け/Ingress や専用ツール（要最新確認）で実装。