Blue/Green・Canary・Rolling Deployment

1. デプロイパターンを複数の軸で考える

SAP-C02では、まず次の2つを分けると判断しやすくなります。

① 環境 / リソースをどう更新するか
② トラフィックや更新対象をどう段階的に切り替えるか

代表的には、環境 / リソース側にブルー/グリーン、インプレース、ローリングがあり、トラフィック外部公開側に一括、カナリア、リニアがあります。ただし、これはアーキテクチャ判断のための分析モデルであり、AWS全体で完全に排他的な公式分類という意味ではありません。

2. ブルー/グリーン：新旧環境を並行して持つ

ブルー/グリーンデプロイでは、現在本番をブルー、新しいバージョンをグリーンとして、2つの本番対応可能環境を並行して用意します。

ブルー
現在本番
       │
       │ グリーン作成
       ▼
グリーン
新しいバージョン
       │
       ▼
テスト / 検証
       │
       ▼
本番トラフィックをグリーンへ移行

大きな特徴は、現在環境を直接書き換えず、新しい環境を別に準備して検証できることです。

3. ブルー/グリーンの判断材料

ブルー/グリーンが強い候補になるのは、デプロイ中の可用性を維持したい、新しいバージョンを本番トラフィック投入前に検証したい、現在バージョンをすぐ捨てたくない、といった要件です。

グリーンに問題
↓
本番トラフィック
グリーン → ブルー

旧環境を保持している間は、トラフィックを戻す復旧を設計しやすくなります。ただし、トラフィック切り戻しとシステム状態全体の復旧は同一ではありません。状態を含む具体的なロールバック設計は変更管理と合わせて判断します。

4. ブルー/グリーンのトレードオフ

ブルー/グリーンではデプロイ中にブルーのキャパシティとグリーン キャパシティを同時に持つ場合があります。

高速なトラフィック切替や分離を得やすい一方、追加キャパシティと運用の複雑さを許容できるかを確認します。

5. カナリア：最初の本番外部公開を小さくする

カナリアデプロイでは、新バージョンへ最初から全トラフィックを送らず、限定された本番外部公開から開始します。

現在 95%
新しい      5%
       ↓
メトリクス / エラー / レイテンシーを観測
       ↓
正常？
├─ いいえ → 外部公開停止
└─ はい → 外部公開拡大

本質は、初期影響範囲を小さくし、本番動作を観測して次の判断を行うことです。

6. カナリアには観測が必要

トラフィックを少量にしただけではカナリアのリスク低減効果を十分に得られません。

限定外部公開
+
観測
+
判断

エラー率、レイテンシー、可用性、ビジネスメトリクスなどを観測し、次の外部公開へ進めるかを判断します。カナリアは一般概念として、2段階だけでなく複数段階へ展開する設計もあり得ます。

7. ブルー/グリーンとカナリアは概念上組み合わせられる

環境構成とトラフィック切り替えを分けて考えると、ブルー/グリーン環境上でカナリアトラフィック切り替えを行う構成が理解できます。

ブルー 現在改訂 ── 90%
                          本番トラフィック
グリーン 新しい改訂     ── 10%
          ↓
      観測
          ↓
      外部公開拡大

この場合、環境の考え方はブルー/グリーンで、リスク制御はカナリアトラフィック切り替えです。ただし、AWSサービスのAPIやコンソールでは、これらが同時に2つの戦略名として指定されるとは限りません。

8. AWS実装でCANARYとLINEARを区別する

Amazon ECSのECS デプロイコントローラーやAWS CodeDeployのデプロイ設定では、CANARYとLINEARが具体的な設定として区別されます。

この具体的なAWS設定では、CANARYとLINEARを別戦略として判断します。一方、一般的なカナリアという概念を「必ず2段階だけ」と一般化しません。

9. ローリング：フリートをバッチ単位で更新する

ローリングデプロイではフリート全体を一度に更新せず、デプロイ単位をバッチ単位で段階的に新バージョンへ切り替えます。

古い  古い  古い  古い
↓ バッチ 1
新しい  古い  古い  古い
↓ バッチ 2
新しい  新しい  古い  古い
↓
新しい  新しい  新しい  新しい

デプロイ中には古いバージョンと新しいバージョンが同時に稼働する期間があります。

10. ローリングの強みと弱み

ローリングでは完全な第2環境をデプロイ完了まで保持せずに段階更新できるため、追加キャパシティコストを抑えたい場合の候補になります。

一方、途中で障害すると混在 バージョン状態になる可能性があります。旧バージョンへの復旧には更新済み単位への再デプロイが必要になる場合があり、ブルー/グリーンのトラフィック切り戻しほど即時とは限りません。

11. ローリングとリニアトラフィック切り替えは同じではない

どちらも「段階的」に見えますが、デプロイ単位の更新とトラフィック切り替えを混同しないことが重要です。

12. インプレース：既存リソース上でアプリケーションを更新する

インプレースデプロイは、新しい並行環境を作成せず、既存コンピューティングリソース上のアプリケーションを更新する方式です。

既存リソース
↓
アプリケーション停止 / 対象から切離し
↓
新しい改訂 インストール
↓
アプリケーション起動
↓
検証

追加環境コストを抑えやすい一方、更新対象そのものへ変更を加えるため、デプロイ中の可用性影響と復旧複雑さを考慮します。

13. インプレースとローリングも排他的ではない

インプレースは「既存リソースを更新するか」という観点で、ローリングは「フリートをどの単位で段階更新するか」という観点です。

既存フリート
インスタンス 1をインプレース更新
↓
インスタンス 2をインプレース更新
↓
インスタンス 3をインプレース更新

そのため、インプレース + ローリングという構成も可能です。インプレース = 一括ではありません。

14. パターンを比較する

15. デプロイリスクから選択する

高リスク変更 + 本番検証

本番動作が不確実で全ユーザーへの同時外部公開を避けたいなら、カナリアが強い候補です。

ダウンタイム最小化 + 高速トラフィック切り戻し

並行キャパシティを許容し、新しい環境を事前検証して旧環境を保持できるなら、ブルー/グリーンが適しています。

コスト機密度 + 段階的なフリート更新

完全な重複 環境を避け、フリートを一部ずつ更新したいならローリングが候補です。

既存コンピューティングを維持

メンテナンス影響を許容し、既存コンピューティングをそのまま更新するならインプレースが候補です。

16. 現在のAWSでの実装例

AWS CodeDeploy

Amazon EC2ではインプレースとブルー/グリーンの両方を利用できます。オンプレミスインスタンスではインプレースを利用します。AWS LambdaとAmazon ECSではCodeDeployによるデプロイはブルー/グリーン型で、トラフィック切り替えとしてカナリア、リニア、一括を選択できます。

Amazon ECS ネイティブデプロイコントローラー

現在 Amazon ECSのECS デプロイコントローラーでは、ROLLING、BLUE_GREEN、LINEAR、CANARYからデプロイ戦略を選択できます。

ここではstrategy = BLUE_GREENとstrategy = CANARYを同時指定するのではありません。CANARYやLINEARもブルー / グリーン サービス改訂を用いてトラフィックを移しますが、API上は個別の戦略として選択します。

17. トラフィック切り替えは環境パターンと分離して考える

AWS CodeDeployのLambda / ECSではブルー/グリーンデプロイのトラフィック切り替えとして、カナリア、リニア、一括を利用できます。

CodeDeploy Lambda / ECS
ブルー/グリーンデプロイ
        ↓
トラフィック切り替え
├─ カナリア
├─ リニア
└─ 一括

一方、Amazon ECS ネイティブデプロイコントローラーではCANARY / LINEAR / BLUE_GREENなどを戦略として個別に選択します。概念上の組合せと、サービス上の設定名称を分けて理解します。

18. 障害モード

19. SAP-C02判断フロー

デプロイ変更
        ↓
新しい環境を並行して用意し
事前検証したい？
        ├─ はい → ブルー/グリーン候補
        │             ↓
        │   初期 外部公開を小さくしたい？
        │             ├─ はい → カナリアを検討
        │             └─ いいえ → 要件に合うトラフィック切り替え
        │
        └─ いいえ
             ↓
完全な重複 環境を避けたい？
             ↓
フリートをバッチ単位で更新？
        ├─ はい → ローリング候補
        └─ いいえ
             ↓
既存コンピューティングを直接更新？
        └─ はい → インプレース候補

最終判断では、ダウンタイム、影響範囲、本番検証、復旧速度、追加キャパシティ、デプロイ継続時間を比較します。

まとめ

• ブルー/グリーンは現在環境と新しい環境を並行して持ち、切替前検証とトラフィック切り戻しを設計しやすいパターンです。
• トラフィック切り戻しとシステム状態全体の復旧は同一ではありません。
• カナリアは初期本番外部公開を限定し、観測後に外部公開を拡大して影響範囲を制御します。
• 一般概念としてのカナリアを必ず2段階と一般化しません。
• Amazon ECSなどの具体設定ではCANARYとLINEARが別戦略として定義されます。
• ローリングはデプロイ単位をバッチ単位で更新し、古い / 新しいバージョンが一時的に混在する場合があります。
• インプレースは既存コンピューティングリソース上のアプリケーションを更新し、ローリングと組み合わせることもできます。
• CodeDeploy Lambda / ECSではブルー/グリーンデプロイのトラフィック切り替えとしてカナリア / リニア / 一括を利用できます。
• 現在 Amazon ECS ネイティブデプロイコントローラーではROLLING / BLUE_GREEN / LINEAR / CANARYを戦略として選択できます。