フレームワーク活用ガイドひとことで言うと#
本番環境をBlue（現行）とGreen（新版）の2面用意し、新バージョンをGreenにデプロイ・検証してからトラフィックを切り替える。問題があれば即座にBlueに戻せる、ダウンタイムゼロのデプロイ手法。
押さえておきたい用語#
- Blue環境
- 現在本番トラフィックを受けている稼働中の環境。切り替え後は待機環境となり、次回デプロイの受け皿になる。
- Green環境
- 新バージョンをデプロイする待機中の環境。検証が完了したらトラフィックの切り替え先になる。
- ロールバック
- 問題発生時にトラフィックをBlue環境に即座に戻す操作。数秒で完了するのがブルーグリーンの最大の利点。
- ターゲットグループ
- ロードバランサーがリクエストを転送するサーバー群の定義。ALB等でBlue/Greenを切り替える単位。
- 前方互換マイグレーション
- 新旧どちらのアプリケーションからも正しく読み書きできるDB変更。ブルーグリーンではDBの即時ロールバックができないため必須。
ブルーグリーンデプロイメントの全体像#
こんな悩みに効く#
- リリースのたびにメンテナンス画面を出してダウンタイムが発生している
- デプロイ後に問題が発覚しても、ロールバックに時間がかかる
- 本番環境でリリース前の最終確認をしたい
基本の使い方#
Blue環境とGreen環境をまったく同じ構成で構築する。
- サーバー、ミドルウェア、ネットワーク構成を揃える
- 現在のトラフィックはBlue環境に向いている
- Green環境はアイドル状態（または前バージョンが動いている）
ポイント: クラウドならIaCで同一構成を簡単に複製できる。
ユーザーに影響を与えずに、Green環境にだけ新バージョンを展開する。
- 自動化されたデプロイパイプラインで展開する
- Green環境で動作確認テストを実施する
- 本番データベースへのアクセスも含めて検証する
ポイント: Blue環境は一切触らないので、この時点でリスクはゼロ。
検証が完了したら、ロードバランサーやDNSでトラフィックをGreenに向ける。
- ロードバランサーの設定変更で瞬時に切り替え
- 切り替え直後のメトリクス（エラー率、レイテンシ）を注視する
- ユーザーから見ると何も変わらず新バージョンに移行
ポイント: 切り替えは数秒で完了。従来のローリングアップデートより圧倒的に速い。
切り替え後に問題が発生したら、トラフィックをBlueに戻すだけでロールバック完了。
- Blue環境には前バージョンがそのまま残っている
- ロールバックも数秒で完了
- 安定を確認したら、Blue環境を次のデプロイ用に更新する
ポイント: 「戻せる安心感」があるからこそ、頻繁にリリースできる。
具体例#
構成: AWS ALB + ECS で Blue/Green 環境を構築。Terraformで同一構成を管理。
Blue環境: 現行の v2.3.0 が稼働中。ALBのターゲットグループが向いている。
Green環境にデプロイ: CI/CDパイプラインが v2.4.0 のコンテナイメージをGreenにデプロイ。自動テスト120件とスモークテストを実行。
切り替え: ALBのターゲットグループをGreenに変更。切り替え完了まで約5秒。
問題発生: 切り替え後10分でエラー率が0.1%→2.3%に上昇。即座にALBをBlueに戻す。5秒で復旧。原因を調査して修正後、再度Greenにデプロイしてリトライ。
従来2時間かかっていたリリース作業が切り替え5秒、ロールバックも5秒に短縮された。リリース頻度は月2回から週3回に増加した。
状況: 金融規制変更に伴うシステム改修。従来はリリースのたびに深夜2:00〜4:00のメンテナンスウィンドウを設定。年間12回のリリースで合計24時間のダウンタイム。
ブルーグリーン導入:
- GKE上にBlue/Green環境を構築。Helmチャートで同一構成を管理
- DBマイグレーションは全て前方互換で実装（カラム追加のみ、削除は次リリースで実施）
- Green環境で規制テストスイート（180ケース）を実行後に切り替え
年間24時間のダウンタイムを完全にゼロにできたとすると、今後のリリース頻度をさらに上げられるのではないか。
状況: 月間PV 500万のメディアサイト。フロントエンドフレームワークをNext.js 13からNext.js 14に移行する大型リニューアル。影響範囲が広く、一発リリースのリスクが高い。
進め方:
- Green環境にNext.js 14版をデプロイ。社内IPからのみGreenにアクセスできるようにし、3日間の社内テストを実施
- 切り替え日はトラフィックが少ない月曜午前10:00を選択
- 切り替え後、Core Web Vitals（LCP、CLS、FID）とエラー率をリアルタイム監視
切り替え後30分でLCPが2.1秒から1.4秒に改善し、エラー率は0.02%で安定した。ロールバック不要で完了し、従来なら深夜メンテナンスで実施していた大型リリースを平日日中に安全に実施できた。
やりがちな失敗パターン#
- データベースの移行を考慮しない — アプリケーションは切り替えられても、DBスキーマの変更は瞬時に戻せない。DBマイグレーションは前方互換性を保つこと
- 2環境のコストを問題視して妥協する — 片方を本番より小さい構成にすると、切り替え後に性能問題が発生する。両環境の構成は必ず揃えること
- 切り替え後の監視を怠る — 切り替え直後が最もリスクが高い。切り替え後15分はメトリクスを注視する体制を作ること
- セッション管理を考慮しない — インメモリセッションを使っていると、切り替え時にユーザーがログアウトされる。外部セッションストア（Redis等）を使うか、セッションレスなアーキテクチャにすること
まとめ#
ブルーグリーンデプロイメントは 「環境を2面持って切り替える」 というシンプルな発想で、ダウンタイムゼロと安全なロールバックを同時に実現する。DBマイグレーションの設計と2環境のコスト管理が課題だが、クラウドネイティブな環境では導入しやすくなっている。安心してリリースできる体制を作ろう。