AWS Step Functions でタスクがエラーになったときに統一的なエラーハンドリング(エラー処理・リカバリ処理・通知処理など)が必要になることがある💡エラーハンドリングを実現する構成例をいくつか考えてみた👍
もちろん最終的には要件次第ではあって絶対にコレ❗️という答えはないと思う \( 'ω')/
案1: タスクごとに Catch する
まず最初に思い付くのはタスクごとに Catch する案だと思う.例えば以下のように AWS Lambda 関数(特に意味はなく Yay! という名前にした✌)を順番に3回呼び出す場合にタスクごとに Catch を実装して,エラーハンドリング用の処理 CustomErrorHandler
を実行するイメージ👌
実行すると期待通りになる❗️タスクごとに異なるエラーハンドリングを実装できて自由度は高いけど,統一的なエラーハンドリングを前提にすると,すべてのタスクに Catch を実装する必要があって AWS Step Functions ワークフローの複雑さは課題になると思う.
案2: Parallel を使ってタスクをグループ化する
AWS Step Functions には複数のタスクをまとめてグループ化する直接的な機能はないけど,タスクを並列に実行するときに使う Parallel は,実はブランチ(レーン)は1以上で使えるという仕様になっている👌
よって Parallel で片側にタスクをまとめると「グループ化」のように実装できるという Tips がある💡
実行すると期待通りになる❗️グループ化のために Parallel を使うのはちょっと裏技感があるけど,統一的なエラーハンドリングで十分な場合は AWS Step Functions ワークフローがシンプルになって良いと思う.
案3: AWS Step Functions ワークフローをネストする
AWS Step Functions の「サービス統合」を使うと AWS Step Functions ワークフローをネストして,別の AWS Step Functions ワークフローを呼び出せる.
複数のタスクを AWS Step Functions ワークフロー(子ワークフロー)にまとめて「グループ化」のようにして,子ワークフローを呼び出す AWS Step Functions ワークフロー(親ワークフロー)ではエラーハンドリングを実装する👌
実行すると期待通りになる❗️エラーハンドリングのために管理する AWS Step Functions ワークフローが増えてしまうのはデメリットだけど,AWS Step Functions ワークフロー全体がさらに複雑化する予定があったりするなら拡張しやすいと思う.
案4: その他
エラーハンドリングを AWS Step Functions ワークフローから独立させて実現する案を2つ考えてみた📝
Amazon EventBridge を使う
Amazon EventBridge で Step Functions Execution Status Change
の ABORTED
/ TIMED_OUT
/ FAILED
をトリガーして AWS Lambda 関数などのエラーハンドリングを実行できる💡
{ "source": [ "aws.states" ], "detail-type": [ "Step Functions Execution Status Change" ], "detail": { "status": [ "ABORTED", "TIMED_OUT", "FAILED" ], "stateMachineArn": [ "arn:aws:states:ap-northeast-1:000000000000:stateMachine:xxxxx" ] } }
Amazon CloudWatch Alarm を使う
AWS Step Functions ワークフローのメトリクス ExecutionsAborted
/ ExecutionsTimedOut
/ ExecutionsFailed
を Amazon CloudWatch Alarm でトリガーして Amazon SNS トピック経由で AWS Lambda 関数などのエラーハンドリングを実行できる💡
ちなみに最近では AWS Lambda 関数を直接実行することもできる👌
まとめ
適材適所に考えよう〜 \( 'ω')/