はじめに
AWS Step Functions を ASL（Amazon States Language）で管理し、 S3・CodePipeline・CodeBuild を用いて CI/CD を構成を見る機会があり、ロールバックの方法としてどのようなパターンが考えられるか気になり、調べました。
本記事では、以下のような構成を前提に、
- ロールバック方法の代表的なパターン
- それぞれの向いているケース
- 自動化を検討してよい境界線
を整理します。
想定する構成（前提）
- Step Functions の ASL 定義ファイルを S3 で管理
- 最新版は
latest/プレフィックスに配置 - 更新前の ASL は
backup/プレフィックスに退避 - S3 更新をトリガに EventBridge → CodePipeline を起動
- CodePipeline
- Source: S3（ASL 定義）
- Build: CodeBuild
-
UpdateStateMachineにより定義を更新
-
- ロールバック時は
-
backup/→latest/に ASL を戻す - Step Functions 定義も旧版へ戻す
-
ロールバック設計の考え方
パターン1：CodePipeline の「ステージロールバック」を使う
概要
このパターンでは、CodePipeline が保持している 過去に成功したパイプライン実行 に対してロールバックを行います。
ロールバックの単位はアーティファクトであり、Step Functions の ASL 定義も、その実行時に使われたアーティファクトへ戻されます。
特徴
ロールバック操作そのものが CodePipeline の実行として記録されるため、「いつ・どのバージョンに戻したか」が明確に残ります。
その結果、監査やトレーサビリティの観点で扱いやすく、CodePipeline が標準で備えている機能のみを使って実現できる点が特徴です。
向いているケース
Step Functions の定義が元に戻れば十分であり、S3 上の latest/ や backup/ といったプレフィックスの状態を厳密に戻す必要がない場合に向いています。
CI/CD をアーティファクト中心で捉え、パイプラインの成果物を正とする考え方を採用している構成では、自然にフィットするパターンです。
向いていないケース
一方で、S3 上のファイル状態そのものを確実に元へ戻す必要がある場合には適していません。
特に latest/ や backup/ を他のシステムや運用が直接参照している構成では、このパターンだけでは要件を満たせない可能性があります。
パターン2：Deploy パイプラインに Rollback ステージを組み込む
概要
このパターンでは、通常のデプロイ用 CodePipeline の中に Manual Approval とロールバック用の CodeBuild を組み込みます。
デプロイ後に問題が発覚した場合、承認を行うことでロールバック処理が実行される構成です。
特徴
デプロイとロールバックが 1 本のパイプラインで完結するため、CI/CD の流れとして理解しやすい点が特徴です。
また、人の判断を挟めるため、誤検知による自動ロールバックといった事故を防ぎやすくなります。
向いているケース
ロールバックも含めて CI/CD の一部として扱いたい場合や、ロールバックの発生頻度が比較的高い環境に向いています。
また、パイプラインの実行履歴や可視性を重視したい場合にも検討しやすい構成です。
パターン3：Rollback 専用 CodePipeline を分ける（おすすめ）
概要
このパターンでは、通常のデプロイ用パイプラインとは別に、ロールバック専用の CodePipeline を用意します。
ロールバックは必要なときにのみ、この専用パイプラインを起動して実施します。
Rollback パイプライン例
ロールバック用パイプラインでは、必要に応じて Manual Approval を挟み、その後 CodeBuild を実行します。
CodeBuild では backup/ から latest/ へ ASL を戻し、あわせて Step Functions の定義を更新します。
処理結果については SNS などで通知する構成を取ることも一般的です。
特徴
ロールバックという「例外作業」を通常のデプロイフローから切り離すことで、責務や権限を明確に分離できます。
その結果、承認履歴や実行履歴、証跡を整理しやすくなり、誤承認や誤実行といった運用事故も防ぎやすくなります。
向いているケース
S3 の状態も含めて確実に元へ戻す必要がある構成に向いています。
ロールバックの頻度は高くないものの、一度の失敗が許されないシステムでは特に有効です。
S3 を含むロールバックでは、最も現実的で安全性の高い選択肢と言えます。
パターン4：自動判定によるロールバック（条件分岐）
概要
このパターンでは、CloudWatch メトリクスやアラームを条件として、自動的にロールバックを実行します。
人の介在を待たず、システムが異常を検知した時点でロールバックを行う構成です。
比較的容易な条件
Step Functions の実行が FAILED や TIMED_OUT になった場合や、一定時間内に失敗が多発した場合など、
「技術的に明確な異常」が検知できる条件であれば、比較的容易に自動化できます。
このレベルであれば、「システムとして壊れているかどうか」を機械的に判断できます。
難易度が跳ね上がる条件
処理結果の内容が正しいか、業務データとして妥当か、外部システムとの整合性が取れているかといった判断を含めると、難易度がかなり高くなりそうです。
Lambda関数を使用すれば、柔軟性高く条件を設定できるものの内容によっては、自動化のメリットより構築の手間によるデメリットのほうが大きいことも多そうな気がしています。
向いているケース
失敗条件が明確であり、誤判定が発生しても影響が限定的なシステムに向いています。
技術的な失敗を素早く検知し、影響を最小化したい場合に有効です。
向いていないケース
処理結果の内容まで含めて判断したい場合や、ロールバック自体が高リスクな操作である場合には、このパターンは適していません。
ロールバック方式と向き・不向きまとめ
| パターン | 自動/手動 | S3も戻す | 向いているケース |
|---|---|---|---|
| ステージロールバック | 半自動 | × | 定義だけ戻せばよい |
| パイプライン内Rollback | 手動 | ○ | ロールバック頻度高 |
| 専用Rollbackパイプライン | 手動 | ○ | 安全性最優先 |
| 条件分岐自動Rollback | 自動 | △ | 技術的失敗のみ |
まとめ
ロールバックを自動化する際は、CloudWatchメトリクスを使用したカウント可能なものに関しては、比較的安易に自動化可能であることが分かりました。一方で、業務的判断や処理内容が正しいかどうかを自動判断させ、ロールバックさせるには、一定の作り込みが必要になると理解しました。