ECSデプロイ失敗時の自動ロールバック環境を構築する

はじめに

本記事では、ECS デプロイサーキットブレーカーを使用し、ECS Serviceのデプロイ失敗時に自動ロールバックされる環境を構築します。
ECS Serviceでは、タスク定義を更新することで新しいバージョンのコンテナへデプロイできます。
通常であれば、新しいタスクが起動し、正常に稼働できることを確認したうえで、古いタスクから新しいタスクへ切り替わります。
しかし、デプロイ時には、以下のような理由で新しいタスクが正常に起動・稼働できない場合があります。

指定したコンテナイメージが存在しない
コンテナ起動時の設定に誤りがある
アプリケーションが起動直後に終了する
ヘルスチェックに失敗する

このような場合、デプロイが正常に完了せず、ECS Serviceが期待した状態に到達できないことがあります。
そこで利用できるのが、ECS デプロイサーキットブレーカーです。
ECS デプロイサーキットブレーカーを有効化し、rollbackオプションを設定することで、デプロイ失敗時に直前の正常な状態へ自動ロールバックできます。

前提（検証構成）

本記事では、過去のECS関連記事と同様に、ALB配下でECS Serviceを稼働させる構成を前提とします。
今回は検証用にFargate起動タイプのECS Serviceを使用し、デプロイサーキットブレーカーによる自動ロールバックの挙動を確認します。

以下の構成・リソースが作成済みであることを前提とします。
VPC、サブネット、セキュリティグループ、ALB、ターゲットグループなどの基本的な作成手順は過去記事と同様のため、本記事では詳細手順を省略します。

VPC
パブリックサブネット2つ
インターネットゲートウェイ
ルートテーブル
セキュリティグループ
ALB
ターゲットグループ
CloudWatch logsロググループ
タスク実行ロール
ECSクラスター
タスク定義
ECS Service

※正常系のタスク定義では、コンテナイメージとして「nginx:latest」を指定しています。
ALBのDNS名へアクセスし、nginxのデフォルトページが表示される状態を、今回のロールバック先となる正常な状態とします。

ECS Service deployment circuit breakerとは

デプロイサーキットブレーカーは、ECS Serviceのデプロイが正常に完了できるかを判定する仕組みです。
有効化すると、ECS Serviceのデプロイが定常状態に到達できない場合に、デプロイを失敗として扱うことができます。

また、ロールバックオプションを有効化することで、デプロイ失敗時に直前の正常なデプロイへ自動ロールバックできます。
失敗判定には、以下の2つの段階があります。

Stage1：タスクが実行中に遷移するか

Stage1では、現在のデプロイに含まれるタスクが実行中に遷移するかを確認します。
タスクが実行中になれない場合、失敗カウントが増加します。
失敗カウントがしきい値に達すると、デプロイは失敗として扱われます。

Stage2：実行中になったタスクのヘルスチェックを確認する

Stage2では、1つ以上のタスクが実行中に遷移した場合に開始されます。
この段階では、現在のデプロイに含まれるタスクに対してヘルスチェックを確認します。
確認対象には、Elastic Load Balancing、AWS Cloud Map、Amazon ECSコンテナヘルスチェックがあります。

ヘルスチェックに失敗した場合、失敗カウントが増加します。
失敗カウントがしきい値に達すると、デプロイは失敗として扱われます。
今回の検証では、存在しないイメージタグを指定することで、新しいタスクが実行中に遷移できない状態を作成していきます。
そのため、本記事ではStage1の失敗パターンを対象に、自動ロールバックの流れを確認します。

検証の流れ

正常に稼働するECS Serviceを確認する
デプロイサーキットブレーカーとロールバックを有効化する
存在しないイメージタグを指定したタスク定義リビジョンを作成する
ECS Serviceを失敗用リビジョンへ更新する
デプロイ失敗と自動ロールバックを確認する

1. 正常に稼働するECS Serviceを確認する

まず、ロールバック先となる正常なECS Serviceを確認します。

今回の正常系では、タスク定義を使用し、コンテナイメージには以下を指定しています。

「nginx:latest」

ECS Serviceを作成後、以下の状態になっていることを確認します。

ECS Serviceの必要なタスク数に対して、実行中タスクが一致していること
タスクが実行中であること
ターゲットグループのヘルスステータスがHealthyであること
ALB経由でnginxの画面が表示されること

この状態が、デプロイ失敗時のロールバック先になります。

2. デプロイサーキットブレーカーとロールバックを有効化する

次に、ECS Serviceのデプロイ設定でデプロイサーキットブレーカーを有効化します。

あわせて、デプロイ失敗時に直前の正常な状態へ戻すため、ロールバックも有効化します。

今回の設定は以下の通りです。

デプロイサーキットブレーカー：有効
ロールバック：有効
最小実行タスク：100%
最大実行タスク：200%

必要なタスク数は1としているため、最小実行タスク100%、最大実行タスク200%の場合、デプロイ中は既存タスクを維持しながら、新しいタスクを最大１つ追加で起動できます。

3. 存在しないイメージタグを指定したタスク定義リビジョンを作成する

次に、意図的にデプロイ失敗を発生させるため、失敗用のタスク定義リビジョンを作成します。

正常系のタスク定義をもとに、新しいリビジョンを作成します。

変更するのはコンテナイメージです。

変更前：nginx:latest
　　　　↓
変更後：nginx:deployment-failure-test

今回は検証用に、存在しないイメージタグを指定しています。
これにより、ECSタスクがコンテナイメージを取得できず、タスクが正常に起動できない状態を作ります。

4. ECS Serviceを失敗用リビジョンへ更新する

作成した失敗用リビジョンをECS Serviceへ適用します。
ECS Serviceを更新すると、新しいタスク定義リビジョンを使用したデプロイが開始されます。
今回の検証では、存在しないイメージタグを指定しているため、新しいタスクは正常に起動できません。
ECS Serviceのイベントを確認すると、失敗用リビジョンのタスク起動が複数回施行されていることを確認できます。

デプロイサーキットブレーカーは、失敗を検知するとすぐにロールバックするわけではありません。
ECS側で一定回数の失敗を確認した後、デプロイ失敗として扱われます。

5. デプロイ失敗と自動ロールバックを確認する

失敗用リビジョンのデプロイが失敗すると、デプロイサーキットブレーカーによりデプロイ失敗が検知されます。
ロールバックを有効化しているため、ECS Serviceは直前の正常なデプロイへ自動ロールバックされます。
今回の検証では、失敗用リビジョンへの更新後、最終的に正常系のリビジョンへ戻ることを確認しました。

ロールバック後は、以下の状態を確認します。

ECS Serviceが安定状態に戻っていること
実行中タスクが正常系リビジョンで稼働していること
ターゲットグループのヘルスステータスがHealthyであること
ALB経由でnginxの画面が表示できること

これにより、デプロイ失敗後に直前の正常な状態へ戻ったことを確認できます。

補足：ALBヘルスチェック失敗について

今回の検証では、存在しないイメージタグを指定し、タスクが実行中に遷移できないパターンを確認しました。
一方で、デプロイサーキットブレーカーでは、タスクが実行中になった後のヘルスチェックも確認対象になります。
ALB配下でECS Serviceを構成している場合、タスク自体が起動していても、アプリケーションの応答内容やヘルスチェックパスの設定によって、ターゲットグループのヘルスチェックに失敗するケースがあります。

このようなケースでも、デプロイサーキットブレーカーとロールバックを有効化しておくことで、デプロイ失敗時に直前の正常なデプロイへ戻すことができます。
そのため、ALB経由でアプリケーションを公開する構成においても、デプロイ失敗時の自動ロールバック手段として活用できます。

まとめ

本記事では、ECS Serviceのデプロイ失敗時に自動ロールバックされる環境を構築しました。
デプロイサーキットブレーカーとロールバックを有効化しておくことで、新しいタスクが正常に起動できない場合でも、直前の正常なデプロイへ戻せることが確認できました。
ECS Serviceの更新では、正常にデプロイできることだけでなく、失敗時の挙動や復旧方法を確認しておくことも重要です。
今回の検証ではコンテナイメージの取得失敗を例に確認しましたが、ヘルスチェック失敗など、ほかのデプロイ失敗パターンでも活用できます。
デプロイ失敗時の復旧手段の一つとして、デプロイサーキットブレーカーの利用を検討してみてください。