EventBridge+LambdaからEventBridge+Step Functions+ECSへの道

背景

EventBridgeとLambdaを組み合わせて定期バッチ処理を実行していたところ、Lambdaのタイムアウト制限(15分)に引っかかってしまった…あるあるだと思います。私もそれに引っかかってFargateに移行することになった時の経験を共有しておきます。ちなみに言語はNode.jsです。

改修したところ

イベント引数の直接利用の制限

EventBridgeからLambdaにパラメータを渡す時は、eventオブジェクトで渡すことになります。Fargate（ECS）に移行する際、それと同じようにソースコードの改修を最小限に抑えて場合はちょっと工夫が必要です。渡すJSONにエスケープ記号を入れる必要があります。

Lambdaがターゲットの場合のEventBridgeのInput

{
  "渡したい変数名": "値"
}

ECS Taskがターゲットの場合のEventBridgeのInput

{
  "event": "{\"渡したい変数名\":\"値\"}"
}

引数として受け取る

// 引数からevent文字列を取得
const eventString = process.arg[2];

// JSON文字列をJavaScriptのオブジェクトに変換
const event = JSON.parse(eventString);

SDKのインストール要件

Lambda環境では特定のAWS SDKがデフォルトで利用可能ですが、Fargate環境だとアプリケーションで使用する各AWS SDKを事前にインストールしておく必要があります。私の場合はCloudWatchのSDKのインストールが必要でした。package.json内で依存関係を明示的に管理し、アプリケーションのデプロイ時に適切なバージョンのSDKが含まれるようにしないといけません。

{
  "dependencies": {
    "@aws-sdk/client-cloudwatch": "<バージョン番号>"
  }
}

.tmpディレクトリは使えない

当たり前だろ…と思った方はすいません。私は引っかかりました。Lambdaは実行時に一時ファイルを.tmpディレクトリに保存することが出来ますが、Fargateにはそんなものありません。移行する際は、ちゃんと一時保存用ディレクトリをちゃんと作成しましょう。

まとめ

ソースコードそのまま移動したらいけるやろ…と思っていた時期が私にもありました。そんなに甘いわけないですね。
サーバーレスという共通点はあるものの、サービスを利用する上での前提は異なるので移行の際はしっかり検討した上で実施しましょう。