要件からDeployment Architectureを選択する

1. 要件から制御へ変換する

最初にAWSサービスを選ぶのではなく、シナリオの要件をアーキテクチャ上の性質へ変換します。

制御名の暗記ではなく、要件から必要な性質を導けることが重要です。

2. 必須制約を利点比較より先に確認する

コンプライアンス、必要なOS 制御、許容ダウンタイムなどの必須制約を満たさない候補は、運用上の利点が大きくても選択できません。

必須制約を満たす？
├─ いいえ → 候補から除外
└─ はい
    ↓
リスク / コスト / 運用負荷を比較

最速・最も自動化された構成を選ぶのではなく、必須要件を満たす候補の中から比較します。

3. 制御をレイヤーとして組み合わせる

各制御は別の責任を持つため、1つを採用しても他のレイヤーが自動的に決まるわけではありません。

信頼できる正本
  コードとしてのインフラストラクチャ（IaC）
        ↓
リリース ワークフロー
  CI/CD / 承認
        ↓
本番ロールアウト
  デプロイパターン
        ↓
障害復旧
  ロールバック / 前進修正
        ↓
運用上のモデル
  マネージド / セルフマネージド

必要なレイヤーだけを要件に合わせて組み合わせます。

4. 自動化と承認を同時に満たす

自動化とガバナンスは二者択一ではありません。例えばビルド、テスト、ステージングまでは自動化し、本番移行だけ手動承認を要求できます。

送信元
↓
ビルド / テスト
↓
ステージング
↓
承認ゲート
↓
本番

承認要件を維持したまま、機械的に実行できる処理を自動化します。

5. デプロイパターンはリスク要件から選ぶ

パターン名から選ぶのではなく、ダウンタイム、初期影響範囲、本番検証、追加キャパシティ、復旧速度の優先度から選択します。

6. デプロイと復旧を同時に評価する

トラフィックを旧環境へ戻せても、データベーススキーマや外部状態が非互換なら完全な復旧にならない場合があります。

デプロイ戦略
+
復旧トリガー
+
復旧対象
+
状態互換性
+
検証

デプロイの速さだけでなく、失敗時に何をどこまで戻せるかをアーキテクチャ選択へ含めます。

7. 運用負荷をアーキテクチャ要件として扱う

同じビジネス要件を満たす候補なら、プロビジョニング、パッチ適用、バックアップ、スケーリング、フェイルオーバーなどの独自運用をどれだけ減らせるかも比較します。

マネージドサービス候補
↓
厳格な要件を満たす？
↓
互換性成立？
↓
運用上の 責任は減る？
↓
移行リスクを許容できる？

マネージドサービスは自動的な正解ではなく、必要な制御を保ちながら運用負荷を下げられる場合に有力です。

8. 要件が衝突したら優先度とトレードオフを決める

ダウンタイム最小、追加キャパシティ最小、即時ロールバックなどは同時に最大化できないことがあります。

必須制約を固定した後、残る要件の優先度で候補を比較します。

9. 候補を変えたら制御も再評価する

アーキテクチャ選択は一方向ではありません。プラットフォームやマネージドサービス候補を変更すると、利用できるデプロイ機能、アップグレード経路、復旧仕組み、顧客責任も変化します。

要件 / 必須制約
↓
プラットフォーム / サービス候補
↓
デプロイ / 復旧制御
↓
運用負荷 / リスク
↓
要件を満たす？
├─ はい → アーキテクチャ選択
└─ いいえ
    ↓
候補または制御を変更
    ↺ 再評価

最初に選んだ制御を固定したままプラットフォームだけ置き換えず、組み合わせ全体を再評価します。

10. シナリオ：複数要件を統合する

顧客向けサービスに次の要件があるとします。

インフラストラクチャを複数環境へ再現
頻繁なリリース
本番前の承認必須
初期 外部公開を限定
異常時は復旧可能
運用要員は少ない

候補は、IaC、CI/CD、承認ゲート、限定外部公開、復旧仕組み、必要に応じたマネージドサービスを組み合わせます。どれか1つだけで全要件を満たそうとしません。

11. 障害モード

12. SAP-C02判断フロー

ビジネス要件
↓
必須制約を抽出
↓
要件 → 制御へマッピング
↓
プラットフォーム / サービス候補を選ぶ
↓
IaC / CI/CD / デプロイ / 復旧を組み合わせる
↓
運用負荷 / リスクを評価
↓
要件を満たす？
├─ いいえ → 候補 / 制御を再評価 ↺
└─ はい → アーキテクチャ選択