2024/12/5 ECS のはなし
所属では Amazon ECS Fargate で各アプリケーションサーバーが稼働しています そのため ECS についての知見はポロポロと出てくるので粗雑に列挙します
ECS タスクの情報をパッと集めておく
ECS タスクは何がしかの理由で落ちることがあります
ELB からのヘルスチェックで落ちる、アプリケーション起動時に例外で起動失敗するしないなど
そしてタスクが落ちた場合のエラーメッセージの確認はだいたい1時間ほどで取得できなくなります
オフトピですが所属ではタスクが落ちたイベントを拾って Chatbot 経由で Slack に通知しています 特に見覚えのない状況でタスクが落ちて問い合わせたい場合、AWSサポートケースに該当のタスクIDなどを連携する必要な場面もあります
勤務時間帯であればその場で起動してたタスク群を取得しておきたいです
aws ecs コマンドを使っても出力されるのですが、わたしは ecstaをよく使っています ecsta list --cluster awesome-cluster --service app で見やすい状態でスナップショットをとっておけます
fujiwara さんが記事を昨日ちょうど記事を書かれていました
ecsta trace も便利でタスクが起動できなかったときのデバッグなどでよく利用しています
ECS サービスを削除する
ESC サービスの削除をする機会がありましたが、自分のロールの権限ではもちろん削除ができないだろうとは考えていました
できると思っていた操作が SCP で制限されているのを知らず、tfstate を壊したヘマが以前あったので毎回シミュレータで確認しています
https://scrapbox.io/files/6750dd557327a8aa0edff568.png
ECS サービス削除と直接関係ないですね
ECS Auto Scaling Policy
アプリケーションサーバの接続先となるデータベースのバージョンアップやデータマイグレーションの都合でメンテを入れる場合、サービスを停止するために一時的にマニュアルでアプリケーションサーバのタスクを 0 にするといった所作があると思います
いくつかのコンポーネントの面倒を見ていると、Auto Scaling Policy の場合は desired count が影響を受けるというのをつい忘れがちです
The service scheduler respects the desired count at all times, but as long as you have active scaling policies and alarms on a service, Service Auto Scaling could change a desired count that was manually set by you.
設定している場合はマニュアルで 0 にしても Auto Scaling Policy によりタスクは立ち上がるので注意しましょう
今日は以上です