Deployment Strategyの全体設計

1. デプロイ戦略はビジネス要件から決める

デプロイは新バージョンを配置する作業だけではありません。変更中の可用性、障害時の影響、許容ダウンタイム、復旧時間を含むアーキテクチャ判断です。

使用するAWSサービス
↓
戦略を決める

ではない

ビジネス要件
↓
必要なデプロイ戦略
↓
実装サービスを選ぶ

同じサービスを使っても異なるデプロイ戦略を構成できるため、サービス名を先に決定打にしません。

2. デプロイ要件を分解する

変更に対する要件を、少なくとも次の観点へ分解します。

戦略を選ぶ前に、どの要件が必須で、どこがトレードオフ可能なのかを分けます。

3. 実行時可用性とデプロイ可用性は別に考える

通常時にマルチAZやAuto Scalingで高可用にしていても、デプロイ方法によっては更新時に全面障害を起こせます。

実行時
複数AZ / 複数インスタンス
        ↓
通常時は冗長

デプロイ
問題のある変更を全体へ同時反映
        ↓
デプロイ起因の全面障害

実行時可用性が高いことは、デプロイ中の可用性を自動的に保証しません。

4. ダウンタイム許容度は戦略の制約

顧客から見えるダウンタイムをどこまで許容できるかによって、必要な戦略の性質が変わります。

ダウンタイムが発生する戦略が常に悪いわけではありません。ビジネス要件以上の複雑さやコストを持ち込まないことも設計判断です。

5. デプロイリスクは複数の軸で評価する

デプロイリスクを単一の数値や公式だけで判断しません。主に次の観点を組み合わせます。

• 障害が起こる可能性
• 障害時の影響範囲
• 影響が継続する時間
• 復旧に必要な時間

同じ欠陥でも、全ユーザーへ一度に外部公開する場合と限定された範囲へ外部公開する場合ではビジネス影響が異なります。

6. 影響範囲を戦略選択へ反映する

高リスクな変更では、最初から最大範囲へ反映すると障害時の影響も最大になります。

高リスク変更
↓
許容できる初期 外部公開範囲は？
↓
結果を検証できるか？
↓
影響を制御できる戦略が必要

ここで決めるのは具体的なデプロイパターン名ではなく、変更の外部公開範囲をどの程度制御できる必要があるかです。

7. デプロイ速度と影響範囲はトレードオフになる

広い範囲へ一度に変更を反映すればデプロイ完了を早められる一方、障害時の影響範囲は大きくなります。

広範囲な外部公開
→ デプロイは速い
→ 障害時の影響は大きい

限定的な外部公開
→ 検証段階を増やせる
→ 初期影響を小さくできる

ビジネスが求めるリリース速度と、許容できるリスクのバランスから戦略を選びます。

8. ロールバック要件を戦略選択前に定義する

問題が起きた後で復旧要件を決めるのではなく、変更前に必要な復旧特性を明確にします。

変更障害
↓
何分以内に復旧が必要？
↓
変更はロールバック可能？
↓
その要件を満たせる戦略か？

ここでは個別のロールバックトリガーや復旧手順ではなく、デプロイ戦略が満たすべき復旧要件として扱います。

9. ステートフル変更はロールバック実現可能性を制約する

アプリケーションバージョンを戻せることと、システム全体を元に戻せることは同じではありません。

アプリケーション変更
+
データベーススキーマ / データ / メッセージ形式 変更
        ↓
旧バージョンへトラフィックを戻せる？
        ↓
システム全体として復旧できる？

ステートフルまたは不可逆な変更が含まれる場合、ロールバック要件を満たせるかを戦略選択時に確認します。

10. 「ゼロダウンタイム」をパターン名だけで判断しない

アプリケーション層でサービスを継続できても、データベース、セッション、キャッシュ、外部依存関係などの変更が非互換ならエンドツーエンドでは停止や復旧失敗が起こり得ます。

アプリケーションデプロイ
だけを見る
        ×
アプリケーション
+
状態
+
依存関係
+
トラフィック
を含めて判断

デプロイ戦略は名前ではなく、変更全体が可用性要件を満たすかで評価します。

11. デプロイ戦略とAWSサービスを分離する

AWS CloudFormation、AWS CodePipeline、AWS CodeDeploy、AWS Systems Managerなどは、デプロイや変更管理を実装するために利用できるサービスです。

要件
↓
デプロイ戦略
↓
必要な機能
↓
AWSサービス

特定サービスを選択した事実だけでは、デプロイ戦略は決まりません。

12. 必要な戦略の性質を比較する

すべての要件で常に最善となる戦略はありません。必須制約を満たし、残ったトレードオフを比較します。

13. シナリオから必要な性質を抽出する

顧客向け重要サービス

停止時間を最小化
高リスク変更
復旧は短時間
        ↓
可用性維持
+ 影響限定
+ 高速復旧
が必要

高リスク機能

本番動作が不確実
全ユーザーへの同時影響を避けたい
        ↓
初期 外部公開範囲を
制御できる性質が必要

内部システム

メンテナンスウィンドウあり
短時間停止可
変更リスク低い
        ↓
過剰な複雑さを避けた
単純な戦略も候補

ステートフル変更

アプリケーション変更
+
スキーマ / データ変更
+
高速復旧要件
        ↓
ロールバック実現可能性を先に確認

14. 障害モード

15. SAP-C02判断フロー

ビジネス要件
        ↓
デプロイ要件
        ↓
デプロイ中の可用性は？
        ↓
許容停止時間は？
        ↓
障害時の許容影響は？
        ↓
影響範囲をどこまで限定する？
        ↓
何分以内に復旧が必要？
        ↓
状態を含めてロールバック可能？
        ↓
速度 / リスク / コスト / 複雑さを比較
        ↓
必要なデプロイ戦略の性質を決定
        ↓
実装サービス / パターンを選択

まとめ

• デプロイ戦略はサービス名ではなくビジネス要件から決めます。
• 実行時可用性とデプロイ中の可用性は別に評価します。
• ダウンタイム許容度は戦略選択の主要制約です。
• デプロイリスクは障害発生確率だけでなく、影響範囲や復旧時間も含めて評価します。
• 高リスク変更では、許容できる外部公開範囲を明確にします。
• デプロイ速度と影響範囲にはトレードオフがあります。
• ロールバック要件とロールバック実現可能性はデプロイ前に確認します。
• ステートフル変更があると、アプリケーションだけ戻しても復旧できない場合があります。
• パターン名ではなく、変更全体が可用性要件を満たすかで判断します。
• 要件 → 戦略 → サービスの順に考えます。

主要AWS公式資料

• AWS Certified Solutions Architect - Professional（SAP-C02）試験ガイド
• AWS Well-Architected Framework — 運用エクセレンス 柱
• 緩和する デプロイ リスク
• 失敗した変更に備えた計画
• 安全なデプロイ戦略の採用
• AWS の DevOps 入門 — デプロイ戦略