マップ実行の再処理

失敗した子ワークフローは、親ワークフローのマップ実行で redriving できます。redriven された親ワークフローは、分散マップを含むすべての失敗状態を redrives します。親ワークフローが実行を完了したときに、ステートの <stateType>Entered イベントに対応する <stateType>Exited イベントがない場合、親ワークフローは失敗した状態を再処理します。例えば、イベント履歴に MapStateEntered イベントの MapStateExited イベントが含まれていない場合は、親ワークフローを再処理して、マップ実行で失敗した子ワークフローの実行をすべて再処理できます。

ステートマシンに ItemReader、ResultWriter、またはその両方にアクセスするために必要な権限がない場合、マップ実行は開始されないか、最初の実行試行に失敗します。親ワークフローの最初の実行時にマップ実行が開始されなかった場合、親ワークフローを再処理すると初めてマップ実行が開始されます。これを解決するには、必要なアクセス許可をステートマシンロールに追加し、次に親ワークフローを再処理します。必要なアクセス許可を追加せずに親ワークフローを再処理すると、新しいマップ実行の実行を開始しようとしますが、再び失敗します。必要なアクセス許可については、「分散マップ状態を使用するための IAM ポリシー」を参照してください。

トピック

• マップ実行での子ワークフローの対象を再処理する
• 子ワークフローの実行再処理動作
• マップ実行再処理で使用される入力のシナリオ
• マップ実行を再処理する IAM アクセス許可
• コンソールでのマップ実行の再処理
• RedrivingAPI を使用したマップ実行の再処理

マップ実行での子ワークフローの対象を再処理する

次の条件が満たされる場合、マップ実行で失敗した子ワークフローの実行を再処理できます。

• 2023 年 11 月 15 日以降に親ワークフローの実行を開始しました。この日付より前に開始した実行は再処理の対象外です。

• 特定のマップ実行の再処理のハードリミットである 1000 件を超えていません。この制限を超えると、States.Runtime エラーが表示されます。

• 親ワークフローは再処理可能です。親ワークフローが再処理可能でない場合、マップ実行で子ワークフローを再処理することはできません。ワークフローの再処理の対象については、「失敗した実行の再処理対象」を参照してください。

• マップ実行でのタイプ Standard の子ワークフロー実行は、実行イベント履歴の上限である 25,000 件を超えていません。イベント履歴の制限を超えた子ワークフローの実行は、許容される失敗しきい値にカウントされ、失敗したと見なされます。実行の再処理の対象については、「失敗した実行の再処理対象」を参照してください。

次の場合、元の実行試行でマップ実行が失敗しても、新しいマップ実行が開始され、既存のマップ実行は再処理されません。

• States.DataLimitExceeded エラーにより、マップ実行が失敗しました。

• JSON データ補間エラー、States.Runtime のため、マップ実行が失敗しました。例えば、OutputPath で存在しない JSON ノードを選択したとします。

マップ実行は、親ワークフローが停止またはタイムアウトした後も引き続き実行できます。これらのシナリオでは、再処理はすぐには実行されません。

• マップ実行は、進行中のタイプ Standard の子ワークフロー実行をキャンセルしているか、タイプ Express の子ワークフロー実行が完了するのを待っている可能性があります。

• 結果をエクスポートするように設定した場合、マップ実行は結果をまだ ResultWriter に書き込んでいる可能性があります。

このような場合、実行中のマップ実行は、再処理を試行する前に操作を完了します。

子ワークフローの実行再処理動作

マップ実行での再処理された子ワークフローの実行は、次の表に示すような動作を示します。

エクスプレス子ワークフロー	標準子ワークフロー
元の実行試行で失敗またはタイムアウトになったすべての子ワークフロー実行は、StartExecutionAPI アクションを使用して開始されます。ItemProcessor で最初に実行されたステートが最初に実行されます。	元の実行試行で失敗、タイムアウト、またはキャンセルされたすべての子ワークフロー実行は、RedriveExecution API アクションを使用して再処理されます。これらの子ワークフローは、redriven ItemProcessor 実行に失敗した最後の状態からのものです。
失敗した実行はいつでも再処理できます。これは、Express の子ワークフロー実行は常に StartExecution API アクションを使用する新しい実行として開始されるためです。	失敗した標準子ワークフローの実行は、常に再処理できるわけではありません。実行が再処理可能でない場合、再試行されることはありません。実行の最後のエラーまたは出力は永続的です。これは、実行の履歴イベントが 25,000 件を超えるか、14 日間の再処理可能な期間が過ぎた場合に発生することがあります。 親ワークフローの実行が 14 日以内に終了し、子ワークフロー実行が 14 日より前に終了した場合、標準子ワークフローの実行は再処理できない可能性があります。
エクスプレス子ワークフローの実行では、元の実行試行と同じ実行 ARN が使用されますが、個々の再処理を明確に識別することはできません。	標準子ワークフロー実行では、元の実行試行と同じ実行 ARN が使用されます。コンソールや API (やなど GetExecutionHistory) を使用すれば、redrives個人を明確に識別できます。DescribeExecution詳細については、「再処理された実行内容を調べる」を参照してください。

マップ実行を再処理していて、同時実行数の制限に達した場合、そのマップ実行での子ワークフロー実行は保留ステートに移行します。マップ実行の実行ステータスも [保留中の redrive] ステートに移行します。指定した同時実行数の制限により子ワークフローの実行回数が増えるまで、実行は、[保留中の redrive] ステートのままになります。

例えば、ワークフロー内の分散マップの同時実行数の上限が 3000 件で、再実行される子ワークフローの数が 6000 件だとします。これにより、3000 件の子ワークフローが並行して実行され、残りの 3000 件のワークフローは [保留中のリドライブ] ステートのままになります。3000 件の子ワークフローの最初のバッチが実行を完了すると、残りの 3000 件の子ワークフローが実行されます。

マップ実行の実行が完了するか中止されると、[保留中の redrive] ステートの子ワークフロー実行数は 0 にリセットされます。

マップ実行再処理で使用される入力のシナリオ

最初の実行時に分散マップにどのように入力したかに応じて、再処理されたマップ実行では次の表に示すように入力を使用します。

最初の実行試行時の入力	マップ実行再処理で使用された入力
前のステートから渡された入力または実行入力。	再処理されたマップ実行は同じ入力を使用します。
入力は ItemReader を使用して渡され、次の条件のいずれかが true であるため、マップ実行は子ワークフローの実行を開始しませんでした。 マップ実行が States.ItemReaderFailed エラーで失敗しました。 マップ実行が States.ResultWriterFailed エラーで失敗しました。 マップ実行が開始される前に、親ワークフローの実行がタイムアウトになったか、キャンセルされました。	再処理されたマップ実行では Amazon S3 バケット内の入力を使用します。
ItemReader入力はを使用して渡されます。子ワークフローの実行を開始または開始しようとした後にマップ実行が失敗しました。	再処理されたマップ実行は、元の実行時と同じ入力を使用します。

マップ実行を再処理する IAM アクセス許可

Step Functions には、マップ実行を再処理するための適切なアクセス許可が必要です。次の IAM ポリシーの例では、マップ実行の再処理に必要な最小限の権限をステートマシンに付与しています。イタリック体のテキストを、リソース固有の情報に必ず置き換えてください。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "states:RedriveExecution"
      ],
      "Resource": "arn:aws:states:us-east-2:123456789012:execution:myStateMachine/myMapRunLabel:*"
    }
  ]
}

コンソールでのマップ実行の再処理

以下のイメージは、分散マップを含むステートマシンの実行グラフを示しています。マップ実行が失敗したため、この実行は失敗しました。マップ実行を再処理するには、親ワークフローを再処理する必要があります。

コンソールからマップ実行を再処理するには

1. Step Functions コンソールを開き、実行に失敗した分散マップを含む既存のステートマシンを選択します。

2. ステートマシンの詳細ページの [実行] で、このステートマシンの失敗した実行インスタンスを選択します。

3. [再処理] を選択します。

4. [再処理] ダイアログボックスで [リドライブの実行] を選択します。

   ヒント

   実行の詳細ページまたはマップ実行の詳細ページからマップ実行を再処理することもできます。

   実行の詳細ページを開いている場合は、次のいずれかを実行して実行を再処理します。

   • [復旧] を選択し、[障害からのリドライブ] を選択します。

   • [アクション]、[再処理] の順に選択します。

   マップ実行の詳細ページを開いている場合は、[復旧] を選択し、[障害からのリドライブ] を選択します。

   再処理は、同じステートマシン定義と ARN を使用していることに注意してください。最初の実行試行で失敗したステップから実行を継続します。この例では、[マップ] という名前の分散マップステップとその中の [入力を処理する] ステップです。失敗したマップ実行の子ワークフロー実行を再開した後も、再処理は、[完了] ステップの実行を継続します。

5. 実行の詳細ページから [マップ実行] を選択すると、再処理されたマップ実行の詳細が表示されます。

   このページでは、redriven 実行の結果を表示できます。例えば、[マップ実行] 実行の概要 セクションには、マップ実行が再処理された回数を表す [リドライブ回数] が表示されます。[イベント] セクションでは、元の実行試行のイベントに追加された再処理関連の実行イベントを確認できます。例えば、MapRunRedriven イベントです。

Map Run redriven を実行した後は、コンソールで、または DescribeExecutionAPI redrive アクションを使用して詳細を確認できます。GetExecutionHistoryredriven 実行の確認の詳細については、実行の詳細については、「再処理された実行内容を調べる」を参照してください。

RedrivingAPI を使用したマップ実行の再処理

親ワークフローの RedriveExecution API を使用して対象のマップ実行を再処理できます。この API は、マップ実行で失敗した子ワークフローの実行を再開します。

AWS Command Line Interface (AWS CLI) で、以下のコマンドを実行して、失敗したステートマシンの実行を再処理します。イタリック体のテキストを、リソース固有の情報に必ず置き換えてください。

aws stepfunctions redrive-execution --execution-arn arn:aws:states:us-east-2:123456789012:execution:myStateMachine:foo

Map Run redriven を実行した後は、コンソールまたは DescribeMapRunAPI redrive アクションを使用して詳細を確認できます。Map Run redrive での標準ワークフロー実行の詳細を調べるには、GetExecutionHistoryまたは DescribeExecutionAPI アクションを使用できます。redriven 実行の確認の詳細については、実行の詳細については、「再処理された実行内容を調べる」を参照してください。

親ワークフローでログ記録を有効にしている場合は、Step Functions コンソールのマップ実行でエクスプレスワークフロー実行の再処理の詳細を確認できます。詳細については、「CloudWatch Logs を使用したログ記録」を参照してください。