【AWS】Step Functions redriveってどんな感じ？

## はじめに
もうだいぶ時間が経ってしまってますが、2023年11月頃にStep Functionsにredrive機能がリリースされました。
Step Functionsは、途中でエラーが起こってもエラーが起こった場所からリトライが出来ませんでした。そのため、長時間駆動が想定されるワークフロー処理には使い辛く、「Amazon Managed Workflows for Apache Airflow」の利用等検討していたと思います。
[Amazon Managed Workflows for Apache Airflow](https://docs.aws.amazon.com/ja_jp/mwaa/latest/userguide/what-is-mwaa.html)

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

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

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

## リリースされた際に気になった点
redrive機能がリリースされた際に個人的に気になった点は以下3点です。
- redriveってそもそもどんな感じになるの？
- Parallel(並列実行)を組んでいる時、片方正常、片方異常の時、redriveはどう動く？
- ネスト化したState Machineで子State Machineが異常の時、redriveはどう動く？

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

## redriveってそもそもどんな感じになるの？
以下シンプルなState Machineを構成し、使ってみました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3635217/725cce6f-e61e-f792-a267-01fb22870631.png)

異常Lambdaは必ずエラーを起こすようにようになっているので、実行してみます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3635217/0f20edec-a8eb-8c24-d6d7-ea2bf1878b02.png)

想定通りエラーとなりましたので、以下の「Recover」からredriveします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3635217/18cf74c2-9793-a460-f4ed-c063c9349752.png)

ここで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を構成し、使ってみました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3635217/8e171df0-14cd-87e6-dab0-c1b349e11e75.png)
※結果を見やすくするために「異常Lambda」の前にWaitを入れています。

実行してエラーを起こしてみます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3635217/6d25dcf4-1408-6f17-ddee-f31f93aa9358.png)

Parallel自体にエラーがついています。
なので、「Redrive from failure」を実行した場合、成功した「正常Lambda2」も再実行される気がしますが、どうでしょう？
確認のため、「Redrive from failure」からredriveしてみます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3635217/84086c2c-92b5-1e79-37ad-90ece36dac60.png)
イベント履歴を確認する限り「異常Lambda」のみ再実行されています。
つまり、Parallel自体にエラーが出ても成功しているStepは再実行されないことが分かります。

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

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

### キャンセルステータスもredive対象？
以下のように「正常Lambda2」の前に「Wait」を置いて、「異常Lambda」の方が早く結果が出るようにしています。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3635217/df4b9521-2004-8cd3-a162-267f1088eb75.png)

実行してエラーを起こしてみます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3635217/83af276c-ea16-1a0e-b6c4-d42d2913c74a.png)

想定通り、「Wait」がキャンセルされています。
redriveし、キャンセルもredrive対象か確認します。
※確認のため、一時的に「異常Lambda」を直し、エラーが出ないようにしています。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3635217/9d809bf3-7039-86d3-c300-d5d21adb0dfa.png)
キャンセルされていた「Wait」以降も実行されているので、キャンセルもredriveの対象であることが分かります。

## ネストされたState Machineで子State Machineが異常の時、redriveはどう動く？
以下のようにState Machineをばらしてネストさせてみます。
**親State Machine**
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3635217/6d41814e-81e2-24ff-bd3b-3eb69f5578c9.png)

**子State Machine　正常Lambda**
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3635217/9773848d-41e3-62dc-2d81-d9a8407d284e.png)

**子State Machine　異常Lambda**
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3635217/e36a51cb-248b-33df-0da2-25ee183b6887.png)

実行してエラーを起こしてみます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3635217/a9e4683c-d153-ed2b-6820-10242cb4a1fc.png)

「異常を起こしたstep」からredriveしてみます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3635217/492982fe-9a64-15ba-6bc3-8c1bbee499a9.png)

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

ここで、新たに以下疑問が出てきました。
- 子State Machine側でredriveしたら親State Machine側のステータスはどうなる？
上記では、ちゃんと親State Machineからredirveしましたが、子State Machineから直接出来るのでしょうか？
また、子State MachineからredriveをかけるとCloudFormationのネステッドスタックと同様に親側のステータスとの不一致が発生するのでしょうか？
[CloudForamitionネステッドスタック](https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/using-cfn-nested-stacks.html)

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

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

子State Machine側を見るとredrive出来るようになっていました。
なので、redriveしてみます。
※確認のため、一時的に「異常Lambda」を直し、エラーが出ないようにしています。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3635217/edfd1830-39a8-82e0-54a9-e4abfb9acbd4.png)

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

親State Machine側を確認してみます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3635217/dbc8a95b-2c23-7cfd-a4cb-acc53129a5e5.png)
こちらは変化なく、失敗のままでした。
試しにこの状態でredriveしてみます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3635217/ffaa701b-66a6-0276-f968-5ac01943c2df.png)

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

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

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

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

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