🍽️ レストランで理解するブルー/グリーンデプロイ
ブルー/グリーンデプロイを、レストランの例で分かりやすく説明します！
🏪
ブルーレストラン（本店）
現在お客様が利用している本店。安定してサービスを提供中。これが「本番環境」です。
🏗️
グリーンレストラン（2号店）
新しいメニューや内装をテストする2号店。お客様には公開前の「ステージング環境」です。
💡 ポイント：
ブルー/グリーンデプロイでは、2つの同じような環境を用意して、新しいバージョンをテストしてから本番に切り替えます。まさにレストランの本店と2号店のような関係です！
🔄 Environment URL Swapの仕組み
B
ブルー環境
prod-app.region.elasticbeanstalk.com
現在の本番環境
バージョン: v1.0
➡️
G
グリーン環境
staging-app.region.elasticbeanstalk.com
新バージョンをテスト
バージョン: v2.0
🔀 URL Swap（看板の付け替え）
レストランで例えると、本店と2号店の看板を瞬時に交換するようなものです！
Swap前
🔵 prod-app → v1.0
🟢 staging-app → v2.0
🔄
Swap後
🔵 prod-app → v2.0
🟢 staging-app → v1.0
📋 デプロイの手順
1
🏗️ グリーン環境の準備
新しいアプリケーションバージョンをグリーン環境にデプロイ。まるで2号店で新メニューを準備するようなものです。
2
🧪 テストの実行
グリーン環境で動作確認とテスト。お客様に提供する前に、スタッフがしっかり味見をする段階です。
3
🔄 URL Swap実行
問題がなければ、ボタン一つでURL Swapを実行。看板を瞬時に交換して、お客様を新店舗に案内開始！
4
📊 監視と確認
本番稼働後の監視。何か問題があれば、すぐに元の環境にSwap Backできます。
⚙️ Elastic Beanstalkでの実装
# 1. 新しいアプリケーションバージョンを作成
$ eb create staging-environment --version v2.0
# 2. グリーン環境でテスト
$ eb open staging-environment
# 3. AWSコンソールまたはCLIでURL Swap実行
$ eb swap prod-environment staging-environment
🎯 重要：
Elastic BeanstalkのURL Swapは、環境のURLを交換するだけです。実際のEC2インスタンスやLoad Balancerは移動しません。まさに看板だけを付け替える感覚です！
✨ ブルー/グリーンデプロイのメリット
⚡
瞬時の切り替え
URL Swapは数秒で完了。ダウンタイムほぼゼロでデプロイできます。
🛡️
安全なロールバック
問題があれば即座に元の環境に戻せます。まるで保険付きのデプロイ！
🧪
本番同等テスト
本番環境と同じ構成でテストできるため、デプロイ後の問題を未然に防げます。
👥
ユーザー影響最小
サービス停止なしでアップデート。お客様は気づかないうちに新機能を利用開始！
🔄 CodeDeploy vs Elastic Beanstalk ブルー/グリーンデプロイ
🏪
Elastic Beanstalk方式
「店舗まるごと切り替え」
✅ 本店と2号店を完全に用意
✅ 看板だけ付け替え（URL Swap）
✅ 簡単だが店舗コストは2倍
👨🍳
CodeDeploy方式
「スタッフ入れ替え」
✅ 同じ店舗で新スタッフを段階的に配置
✅ 古いスタッフと新スタッフが共存
✅ コスト効率良く細かい制御が可能
|
項目
|
Elastic Beanstalk
|
CodeDeploy
|
|
🏗️ アプローチ
|
環境全体の切り替え
|
アプリケーションレベルの置換
|
|
💰 コスト
|
高い（2つの環境が必要）
|
低い（既存インフラを活用）
|
|
⚙️ 複雑さ
|
簡単（ボタン一つ）
|
やや複雑（設定が必要）
|
|
🎯 対象
|
Beanstalk管理アプリのみ
|
EC2、Lambda、ECS対応
|
|
🔧 柔軟性
|
低い（Beanstalkの機能範囲）
|
高い（カスタム設定可能）
|
|
⏱️ 切り替え時間
|
瞬時（数秒）
|
段階的（数分〜数十分）
|
🤔 どちらを選ぶべき？
🏪
Elastic Beanstalkを選ぶ場合
✅ 簡単にデプロイしたい
✅ Webアプリケーション中心
✅ 運用コストより開発スピード重視
✅ AWS初心者
⚙️
CodeDeployを選ぶ場合
✅ コストを抑えたい
✅ 細かい制御が必要
✅ 既存EC2インフラを活用
✅ マイクロサービス構成
🎯 レストランの例で使い分け：
🏪 Elastic Beanstalk方式が向いているケース：
「新しい店舗を丸ごと作って、看板だけ付け替えたい。簡単で確実だが、家賃は2倍かかってもOK」
👨🍳 CodeDeploy方式が向いているケース：
「同じ店舗で、スタッフを段階的に新しい人に入れ替えたい。コストは抑えたいが、管理は少し複雑になってもOK」
👨🍳 CodeDeployのブルー/グリーンデプロイ詳細
1
🍳 新スタッフ準備
既存のEC2インスタンスに新しいアプリケーションバージョンをデプロイ準備。料理人が新レシピを覚える段階。
2
⚖️ 段階的切り替え
Load Balancerで徐々にトラフィックを新バージョンに流す。お客様を少しずつ新スタッフのテーブルに案内。
3
📊 ヘルスチェック
新バージョンの動作を監視。問題があれば自動で旧バージョンに戻す。スタッフの様子を見ながら調整。
4
🎯 完全切り替え
問題なければ全トラフィックを新バージョンに。全てのお客様が新スタッフのサービスを受ける状態。
# CodeDeployでのブルー/グリーンデプロイ設定例
{
"applicationName": "MyApp",
"deploymentGroupName": "MyDeploymentGroup",
"deploymentConfigName": "CodeDeployDefault.BlueGreen",
"blueGreenDeploymentConfiguration": {
"terminateBlueInstancesOnDeploymentSuccess": {
"action": "TERMINATE",
"terminationWaitTimeInMinutes": 5
},
"deploymentReadyOption": {
"actionOnTimeout": "CONTINUE_DEPLOYMENT"
}
}
}
🎯 まとめ
🏪 レストランの例で覚えよう：
-
Elastic Beanstalk
= 店舗まるごと切り替え（簡単・高コスト）
-
CodeDeploy
= スタッフ段階的入れ替え（複雑・低コスト）
-
URL Swap
= 看板の瞬時付け替え（Beanstalk）
-
Traffic Shifting
= お客様の案内先を徐々に変更（CodeDeploy）
用途に応じて適切なデプロイ手法を選択し、安全で確実なアプリケーションデプロイを実現しましょう！🚀