はじめに
もうだいぶ時間が経ってしまってますが、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とステータスの不一致が発生する。
任意のポイントから再実行できない等軽微な課題はありますが、途中からの再実行が出来るようになったので、長時間駆動が想定されるワークフロー処理も利用しやすくなったと思われます。
ワークフロー処理構成をご検討される際は、参考にして頂けると幸いです。
※ 本ブログに記載した内容は個人の見解であり、所属する会社、組織とは全く関係ありません。