AWSで実践する！Blue-GreenデプロイとCanaryデプロイの完全ガイド

Blue-GreenデプロイとCanaryデプロイは、アプリケーションのリリースにおけるリスクを最小限に抑えつつ、新しいバージョンの導入を安全かつ効率的に行うための重要な戦略です。本記事では、それぞれのデプロイ手法の基本概念から、AWSにおける具体的な実装方法、さらにベストプラクティスまでを詳しく解説します。

1. Blue-Greenデプロイとは？

Blue-Greenデプロイは、現在稼働している環境（Blue）とは別に新しい環境（Green）を用意し、ユーザーへのトラフィックを切り替えることでリスクを抑えるデプロイ手法です。切り替えによってダウンタイムを回避し、迅速なロールバックも可能になります。

Blue-Greenデプロイの流れ

本番稼働中のBlue環境でサービス提供
新バージョンをGreen環境にデプロイ
内部検証または限定ユーザーで動作確認
ロードバランサーやDNSの設定を変更し、トラフィックをGreen環境へ切り替え
問題発生時は即座にBlue環境へロールバック

メリットとデメリット

✅ ダウンタイムなし
✅ 即時ロールバック可能
❌ 二重環境維持のためインフラコストが増加
❌ データベースの一貫性保持が難しい場合あり

AWSでの実装方法（ECSを例に）

1. AWS CodeDeploy + ECS

aws deploy create-deployment \
  --application-name MyECSApp \
  --deployment-group-name MyECSDeploymentGroup \
  --deployment-config-name CodeDeployDefault.ECSAllAtOnce \
  --github-location repository=MyOrg/MyRepo,commitId=latest

CodeDeployはターゲットグループとALBを活用し、Green環境へ切り替え可能です。

2. Route 53によるDNSスイッチ

aws route53 change-resource-record-sets \
  --hosted-zone-id ZXXXXXXXXXXX \
  --change-batch file://dns-switch.json

dns-switch.jsonの例:

{
  "Changes": [
    {
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "app.example.com",
        "Type": "A",
        "AliasTarget": {
          "HostedZoneId": "ZXXXXXXXXXXX",
          "DNSName": "green.example.com"
        }
      }
    }
  ]
}

2. Canaryデプロイとは？

Canaryデプロイは、新バージョンのリリースを一部のユーザーに限定して提供し、段階的に展開していくことで影響範囲を抑える戦略です。モニタリングと連携することで、エラー検出後の迅速な対応が可能になります。

Canaryデプロイの流れ

現行バージョン（旧バージョン）を稼働
新バージョンを一部ユーザー（例：5%）に配信
CloudWatch等でパフォーマンス・エラーレートをモニタリング
問題がなければ段階的に割合を拡大（例：50%→100%）
問題があれば即時ロールバック

メリットとデメリット

✅ 最小限の影響で新バージョンを検証可能
✅ リスク低減、ユーザーへの影響を制御
❌ 綿密なモニタリングと自動化の仕組みが必要
❌ フルデプロイまでに時間を要することがある

AWSでの実装方法（Lambdaを例に）

1. AWS CodeDeployによるCanaryデプロイ

aws deploy create-deployment \
  --application-name MyLambdaApp \
  --deployment-group-name MyLambdaDeploymentGroup \
  --deployment-config-name CodeDeployDefault.LambdaCanary10Percent5Minutes \
  --github-location repository=MyOrg/MyRepo,commitId=latest

この例では、10%のトラフィックを新バージョンに向け、5分後に全体切り替えを行います。

2. Application Load Balancerでのトラフィック分岐

aws elbv2 modify-listener \
  --listener-arn arn:aws:elasticloadbalancing:us-east-1:123456789012:listener/app/MyALB/50dc6c495c0c9188/a2e5d5c1b6a3c6cb \
  --default-actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/MyGreenTG/1a2b3c4d5e6f7g8h9i0j

ALBのターゲットグループを柔軟に切り替えることで、段階的にトラフィックを誘導可能です。

3. デプロイ戦略の選択ガイド

デプロイ方式	メリット	デメリット	適用ケース
Blue-Green	ダウンタイムなし、即時ロールバック	インフラコストが増加、DB切り替えが難しい	重要アプリの即時切替、システム全体の刷新
Canary	小規模から安全に導入可能、影響の限定化	監視体制の構築が必須、時間がかかる	段階的なアップデート、ユーザー数が多いサービス

4. AWSでのデプロイにおけるベストプラクティス

ALBやRoute 53を活用し、柔軟にトラフィックを制御
CloudWatchと統合し、リアルタイムでエラーレートやレスポンスタイムを監視
CodeDeployのライフサイクルイベントを活用し、自動テストを導入
問題発生時の自動ロールバック機能を有効化
Infrastructure as Code（IaC）による再現性のある構成管理（例：CloudFormation, Terraform）

5. まとめ

Blue-GreenデプロイとCanaryデプロイを正しく活用することで、AWS上でのアプリケーションのリリースはより安全で柔軟なものとなります。

Blue-Greenデプロイ： ECSやEC2など、環境切替型のデプロイに有効
Canaryデプロイ： LambdaやAPI Gatewayなど、段階配信型に適したデプロイ
CloudWatch・CodeDeployとの連携： モニタリングと自動ロールバックによる信頼性向上