Zenn
💭

Step Functionsのエラー処理・通知、リトライを考える

2024/11/03に公開
AWS
Step Functions
tech

ステートのリトライ

リトライを設定できるステートはTask、Parallel、Mapステートです。これらはRetryフィールドを持つことができます。

RetryのErrorEqualsフィールドには、States.ALLなどの公式ドキュメント記載の「エラー名」のほか、Lambda.ClientExecutionTimeoutExceptionやZeroDivisionErrorといった値も指定することができます。

とりあえずエラーを全部拾う場合はStates.ALLを使用します。

参考：

Lambda関数呼び出しのリトライのベストプラクティス

リトライによって解決する可能性の高い、Lambdaの一時的なエラーに対してリトライを設定するようにします。

マネジメントコンソールでLambda: Invokeステートを作成すると、自動的に以下のデフォルト設定が入るようになっています。

"Retry": [
  {
    "ErrorEquals": [
      "Lambda.ServiceException",
      "Lambda.AWSLambdaException",
      "Lambda.SdkClientException",
      "Lambda.TooManyRequestsException"
    ],
    "IntervalSeconds": 1,
    "MaxAttempts": 3,
    "BackoffRate": 2
  }
]

参考：一時的な Lambda サービスの例外を処理する

ステートのエラー処理

Task、Parallel、Mapステートではエラーをキャッチして別のステートに遷移させることができます。設定はCatchフィールドで行います。

リトライ設定がある場合は、すべてのリトライに失敗した後でキャッチが実行されます。

CatchのErrorEqualsフィールドの考え方はRetryと同じです。

参考：Fallback 状態

Parallel/Mapステートのエラー処理

ParallelやMapステートで、一部のブランチ/イテレーションが失敗してもすべての処理を完了させたい場合には、内部でエラーをキャッチする必要があります。

参考：Parallel task error handling in Step Functions - DEV Community

ただし、その場合はステートマシン全体が成功で完了するため、エラーがあったことに気づけないおそれがあります。その対策として、内部のエラーキャッチ後に通知の仕組みを入れておくか、ParallelやMapステートが終わった後でエラーを検知してステートマシンを失敗させるような処理を入れておく必要があります。

参考：Parallel/Map内でエラー処理するけどマシン全体は失敗させる

ステートマシンのエラー通知

ステートマシン全体のエラー通知をざっくりやるには、主に以下のパターンが考えられます。

  1. CloudWatchメトリクス→CloudWatchアラーム→SNSトピック
  2. EventBridge→User Notifications

CloudWatchメトリクスを使用する場合は、AWS/States名前空間のExecutionsFailedとExecutionsTimedOutメトリクスを拾ってアラームを発報します。

参考：Amazon CloudWatch を使用した Step Functions メトリクスのモニタリング

EventBridgeを使用する場合は、Step Functions Execution Status Changeイベントタイプで、FAILEDとTIMED_OUTステータスを拾って通知します。User Notificationsの通知が実行履歴に辿りやすくて良い感じです。

参考：

明示的なタイムアウト設定を検討する

ステートマシン全体および各ステートで、必要に応じてタイムアウト時間の設定を検討します。例えば、いくら長くても終わっているはずの時間があるならば、想定外の問題を発見できるようにタイムアウト時間を設定しておくと良いと思います。ステートマシン（標準ワークフロー）のデフォルトのタイムアウトは1年、Taskステートは1,000日超であるため、最悪の場合実行がスタックしたまま長期間気づかない可能性があります。

最大実行時間
1 年
Step Functions サービスクォータ

TimeoutSeconds (オプション)
... デフォルト値は 99999999 です。
タスクワークフローの状態

参考：タイムアウトを使用して Step Functions ワークフロー実行が停止しないようにする

クォータを考慮する

何かが大きかったり多かったりする場合は、クォータを考慮しましょう。例えば、ペイロードサイズは256kB、実行あたりの履歴は25,000件です。

参考：

Discussion