翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
Step Functions ワークフローでのエラー処理
Pass と Wait 状態を除くすべての状態でランタイムエラーが発生する可能性があります。エラーは、次のようなさまざまな理由で発生する可能性があります。
-
ステートマシン定義の問題 - 一致するルールのない選択状態など
-
タスクの失敗 - AWS Lambda 関数の例外など
-
一時的な問題 - ネットワークパーティションイベントなど
状態がエラーを報告すると、Step Functions はデフォルトでステートマシンの実行全体を失敗させます。Step Functions には、より高度なエラー処理機能もあります。エラーをキャッチし、失敗した状態を再試行し、エラー処理プロトコルを適切に実装するようにステートマシンを設定できます。
Step Functions キャッチャーは、タスク、並列、マップの各状態で使用できますが、最上位のステートマシンの実行失敗では利用できません。予想される実行を処理するには、発信者がエラーを処理するか、それらの実行を子ワークフロー内にネストして親ワークフロー内のエラーをキャッチします。または、EventBridge バスを使用して標準ワークフローからTIMED_OUTイベントをリッスンし、失敗した実行を処理するアクションを呼び出すこともできます。
エラー処理の実例
エラー処理を含むワークフローの例をデプロイするには、このガイドのStep Functions ステートマシンでのエラー条件の処理チュートリアルとワークショップのエラー処理
エラー名
Step Functions は、エラー名と呼ばれる大文字と小文字を区別する文字列を使用してエラーを識別します。Amazon States Language は、よく知られているエラー名を付ける一連の組み込み文字列を定義します。すべて States. プレフィックスが付いています。
状態は別の名前でエラーを報告することがあります。ただし、エラー名は States. プレフィックスで始めることはできません。
本番コードが AWS Lambda サービス例外 (Lambda.ServiceException および ) を処理できることを確認しますLambda.SdkClientException。詳細については、「 ベストプラクティスLambda サービスの一時的な例外の処理」の「方法」を参照してください。
-
States.ALL -
あらゆる既知のエラー名に一致するワイルドカード。
States.ALLエラータイプは 内で単独で表示される必要がありCatcher、States.DataLimitExceededターミナルエラーまたはRuntimeエラータイプをキャッチすることはできません。詳細については、「States.DataLimitExceeded」および「States.Runtime」を参照してください。
-
States.DataLimitExceeded -
エラータイプでは検出できないターミナル
States.ALLエラー。以下の条件により報告されます。
-
コネクタの出力がペイロードサイズのクォータを超えています。
-
状態の出力がペイロードサイズのクォータを超えています。
-
Parameters処理後、状態の入力はペイロードサイズのクォータよりも大きくなります。
クォータに関する詳細については、Step Functions のサービスクォータ を参照してください。
-
States.ExceedToleratedFailureThreshold失敗したアイテムの数がステートマシン定義で指定されたしきい値を超えたため、
Map状態が失敗しました。詳細については、「Step Functions での分散マップ状態の失敗しきい値の設定」を参照してください。-
States.HeartbeatTimeout -
HeartbeatSeconds値より長時間実行されたため ハートビートの送信に失敗したTask状態。HeartbeatTimeoutはCatchおよびRetryフィールド内で使用できます。 -
States.Http.Socket -
HTTP タスクが 60 秒後にタイムアウトしたときに発生します。「HTTP タスクに関連するクォータ」を参照してください。
States.ItemReaderFailedItemReaderフィールドに指定されたアイテムソースから読み取れなかったため、Map状態が失敗しました。詳細については、「ItemReader (Map)」を参照してください。-
States.Permissions -
指定されたコードの実行に必要な特権が足りないため
Task状態が失敗しました。 States.ResultWriterFailedResultWriterフィールドに指定された宛先に結果を書き込めなかったため、Map状態が失敗しました。詳細については、「ResultWriter (Map)」を参照してください。States.Runtime-
処理できない例外のため、実行に失敗しました。多くの場合、これらは実行時のエラー (null JSON ペイロードに
InputPathまたはOutputPathを適用しようとしたなど) によって発生します。States.Runtimeエラーは再試行可能ではなく、常に実行が失敗する原因になります。States.ALLでの再試行またはキャッチではStates.Runtimeエラーはキャッチされません。 -
States.TaskFailed -
実行中に失敗した
Task状態。リトライやキャッチで使用すると、States.TaskFailedは、States.Timeout以外のあらゆる既知のエラー名に一致するワイルドカードとして機能します。 -
States.Timeout -
Task状態がTimeoutSeconds値よりも長く実行された場合、またはHeartbeatSeconds値よりも長い期間ハートビートを送信できなかった場合にレポートされます。ネストされたステートマシンが をスローすると
States.Timeout、親はStates.TaskedFailedエラーを受け取ります。States.Timeoutエラーは、ステートマシンの実行全体が指定されたTimeoutSeconds値よりも長く実行された場合にも報告されます。
注記
Lambda ランタイムの未処理エラーは、履歴的に としてのみ報告されましたLambda.Unknown。新しいランタイムでは、タイムアウトはエラー出力Sandbox.Timedoutで として報告されます。
Lambda が呼び出しの最大数を超えると、報告されたエラーは になりますLambda.TooManyRequestsException。
Lambda.Unknown、、および で一致States.TaskFailedさせてSandbox.Timedout、考えられるエラーを処理します。を使用することもできますがStates.ALL、リストの最後に単独で存在する必要があります。
Lambda Handled と Unhandled エラーの詳細については、AWS Lambda デベロッパーガイドの FunctionError を参照してください。
エラー後の再試行
Task、Parallel、Map の状態は Retry という名前のフィールドを持つことができます。その値は Retrier と呼ばれるオブジェクトの配列にする必要があります。個々の Retrier は特定回数の再試行を表し、通常は時間間隔が増加していきます。
いずれかの状態がエラーを報告し、Retry フィールドがある場合、Step Functions は配列にリストされた順序で Retrier をスキャンします。Retrier の ErrorEquals フィールドの値にエラー名が表示されると、ステートマシンは Retry フィールドで定義されているとおりに再試行します。
再試行を定義した、Task ワークフロー状態、Parallel ワークフローの状態、または インラインマップステートを redriven で再実行すると、redrive での再試行回数が最大になるように、これらのステートの再試行回数は 0 にリセットされます。redriven 実行では、コンソールを使用してこれらのステートでの再試行を個別に追跡できます。詳細については、「Step Functions で redrive を使用してステートマシン実行を再開する」の 再処理された実行の再試行動作 を参照してください。
retrier には以下のフィールドがあります。
-
ErrorEquals(必須) -
エラー名に一致する空でない文字列の配列です。状態がエラーを報告すると、Step Functions は再試行全体をスキャンします。エラー名がこの配列に表示されている場合、この retrier に記述されている再試行ポリシーを実装します。
-
IntervalSeconds(オプション) -
最初の再試行前の秒数を表す整数 (デフォルトで
1)。IntervalSecondsには 99999999 の最大値があります。 -
MaxAttempts(オプション) -
再試行の最大回数を表す正の整数 (デフォルトでは
3)。エラーが指定された回数を超えて再発する場合は、再試行が停止され通常のエラー処理が再開されます。0の値は、エラーが再試行されないことを指定します。MaxAttemptsには 99999999 の最大値があります。 -
BackoffRate(オプション) -
各試行間の後に
IntervalSecondsで表される再試行間隔が増加する乗数。デフォルトでは、BackoffRate値は2.0ずつ増加します。例えば、
IntervalSecondsが 3、MaxAttemptsが 3、BackoffRateが 2 だとします。最初の再試行は、エラーが発生した 3 秒後に行われます。2 回目の再試行は、1 回目の再試行の 6 秒後に行われます。また、3 回目の再試行は 2 回目の再試行の 12 秒後に行われます。 -
MaxDelaySeconds(オプション) -
再試行間隔を延長できる最大値を秒単位で設定する正の整数。このフィールドは
BackoffRateフィールドと併用すると便利です。このフィールドで指定する値によって、連続する再試行ごとにバックオフ率の乗数が適用されることによる指数関数的な待機時間を制限できます。MaxDelaySecondsには 0 より大きく 31622401 より小さい値を指定する必要があります。この値を指定しない場合、Step Functions は再試行間の待機時間を制限しません。
-
JitterStrategy(オプション) -
連続する再試行間の待機時間にジッターを含めるかどうかを決定する文字列。ジッターは、ランダムな遅延間隔にわたって再試行回数を分散させて同時再試行回数を減らします。この文字列は、
FULLまたはNONEを値として受け入れます。デフォルト値はNONEです。例えば、
MaxAttemptsを 3、IntervalSecondsを 2、BackoffRateを 2 に設定したとします。最初の再試行は、エラーが発生した 2 秒後に行われます。2 回目の再試行は 1 回目の再試行の 4 秒後に行われ、3 回目の再試行は 2 回目の再試行の 8 秒後に行われます。JitterStrategyをFULLに設定した場合、1 回目の再試行間隔は 0~2 秒の間でランダム化され、2 回目の再試行間隔は 0~4 秒の間でランダム化され、3 回目の再試行間隔は 0~8 秒の間でランダム化されます。
注記
再試行は状態遷移として扱われます。状態遷移が課金に及ぼす影響については、Step Functions コスト
再試行フィールドの例
このセクションには、次の Retry フィールドの例が含まれます。
例 1 - BackoffRate を使用して再試行する
次の Retry の例では、2 回の再試行を行い、3 秒待ってから最初の再試行します。Step Functions は、指定した BackoffRate に基づいて、再試行の最大回数に達するまで各再試行の間隔を増やします。次の例では、1 回目の再試行から 3 秒待ってから 2 回目の再試行が開始されます。
"Retry": [ {
"ErrorEquals": [ "States.Timeout" ],
"IntervalSeconds": 3,
"MaxAttempts": 2,
"BackoffRate": 1
} ]
例 2 - MaxDelaySeconds を指定して再試行する
次の例では、再試行を 3 回行い、BackoffRate から生じる待機時間を 5 秒に制限しています。最初の再試行は 3 秒待ってから行われます。2 回目と 3 回目の再試行は、MaxDelaySeconds で設定されている最大待機時間制限により、前回の再試行から 5 秒間待ってから行われます。
"Retry": [ {
"ErrorEquals": [ "States.Timeout" ],
"IntervalSeconds": 3,
"MaxAttempts": 3,
"BackoffRate":2,
"MaxDelaySeconds": 5,
"JitterStrategy": "FULL"
} ]
MaxDelaySeconds を使用しない場合、2 回目の再試行は 1 回目の再試行の 6 秒後に行われ、3 回目の再試行は 2 回目の再試行の 12 秒後に行われます。
例 3 - States.Timeout を除くすべてのエラーを再試行する
retrier の ErrorEquals フィールドにあらかじめ表示される名前 States.ALL は、すべてのエラー名に一致するワイルドカードです。ErrorEquals 配列では単独で表示される必要があり、Retry 配列では最後の retrier に表示される必要があります。名前 States.TaskFailed もワイルドカードの役割を果たし、States.Timeout を除くあらゆるエラーに一致します。
Retry フィールドの例では、States.Timeout を除くすべてのエラーを再試行します。
"Retry": [ {
"ErrorEquals": [ "States.Timeout" ],
"MaxAttempts": 0
}, {
"ErrorEquals": [ "States.ALL" ]
} ]
例 4 - 複雑な再試行シナリオ
retrier のパラメータは、単一状態実行のコンテキストの retrier に対するすべてのアクセスに適用されます。
次の Task 状態の場合を考えてみます。
"X": {
"Type": "Task",
"Resource": "arn:aws:states:region:123456789012:task:X",
"Next": "Y",
"Retry": [ {
"ErrorEquals": [ "ErrorA", "ErrorB" ],
"IntervalSeconds": 1,
"BackoffRate": 2.0,
"MaxAttempts": 2
}, {
"ErrorEquals": [ "ErrorC" ],
"IntervalSeconds": 5
} ],
"Catch": [ {
"ErrorEquals": [ "States.ALL" ],
"Next": "Z"
} ]
}
このタスクは 4 回連続で失敗し、エラー名 ErrorA、ErrorB、ErrorC,ErrorB を出力します。結果として以下が発生します。
-
最初の 2 つのエラーが最初の retrier に一致し、1 秒および 2 秒の待機が発生します。
-
3 番目のエラーが 2 番目の retrier に一致し、5 秒の待機が発生します。
-
4 番目のエラーも最初の retrier に一致します。ただし、その特定のエラーに対する再試行の最大回数 2 回 (
MaxAttempts) に達しています。そのため、その retrier は失敗し、実行によってワークフローがCatchフィールドを通じてZ状態にリダイレクトされます。
フォールバック状態
Task、Map、Parallel 状態はそれぞれ Catch というフィールドを持つことができます。このフィールドの値は、catchers と言われるオブジェクトの配列である必要があります。
catcher には以下のフィールドがあります。
-
ErrorEquals(必須) -
同じ名前の retrier フィールドで指定されたエラー名と正確に一致する空ではない文字列。
-
Next(必須) -
ステートマシンの状態名のいずれかに正確に一致する必要がある文字列。
-
ResultPath(JSONPath、オプション) -
Nextフィールドに指定された状態に catcher が送信する入力を決定するパス。
状態がエラーを報告し、Retry フィールドがないか、再試行でエラーが解決できなかった場合、Step Functions は配列にリストされた順序で catcher をスキャンします。エラー名が catcher の ErrorEquals フィールドの値に表示される場合、ステートマシンは Next フィールドに名前がある状態に移行します。
catcher の ErrorEquals フィールドにあらかじめ表示される名前 States.ALL は、すべてのエラー名に一致するワイルドカードです。ErrorEquals 配列では単独で表示される必要があり、Catch 配列では最後の catcher に表示される必要があります。名前 States.TaskFailed もワイルドカードの役割を果たし、States.Timeout を除くあらゆるエラーに一致します。
Catch フィールドの次の例では、Lambda 関数が処理されない Java 例外を出力した場合に RecoveryState という名前の状態に移行します。それ以外の場合、フィールドは EndState 状態に移行します。
"Catch": [ {
"ErrorEquals": [ "java.lang.Exception" ],
"ResultPath": "$.error-info",
"Next": "RecoveryState"
}, {
"ErrorEquals": [ "States.ALL" ],
"Next": "EndState"
} ]
キャッチャーはいくつのエラーをキャッチできますか?
各キャッチャーは、処理する複数のエラーを指定できます。
エラー出力
Step Functions が catch 名に指定された状態に移行する場合、オブジェクトには通常 Cause というフィールドが含まれます。このフィールドの値は人間が読んで理解できるエラーの説明です。このオブジェクトはエラー出力といいます。
前の JSONPath の例では、最初のキャッチャーに ResultPathフィールドが含まれています。これは状態の最上位の ResultPath フィールドに似た動作を行い、次のいずれかの結果になります。
-
その状態の実行結果を取得し、状態の入力のすべてまたは一部を上書きします。
-
結果を取得し、入力に追加します。catcher によって処理されたエラーの場合、状態の実行の結果はエラー出力です。
したがって、この例の最初の catcher の場合、catcher がエラー出力が error-info という名前のフィールドとして入力に追加します (入力にこの名前のフィールドが存在しない場合)。次に、catcher は入力全体を RecoveryState に送信します。2 番目 catcher では、エラー出力によって入力が上書きされ、catcher はエラー出力のみを EndState に送信します。
JSONPath ワークフローでは、 ResultPathフィールドを指定しない場合、デフォルトで になり$、入力全体を選択して上書きします。
状態に Retry と Catch フィールドの両方がある場合、Step Functions は最初に適切な Retrier を使用します。リトライポリシーがエラーを解決できなかった場合、Step Functions は一致する catcher の移行を適用します。
ペイロードとサービス統合の原因
キャッチャーは、文字列ペイロードを出力として返します。Amazon Athena や などのサービス統合を使用する場合は AWS CodeBuild、Cause文字列を JSON に変換できます。組み込み関数を使用した Pass 状態の次の例は、Cause 文字列を JSON に変換する方法を示しています。
"Handle escaped JSON with JSONtoString": {
"Type": "Pass",
"Parameters": {
"Cause.$": "States.StringToJson($.Cause)"
},
"Next": "Pass State with Pass Processing"
},
再試行とキャッチを使用したステートマシンの例
次の例で定義されたステートマシンには、2 つの Lambda 関数があるとします。1 つは常に失敗し、1 つはステートマシンで定義されたタイムアウトが発生するのに十分な時間待機する許可をだします。
これは、常に失敗してメッセージ error を返す Node.js Lambda 関数の定義です。続くステートマシンの例では、この Lambda 関数の名前は FailFunction です。Lambda 関数の作成の詳細については、「ステップ 1: Lambda 関数を作成する」セクションを参照してください。
exports.handler = (event, context, callback) => {
callback("error");
};
これは、10 秒間スリープする Node.js Lambda 関数の定義です。続くステートマシンの例では、この Lambda 関数の名前は sleep10 です。
exports.handler = (event, context, callback) => {
setTimeout(function(){
}, 11000);
};
関数のタイムアウト設定
例の Lambda 関数を作成するときは、詳細設定のTimeout値を 11 秒に設定してください。
Retry を使用して失敗を処理する
このステートマシンは Retry フィールドを使用して、失敗してエラー名 HandledError を出力する関数を再試行します。この関数は 2 回再試行され、再試行間にはエクスポネンシャルパックオフが使用されます。
{
"Comment": "A Hello World example invoking Lambda function",
"StartAt": "HelloWorld",
"States": {
"HelloWorld": {
"Type": "Task",
"Resource": "arn:aws:lambda:region:123456789012:function:FailFunction",
"Retry": [ {
"ErrorEquals": ["HandledError"],
"IntervalSeconds": 1,
"MaxAttempts": 2,
"BackoffRate": 2.0
} ],
"End": true
}
}
}
このバリエーションでは、Lambda 関数が出力するあらゆるエラーに一致する事前定義されたエラーコード States.TaskFailed を使用します。
{
"Comment": "Hello World example which invokes a AWS Lambda function",
"StartAt": "HelloWorld",
"States": {
"HelloWorld": {
"Type": "Task",
"Resource": "arn:aws:lambda:region:123456789012:function:FailFunction",
"Retry": [ {
"ErrorEquals": ["States.TaskFailed"],
"IntervalSeconds": 1,
"MaxAttempts": 2,
"BackoffRate": 2.0
} ],
"End": true
}
}
}
Lambda 例外を処理するためのベストプラクティス
Lambda 関数を参照するタスクは、Lambda サービスの例外を処理する必要があります。詳細については、「 ベストプラクティスLambda サービスの一時的な例外の処理」の「」を参照してください。
Catch を使用して失敗を処理する
この例では、Catch フィールドを使用します。Lambda 関数がエラーを出力すると、そのエラーをキャッチし、ステートマシンは fallback 状態に移行します。
{
"Comment": "Hello World example which invokes a AWS Lambda function",
"StartAt": "HelloWorld",
"States": {
"HelloWorld": {
"Type": "Task",
"Resource": "arn:aws:lambda:region:123456789012:function:FailFunction",
"Catch": [ {
"ErrorEquals": ["HandledError"],
"Next": "fallback"
} ],
"End": true
},
"fallback": {
"Type": "Pass",
"Result": "Hello, AWS Step Functions!",
"End": true
}
}
}
このバリエーションでは、Lambda 関数が出力するあらゆるエラーに一致する事前定義されたエラーコード States.TaskFailed を使用します。
{
"Comment": "Hello World example which invokes a AWS Lambda function",
"StartAt": "HelloWorld",
"States": {
"HelloWorld": {
"Type": "Task",
"Resource": "arn:aws:lambda:region:123456789012:function:FailFunction",
"Catch": [ {
"ErrorEquals": ["States.TaskFailed"],
"Next": "fallback"
} ],
"End": true
},
"fallback": {
"Type": "Pass",
"Result": "Hello, AWS Step Functions!",
"End": true
}
}
}
Retry を使用してタイムアウトを処理する
このステートマシンは Retry フィールドを使用して、TimeoutSeconds で指定されたタイムアウト値に基づいてタイムアウトした Task 状態を再試行します。Step Functions は、この Task 状態で Lambda 関数の呼び出しを 2 回再試行し、再試行間にはエクスポネンシャルパックオフが使用されます。
{
"Comment": "Hello World example which invokes a AWS Lambda function",
"StartAt": "HelloWorld",
"States": {
"HelloWorld": {
"Type": "Task",
"Resource": "arn:aws:lambda:region:123456789012:function:sleep10",
"TimeoutSeconds": 2,
"Retry": [ {
"ErrorEquals": ["States.Timeout"],
"IntervalSeconds": 1,
"MaxAttempts": 2,
"BackoffRate": 2.0
} ],
"End": true
}
}
}
Catch を使用してタイムアウトを処理する
この例では、Catch フィールドを使用します。タイムアウトが発生すると、ステートマシンは fallback 状態に移行します。
{
"Comment": "Hello World example which invokes a AWS Lambda function",
"StartAt": "HelloWorld",
"States": {
"HelloWorld": {
"Type": "Task",
"Resource": "arn:aws:lambda:region:123456789012:function:sleep10",
"TimeoutSeconds": 2,
"Catch": [ {
"ErrorEquals": ["States.Timeout"],
"Next": "fallback"
} ],
"End": true
},
"fallback": {
"Type": "Pass",
"Result": "Hello, AWS Step Functions!",
"End": true
}
}
}
JSONPath での状態入力とエラーの保存
JSONPath では、 を使用して状態入力とエラーを保持できますResultPath。「ResultPath を使用してエラーと入力の両方を に含める Catch」を参照してください。