本番リリースのたびにダウンタイムが発生し、深夜にメンテナンスウィンドウを設ける――そんな運用から脱却する手段として、ブルーグリーンデプロイメントが注目されています。2つの本番環境を交互に切り替えるだけというシンプルな考え方でありながら、ゼロダウンタイムと即時ロールバックを同時に実現できる手法です。
ブルーグリーンデプロイメントの定義
ブルーグリーンデプロイメント（Blue-Green Deployment）は、同一構成の本番環境を2系統用意し、トラフィックの切り替えによってリリースを行うデプロイ戦略です。
- ブルー環境: 現在ユーザーにサービスを提供している稼働中の本番環境
- グリーン環境: 新しいバージョンをデプロイしてテストを行うスタンバイ環境
グリーン環境で十分な検証が完了したら、ロードバランサーやDNSの向き先をブルーからグリーンに切り替えます。切り替え完了後はグリーンが新たな本番環境となり、旧ブルー環境はロールバック用にしばらく維持されます。
この手法は、2010年にJez Humble氏とDavid Farley氏が書籍『Continuous Delivery』で体系的に紹介し、Martin Fowler氏がブログ記事で広めたことで業界標準のプラクティスとなりました。
ブルーグリーンデプロイメントの動作フロー
実際のリリース作業は、以下の5ステップで進みます。
ステップ1: グリーン環境の構築
ブルー環境とまったく同じインフラ構成（サーバー台数、スペック、ネットワーク設定）でグリーン環境を用意します。IaC（Infrastructure as Code）ツールで管理していれば、同一のテンプレートからもう1セットを立ち上げるだけです。
ステップ2: 新バージョンのデプロイ
グリーン環境に新バージョンのアプリケーションをデプロイします。この時点ではユーザーのトラフィックはブルー環境にのみ流れているため、グリーン環境への影響はありません。
ステップ3: グリーン環境の検証
スモークテスト、結合テスト、負荷テストなどをグリーン環境で実施します。本番と同一の構成で検証できる点が、ステージング環境でのテストと大きく異なります。
ステップ4: トラフィックの切り替え
検証完了後、ロードバランサーの向き先をブルーからグリーンに変更します。この切り替えは通常数秒以内に完了し、ユーザーから見たダウンタイムは事実上ゼロです。
ステップ5: ブルー環境の待機・削除
切り替え後もブルー環境は一定期間維持します。新バージョンに重大な不具合が発見された場合、ロードバランサーの向き先をブルーに戻すだけで即座にロールバックできます。安定稼働を確認できたら、ブルー環境を削除するか、次回リリースのグリーン環境として再利用します。
メリットとデメリット
メリット
| 観点 | 内容 |
|---|---|
| ゼロダウンタイム | ロードバランサーの切り替えのみでリリースが完了するため、サービス停止が発生しません |
| 即時ロールバック | 問題発生時にトラフィックを旧環境に戻すだけで、数秒で復旧できます |
| 本番同等のテスト | 実際の本番インフラで新バージョンを検証でき、環境差異による不具合を事前に検出できます |
| リリース作業の心理的負荷軽減 | ロールバック手段が明確なため、リリース担当者のプレッシャーが軽減されます |
| 段階的な検証が可能 | 切り替え前にグリーン環境で十分な時間をかけたテストを実施できます |
デメリット
| 観点 | 内容 |
|---|---|
| インフラコスト | 常時2つの本番環境を維持するため、サーバー・ネットワーク等のコストが最大2倍になります |
| データベースの整合性管理 | アプリケーション層は切り替えられても、データベースのスキーマ変更やデータ同期は別途考慮が必要です |
| 環境構成の同期維持 | 2つの環境のインフラ構成が乖離しないよう、IaCによる管理が不可欠です |
| セッション管理の複雑化 | 切り替え時にユーザーセッションが失われる可能性があり、外部セッションストアの導入が望ましいです |
デプロイ戦略の比較：カナリアリリース・ローリングアップデートとの違い
ブルーグリーンデプロイメントを正しく評価するには、他のデプロイ戦略との違いを把握することが重要です。
戦略別の比較
| 項目 | ブルーグリーン | カナリアリリース | ローリングアップデート | イミュータブルデプロイ | インプレースデプロイ |
|---|---|---|---|---|---|
| 切り替え方式 | 全量一括 | 段階的に比率拡大 | サーバー単位で順次 | 新環境を構築後に切り替え | 既存サーバーを直接更新 |
| ダウンタイム | なし | なし | 短い（瞬断あり） | なし | あり |
| ロールバック速度 | 即時（秒単位） | 即時（比率を戻す） | 遅い（順次戻す） | 即時 | 遅い |
| コスト | 高い（2環境分） | 中程度 | 低い | 高い | 低い |
| リスク検知 | 切り替え後に全体 | 少数ユーザーで先行検知 | 段階的に検知 | 切り替え後に全体 | 更新後に検知 |
| 導入の容易さ | 中程度 | やや複雑 | 容易 | やや複雑 | 最も容易 |
ブルーグリーンデプロイメント vs カナリアリリース
ブルーグリーンデプロイメントは新旧を一括で切り替えるのに対し、カナリアリリースではまず全トラフィックの5〜10%程度だけを新バージョンに振り分け、エラー率やレスポンスタイムを監視しながら段階的に比率を拡大していきます。
カナリアリリースの強みは、少数のユーザーでのみ新バージョンの影響を検証できる点です。新バージョンに問題があった場合でも影響範囲が限定されます。一方、ブルーグリーンデプロイメントは構成がシンプルで、リリースの全体像を把握しやすいという利点があります。
選定の目安:
- ユーザー影響を最小化したい大規模サービス → カナリアリリース
- シンプルな運用で確実にリリースしたい → ブルーグリーンデプロイメント
- 両方を組み合わせることも可能（グリーン環境にカナリア的にトラフィックを流す）
ブルーグリーンデプロイメント vs ローリングアップデート
ローリングアップデートは、複数のサーバーを1台ずつ順番に更新していく方式です。追加のインフラコストが不要な反面、更新中に新旧バージョンが混在する時間帯が生まれます。
ブルーグリーンデプロイメントでは新旧バージョンの混在が発生しないため、バージョン間の互換性を気にする必要がありません。ただし2環境分のリソースが必要になります。
Red/Blackデプロイメント（Netflix方式）
海外ではNetflixが採用する「Red/Blackデプロイメント」という呼び方も存在します。仕組みはブルーグリーンデプロイメントとほぼ同一ですが、Netflixのツール群（Spinnaker等）では旧環境をRedの名前で管理する慣習があります。技術的な差異はなく、組織やツールチェーンによる呼称の違いです。
データベースのブルーグリーンデプロイメント
アプリケーション層の切り替えは比較的シンプルですが、データベースを含むステートフルなコンポーネントでは追加の考慮が必要です。
課題：スキーマ変更とデータ同期
ブルーグリーンデプロイメントにおけるデータベースの課題は大きく2つあります。
- スキーマの互換性: 新バージョンでカラム追加やテーブル変更がある場合、切り替え中に旧バージョンがデータベースにアクセスし続ける可能性があります
- データの同期: ブルー環境で書き込まれたデータがグリーン環境のDBにも反映されている必要があります
解決策1: 共有データベースパターン
最もシンプルな方法は、ブルーとグリーンで同一のデータベースを共有することです。スキーマ変更は後方互換性を保つ方法（Expand/Contractパターン）で段階的に適用します。
[ブルー環境] --→ [共有DB] ←-- [グリーン環境]
解決策2: AWS RDSブルー/グリーンデプロイ
Amazon RDSでは、マネージドなブルー/グリーンデプロイ機能が提供されています。ブルー環境（現在の本番DB）のレプリカとしてグリーン環境を自動作成し、論理レプリケーションでデータを同期します。切り替え時のダウンタイムは従来「1分未満」とされていましたが、2026年1月のアップデートにより単一リージョン構成では5秒未満にまで短縮されています。
対応エンジン:
- Amazon RDS for MySQL
- Amazon RDS for PostgreSQL
- Amazon RDS for MariaDB
- Amazon Aurora（MySQL互換・PostgreSQL互換）
解決策3: Expand/Contractパターンによるスキーマ移行
データベーススキーマの変更を安全に適用するパターンです。
- Expand（拡張）: 新しいカラムやテーブルを追加する（既存のカラムは残す）
- Migrate（移行）: アプリケーションを新スキーマ対応版に切り替える
- Contract（収縮）: 不要になった旧カラムやテーブルを削除する
各フェーズを個別のリリースとして実施することで、ブルーグリーン切り替え時にもスキーマの後方互換性を維持できます。
クラウドサービス別の実装パターン
AWS ECS（Elastic Container Service）での実装
AWS ECSでは、CodeDeployと連携したブルーグリーンデプロイメントが標準で利用できます。2025年にはCodeDeployを使わない「ネイティブブルー/グリーンデプロイ」も追加されました。
CodeDeploy連携方式:
# appspec.yaml
version: 0.0
Resources:
- TargetService:
Type: AWS::ECS::Service
Properties:
TaskDefinition: "arn:aws:ecs:ap-northeast-1:123456789:task-definition/my-app:2"
LoadBalancerInfo:
ContainerName: "my-app"
ContainerPort: 80
動作の流れ:
- 新しいタスク定義を登録
- CodeDeployがグリーン用のターゲットグループにタスクを起動
- テストリスナーで検証
- 本番リスナーのターゲットグループをグリーンに切り替え
- 旧タスクを停止
ネイティブ方式（2025年〜）: CodeDeployを介さずECS単体でブルーグリーンデプロイが完結する方式です。設定がシンプルで、ECSサービスの更新だけでデプロイが実行されます。
Kubernetesでの実装
Kubernetesでは、Serviceオブジェクトのセレクタを切り替えることでブルーグリーンデプロイメントを実現します。
# blue-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app-blue
spec:
replicas: 3
selector:
matchLabels:
app: my-app
version: blue
template:
metadata:
labels:
app: my-app
version: blue
spec:
containers:
- name: my-app
image: my-app:1.0
ports:
- containerPort: 8080
---
# green-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app-green
spec:
replicas: 3
selector:
matchLabels:
app: my-app
version: green
template:
metadata:
labels:
app: my-app
version: green
spec:
containers:
- name: my-app
image: my-app:2.0
ports:
- containerPort: 8080
---
# service.yaml（セレクタを切り替えてトラフィックを制御）
apiVersion: v1
kind: Service
metadata:
name: my-app-service
spec:
selector:
app: my-app
version: blue # ← ここを green に変更して切り替え
ports:
- port: 80
targetPort: 8080
切り替えコマンド:
kubectl patch service my-app-service -p '{"spec":{"selector":{"version":"green"}}}'
Argo Rolloutsを使えば、ブルーグリーンデプロイメントの自動化やプロモーション制御をより高度に管理できます。
Azure Container Appsでの実装
Azure Container Appsでは「リビジョン」の仕組みを利用してブルーグリーンデプロイメントを実現します。新リビジョンを作成してトラフィック配分を0%に設定し、検証後に100%へ切り替えます。
# 新リビジョンをデプロイ（トラフィック0%）
az containerapp update --name my-app \
--resource-group my-rg \
--image my-app:2.0 \
--revision-suffix green
# トラフィックを切り替え
az containerapp ingress traffic set --name my-app \
--resource-group my-rg \
--revision-weight my-app--green=100
Google Cloud Runでの実装
Cloud Runでも、トラフィック分割機能を使ってブルーグリーンデプロイメントを実装できます。新リビジョンをデプロイ時に--no-trafficフラグを指定し、検証後にトラフィックを移行します。
ブルーグリーンデプロイメント導入のベストプラクティス
海外の事例や実践ガイドをもとに、導入時に押さえるべきポイントをまとめます。
1. IaCで環境を完全にコード管理する
ブルーとグリーンの環境差異は致命的な問題を引き起こします。Terraform、AWS CloudFormation、Pulumiなどを使い、同一テンプレートから両環境を構築してください。手動で構築した環境では「ブルーでは動くがグリーンでは動かない」という事態が発生しやすくなります。
2. 切り替え前に自動テストを必ず実行する
グリーン環境へのデプロイ後、トラフィック切り替え前に自動化されたスモークテストやヘルスチェックを実行します。CI/CDパイプラインに組み込むことで、人手による確認漏れを防ぎます。
3. データベースの移行戦略を事前に設計する
前述のExpand/Contractパターンを採用し、スキーマ変更とアプリケーション変更を別のリリースに分離してください。1回のデプロイでスキーマ変更とアプリケーション変更を同時に行うと、ロールバック時にデータ不整合が発生するリスクがあります。
4. 外部セッションストアを導入する
RedisやMemcachedなどの外部セッションストアを使い、セッション情報をアプリケーションサーバーから切り離します。環境切り替え時にユーザーセッションが失われる問題を回避できます。
5. 監視とアラートを整備する
切り替え後の数分間は特に重要です。エラー率、レスポンスタイム、CPU・メモリ使用率などのメトリクスを即座に確認できるダッシュボードを用意してください。閾値を超えた場合に自動でアラートが飛ぶ仕組みも不可欠です。
6. ロールバック手順を定期的にリハーサルする
ロールバックが必要な場面は障害発生時であり、冷静な判断が難しい状況です。定期的にロールバック手順のリハーサルを実施し、手順の正確性と所要時間を確認しておきます。
7. DNS切り替えではなくロードバランサー切り替えを選ぶ
DNS切り替え方式ではTTL（Time to Live）の制約により、切り替え完了までに時間がかかる場合があります。ロードバランサーのターゲットグループを切り替える方式のほうが、反映速度が速く確実です。
8. 旧環境の保持期間を明確に定める
コスト削減のため、切り替え後のブルー環境をいつ削除するかのルールを事前に決めておきます。一般的には24〜72時間の保持が目安です。自動削除をスケジュールしておくと、不要リソースの放置を防げます。
ブルーグリーンデプロイメントが向いているケース・向いていないケース
向いているケース
- ダウンタイムが許容できないサービス: ECサイト、金融系サービス、SaaSプラットフォームなど
- リリース頻度がそこまで高くないプロジェクト: 週1〜月1程度のリリースサイクルで、確実にリリースしたい場合
- ステートレスなアプリケーション: コンテナベース、マイクロサービスアーキテクチャとの相性が良いです
- コストよりも安定性を重視する組織: インフラコスト増を許容できる場合
向いていないケース
- 日に複数回デプロイするチーム: 頻繁なデプロイにはカナリアリリースやローリングアップデートのほうが効率的です
- インフラコストを極限まで抑えたい場合: 2環境分のリソースが必要なため、小規模プロジェクトではコスト負担が大きくなります
- 大規模なステートフルアプリケーション: データベースの同期やセッション管理の設計コストが大きく、メリットが薄れる場合があります
応用情報技術者試験での出題
ブルーグリーンデプロイメントは、IPA（独立行政法人 情報処理推進機構）の応用情報技術者試験でも出題されるテーマです。令和7年春期の午前問題（問46）では、デプロイ戦略の1つとして出題されました。
試験では、ブルーグリーンデプロイメントの基本的な仕組み（2つの環境を用意し、切り替えによってリリースする）を理解していれば対応できます。カナリアリリースやローリングアップデートとの違いを説明できるようにしておくと、午後問題でも活用できます。
よくある質問
ブルーグリーンデプロイメントのダウンタイムは発生しますか？
ロードバランサーによるトラフィック切り替え方式であれば、ダウンタイムは事実上ゼロです。DNS切り替え方式の場合は、DNSキャッシュのTTLに応じて数分〜数十分の移行期間が生じることがあります。
ブルーグリーンデプロイメントの名前の由来は？
「ブルー」と「グリーン」に特別な技術的意味はありません。2つの環境を区別するための任意の名称であり、「A/B」「Red/Black」「Old/New」と呼ばれることもあります。重要なのは、2つの同一構成の環境を交互に切り替えるという概念です。
カナリアリリースとどちらを選ぶべきですか？
ユーザー基盤が大きく、段階的にリスクを検知したい場合はカナリアリリースが適しています。シンプルな構成で確実にリリースしたい場合や、チーム規模が小さく運用負荷を抑えたい場合はブルーグリーンデプロイメントが適しています。両者は排他的ではなく、ブルーグリーン切り替え時にカナリア的な段階的トラフィックシフトを行うハイブリッド方式も実現可能です。
インフラコストは本当に2倍になりますか？
常時2環境を稼働させる場合は最大で2倍になります。ただし、クラウド環境ではリリース時のみグリーン環境を起動し、切り替え完了後に旧環境を破棄するオンデマンド方式を取れば、コスト増は限定的です。AWS Auto Scalingグループやコンテナオーケストレーションを活用すると、リソースの動的な増減が容易です。
まとめ
ブルーグリーンデプロイメントは、ゼロダウンタイムリリースと即時ロールバックを両立するデプロイ戦略です。2環境分のインフラコストという課題はありますが、クラウドサービスのオンデマンドリソース管理と組み合わせることで、コスト効率の良い運用が可能になっています。
AWS ECS、Kubernetes、Azure Container Apps、Cloud Runなど、主要なコンテナプラットフォームではいずれもブルーグリーンデプロイメントの仕組みが標準サポートされています。まだ導入していないチームは、まず非クリティカルなサービスから試験的に導入し、運用フローを確立してから本番サービスに適用するステップが効果的です。
