Change ManagementとRollback

1. 変更管理は承認だけではない

変更管理は本番変更を制御されたプロセスとして扱います。承認だけでなく、何を変更するか、どのシグナルを障害と判断するか、どの状態へ復旧するか、復旧成功を何で確認するかまで事前に決めます。

計画
↓
レビュー
↓
承認
↓
実行
↓
観測
↓
検証
↓
復旧または完了

障害が発生してからロールバック条件や担当者を決め始める設計では、復旧開始が遅れます。

2. 変更実行前に影響を確認する

本番変更では、変更対象、依存関係、可用性影響、再起動 / 置換、状態への影響、復旧可能性を実行前に確認します。

CloudFormationを利用する変更では、既知の変更セットを変更前の制御として組み込みます。

テンプレート変更
↓
変更セットで影響レビュー
↓
承認
↓
実行
↓
監視 / ロールバック制御

変更セットの詳細なアクション判定そのものではなく、変更管理全体の中で「実行前に何が変わるかを確認する制御」として利用することが重要です。

3. 変更セットとロールバックトリガーは時間軸が違う

変更セット
→ この変更を実行してよいか

ロールバックのトリガー
→ 実行した変更を維持してよいか

4. ロールバックトリガーは変更前に定義する

ロールバックトリガーは「問題がありそうなら戻す」ではなく、観測可能なシグナルとしきい値へ落とします。

エラー率
レイテンシー
可用性
ヘルスチェック
デプロイ障害
        ↓
しきい値 / 条件
        ↓
ロールバック判断

トリガーを変更前に定義すると、障害時に人がゼロから判断基準を作る必要がなくなります。

5. トリガーと仕組みを分離する

ロールバックトリガーとロールバック仕組みは別の責任です。

ロールバックのトリガー
= いつ復旧を開始するか

ロールバックの仕組み
= どう安全な状態へ復旧するか

トリガーだけ存在しても復旧方法がなければ戻せません。逆に復旧手順があってもトリガーが曖昧なら開始判断が遅れます。

6. CloudFormation ロールバックトリガー

AWS CloudFormationではCloudWatch アラームをロールバックトリガーとして利用できます。

スタック 作成 / 更新
↓
CloudWatch アラームを監視
↓
運用完了後も監視期間
↓
アラーム = ALARM ?
├─ いいえ → 変更を維持
└─ はい → スタック運用をロールバック

リソース作成自体が成功しても、アプリケーション正常性やレイテンシーなどのアラームによってロールバック判断へ進められます。

7. CodeDeploy 自動ロールバック

AWS CodeDeployでは、デプロイ障害や設定したCloudWatch アラームを契機として自動ロールバックを構成できます。ただし、具体的な復旧仕組みはコンピューティングプラットフォームによって異なります。

したがって、「CodeDeploy ロールバックは全プラットフォームで同じ改訂再デプロイ」と一般化しません。目的は、プラットフォームに適した仕組みで以前の既知の正常状態へ復旧することです。

8. 復旧対象を一意に特定する

安全な復旧には、どの状態へ戻すかを再現可能に特定できることが必要です。

アプリケーションやインフラストラクチャなどバージョン管理可能な対象では、次のような識別子を利用します。

アプリケーション改訂
コンテナイメージダイジェスト
Git コミット ID
インフラストラクチャ定義
設定バージョン

latest や production-current のような変更可能な識別子だけに依存すると、同じ名前が後から別内容を指す可能性があります。

9. バージョンとアーティファクトを追跡する

変更リクエスト、デプロイバージョン、アーティファクト、本番結果を追跡できると、どのバージョンが正常だったか、どのバージョンを再利用するかを明確にできます。

変更リクエスト
↓
バージョン管理された / 不変 アーティファクト
↓
デプロイ
↓
本番 結果
↓
既知の正常状態 候補

テストしたアーティファクトと本番へデプロイするアーティファクトを同一に保つことも、再現性のある復旧に有効です。

10. 停止とロールバックは同じではない

デプロイを停止しても、変更が一部へ反映済みの場合があります。

新しい  新しい  古い  古い
        ↓
デプロイ停止

これは既知の正常状態へ戻ったことを意味しません。停止は変更の進行を止める操作であり、ロールバックは定義済みの安全な状態への復旧です。

11. トラフィック切り戻しとシステム状態復旧を分ける

ブルー/グリーンなどでは本番トラフィックを旧環境へ戻すことでアプリケーション経路を素早く復旧できる場合があります。

しかし、永続 データや外部状態まで自動的に元へ戻るとは限りません。

新しいバージョン
↓
状態を書き換える
↓
トラフィックを古いバージョンへ切り戻し
↓
状態互換性は別途確認が必要

トラフィック切り戻し ≠ システム状態全体のロールバックとして復旧手順を設計します。

12. ロールバックと前進修正を選択する

障害時に常にロールバックを選ぶわけではありません。

障害
↓
現在状態を確認
↓
安全にロールバックできる？
├─ はい → ロールバック
└─ いいえ → 前進修正を検討

13. 復旧手順を変更前に作る

復旧手順は単なるコマンド一覧ではありません。少なくとも次の要素を定義します。

14. 復旧運用成功だけで完了にしない

ロールバック APIやデプロイジョブが成功しても、ビジネスサービスが正常とは限りません。

復旧運用成功
↓
可用性
エラー率
レイテンシー
機能確認
重要ビジネストランザクション
↓
既知の正常状態を確認
↓
復旧完了

15. CloudFormation 変更のシナリオ

本番スタックを更新し、実行前の影響レビューと、更新後レイテンシー悪化時の自動ロールバックが必要だとします。

テンプレート変更
↓
変更セットで影響レビュー
↓
承認
↓
実行
↓
CloudWatch アラーム監視
↓
レイテンシーしきい値超過
↓
CloudFormation ロールバックのトリガー
↓
スタック運用ロールバック
↓
サービス検証

変更前の制御と変更後の正常性制御を同じ変更プロセスへ組み込みます。

16. アプリケーションデプロイのシナリオ

EC2 / オンプレミスへのアプリケーションデプロイで、デプロイ障害またはエラーアラーム時に以前の正常改訂へ戻す必要があるとします。

バージョン管理された 改訂 v8
↓
CodeDeploy
↓
デプロイ障害 / アラーム
↓
自動ロールバック
↓
以前に成功した 改訂 v7
↓
新しいデプロイとして再デプロイ
↓
サービス検証

このシナリオでは、トリガーと復旧対象の両方が事前に定義されています。

17. 障害モード

18. SAP-C02判断フロー

本番変更
      ↓
変更前の影響レビューが必要？
      ↓
IaCなら変更セット等で確認
      ↓
承認
      ↓
復旧対象を特定
      ↓
ロールバックのトリガーを事前定義
      ↓
実行 / 監視
      ↓
トリガー発生？
├─ いいえ → 検証 → 完了
└─ はい
     ↓
現在状態を確認
     ↓
安全にロールバック可能？
├─ はい → ロールバック
└─ いいえ → 前進修正
     ↓
サービス検証
     ↓
復旧完了

まとめ

• 変更管理はレビュー / 承認だけでなく、実行、監視、復旧、検証まで含む制御されたプロセスです。
• 変更セットは変更前の制御、ロールバックトリガーは実行中・監視期間の障害制御として役割が異なります。
• ロールバックトリガーは観測可能なシグナルとしきい値として変更前に定義します。
• CloudFormationではCloudWatch アラームをロールバックトリガーとして利用できます。
• CodeDeploy 自動ロールバックの具体的仕組みはコンピューティングプラットフォームによって異なります。
• 復旧対象は再現可能に一意特定し、アーティファクトでは不変 / バージョン管理された 識別子を利用します。
• 停止とロールバック、トラフィック切り戻しとシステム状態復旧は同じではありません。
• 現在状態によってはロールバックより前進修正が安全な場合があります。
• 復旧手順にはトリガー、所有者、対象、手順、状態 処理、検証を含めます。
• 復旧運用成功後もサービス検証を行ってから完了と判断します。