AWS Certified Developer - Associate (DVA-C02) #11 Domain 3-3 デプロイ — デプロイ戦略
#10 IaC とサーバーレスデプロイ でデプロイツールを整理したので、デプロイドメインの最後は 無停止で安全に更新する戦略そのもの です。試験は「ダウンタイムなしで、リスクを減らしながら、問題が起きたら素早く戻す」方法を問います。
in-place vs blue/green #
| 区分 | in-place | blue/green |
|---|---|---|
| 方式 | 既存インスタンス上で置き換え | 新環境 (green) にデプロイ後トラフィックを切り替え |
| ダウンタイム | あり得る | なし |
| ロールバック | 再デプロイが必要 (遅い) | トラフィックを blue に戻すだけ (速い) |
| コスト | 低い | 一時的に 2 倍 |
核心: blue/green は速いロールバックと無停止 が強みです。「デプロイ失敗時に即座に戻さなければならない」の答えは通常 blue/green です。欠点は一時的に 2 つの環境を運用するコストです。
トラフィック切り替え方式 #
新バージョンへトラフィックを移す方式は 3 つです。CodeDeploy と SAM がこの名前をそのまま使います。
| 方式 | 動作 |
|---|---|
| Canary | 最初に 一部の比率 (例: 10%) のみ送り、一定時間後に残り全部 |
| Linear | 一定比率ずつ段階的に (例: 10 分ごとに 10%) 増加 |
| All-at-once | 一度に 100% 切り替え |
カナリア・線形は新バージョンを一部のトラフィックで先に検証するため、リスクが低くなります。「新バージョンを少数のユーザーに先に公開して指標を見てから拡大」の答えは カナリア です。
Lambda バージョン・エイリアスと加重ルーティング #
#2 で見たエイリアスがここで核心になります。
- バージョン (Version) — 公開するたびに作られる不変のスナップショット (
:1,:2)。 - エイリアス (Alias) — 特定のバージョンを指すポインター (
prod→:2)。 - 加重ルーティング — エイリアスが 2 つのバージョンに比率でトラフィックを分配 します (例:
:2に 90%、:3に 10%)。
この加重を段階的に上げるのが Lambda のカナリア/線形デプロイです。SAM では AutoPublishAlias と DeploymentPreference (例: Canary10Percent5Minutes) で宣言すると、CodeDeploy が自動でトラフィックを移し、失敗すればロールバックします。
「Lambda の新バージョンを 10% だけ送り、問題なければ全体へ」の答えは エイリアスの加重ルーティング (SAM DeploymentPreference カナリア) です。
API Gateway の段階的デプロイ #
API Gateway も ステージのカナリア設定 で一部のトラフィックを新しいデプロイに送れます。ステージ変数と併用すると、環境別・バージョン別の分岐が可能です。
ECS/EC2 デプロイ戦略の整理 #
- ECS — CodeDeploy で blue/green (新タスクセットにデプロイ後リスナーを切り替え)。ロールバックが速いです。
- EC2 (CodeDeploy) — in-place または blue/green。appspec ライフサイクルフックの
ValidateServiceでデプロイを検証。 - Elastic Beanstalk — Immutable/Blue-Green が最も安全。
自動ロールバック #
デプロイが実際に健全かを判定し、悪ければ自動的に戻すのが運用の核心です。
- CloudWatch アラーム連携 — デプロイ中にエラー率・遅延のアラームが鳴ると CodeDeploy が 自動ロールバック します。
- デプロイ失敗時のロールバック — ライフサイクルフックの検証失敗、ヘルスチェック失敗時に以前のバージョンへ復帰。
- SAM/CodeDeploy のカナリアデプロイはアラームと束ねて「指標が悪化したら拡大停止 + ロールバック」を自動化します。
「新バージョンのデプロイ後にエラー率が急上昇したら自動的に戻せ」の答えは CloudWatch アラーム + CodeDeploy 自動ロールバック です。
戦略選択クイック表 #
| 要件 | 正解 |
|---|---|
| 無停止 + 速いロールバック | Blue/Green |
| 新バージョンを少数に先に公開 | Canary |
| 比率を段階的に増加 | Linear |
| Lambda 新バージョンの段階的切り替え | エイリアスの加重ルーティング |
| 指標悪化時に自動復帰 | CloudWatch アラーム + 自動ロールバック |
試験の出題パターン #
- 「デプロイ失敗時に即座に以前へ戻さなければならない。」 → Blue/Green。
- 「新機能をユーザーの 10% に先に。」 → Canary。
- 「Lambda 新バージョンにトラフィックを段階的に。」 → エイリアスの加重ルーティング (SAM DeploymentPreference)。
- 「デプロイ後エラー率急増時に自動ロールバック。」 → CloudWatch アラーム + CodeDeploy。
- 「EC2 デプロイ後にアプリケーションの正常性を検証。」 → appspec
ValidateServiceフック。
よく出会う落とし穴 #
1) blue/green と in-place のロールバック速度の混同 #
blue/green はトラフィックを戻すだけでロールバックが即時です。in-place は再デプロイが必要で遅いです。
2) バージョンとエイリアスの混同 #
バージョンは不変のスナップショット、エイリアスは指し示すポインター (+加重分配) です。加重デプロイの主体はエイリアスです。
3) 自動ロールバックをヘルスチェックだけと考える #
指標ベースの自動ロールバックは CloudWatch アラーム 連携が核心です。
まとめ #
この記事の要点:
- in-place (低コスト・遅いロールバック) vs blue/green (無停止・速いロールバック・2 倍コスト)
- トラフィック切り替え — Canary (一部を先に)、Linear (段階増加)、All-at-once
- Lambda エイリアスの加重ルーティング でバージョン間の段階的切り替え (SAM DeploymentPreference)
- CloudWatch アラーム + CodeDeploy 自動ロールバック で指標悪化時に復帰
次へ — Domain 4-1 オブザーバビリティ #
デプロイまで終えました。最後のドメインは 18% のトラブルシューティングと最適化です。#12 オブザーバビリティ では、CloudWatch Logs・Metrics・Alarms、X-Ray 分散トレーシング、そして EMF (Embedded Metric Format) でログから指標を抽出する方法を整理します。