ECサイトの注文処理ワークフローをAWS Step Functionsで構築しています。`ProcessPayment` ステートはLambda関数を呼び出しており、一時的な決済ゲートウェイの障害時に `PaymentFailedException` をスローすることがあります。開発チームは以下の3つの動作を実装したいと考えています。 ① `PaymentFailedException` 発生時は最大3回、指数バックオフでリトライする ② すべてのリトライが失敗した場合は `CompensateOrder` ステートに遷移する ③ その他の予期しないエラーは `NotifyError` ステートに遷移する これら3つの要件をすべて満たすステートマシンの設定はどれですか？
Step Functions では Retry と Catch を組み合わせてエラーハンドリングを細かく制御できます。Retry は Catch より先に評価され、MaxAttempts を超えた場合にのみ Catch に処理が移ります。 Retry に ErrorEquals: ["PaymentFailedException"] を指定することで、支払いエラーのみを対象にリトライし要件①を満たします。Catch は配列の先頭から順番に評価されるため、より具体的な ["PaymentFailedException"] → CompensateOrder を先頭に定義し、その後に ["States.ALL"] → NotifyError を定義することで、リトライ上限後の補償処理と予期しないエラーの通知処理を正しく振り分けられます。 選択肢Bの Retry 設定は、ErrorEquals に ["States.ALL"] を使用するため、PaymentFailedException 以外のエラー（入力バリデーションエラーなど）も最大3回リトライされてしまい、要件①を満たしません。 選択肢Cの Catch 設定は、RetryCount というパラメータは Step Functions に存在せず、リトライ機能は Retry フィールドでのみ実現できます。Catch だけではリトライを制御できません。 選択肢Dの Catch 設定は、["States.ALL"] が先頭にあるため、PaymentFailedException がリトライ上限に達した場合も States.ALL に捕捉されて NotifyError に遷移し、CompensateOrder には到達できません。