1. 何が起きたか
Amazon Aurora PostgreSQL-Compatible Edition を利用しているシステムがあり、PostgreSQLのバージョンが13系でした。
Aurora PostgreSQL のリリースカレンダーを確認すると Auroraの標準サポート終了日が迫っていることに気がついたため、バージョンアップ計画とバージョンアップ手順の作成していました。
DBメンテナンスの事前作業手順にECSタスクのタスク停止し、アプリケーションからデータベースへのアクセスを防ごうとしていたのですが、タスクをAWSマネジメントコンソールからタスク停止を行ったところ数分後にタスクが立ち上がっていました。
もしこれが本番環境だった場合、アプリケーションからDBの操作が発生し事故に発展する可能性があります。
正しいECSタスクの止め方とユーザーからのアクセスを止める方法について述べていきます。
2.2. 復活した理由
結論：ECSサービスが「あるべき姿（Desired Count）」を維持しようとしたためです。
ECSサービスには、*「常に実行しておきたいタスクの数」*を指定する desiredCount（希望するタスク数）という設定があります。
ECSサービスは、以下のタスクを監視しています。
-
理想（Desired）： ユーザーが設定した「実行したいタスク数」
-
現実（Running）： 実際に動いているタスクの数
今回、私が手動でタスクを停止したことで、ECSサービスは「現実が理想を下回った」と判断しました。その結果、サービスは自動的に新しいタスクを起動し、差分を埋めようとしたのです。
※ ECSにとって、手動停止もシステム障害も「タスクが減った」という事実に変わりはありません。desiredCount が 0 でない限り、タスク内のコンテナが復活します。
3. 正しい対処方法
ECS 上で稼働させているアプリケーションからDB にアクセスさせたくないケースがあるのであれば、タスクを停止するという方法はおすすめできません。
前述したとおり、ECS サービスで設定したdesiredCountの設定値通りのコンテナをECS サービスが稼働させ続けようとするからです。
以下、ECS へ接続を防ぐ方法の一例です。
3.1. タスクを停止する場合
ECS タスク内のコンテナを停止させたい場合は、ECS サービスの desiredCount を 0 に設定を変更させます。
この設定により ECS サービスのがECS タスク内のコンテナ数を 0 に自動的に保つようになります。
3.2. ALB (Application Load Balancer) の場合
セキュリティグループのインバウンドルールを一時的に削除（または許可されていないものに変更）する方法です。 これにより、ECSタスクが動いていたとしても、外部からのリクエストがDBに到達する前にALBで遮断されます。 ※注意: ユーザーにはタイムアウトやエラー画面が表示されるため、あらかじめメンテナンス画面（Sorryページ）への切り替え設定もセットで検討するのが理想的です。
4. 学び
4.1. タスク停止ではなくサービスの設定変更
ECS などのクラウドネイティブなリソースは、停止ではなく、サービスの設定変更で対応するのが理想的です。
ECS では、サービス全体のあるべき姿を変更すべきだと学びました。
4.2. 意図しない自動復旧
本番稼働中はタスクの自動復旧機能は非常に心強い機能ですが、メンテナンス時など意図しない挙動になるケースがあることを学びました。