はじめに
本ドキュメントは、AWS環境で安全に、かつダウンタイムを最小限に抑えてアプリケーションをリリースする手法として「ブルーグリーンデプロイメント」を体系的に解説することを目的としています。
目的
本稿では概念の説明に加え、メリット・注意点、AWSの代表的な実装パターン、さらにElastic Load Balancer、Amazon ECS、CodeDeployなどの具体的なサービスを使った構成例や運用上のポイントまで実務寄りに扱います。
対象読者
AWSで本番運用を行うエンジニア、SRE、DevOps担当者向けです。CI/CDの基本やAWSの基礎的なサービス(VPC、EC2、ELBなど)に馴染みがあると読みやすいです。
本書の構成と読み方
続く章で概念→利点・注意点→全体の実装パターン→サービス別の具体例と順に深掘りします。まずは第2章で基本概念を押さえ、その後、ご自身の環境に合うパターンを第4~7章で検討してください。手順や設定例は実運用で使えるレベルで示しますので、設計や運用の判断材料にしていただければ幸いです。
ブルーグリーンデプロイメントとは何か
概要
ブルーグリーンデプロイメントは、本番と同一構成の環境を2つ(ブルーとグリーン)用意し、新旧バージョンを並行稼働させる手法です。ブルーは稼働中の旧バージョン、グリーンに新バージョンをデプロイして動作確認します。ロードバランサーでトラフィックを切り替え、ほぼダウンタイムをゼロに保てます。
基本的な仕組み
- グリーン環境に新しいリリースをデプロイし、テストを実行します。
- 問題なければロードバランサーの配信先をグリーンへ切り替えます。
- 異常があれば、すぐブルーへ戻してロールバックします。
具体例(Webアプリ)
Webサーバーを2セット用意し、DNSやロードバランサーで切り替えると簡単です。例えば夜間にグリーンへ切替え、短時間でユーザー影響を確認できます。
切り替え方法とロールバック
段階的にトラフィックを入れる方法と、一気に切り替える方法があります。問題が出たら即座に切替え先を元に戻すだけで復旧できます。
向いている場面と注意点
ユーザーに影響を与えたくない重要なサービス向けに有効です。リソースが2倍必要になる点やデータベースの互換性に注意してください。
ブルーグリーンデプロイのメリットと注意点
メリット
- ダウンタイムの最小化
-
新しい環境(グリーン)を準備してからロードバランサーで瞬時に切り替えます。ユーザーへの停止をほとんど発生させません。例えば、深夜に切り替えてもサイトがそのまま動き続けます。
-
ロールバックの容易さ
-
不具合が出たら、元の環境(ブルー)に戻すだけで復旧できます。デプロイ作業が短時間で済むため、運用の負荷が下がります。
-
本番相当環境でのテストが可能
- 負荷テストやA/Bテストを本番と同等の構成で行えます。実運用に近い条件で問題を早期発見できます。
注意点
- インフラコストの増加
-
本番相当の環境を2つ同時に動かすため、サーバーやライセンス費用が増えます。小規模サービスではコストがネックになることがあります。
-
データベース互換性の課題
-
スキーマ変更は互換性を意識して段階的に行います。書き込み側と読み取り側で差が出ないように設計する必要があります。例:後方互換のカラム追加→アプリ側対応→不要列の削除。
-
設計の複雑さ
- トラフィック切り替え、セッション管理、DBマイグレーションなどを総合的に考慮します。セッションは外部ストア(Redisなど)に切り出す、ヘルスチェックを厳密に設定するなどの工夫が必要です。
実践でのポイント
- 自動化して手順ミスを減らす
- ロールバック手順を事前に検証する
- 影響範囲を小さくするためにサービスを分割する(マイクロサービス化)
以上を踏まえ、ブルーグリーンは信頼性向上に強い手法ですが、コストと設計の工夫が欠かせません。
AWSでの典型的な実装パターン(全体像)
概要
AWSでブルーグリーンデプロイを設計するときは、アプリケーション層とデータベース層を分けて考えると分かりやすいです。アプリ側はトラフィックの切り替えで新旧を入れ替え、DBはレプリカや専用機能で切り替えます。
アプリケーション層の代表パターン
- ECS + ALBのターゲットグループ切り替え:新しいタスク群(グリーン)を用意し、ALBのターゲットグループを切り替えてトラフィックを移します。切替は瞬時、段階的どちらも可能です。
- EC2/オンプレ向けのCodeDeployブルー/グリーン:既存のサーバ群(ブルー)と入替用群(グリーン)を用意し、ロードバランサーやIPルーティングで切替えます。
- DNS切替(Route53の加重ルーティング):小規模や外部サービスを含む場合に使います。切替の反映はTTLに左右されます。
データベース層の代表パターン
- RDS/AuroraのBlue/Green機能:AWSが提供する切替機能で、クローン作成→検証→エンドポイント切替の流れです。ダウンタイムを最小に抑えられます。
- レプリカ→昇格:手動または自動でレプリカをプロモートして切替えます。スキーマ変更がある場合は設計を工夫します。
CI/CDとの連携
- GitHub ActionsやCodePipelineでデプロイを自動化し、CodeDeployやECSの切替APIを呼びます。テストや監視(CloudWatchアラームなど)を組み合わせると安全性が高まります。
組み合わせ例(全体像)
ECSでアプリを動かし、ALBでトラフィックを制御、RDSのBlue/GreenでDBを準備、CIで一連の手順を自動実行する構成が典型です。アプリとDBを別々に検証し、問題なければ切替える流れを作ると運用が楽になります。
注意点
スキーマ変更やセッション管理、外部APIとの互換性は事前に確認してください。DNSのTTLや監視アラートを活用して、問題発生時に素早くロールバックできる体制を整えましょう。
AWS Elastic Load Balancer を利用したシンプルな構成例
構成の全体像
ALB(Application Load Balancer)配下に2つのターゲットグループを用意します。BlueTargetGroupには旧バージョンのインスタンスやタスク、GreenTargetGroupには新バージョンを登録します。ALBはリスナー(通常はHTTP/HTTPS)でどちらのターゲットグループにルーティングするかを制御します。
手順(簡潔)
- Green環境に新しいアプリをデプロイして起動します。例:新しいECSタスク定義や新しいEC2インスタンスを登録します。
- Greenで動作確認(ヘルスチェック、簡単な機能テスト)を行います。
- ALBのリスナー設定を変更し、トラフィックをBlueからGreenに切り替えます。短時間で切り替わるためユーザー影響を最小化できます。
- 問題がなければBlueを停止または削除します。ロールバックが必要ならALBのルーティングを元に戻します。
注意点
- ヘルスチェックを適切に設定してください。異常なインスタンスを切替先に含めないため重要です。
- セッションやスティッキー設定に注意してください。セッション情報がある場合は共有ストレージやクッキー設定で対応します。
- データベースの変更がある場合は後方互換性を保つなど、ロールバックを想定してください。
ECS/EC2への応用
ECSではサービスのターゲットグループ切替で同じ考え方が使えます。EC2の場合はインスタンスの登録解除・登録で同様に切り替えます。簡単で汎用性の高い基本パターンです。
Amazon ECS の「組み込みブルー/グリーンデプロイ」機能
概要
Amazon ECSはサービス単位でブルー/グリーンデプロイを組み込んでおり、外部ツールを作らずに安全な切替ができます。デプロイコントローラーを「ECS」に設定し、戦略でブルー/グリーンを選びます。ロードバランサー(ALBなど)とターゲットグループが必要です。
設定の流れ(簡単な手順)
- 新しいタスク定義(グリーン)を用意します。
- サービスのデプロイ戦略をブルー/グリーンに設定します。
- ALBの既存ターゲットグループと新規のターゲットグループを関連付けます。
- デプロイを開始すると、トラフィックを段階的にグリーンへ移行します。
ベイク時間とロールバック
ベイク時間を設定すると、グリーンへ完全移行後にブルーを即時ロールバックできる猶予が生まれます。ベイク時間が終わると、古い(ブルー)タスクが自動で削除されます。ロールバック可能時間とコストのバランスを考えて設定してください。
ECS Service Connect と組み合わせる利点
Service Connectを使うとサービス間通信のエンドポイント管理が簡単になり、デプロイ時にサービスディスカバリや内部通信を意識しにくくなります。特にマイクロサービス構成で効果的です。
運用時の注意点
- ヘルスチェックは正しく設定し、移行を阻害しないようにします。
- ログやメトリクスで段階的に状態を監視します。
- テスト環境で洗練されたロールアウトを事前に検証してください。
AWS CodeDeploy によるブルーグリーンデプロイの詳細
概要
AWS CodeDeploy は EC2、オンプレミス、ECS 向けにトラフィック切り替え付きのブルーグリーンデプロイを提供します。ブルーは現行本番、グリーンは新バージョンを配置して検証する環境です。CodeDeploy が切り替えとライフサイクルを管理し、安全な公開と迅速なロールバックを実現します。
主な構成要素
- デプロイグループ:対象のインスタンスやサービスをまとめます。
- ターゲットグループ/ロードバランサ:トラフィックを誘導する先を制御します。
- ライフサイクルフック:BeforeInstall、AfterInstall、ValidateService などで検証や準備処理を実行できます。
トラフィック切り替えの流れ
- グリーン環境に新バージョンをデプロイ
- ヘルスチェックやカスタム検証を実行
- 段階的もしくは一括でトラフィックをグリーンに移行
- 問題があれば自動または手動でロールバック
ロールバックと監視
ヘルスチェックや CloudWatch アラームで異常を検知すると自動ロールバック可能です。ログやメトリクスを事前に設定し、短時間で原因特定できるようにします。
CI/CD との連携
GitHub Actions や CodePipeline からデプロイを起動して自動化します。CI でビルド・テストを通過してから CodeDeploy に通知すると安全です。
注意点とベストプラクティス
- DB マイグレーションは後方互換を確保する
- セッション管理やキャッシュを考慮する
- 段階的切替で問題検出の余地を残す
- 自動化と監視を充実させる
これらを組み合わせることで、安全で可観測なブルーグリーンデプロイが実現できます。












