AWS Step Functionsのリトライとキャッチの仕組みと設定方法

はじめに

AWS Step Functionsは、分散アプリケーションのワークフローを簡単に調整できるサービスです。しかし、実際の業務システムではタスクの失敗や一時的な障害は避けられません。そのため、堅牢なエラーハンドリングが非常に重要になります。

本記事では、Step Functionsのリトライとキャッチのメカニズムについて詳しく解説し、プロダクション環境での効果的な設定方法と実装例を紹介します。

これらの機能を活用することで、システムの信頼性と可用性を向上させ、運用負荷を軽減することが可能になります。

リトライ・キャッチのメリットとデメリット

メリット

自動リカバリー: 一時的な障害から自動的に回復し、システムの安定性が向上します。
柔軟なエラー処理: 様々なエラー種別に応じて異なる対応が可能です。
可視性の向上: エラーとその処理過程が明確に可視化され、デバッグが容易になります。
カスタマイズ性: リトライ間隔やバックオフ戦略など、詳細な調整が可能です。
運用負荷の軽減: 自動エラー処理により、手動介入の必要が減少します。

デメリット

設定の複雑さ: 適切なリトライ・キャッチの設定には経験と理解が求められます。
実行時間の増加: 過度なリトライはワークフロー全体の完了時間を延長させる可能性があります。
コストへの影響: 実行回数が増えると、それに伴いコストが増加します。
デバッグの難しさ: エラー処理フローが複雑になるとトラブルシューティングが難しくなる場合があります。
状態管理の課題: 多段階のエラー処理では状態遷移の把握が難しくなることがあります。

Step Functionsのリトライメカニズム

Step Functionsでは、タスクが失敗した際に自動的に再試行を行うリトライ機能が用意されています。

リトライ設定の例

{
  "States": {
    "ProcessOrder": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:region:account-id:function:process-order",
      "Retry": [
        {
          "ErrorEquals": ["States.Timeout", "States.TaskFailed"],
          "IntervalSeconds": 3,
          "MaxAttempts": 3,
          "BackoffRate": 2.0
        }
      ],
      "End": true
    }
  }
}

主要なリトライパラメータ

Step Functionsでは、タスクの失敗時に再試行（リトライ）を行う際、以下のパラメータで細かく挙動を制御できます。

ErrorEquals
リトライ対象とするエラータイプを指定します。
例えば ["States.Timeout", "States.TaskFailed"] と設定すれば、それらのエラーが発生した場合にリトライを行います。
States.ALL を指定すれば、すべてのエラーがリトライ対象になります。
IntervalSeconds
リトライ間隔を秒単位で指定します。
たとえば 3 を設定すると、最初のリトライは3秒後に実行されます。
MaxAttempts
最大リトライ回数を指定します。
デフォルトは3回ですが、例えば 5 に設定すると最大5回までリトライされます。
無限ループを避けるため、適切な回数を設定することが重要です。
BackoffRate
リトライ間隔の増加率を指定します。
2.0 に設定した場合、リトライ間隔がリトライごとに倍々に伸びます。
例えば、IntervalSeconds: 3、BackoffRate: 2.0 なら、
1回目は3秒後 → 2回目は6秒後 → 3回目は12秒後… という形で間隔が長くなります。
これにより、一時的な負荷や障害からの回復を待つことができます。

主なビルトインエラータイプ

Step Functionsでは、あらかじめ定義された標準的なエラータイプを使用できます。それぞれ、どのような状況で発生するかを以下に説明します。

States.ALL
すべてのエラーを捕捉します。特定のエラーを指定せず、発生したどのエラーにも適用したい場合に使用します。
States.Timeout
タスクが設定されたタイムアウト時間（例: TimeoutSeconds）内に完了しなかった場合に発生します。
例えば、Lambda関数や外部APIへの呼び出しが制限時間を超えて応答しなかったときにこのエラーになります。
States.TaskFailed
タスク自体が失敗した場合に発生します。
具体的には、タスク内のLambda関数がエラーを返したり、Failステートを返却した場合などにこのエラーが発生します。
States.Permissions
IAMロールの権限不足により、リソースへのアクセスが拒否された場合に発生します。
例えば、Lambda関数を実行しようとしたが、必要な実行権限が付与されていない場合にこのエラーになります。
States.ResultPathMatchFailure
タスクの出力結果を、指定した ResultPath に適用しようとした際に、構造が合わず適用できなかった場合に発生します。
たとえば、出力データに存在しないフィールドを ResultPath で指定した場合などにこのエラーが返されます。

Step Functionsのキャッチメカニズム

リトライが最大回数に達した場合や、リトライ対象外のエラーが発生した場合は、Catchを利用して代替フローに遷移できます。

キャッチ設定の例

{
  "States": {
    "ProcessPayment": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:region:account-id:function:process-payment",
      "Catch": [
        {
          "ErrorEquals": ["PaymentError"],
          "ResultPath": "$.error",
          "Next": "HandlePaymentError"
        },
        {
          "ErrorEquals": ["States.ALL"],
          "ResultPath": "$.error",
          "Next": "DefaultErrorHandler"
        }
      ],
      "Next": "CompleteOrder"
    }
  }
}

主要なキャッチパラメータ

ErrorEquals: 捕捉するエラータイプを指定します。Lambdaで throw したエラー名もそのまま使用できます。
ResultPath: エラー情報の格納場所を指定します（例: $.error）。
Next: エラー発生時の遷移先ステートを指定します。

具体的な実装シナリオ

外部APIリクエストのリトライ

{
  "States": {
    "CallExternalAPI": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:region:account-id:function:call-external-api",
      "Retry": [
        {
          "ErrorEquals": ["ServiceUnavailable", "TooManyRequestsException"],
          "IntervalSeconds": 2,
          "MaxAttempts": 5,
          "BackoffRate": 2.0
        }
      ],
      "Catch": [
        {
          "ErrorEquals": ["States.ALL"],
          "ResultPath": "$.errorInfo",
          "Next": "HandleAPIFailure"
        }
      ],
      "Next": "ProcessAPIResponse"
    }
  }
}

段階的なフォールバック処理

{
  "States": {
    "TryPrimaryService": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:region:account-id:function:primary-service",
      "Retry": [
        {
          "ErrorEquals": ["ServiceError"],
          "IntervalSeconds": 1,
          "MaxAttempts": 2
        }
      ],
      "Catch": [
        {
          "ErrorEquals": ["States.ALL"],
          "ResultPath": "$.primaryError",
          "Next": "TrySecondaryService"
        }
      ],
      "Next": "SuccessState"
    }
  }
}

Lambda関数のエラー処理とリトライ

Lambda関数の設定例

exports.handler = async (event) => {
  try {
    if (event.input.amount <= 0) {
      throw new Error('InvalidAmountError');
    }
    if (!event.input.paymentMethod) {
      throw new Error('MissingPaymentMethodError');
    }
    return {
      status: 'success',
      transactionId: 'txn_' + Math.random().toString(36).substring(2, 15)
    };
  } catch (error) {
    throw new Error(error.message);
  }
};

Step Functions側の設定例

{
  "States": {
    "ProcessPayment": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:region:account-id:function:process-payment",
      "Retry": [
        {
          "ErrorEquals": ["PaymentProcessingError"],
          "IntervalSeconds": 1,
          "MaxAttempts": 3
        }
      ],
      "Catch": [
        {
          "ErrorEquals": ["InvalidAmountError"],
          "ResultPath": "$.errorDetails",
          "Next": "HandleInvalidAmount"
        }
      ],
      "Next": "CompleteOrder"
    }
  }
}

エラーハンドリングのベストプラクティス

リトライはべき等性を確保
リトライ実行により、同じ処理が複数回行われても問題ないよう設計します。
バックオフ戦略を適切に設定
リトライ間隔は指数バックオフを活用し、負荷集中を防ぎます。
リトライとキャッチを組み合わせる
一時的なエラーにはリトライ、致命的なエラーにはキャッチを活用します。
エラータイプを具体化
可能な限り具体的なエラータイプを定義し、個別に最適な対応を行います。
リトライ回数に上限を設ける
無限リトライ防止のため、MaxAttemptsを必ず設定します。
エラー情報を保持する
ResultPathでエラー内容を保存し、後続処理で活用します。
エラー通知の導入
SNS等を利用し、重大エラーは即座に運用チームへ通知します。

まとめ

AWS Step Functionsのリトライとキャッチ機能は、堅牢なワークフローを構築するための鍵となります。正しく設定することで、一時的障害からの復旧、段階的なフォールバック、適切な通知が実現可能です。

ぜひ本記事の具体例とベストプラクティスを参考に、プロダクション環境に適したエラーハンドリングを導入し、システム全体の信頼性向上に役立ててください。

参考

備考

Hakky ではエンジニアを募集中です！まずは話してみたいなどでも構いませんので、ぜひお気軽に採用ページからお問い合わせくださいませ。