![[アップデート] Amazon ECS で手動ロールバック（デプロイメントの手動停止）がサポートされました](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-6d4fdf3578638cab4e6e4655b3d692aa/15a803840d72679e6593006354d5766b/amazon-elastic-container-service)
[アップデート] Amazon ECS で手動ロールバック（デプロイメントの手動停止）がサポートされました
2025.05.06こんにちは！クラウド事業本部コンサルティング部のたかくに（@takakuni_）です。
Amazon ECS で手動ロールバック（デプロイメントの手動停止）がサポートされました。
アップデート内容
アップデート前までの手動ロールバックについて触れていきます。
「ロールバック」と言う言葉の捉え方によっては、「ロールバックじゃない！」という方もいるかもしれませんが、安定バージョンのリビジョンを利用したデプロイメントを再作成することで、もともと手動でロールバックっぽいことができていました。
はじめに ECS サービスへのデプロイが事実上、失敗している（デプロイ自体の状態は IN_PROGRESS で、タスクが起動/停止を繰り返している）状態が発生したとします。
タスクの起動/停止の原因がリビジョン Y の更新内容だったとします。リビジョン Y を利用したデプロイメント 2 を停止したいですよね？
しかし、アップデート前までは「リビジョン Y を利用したデプロイメント 2 を停止する」といった、直接的なデプロイメントの手動停止ができませんでした。
そのため、リビジョン X を利用した、新しいデプロイメント（デプロイメント3）を作成する必要がありました。
デプロイメント 3 によって、以前のデプロイメントで発生した ECS タスクの削除が開始されます。デプロイメント 1 のタスクは削除されてしまいますが、以前の状態へ巻き戻すといった手動のロールバックが完了します。デプロイメント 2 で発生したタスクを起動し続ける挙動は、停止されます。
今回のアップデートは、先ほどできなかった「リビジョン Y を利用したデプロイメント 2 を停止する」ができるようになりました。といったものです。
自動ロールバックについて
先ほど「直接的なデプロイメントの手動停止ができませんでした。」と記載しました。というのも、自動ロールバックが AWS には提供されているためです。
自動ロールバックには、CloudWatch Alarm によるものと、デプロイサーキットブレーカーの 2 種類があります。
CloudWatch Alarm の自動ロールバックは、デプロイ後に HTTPCode_ELB_5XX_Count や CPUUtilization、MemoryUtilization などのメトリクスを監視し、閾値を超えた場合にロールバックする機能です。
デプロイサーキットブレーカーによる自動ロールバックは、デプロイメントによって起動する ECS タスクが、 RUNNING 状態に移行するか/ヘルスチェックに合格するかをチェックし、一定回数チェックに失敗した場合にロールバックをする機能です。
アップデート内容を見てみると、自動ロールバックで提供される CloudWatch Alarm およびデプロイサーキットブレーカーのいずれもで検出されなかった場合に有効である旨が記載されています。（私個人としては体験したことがないですが、頭の片隅に入れておきましょう。）
Previously, in scenarios where a failing deployment was not detected by either of these mechanisms, customers had to manually trigger a new deployment to roll back to a previous safe state.
今回のアップデートで、私個人的に嬉しいポイントは、デプロイサーキットブレーカーが発動するより前にロールバックが可能になったことです。
デプロイサーキットブレーカーの最小タスク数
デプロイサーキットブレーカーが発動するタイミング（何タスク起動失敗したらロールバックするか）は、 ECS サービスに定義した Desired Count（希望するタスク数）に依存し、計算式は Minimum threshold <= 0.5 * desired task count => maximum threshold で求まります。
ただし、最小タスク数は 3 となっており、Desired Count が 1 であっても、タスクが 3 回失敗するのを見届けないと自動ロールバックが働きません。
普段の検証などで時間がかかっていた部分が、解消されそうで嬉しいです。
手動ロールバックの動き
手動ロールバックの挙動について説明します。ECS サービスへのデプロイが事実上、失敗している（デプロイ自体の状態は IN_PROGRESS で、タスクが起動/停止を繰り返している）状態が発生したとします。
StopServiceDeployment API によって、デプロイメント 2 のステータスは ROLLBACK_REQUESTED（ロールバックはリクエストされました）へ移行します。
デプロイメント 2 は ROLLBACK_IN_PROGRESS（ロールバックが進行中）に遷移し、ロールバックを開始します。
最後に ROLLBACK_SUCCESSFUL（ロールバックが成功）に遷移し完了です。この通り、デプロイメント 1 の置き換えが発生することなく、ロールバックが完了します。
やってみた
実際に手動ロールバックを試してみます。
StopServiceDeployment はマネジメントコンソール or API 経由で実行可能です。今回はマネジメントコンソール経由で実行します。
デプロイメントのステータスは成功、デプロイサーキットブレーカーはオンにしています。
ECS タスクの Desired Count は 1 にしています。そのため先ほどの通り、デプロイメントサーキットブレーカーの最小タスク数は 3 になります。
サービスの更新からリビジョンを更新します。このリビジョンでは存在しない、コンテナイメージを取得するよう設定しています。
新しいデプロイメントが作成され、ステータスが進行中になっています。
不明なコンテナイメージを取得しようとしているため、タスクがこけています。想定通りですね。
手動ロールバック
本題の手動ロールバックに移ります。失敗しているデプロイ ID をクリックします。
すると、右上にロールバックがあるのでクリックします。
ロールバックの可否を聞かれます。注意事項を読んでロールバックをクリックしましょう。
ロールバックのリクエストが行われました。
サービスデプロイに戻ると、ロールバックが行われた旨が記載されています。
ロールバックが進行中にステータスが変化しています。
サービスデプロイ側でもステータスの変化が確認できます。
最後にロールバックが成功で完了です。
イベントからもロールバックの履歴を辿れるようになっていました。
また、現行稼働していた ECS タスクも置き換わることなく、ロールバックが完了しています。
まとめ
以上、「Amazon ECS で手動ロールバック（デプロイメントの手動停止）がサポートされました。」でした。
今までやっていた手動ロールバックは一方通行だったため、これはロールバックなのか？と少し疑問に感じていましたが、ついに純粋な手動ロールバックが出てきて嬉しいです。
参考になれば幸いです。クラウド事業本部コンサルティング部のたかくに（@takakuni_）でした！
