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

なぜ「戦略」が要るのか

古いやり方は「サーバを止める → 新バージョンを置く → 起動する」。これだと 停止時間（ダウンタイム） が出ますし、起動して初めて不具合に気づくと 全ユーザーが巻き込まれます。

そこで、複数のインスタンスを 同時に・並行して 動かせる前提（コンテナとVM や CI/CD の自動化）を活かし、

• 無停止（ゼロダウンタイム） で出す
• 問題を 一部に閉じ込める
• ダメなら 素早く元に戻す（ロールバック）

ための「出し方の型」が必要になります。これがデプロイ戦略です。

ローリング：少しずつ入れ替える

稼働中のインスタンスを 数台ずつ 新バージョンに置き換えていく方式。古い v1 と新しい v2 がしばらく 混在 しながら、徐々に v2 へ寄せていきます。

• 追加リソースが少なくて済む（全台ぶんの余剰環境が不要）
• 一度に落とす台数（maxUnavailable）と増やせる台数（maxSurge）で進み方を制御
• ヘルスチェックに通った台だけ流量を受ける

弱点は 切り替え中に v1 と v2 が同時に動く こと。両者が同じDBや同じAPIを触るため、互換性がないと壊れます。また全台が入れ替わるまで時間がかかり、途中で問題が出ると戻すのも段階的で遅くなりがちです。

# Kubernetes の Deployment（ローリング更新の例）
spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1   # 同時に止めるのは最大1台
      maxSurge: 1         # 一時的に1台だけ増やしてよい

ブルーグリーン：2環境を丸ごと切り替える

現行(Blue)と 同じ規模の新環境(Green) をまるごと用意し、Green で十分に確認してから ロードバランサ（やDNS）の向き先を一気に切り替える 方式。

• 切り替えは 一瞬。利用者から見たダウンタイムがほぼない
• 問題が出たら 向き先をBlueに戻すだけ で即ロールバック
• 旧環境はしばらく残すので、安心して様子を見られる

弱点は 本番を2面ぶん用意する コスト。また「全ユーザーが同時に新版へ移る」ため、Green側の検証が甘いと 影響範囲は全体 になります（＝小さく試すのには向かない）。

カナリア：一部にだけ先行投入する

新版をまず 5%や1% といったごく一部のトラフィックにだけ流し、エラー率やレイテンシを 計測しながら 段階的に 25% → 50% → 100% と広げていく方式。炭鉱のカナリア（危険をいち早く知らせる鳥）が名前の由来です。

• 本番の実トラフィック でリスクを測れる（ステージングでは出ない問題を捕まえる）
• 異常を検知したら その一部だけ を巻き戻せばよく、被害が小さい
• 「指標が悪化したら自動で停止／巻き戻し」まで組むのが理想

弱点は 仕組みが重い こと。トラフィックの重み付けルーティングと、良し悪しを判定する 監視・可観測性（エラー率・レイテンシ・SLO）がそろって初めて機能します。判定基準がないと「なんとなく1%」を出しているだけで、ただ遅いブルーグリーンになりかねません。

三者の比較

どれを選んでも欠かせない前提

戦略の選択以前に、ロールバックできる状態 を作っておくことが本丸です。これが崩れると、どの方式でも安全に切り替えられません。

• DBスキーマの後方互換：新旧バージョンが同じDBを同時に触る瞬間が必ずある。カラム削除や非互換な変更を一発でやらない（"expand and contract"＝先に足して、移行してから消す）。これを怠ると「アプリは戻せてもDBが戻せない」状態になります。
• ヘルスチェック / Readiness：起動しただけで流量を流さず、「本当に応答できる」状態になってから受ける。これがないと壊れた新版にトラフィックが流れます。
• 状態を持たない設計：ローカルにセッションやファイルを溜めないこと。イミュータブルインフラ のように使い捨てできる前提だと、入れ替えも切り戻しも単純になります。

まとめ：使い分けの早見

• コストを抑えて日常的に更新したい → ローリング（後方互換が前提）
• 重要な更新を、ダメなら即座に戻したい → ブルーグリーン（2面ぶんのコストと引き換え）
• 大きな変更のリスクを本番で実測したい → カナリア（監視と自動判定が前提）

実務ではこれらは排他ではなく、ブルーグリーンの切り替えをカナリア的に少しずつ流す といった組み合わせも一般的です。土台となる自動化は CI/CD や GitOps が担います。