ブルーグリーンデプロイ

概要

ブルーグリーンデプロイは、本番環境を「ブルー」と「グリーン」の2系統まるごと用意し、片方（ブルー）が本番トラフィックを受けている間にもう片方（グリーン）へ新バージョンをデプロイして、動作確認が済んだらルーティングを一斉に切り替える手法です。ユーザーから見るとある瞬間に旧バージョンから新バージョンへ切り替わるだけで、サービスは一度も止まりません。

この手法の最大の魅力はロールバックの速さです。切り替え後も旧バージョンの環境はそのまま残っているため、問題が発覚したらルーティングを元に戻すだけで、数秒で旧バージョンに復帰できます。「デプロイのやり直し」ではなく「スイッチを戻す」だけ — この即時性が、CI/CD でリリース頻度を上げたいチームにとっての安全網になります。

なぜ生まれたか

伝統的なデプロイは「稼働中のサーバを上書きする」方式でした。サービスを止めてファイルを入れ替え、再起動する — このやり方には2つの根深い問題があります。第一に、入れ替え中はサービスが止まる（あるいは新旧が混在した不安定な状態になる）ため、深夜のメンテナンスウィンドウを設けるのが常識でした。第二に、問題が起きたときの復旧が遅い。旧バージョンはすでに上書きされて消えているため、ロールバックは「旧バージョンを再デプロイする」作業になり、その間ずっと障害が続きます。しかも本番サーバ上で直接入れ替えるため、失敗すると中途半端な壊れた状態が残ることさえありました。

ブルーグリーンデプロイは「稼働中の環境には手を触れない」という逆転の発想でこれを解決しました。新バージョンは本番トラフィックの当たっていない別系統に配置し、そこで起動確認・疎通確認まで済ませてから、トラフィックの向き先だけを変える。デプロイ作業とリリース（公開）の瞬間が分離され、危険な作業はすべてユーザーの見ていない場所で終わらせられるようになったのです。クラウド（IaC で環境を複製できる基盤）の普及により、「本番をもう1系統用意する」コストが劇的に下がったことが、この手法を現実的にしました。

詳細

仕組み — 2系統とルータの切り替え

構成要素は3つです。現在本番トラフィックを受けている環境（アクティブ、慣例的にブルー）、待機中の環境（アイドル、グリーン）、そして両者の手前でトラフィックの向き先を決めるルータ — 実体はロードバランサやリバースプロキシ、あるいは DNS レコードです。

デプロイの手順はこう進みます。（1）グリーン環境に新バージョンをデプロイし、起動を確認する。（2）本番トラフィックが来ない状態のグリーンに対し、ヘルスチェックやスモークテスト（主要機能の疎通確認）を実行する。（3）問題なければルータの向き先をブルーからグリーンへ切り替える。（4）しばらくモニタリングして安定を確認したら、ブルーは次回デプロイの待機系に回る。次のリリースでは役割が入れ替わり、今度はブルーに新バージョンを置いてグリーンから切り替える — 2系統が交互にアクティブになるのがこの手法のリズムです。

切り替えの実装は環境によって異なります。DNS の向き先変更は最も単純ですが、クライアント側のキャッシュ（TTL）のせいで切り替えが即時に完全には反映されないため、確実性を求めるならロードバランサのターゲット変更が推奨されます。Kubernetes では Service のセレクタを新バージョンの Pod 群に書き換える方法や、Argo Rollouts の BlueGreen ストラテジがこの手順を自動化してくれます。

最大の落とし穴 — データベース

ブルーグリーンで環境を2系統にできるのはステートレスなアプリケーション層だけで、データベースは通常1つを両系統で共有します。ここに この手法の最大の難所があります。新バージョンがスキーマ変更（カラム名変更や削除など）を含む場合、切り替えの前後や、ロールバックでブルーに戻した瞬間に、旧コードが新スキーマを読めずに壊れるのです。「切り替えは一瞬」という利点は、データベースが新旧どちらのコードとも互換であるときにしか成立しません。

定石は「展開とスキーマ変更を分離する」ことです。破壊的な変更は一度に行わず、（1）新カラムを追加して新旧コードが共存できる状態を作る、（2）データを移行する、（3）旧カラムへの参照が完全になくなった後のリリースで旧カラムを削除する、と複数回のデプロイに分割します（expand & contract パターンと呼ばれます）。同様に、切り替えの瞬間に処理中だったリクエストやユーザーのセッションをどう引き継ぐか（セッションを外部ストアに出しておく、コネクションドレイニングで処理中のリクエストを完了させる、など）も事前に設計しておく必要があります。

コストとトレードオフ

本番環境を2系統維持するため、素朴にやるとインフラコストは2倍になります。クラウドなら「デプロイ時だけグリーンを起動し、安定後にブルーを縮退させる」運用でコストを抑えられますが、その場合は即時ロールバックの窓が短くなるというトレードオフがあります。また、切り替えは全ユーザー一斉なので、新バージョンにバグがあれば（短時間とはいえ）全ユーザーが影響を受けます。一部のトラフィックで検証しながら広げたい場合はカナリアリリースが適しており、「切り戻しの速さのブルーグリーン、検証の丁寧さのカナリア」という使い分けが基本です。さらに、切り替え前のグリーンに本番同様のリクエストを流して最終確認したい場合は、本番トラフィックを複製して流すシャドーイングや、社内ユーザーだけ先にグリーンを使う運用を組み合わせることもあります。