はじめに

もうだいぶ時間が経ってしまってますが、2023年11月頃にStep Functionsにredrive機能がリリースされました。
Step Functionsは、途中でエラーが起こってもエラーが起こった場所からリトライが出来ませんでした。そのため、長時間駆動が想定されるワークフロー処理には使い辛く、「Amazon Managed Workflows for Apache Airflow」の利用等検討していたと思います。
Amazon Managed Workflows for Apache Airflow

この課題に対して途中からリトライできるredrive機能がリリースされました。

このredrive機能に関していくつか気になる点があったので、とりあえず使ってみて整理してみましたので、ご紹介させて頂きます。

※ 本ブログに記載した内容は個人の見解であり、所属する会社、組織とは全く関係ありません。

リリースされた際に気になった点

redrive機能がリリースされた際に個人的に気になった点は以下3点です。

redriveってそもそもどんな感じになるの？
Parallel(並列実行)を組んでいる時、片方正常、片方異常の時、redriveはどう動く？
ネスト化したState Machineで子State Machineが異常の時、redriveはどう動く？

上記3点にフォーカスしてそれぞれ確認してみましたので、ご紹介させて頂きます。

redriveってそもそもどんな感じになるの？

以下シンプルなState Machineを構成し、使ってみました。

異常Lambdaは必ずエラーを起こすようにようになっているので、実行してみます。

想定通りエラーとなりましたので、以下の「Recover」からredriveします。

ここで1点気になったことがあります。redrive出来るのは、「Redrive from failure(異常を起こしたStepからRedrive)」もしくは、「Start new ececution(State Machineを再実行)」となり、任意の所からredriveすることは出来ません。
仮に「正常Lambda2」の出力に問題があり、「異常Lambda」がエラーとなった、「正常Lambda2」を修正し、「全体」でredriveをかける必要があります。
※「Redrive from failure」を実施すると「正常Lambda2」が再実行されないため、出力が変わりません。

以上が、redriveの基本的な動きになります。

Parallel(並列実行)を組んでいる時、片方正常、片方異常の時、redriveはどう動く？

Parallelステート(並列実行)時はどうなるのかです。
以下のState Machineを構成し、使ってみました。

※結果を見やすくするために「異常Lambda」の前にWaitを入れています。

実行してエラーを起こしてみます。

Parallel自体にエラーがついています。
なので、「Redrive from failure」を実行した場合、成功した「正常Lambda2」も再実行される気がしますが、どうでしょう？
確認のため、「Redrive from failure」からredriveしてみます。

イベント履歴を確認する限り「異常Lambda」のみ再実行されています。
つまり、Parallel自体にエラーが出ても成功しているStepは再実行されないことが分かります。

ここで、新たに以下疑問が出てきました。

キャンセルステータスもredrive対象？
Parallelの中で、「正常Lambda2」より、「異常Lambda」の方が先に結果が出る場合は、「正常Lambda2」はキャンセルされると思いますが、キャンセルもredriveの対象になるのか？

ということで、確認してみました。

キャンセルステータスもredive対象？

以下のように「正常Lambda2」の前に「Wait」を置いて、「異常Lambda」の方が早く結果が出るようにしています。

実行してエラーを起こしてみます。

想定通り、「Wait」がキャンセルされています。
redriveし、キャンセルもredrive対象か確認します。
※確認のため、一時的に「異常Lambda」を直し、エラーが出ないようにしています。

キャンセルされていた「Wait」以降も実行されているので、キャンセルもredriveの対象であることが分かります。

ネストされたState Machineで子State Machineが異常の時、redriveはどう動く？

以下のようにState Machineをばらしてネストさせてみます。
親State Machine

子State Machine　正常Lambda

子State Machine　異常Lambda

実行してエラーを起こしてみます。

「異常を起こしたstep」からredriveしてみます。

異常を起こした子State Machineのみ再実行されていました。
つまり、ネスト化された子State Machineもredriveの対象ということが分かります。

ここで、新たに以下疑問が出てきました。

子State Machine側でredriveしたら親State Machine側のステータスはどうなる？
上記では、ちゃんと親State Machineからredirveしましたが、子State Machineから直接出来るのでしょうか？
また、子State MachineからredriveをかけるとCloudFormationのネステッドスタックと同様に親側のステータスとの不一致が発生するのでしょうか？
CloudForamitionネステッドスタック

ということで、確認してみましたので、ご紹介させて頂きます。

子State Machine側でredriveしたら親State Machine側のステータスはどうなる？

子State Machine側を見るとredrive出来るようになっていました。
なので、redriveしてみます。
※確認のため、一時的に「異常Lambda」を直し、エラーが出ないようにしています。

redriveが成功したことが確認出来ます。

親State Machine側を確認してみます。

こちらは変化なく、失敗のままでした。
試しにこの状態でredriveしてみます。

問題なく再実行され成功しました。
つまり、ステータス管理のためには、Step FunctionsもCloudFormationと同様にネストされている場合は、親から実行していく形式を取らないとステータスがおかしくなってしまうことが分かります。

まとめ

確認出来たStep Functions redrive機能のポイントを以下にまとめます。

redriveはエラーが出力されたポイントから再実行、もしくは全体State Machine全体で再実行
エラーが出力されたもののみが対象となる。
Parallelを組んでいる状態でredriveをかけても成功した処理はSkipされる
キャンセルステータスもredriveの対象となる
ネストされたState Machineを組んでいる場合、redriveは親State Machineから実行する必要がある
エラーが発生した子State Machineからredriveを実行することも出来るが、親State Machineとステータスの不一致が発生する。

任意のポイントから再実行できない等軽微な課題はありますが、途中からの再実行が出来るようになったので、長時間駆動が想定されるワークフロー処理も利用しやすくなったと思われます。

ワークフロー処理構成をご検討される際は、参考にして頂けると幸いです。

※ 本ブログに記載した内容は個人の見解であり、所属する会社、組織とは全く関係ありません。