Blue/Green デプロイ
2 つの同一環境を用意し、トラフィックを切り替えることでゼロダウンタイムデプロイを実現する手法
デプロイ可用性
Blue/Green デプロイとは
Blue/Green デプロイは、本番環境 (Blue) と同一の新環境 (Green) を用意し、新バージョンを Green にデプロイ後、トラフィックを Blue から Green に切り替える手法である。問題があれば Blue に即座にロールバックできる。
流れ
流れを図で示す。
Step 1: Blue (v1) がトラフィックを受けている
[ALB] → [Blue: v1] ← 本番
Step 2: Green (v2) をデプロイ・テスト
[ALB] → [Blue: v1] ← 本番
[Green: v2] ← テスト中
Step 3: トラフィックを Green に切り替え
[ALB] → [Green: v2] ← 本番
[Blue: v1] ← スタンバイ
Step 4: 問題があれば Blue にロールバック (即座)
[ALB] → [Blue: v1] ← 本番に戻す
ローリングアップデートとの比較
ローリングアップデートとの主な違いを以下に比較する。
| 観点 | Blue/Green | ローリングアップデート |
|---|---|---|
| ロールバック速度 | 即座 (切り替えるだけ) | 遅い (再デプロイ) |
| リソースコスト | 2 倍 (2 環境) | 追加コスト小 |
| 新旧の混在 | なし (一括切り替え) | あり (段階的) |
| テスト | Green を事前にテスト可能 | 本番トラフィックでテスト |
AWS での実装
ALB + ターゲットグループ
CodeDeploy
Lambda エイリアス
S3 + CloudFront での Blue/Green
静的サイトの場合、S3 のプレフィックスまたはバケットを切り替える。
CloudFront → S3 /blue/ (v1)
→ S3 /green/ (v2) ← オリジンパスを切り替え
注意点
注意点を以下にまとめる。
| 注意点 | 対策 |
|---|---|
| DB スキーマの互換性 | Expand-Contract パターン |
| セッションの引き継ぎ | 外部ストア (DynamoDB) で管理 |
| DNS キャッシュ | TTL を短くしてから切り替え |
全体像を把握するには関連書籍も有用。
この記事は役に立ちましたか?
関連用語
ゼロダウンタイムデプロイ
サービスを停止せずに新バージョンをデプロイする手法の総称
カナリアリリース
新バージョンを少数のユーザーに先行公開し、問題がないことを確認してから全体に展開するデプロイ手法
ロールバック
デプロイやデータ変更を以前の状態に戻し、障害からの復旧を行う操作
Kubernetes ローリングアップデート
Pod を段階的に新バージョンに置き換え、ゼロダウンタイムでアプリケーションを更新するデプロイ戦略
Operator パターン
Kubernetes のカスタムリソースとコントローラーで、アプリケーションの運用を自動化するパターン
スモークテスト
デプロイ後にシステムの基本機能が動作することを確認する簡易テスト