概要
とある案件で AWS の AppFlow を複数件スケジュール実行したいという話があった。
運用コストを極力抑えたかったので、サーバレスの Step Functions を使ってワークフローを書いた。また、本稿では記載していないが、スケジュール実行部分に関してはセオリー通り EventBridge を用いた。
ステートマシンの全体像
親
特に複雑なことはしておらず、実行対象のフロー (ここではバックアップ処理を行うフロー) の一覧を取得し、あとは Step Functions の Map を使って逐次処理しているのみ。一覧取得は若干複雑な条件を利用してフィルタリングしているため、 Lambda で実装している。
Run AppFlow は別のステートマシンであり、いわゆるネストされたステートマシンとなっている。理由としては、後述するステートマシンのイベント数上限を回避しやすくするため。
子
AppFlow の実行と、終了確認を一定時間ごとに行っている。数時間かかるような長いフローだとポーリングする回数が増大してしまい、結果として Step Functions のイベント数クオータ (25,000 events) に達してしまうため、親でひとまとめでやらずにステートマシンを子に分割してクオータに達しにくくしている。
特に Lambda は利用しておらず、Step Functions の SDK 統合機能を使って appflow:StartFlow や appflow:DescribeFlow を呼び出している。
Whether Flow Ended は Step Functions の Choice を使い、DescribeFlow の LastRunExecutionDetails.MostRecentExecutionStatus が
- InProgress:
Waitへ - Successful:
Flow Successfulへ - それ以外:
Flow Errorへ
それぞれ移行するように制御している。
まとめ
ほとんどの処理を Step Functions に任せられることができた。サーバレスであるため運用の手間がなく、また料金面も格安で利用が可能。
Step Functions の SDK 統合機能が強すぎる。