Terraform applyコース / Chapter 04

定期バッチを短命タスクとして運用する

決まった時刻に必要な処理だけを起動し、終わったら終了する。API serviceを常駐させる設計とは、起動契機・権限・ログの読み方を分ける。

TL;DR

  1. バッチ用task definitionはAPI serviceと別にし、最新イメージを指す。
  2. EventBridge Schedulerが指定時刻にRunTaskを呼び、IAM roleで実行を許可する。
  3. 実行した証拠は、ECS taskの終了状態と同じmessage_idを含むログでつなぐ。

01スケジュールから終了までを一つの経路で見る

「時刻になった」だけでは完了ではない。Scheduler、RunTask、ECS task、ログまでを一つの実行として追う。

EventBridge SchedulerがIAM roleを引き受けてECS RunTaskを呼び、短命のbatch taskがログを出力する構成図
Schedulerが起動を委任し、短命のECS taskが処理とログを残して終了する。

1. task definitionはバッチ専用

slack-metrics-batchは、常駐APIとは別のtask definitionにする。起動前にECRの最新イメージタグを確認し、必要な更新だけをapplyする。

2. SchedulerがRunTaskを呼ぶ

EventBridge Schedulerには実行時刻、ECS cluster、task definition、network設定を渡す。Scheduler自身のIAM roleには、対象taskを起動する権限と、task execution roleを渡すための権限が必要になる。

3. 完了はmessage_idで追う

一回の処理について、Received message、処理のログ、Successfully handled messageを同じmessage_idで結ぶ。近い時刻の別ログを成功証拠にしない。

確認段階見る証拠
スケジュール設定EventBridge Schedulerの対象と実行時刻
task実行ECS taskの起動・停止状態
メッセージ処理同一message_idの受信から成功までのログ

確認用の時刻変更: 動作確認のために一回限りの時刻へ変えたら、確認後にTerraform applyで元の設定へ戻す。

この章で持ち帰ること

  1. 定期バッチは、常駐APIではなく短命taskとして定義する。
  2. Schedulerの実行権限とECS taskの実行権限を区別する。
  3. 実行成功はtask状態だけでなく、同じmessage_idのログで確認する。