こんにちは! Agoと申します｡
今回は問題が発生していたシステムをStepfunctionとECSで構成したことで問題解決できた内容及び､構成する上で詰まった点等を共有させていただきたいと思います｡

読む時間が無い方にも要約(TL;DR)を載せてありますのでそちらだけでも読んでいただけると幸いです｡

TL;DR

前提

旧システムはzipファイル配置バケットから対象となる30件ずつリスト化し､RDSに保存するジョブとRDSの配置リストを元に30件ずつzipを展開して指定バケットに配置するジョブが別れており､それぞれ定期実行で動くシーケンシャルな構成でした｡
下記が以前のインフラの構成図になります

以前までは1つのZipファイルの容量はおよそ50MB〜3GBが主でした
また､一日のZipの配置数は約1000件ほどありました｡

Zipファイルの肥大化
旧システムの仕組み上､Zipの解凍及び展開jobで従来のZipファイルのサイズよりも大きいZipファイルが対象となった場合､定期実行処理のシーケンスに間に合わなくなり､その定期実行処理で拾われた30件のZipファイルがいつまでも配置されない問題が度々発生する様になりました｡
つまり､今回のケースのように､シーケンシャルな構成だと､大容量のZipファイルが置かれた場合に耐えられない構成になっていました｡

上記問題を解決するために下記の構成で解決を検討しました｡

Event Bridge + Stepfunctions + lambdaを使ってS3にZipが配置されたタイミングで1件ごとにZipファイルを処理するイベントドリブンな構成

しかし､この構成だと10GB以上のZipファイルが配置された場合にlambdaの処理制限時間の15分に間に合わないことが判明したため､断念をしました｡
そこで､大容量のZipファイルを処理するために下記の構成にすることで､時間制限なく大容量のzipファイルを処理することに成功しました｡

Event Bridge + Stepfunctions + ECSを使ってS3にzipが配置されたタイミングを検知し､1件ごとにzipファイルを処理するイベントドリブンな構成

実際のインフラ構成図が以下になります｡

StepfunctionsでECSを行う構成で作成を行った際につまずいた点があるため､共有します

今回の改善によって得られたことは以下の通りでした｡

stepfunctionのjobの選択肢として､lambdaの処理制限に引っかかるのであればECSを選ぶのもあり
- ただし､lambdaのように後続処理に値を渡すことが容易ではないため､stepfunctionの定義する内容から取得する等､工夫する必要がある｡