outputBlue-GreenデプロイとカナリアリリースのAWS実践ガイド｜ダウンタイムゼロを実現するデプロイ戦略の選び方

オンプレ時代、リリース作業といえば深夜のメンテナンス窓にアプリを止めてデプロイ、動作確認して開放——という流れが当たり前でした。しかしクラウド時代に入ると、「そもそもダウンタイムを発生させないリリース」が標準となりつつあります。

Blue/Greenデプロイとカナリアリリースはどちらもそのための手法ですが、仕組みも使いどころもまったく異なります。「名前は聞いたことがあるけど、実際にAWSでどう実装するのかわからない」「どちらを使えばいいのか判断基準が知りたい」という方は多いはずです。

この記事では、Blue/Greenデプロイとカナリアリリースをオンプレ経験者向けにわかりやすく解説し、AWS CodeDeploy・Amazon ECS・Amazon Route 53を使った具体的な実装手順、現場での使い分け基準、よくあるトラブルと対処法まで網羅して解説します。

なぜデプロイ戦略がクラウド時代に重要になったのか

オンプレでは、サーバーを新しくするには物理マシンを用意して設定を書き換える必要がありました。コストも時間もかかるため、「なるべく変更回数を減らし、一度に大きなリリースをする」という方向に自然と向かいます。クラウドではサーバーがAPIで秒単位に作れます。古い環境と新しい環境を同時に立ち上げてトラフィックを切り替える、少しずつ新しい環境に流していくなど、オンプレではコスト的に不可能だった戦略が現実的な選択肢になりました。

この変化の背景には、3つの要因があります。

・インフラのコード化（IaC）: Terraform・CloudFormationで環境を複製できる
・コンテナ技術の普及: ECSやEKSでアプリとインフラを一体管理できる
・継続的デリバリーの浸透: CodePipeline・GitHub Actionsでリリース頻度が上がっている

週1回の大きなリリースではなく、1日に何度もリリースするスタイルに変わった今、「いかにリスクを下げてデプロイするか」が重要な設計課題になっています。

Blue/Greenデプロイの仕組みとオンプレとの違い

Blue/Greenデプロイとは、現行の本番環境（Blueと呼ぶ）と同等の新環境（Greenと呼ぶ）を並行して立ち上げ、テストが完了したらトラフィックをまるごとGreenに切り替える手法です。

オンプレで近いことをしようとすると、物理サーバーをもう1台用意して、ロードバランサーのバックエンドを切り替える——という作業になります。サーバー代が倍かかるため、恒常的な運用としては現実的ではありませんでした。クラウドならば、EC2インスタンスやECSタスクを一時的に2セット立ち上げても、切り替え後に旧環境を削除すればコストは最小化できます。オンプレの「物理的制約」がなくなったことで、初めて実用的な戦略になりました。

1. Blue/Greenデプロイの基本的な流れ

AWS CodeDeployを使ったEC2のBlue/Greenデプロイを例に流れを説明します。

1. 現行のEC2グループ（Blue）がALBの背後で稼働中
2. CodeDeployが新しいEC2グループ（Green）を起動し、新バージョンのアプリをデプロイ
3. ヘルスチェックが通ったら、ALBのターゲットグループをGreenに切り替え
4. しばらく待機した後、Blueを終了（またはロールバック用に一定時間保持）

切り替えはALBのターゲットグループ付け替えによって行われるため、ユーザーからはダウンタイムなしに見えます。もし切り替え後に問題が発見されても、Blueがまだ生きていれば即座にトラフィックを戻せます。

# AWS CLI: CodeDeployのBlue/Greenデプロイグループ作成例
aws deploy create-deployment-group \
  --application-name MyApp \
  --deployment-group-name MyBGDeploymentGroup \
  --service-role-arn arn:aws:iam::123456789012:role/CodeDeployRole \
  --deployment-style \
    '{"deploymentType":"BLUE_GREEN","deploymentOption":"WITH_TRAFFIC_CONTROL"}' \
  --blue-green-deployment-configuration \
    '{"terminateBlueInstancesOnDeploymentSuccess":{"action":"TERMINATE","terminationWaitTimeInMinutes":60},"deploymentReadyOption":{"actionOnTimeout":"CONTINUE_DEPLOYMENT"}}' \
  --load-balancer-info \
    '{"targetGroupPairInfoList":[{"targetGroups":[{"name":"blue-tg"},{"name":"green-tg"}],"prodTrafficRoute":{"listenerArns":["arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:listener/app/my-alb/xxx/yyy"]}}]}'

2. ECSのBlue/Greenデプロイ

Amazon ECSでは、AWS CodeDeployとECSを組み合わせたBlue/Greenデプロイが最も普及しています。コンテナイメージを差し替えて新タスクを起動し、ALBのトラフィックを切り替えるまでが自動化されます。

ECSのBlue/Greenで特徴的なのは、テストリスナーと本番リスナーを分けて設定できる点です。

・テストリスナー（例: ポート8080）: Greenに先行でルーティングし、自動テストや社内確認を実施
・本番リスナー（例: ポート443）: 確認完了後にGreenに切り替え（ここで初めてユーザーが新バージョンを踏む）
・ロールバック: Blueに戻す場合も数秒で完了（ECSタスクはすでに稼働中のため）

ECSタスク定義でコンテナイメージのタグを更新し、CodeDeployのデプロイをトリガーするだけで一連の流れが動きます。ECRにイメージをプッシュ → CodePipelineでデプロイ → CodeDeployがBlue/Green切り替えを実行、というCI/CDパイプラインを組むのが現場での標準的な構成です。

3. 料金の考え方

Blue/Greenデプロイ中はBlueとGreenが同時稼働するため、一時的にEC2・ECSの料金が2倍になります。ただし、切り替え後にBlueを速やかに削除すれば、余分にかかるのはデプロイ時間（通常15分～1時間程度）分だけです。

・EC2（t3.medium、東京リージョン ap-northeast-1）: 約$0.0544/時間（2026年3月時点）
・2台並行稼働で1時間追加: 約$0.054の追加コスト
・ECS Fargate（vCPU 0.5、メモリ 1GB）: 約$0.02/時間（2026年3月時点）

ほとんどのケースで、ダウンタイムによる機会損失と比較すれば無視できるレベルです。コスト最適化の観点では、CodeDeployのterminationWaitTimeInMinutesを必要最小限（問題発見に十分な観察時間）に設定し、Blueを長時間放置しないことが大切です。

カナリアリリースの仕組みとBlue/Greenとの違い

カナリアリリースとは、新バージョンのアプリへのトラフィックを少量（たとえば5%）から始めて、問題がなければ徐々に100%まで引き上げていく手法です。名前の由来は炭鉱のカナリア——危険を検知する役割を担う少数が先に新環境に入り、安全確認後に全員が移行するイメージです。

Blue/Greenとの根本的な違いは「切り替え方」にあります。Blue/Greenは「0%か100%か」のバイナリな切り替えです。カナリアは「5%→25%→50%→100%」のように段階的にトラフィックを移行します。

1. AWS CodeDeployの段階的デプロイ設定

CodeDeployには、トラフィック移行設定として以下の3パターンが用意されています。

・TimeBasedCanary: 最初に指定した%のトラフィックを移行し、一定時間後に残りを移行
・TimeBasedLinear: 一定間隔で均等にトラフィックを移行（例: 10%ずつ10分おき）
・AllAtOnce: 一括移行（Blue/Greenと同等。検証用途には不向き）

# AWS CLI: カナリア10%→5分後に残り90%を移行するデプロイ設定
aws deploy create-deployment-config \
  --deployment-config-name MyCanary10Percent5Min \
  --compute-platform ECS \
  --traffic-routing-config '{
    "type": "TimeBasedCanary",
    "timeBasedCanary": {
      "canaryPercentage": 10,
      "canaryInterval": 5
    }
  }'

# Linear: 10%ずつ、1分おきに増加（10分で100%到達）
aws deploy create-deployment-config \
  --deployment-config-name MyLinear10Percent1Min \
  --compute-platform ECS \
  --traffic-routing-config '{
    "type": "TimeBasedLinear",
    "timeBasedLinear": {
      "linearPercentage": 10,
      "linearInterval": 1
    }
  }'

カナリア期間中にCloudWatchアラームをCodeDeployに連携させると、エラーレートやレイテンシが閾値を超えた時点で自動的にロールバックをトリガーできます。手動で監視する必要がなく、問題発生から数分以内に自動で切り戻しが行われます。

2. Amazon Route 53の加重ルーティングによるカナリア

Route 53の加重ルーティングポリシーを使うと、DNSレベルでのトラフィック分割ができます。新しいALBやCloudFrontディストリビューションに少しずつトラフィックを振り向ける方法です。

設定イメージとしては、同一ドメインに対して2つのAレコード（またはエイリアスレコード）を作り、それぞれにウェイトを割り当てます。ウェイト90:10なら、おおよそ90%が旧ALB、10%が新ALBに向きます。

ただし、DNSにはTTLによる遅延があります。TTLを短く設定（例: 60秒）しても、切り替え直後はDNSキャッシュを持つクライアントが旧環境に向き続けます。即時のロールバックが必要な場面には向いていません。確認に時間的余裕がある、大規模なサービス移行などに適した方法です。

3. AWS Lambda関数のカナリアデプロイ

AWS Lambdaには、関数のバージョン管理とエイリアスによるトラフィック分割機能が組み込まれています。

# Lambdaエイリアスで10%を新バージョンv2に向けるAWS CLI例
aws lambda update-alias \
  --function-name MyFunction \
  --name production \
  --function-version 1 \
  --routing-config AdditionalVersionWeights={"2"=0.1}
# → 90%がv1、10%がv2に自動ルーティングされる

サーバーレスアーキテクチャではECSのようなインフラ管理が不要なため、関数単位のカナリアデプロイが最もシンプルに実現できます。CodeDeployとLambdaを組み合わせると、カナリア中のCloudWatchアラーム自動ロールバックも同様に設定できます。

Blue/Green vs カナリア：どちらを選ぶべきか

現場でよく聞かれる「どちらを使えばいいのか」という問いへの回答は、「目的によって違う」です。以下の判断チェックリストを参考にしてください。

Blue/Greenデプロイが向いているケース

・一括リリースで確実に切り替えたい: DBスキーマ変更を伴うリリースや、バッチ処理のリリース
・テスト環境での確認で十分: 機能変更が限定的で、本番トラフィックを使った確認が不要
・ロールバックの速度が最優先: 切り戻し時間を秒単位で保証したい
・セッション管理が複雑でない: 外部セッションストアを使っており切り替え時の影響が限定的

カナリアリリースが向いているケース

・UIや機能変更の実ユーザー反応を測定したい: 新しいUIへの反応をA/Bテスト的に確認
・本番負荷での安定性を段階的に確認したい: ステージング環境で再現できない性能問題を早期検出
・マイクロサービスの段階的な移行: 複数サービスが連携している環境での慎重なリリース
・新しい外部APIやデータソースへの切り替え: 段階的に流量を増やしながら安定性を確認

判断チェックリスト

・DBスキーマの後方互換性がない変更を含む → Blue/Green推奨
・ユーザーの行動データで新機能を評価したい → カナリア推奨
・問題発生時の影響範囲を最小化したい（一部ユーザーにとどめる） → カナリア推奨
・切り替え後に素早くロールバックできることが最重要 → Blue/Green推奨
・コスト的に並行稼働時間を最短にしたい → Blue/Green推奨（1回の切り替えで完了）
・CloudWatchアラームと連動した自動ロールバックを組み込みたい → どちらも対応可能

実装前に確認すべき設計上のポイント

1. ステートレス設計になっているか

Blue/GreenでもカナリアでもリリースのたびにEC2インスタンスやECSタスクが入れ替わります。アプリの状態（セッション情報・一時ファイル等）をインスタンスのローカルに持っていると、切り替え時に情報が失われます。

Amazon ElastiCache（Redis）を使ったセッション外部化、またはJWTなどのトークンベース認証への移行が前提条件になります。これはBlue/Greenに限らず、クラウドのオートスケーリングを活用するためのインフラ設計の基本です。

2. ヘルスチェックの設定

ALBのヘルスチェックが適切に設定されていないと、起動中のGreenインスタンスに本番トラフィックが流れてしまいます。CodeDeployにはデプロイフック（ApplicationStart・ValidateService等）が用意されており、アプリの起動完了を確認してからALBに登録するよう制御できます。

・ヘルスチェックパス: アプリのメインエンドポイントではなく /healthcheck 等の専用エンドポイントを用意
・ヘルスチェック間隔・閾値: ALBのデフォルト（30秒間隔・2回連続成功）よりも短い間隔に調整
・ウォームアップ時間: CodeDeployの設定でアプリ起動に必要な時間を考慮した待機時間を設定

3. CloudWatchアラームとの自動ロールバック連携

カナリアリリース中に自動ロールバックを機能させるには、CodeDeployのデプロイグループにCloudWatchアラームを関連付けます。監視すべき主なメトリクスは以下の通りです。

・HTTPCode_Target_5XX_Count: ALBバックエンドの5xxエラー数
・TargetResponseTime: レスポンスタイムの増加
・UnHealthyHostCount: ALBターゲットの異常ホスト数

アラームがOK状態を外れた時点でCodeDeployが自動的にロールバックを開始します。夜間リリース時や自動化されたCI/CDパイプラインで特に有効な設定です。

よくあるトラブルと対処法

1. セッションが切れてユーザーがログアウトされる

Blue/GreenでBlueからGreenに切り替えた瞬間、セッションがBlueのサーバーに残っていたユーザーはセッション切れになります。オンプレからの移行直後に最も多く出るトラブルです。

対処法: ElastiCache（Redis）などの外部セッションストアを使い、セッションをEC2/ECSに依存させない設計にします。切り替えるまでにこの対応を済ませておくことが必要です。

2. DBスキーマ変更との整合性が取れない

新アプリ（Green）が新しいDBスキーマを必要とする場合、Blueがまだ動いている間はDBの後方互換性が必要になります。新しいカラムを追加する場合はNULLABLEにする、旧アプリが使わないカラムを先に追加だけしておくなどの対応が必要です。

対処法: DBスキーマ変更を「後方互換フェーズ」「切り替えフェーズ」「旧コード削除フェーズ」の3段階に分けます。1回のリリースでスキーマとアプリの両方を変えない、というルールを開発チームで徹底することが大切です。

3. Greenへの切り替え後にヘルスチェックが落ちる

新しいインスタンスが起動してもアプリの初期化に時間がかかり、ALBのヘルスチェックが通る前にトラフィックが到達してしまうケースです。JVMアプリやPythonのDjangoなどは起動に数十秒かかることがあります。

対処法: CodeDeployのAfterInstall・ApplicationStartフックでアプリの起動完了を確認してからALBへの登録を行うよう設定します。/healthcheckエンドポイントが200を返すまでポーリングするシェルスクリプトをフックに仕込む方法が現場では多く使われます。

4. カナリア中にログがBlue/Green混在して分析できない

BlueとGreenのログが混在すると、どちらのバージョンのエラーかわからなくなります。特にカナリア中は両バージョンが同時稼働するため、原因特定が難しくなります。

対処法: CloudWatch Logsのロググループをバージョンごとに分けるか、ログの各行にapp_versionフィールドを必ず含める設計にします。CloudWatch Insightsでは次のようなクエリでバージョン別のエラー率を比較できます。

# CloudWatch Insightsクエリ例: バージョン別のエラー率を比較
fields @timestamp, app_version, status_code
| filter status_code >= 500
| stats count(*) as error_count by app_version
| sort error_count desc

本記事のまとめ

Blue/Greenデプロイとカナリアリリースはどちらもダウンタイムゼロを実現するためのデプロイ戦略ですが、目的と使いどころが異なります。

オンプレ時代は「リリース＝危険な作業」でした。クラウドのデプロイ戦略を身につけることで、リリースを「安全・小さく・頻繁に」行えるようになります。まずはCodeDeployでBlue/Greenを試し、慣れてきたらカナリアデプロイと自動ロールバックを組み合わせるという順序で進めるのが現場での定石です。

Linuxサーバーの基礎については、姉妹サイトLinuxMaster.JPで詳しく解説しています。EC2やECS上のアプリがBlue/Green切り替え時に安定稼働するためには、OS・ミドルウェアレベルの知識も欠かせません。