プロローグ
ぼく 「よしバッチプログラム完成、このバッチ処理は 最重要 だから絶対に動かしたいな。」
ぼく 「もし動かなかったら…。。。」
ぼく 「… (´・ω・｀)」
ぼく 「今は考えないでおこう…、ECSのスケジュールされたタスクに登録して…ﾎﾟﾁﾎﾟﾁ」
ぼく 「完了！」
ぼく 「仮にプログラムが失敗しても、プログラムのエラーやタスクの失敗は監視しているし、大丈夫なはず…！」
数ヶ月後
上司 「おい！バッチプログラム動いないみたいだぞ！」
ぼく 「え、何ですって！？エラーやタスクの失敗の通知は来ていないんですが！」
上司 「そんなことはこっちではわからん！何とかしろ！」
ぼく 「は、はい！とりあえず本日分は手動で実行しておきました！」」
終業後
ぼく 「なにが原因で動いてなかったんだろう…。とりあえず、CloudTrailを見てみるか・・・。ECSのタスクはRunTask APIを介して起動されるからEvent名 RunTaskで検索して…。」
ぼく 「あったあった。ええと、失敗の原因は…」
"failures": [
{
"arn": "arn:aws:ecs:ap-northeast-1:xxx:container-instance/xxx",
"reason": "AGENT"
}
]
ぼく 「reason…、AGENT？」
目的
ECS on EC2環境で、タスクの起動が AGENT エラーで失敗することがあります。本稿では、その原因と対策について解説します。
そもそもの原因
コンテナインスタンスとして稼働しているEC2では、ECSとの通信を行うためにECS Agentが常に起動しています。しかしこのAgentが数時間に1度更新されることがあり、そのタイミングとECSタスク起動が重なってしまうと実行がエラーになります。
そもそもEC2の乗り込むことが出来ていないため、プログラムのエラーでもなく、ECSタスクの異常終了でもないわけです。
ではどのように対策すればいいのでしょうか？
対策
まず１つ、StepFunctionsを挟むことが考えられます。
例えば、[AWS] EventBridge Rules による ECS Scheduled Task はエラー時リトライできないでは、EventBridge Rules とECSの間にStepFunctionsを挟むことでリトライを可能にしています。
この方法は素晴らしく、StepFunctionsによるRunTaskであればリトライ可能ですし、変更点も少ないです。（EventBridge Rulesでもリトライは可能ですが、同記事にあるように今回のケースは検知してくれないそうです。）
しかし、多くのタスクが実働してる場合にそれら全てを移行するには少々コストがかかってしまいます。
そのため、起動の失敗を検知し再実行できるインフラは実現できないかと考え以下のようなCloudFormation Templateを作成しました🎉
（アーキテクチャ図右側のリソースを作成します。Repositoryには左側のリソースを作成するためのTerraformもあります。）
このテンプレートは、EventBridgeを利用してECSタスクの起動失敗を検出し、Step Functionsを使ってタスクを再実行します。
前述のインフラとは違い、既存のECSタスクをすべてこのテンプレートに移行する必要はありません。必要に応じて、タスクの起動が失敗した際に再実行を試みます。
詳細
アーキテクチャ図に示した通り、Templateは以下のリソースを作成します。
- EventBridge (and rules)
- Step Functions
a. SNS Topic
b. Lambda Function
（とそれに付随するIAM RoleとPolicy。）
EventBridge
まずは、失敗イベントを検知する必要があります。そのためのEventBridgeです。
具体的なルールはこんな感じです。
{
"detail-type": ["AWS API Call via CloudTrail"],
"source": ["aws.ecs"],
"detail": {
"responseElements": {
"failures": {
"reason": [{
"exists": true
}]
}
},
"requestParameters": {
"startedBy": [{
"anything-but": "AWS Step Functions"
}]
},
"eventSource": ["ecs.amazonaws.com"],
"eventName": ["RunTask"]
}
}
簡単にこのルールの説明をします。
anything-butは否定であり、StepFunctionsがキックしたECSタスクのイベントは含めないことを意味しています。なぜなら無限ループしてしまう恐れがあるからです。
実はテスト中に無限ループしてしまって、大慌てでリソースを削除しました。。。
existsは存在の条件で、今回で言うとfailuresが空配列ではない場合に起動するようにしています。
詳しくは公式を参照。
Amazon EventBridge のイベントパターン
Step Functions
SNSはLambdaと連携し、Slack通知のために使用しています。
Check Reasonで失敗の原因を確認し、AGENTであれば再実行するようにしています。
まとめ
バッチプログラムは多くのアプリケーションで重要な役割を果たしています。その実行が中断されると、結果として大きな問題を引き起こす可能性があります。この記事では、Amazon ECSでのタスク実行が AGENT エラーにより失敗した場合の対処法を提案しました。
その解決策として、ECSの起動失敗を検出し再実行するためのCloudFormationテンプレートを作成しました。EventBridgeを使用して失敗イベントを検知し、Step Functionsを利用してタスクを再起動するという方法を用いました。
また、この方法は既存のECSタスクをすべて移行する必要はなく、タスクの起動が失敗した場合にのみ再実行を試みるという外付けのリソースであるため、実装が楽です。
この記事が、皆さんがAmazon ECSでの信頼性の高いバッチプログラムを実現するための一助となれば幸いです。