こんにちわ。プロフェッショナルサービス事業部の小松です。
Amazon ECSでタスクの再起動をせずにコンテナを再起動することができる再起動ポリシーを設定できるようになりました。
https://aws.amazon.com/jp/about-aws/whats-new/2024/08/amazon-ecs-restart-containers-task-relaunch/
アップデート内容
これまではECSで利用しているコンテナが異常終了した場合、タスクの再起動を行うことで正常復帰する仕組みになっていました。今回のアップデートにより、タスクを再起動するのではなく、タスク上で動いているコンテナ単体を再起動させることができるようになりました。
何が嬉しいのか
タスクの再起動が発生した場合、新しいタスクの起動や古いタスクのドレインに時間がかかり、どうしても数分間のダウンタイムが発生します。一方でコンテナの再起動の場合、ローカルでの再起動となるため数秒での復帰が可能になるとのこと。
実際に比べてみた
実際にどれくらいの差があるのかを確認してみました。
まずはnginxを起動させるサービスを2つ用意し、片方のサービスだけ再起動ポリシーの設定を入れておきます。
また、異常終了を意図的に作り出すために、ECS-Execでコマンドを実行する準備もしておきました。
今回用意したタスク定義はこんな感じ。
{
"containerDefinitions": [
{
"essential": true,
"image": "nginx:latest",
"logConfiguration": {
"logDriver": "awslogs",
"options": {
"awslogs-group": "/ecs/sample-task-definition",
"awslogs-region": "ap-northeast-1",
"awslogs-stream-prefix": "ecs"
}
},
"name": "sample-fargate-app",
"portMappings": [
{
"containerPort": 80,
"hostPort": 80,
"protocol": "tcp"
}
],
"restartPolicy": {
"enabled": true,
"ignoredExitCodes": [0],
"restartAttemptPeriod": 180
}
}
],
"cpu": "256",
"executionRoleArn": "arn:aws:iam::123456789012:role/ecsTaskExecutionRole",
"taskRoleArn": "arn:aws:iam::123456789012:role/ecsExecTaskRole",
"family": "sample-task-definition",
"memory": "512",
"networkMode": "awsvpc",
"runtimePlatform": {
"operatingSystemFamily": "LINUX"
},
"requiresCompatibilities": ["FARGATE"]
}
restartPolicyのブロックの有無だけ違うサービスになっています。また、TaskRoleにはECS-Execに必要なポリシーを含めてあります。
素のnginxトップページが表示されたところから、ECS-Execを利用してnginxのメインプロセスをkillしてみます。この際に SIGTERM だと正常終了と識別されてしまうため、 SIGKILL を指定してプロセスを強制終了していきます。
まず、再起動ポリシーを入れていないサービスでは、プロセスの強制停止した後にnginxトップページが表示されるまでに1分3秒ほどかかりました。
こちらはタスク自体が再作成されるため、IPアドレスも変わるのが注意点になります。また、シグナルを送るとCloudShellの応答が無くなるので、CloudShellの再起動が必要になってしまいました。。。
続いて、再起動ポリシーを入れているサービスで試したところ23秒で応答が再開されました!タスクIDもIPアドレスも変化することなくnginxトップページが応答するようになりました。
アプリケーションの異常終了をした際、復旧までにかかる時間が半分以下となりました。この再起動ポリシーを利用してさらに安定したサービス提供を目指してみてはいかがでしょうか。