AWS Step Functions で再実行(リドライブ)ができるようになったので、前回のシンプル編と集中と分散編にに引き続き、ジョブネットが親子構造(ネスト構造)を持っていると想定したときのエラー対応の挙動を試してみます。
想定するジョブネット
今回はジョブネットが親子構造を持っていると想定して実験します。今回は子ジョブ2が異常終了したときの挙動を確認します。
検証の結論
最初に検証の結論です。今回の実装では少し癖のあるリドライブ挙動となったので、運用に注意が必要ですね。
- 子ジョブ2が異常終了した時には、(1)親ステートマシンをリドライブする方法と、(2)子ステートマシンをリドライブする方法の2通りが考えられる
- (1)親ステートマシンをリドライブした場合、単純に子ステートマシンは全体が再実行される。これにより、子ステートマシン側のジョブはエラー状態にかかわらず、子ジョブ1から3のすべてが実行される。その後、親ステートマシンの残りのジョブ3が実行されて処理完了となる。
- (2)子ステートマシンをリドライブした場合、異常終了した子ジョブ2と子ジョブ3が実行されるが、親ステートマシンは異常終了状態のまま変わらない。つまり、親側のジョブ3は再実行されない。
実装の概要
前回と同じくaws-samples の amazon-stepfunctions-ssm-waitfortasktoken を利用した SfnRunCommandByInstanceIds を用いて、Steps Functions に以下のようなステートマシンを定義しました。
親ステートマシン
{
"Comment": "This is a test state machine by yki",
"StartAt": "StartAutomationWaitForCallBack (Parent Job 1)",
"States": {
"StartAutomationWaitForCallBack (Parent Job 1)": {
"Type": "Task",
"Resource": "arn:aws:states:::aws-sdk:ssm:startAutomationExecution.waitForTaskToken",
"Parameters": {
"DocumentName": "SfnRunCommandByInstanceIds",
"Parameters": {
"InstanceIds": [
"i-xxxxxxxxxxxxxxxxx"
],
"taskToken.$": "States.Array($$.Task.Token)",
"workingDirectory": [
"/home/ec2-user/sample-batch/"
],
"Commands": [
"./do-some1.sh"
]
}
},
"Next": "Step Functions StartExecution"
},
"Step Functions StartExecution": {
"Type": "Task",
"Resource": "arn:aws:states:::states:startExecution.sync:2",
"Parameters": {
"StateMachineArn": "arn:aws:states:us-east-1:0000000000:stateMachine:MyChildStateMachine-fdk35erfa",
"Input": {
"StatePayload": "Hello from Step Functions!",
"AWS_STEP_FUNCTIONS_STARTED_BY_EXECUTION_ID.$": "$$.Execution.Id"
}
},
"Next": "StartAutomationWaitForCallBack (Parent ob 3)"
},
"StartAutomationWaitForCallBack (Parent ob 3)": {
"Type": "Task",
"Resource": "arn:aws:states:::aws-sdk:ssm:startAutomationExecution.waitForTaskToken",
"Parameters": {
"DocumentName": "SfnRunCommandByInstanceIds",
"Parameters": {
"InstanceIds": [
"i-xxxxxxxxxxxxxxxxx"
],
"taskToken.$": "States.Array($$.Task.Token)",
"workingDirectory": [
"/home/ec2-user/sample-batch/"
],
"Commands": [
"./do-some3.sh"
]
}
},
"End": true
}
}
}
子ステートマシン
{
"Comment": "This is a test state machine by yki",
"StartAt": "StartAutomationWaitForCallBack (Child Job 1)",
"States": {
"StartAutomationWaitForCallBack (Child Job 1)": {
"Type": "Task",
"Resource": "arn:aws:states:::aws-sdk:ssm:startAutomationExecution.waitForTaskToken",
"Parameters": {
"DocumentName": "SfnRunCommandByInstanceIds",
"Parameters": {
"InstanceIds": [
"i-xxxxxxxxxxxxxxxxx"
],
"taskToken.$": "States.Array($$.Task.Token)",
"workingDirectory": [
"/home/ec2-user/sample-batch/"
],
"Commands": [
"./do-some1.sh"
]
}
},
"Next": "StartAutomationWaitForCallBack (Child Job 2)"
},
"StartAutomationWaitForCallBack (Child Job 2)": {
"Type": "Task",
"Resource": "arn:aws:states:::aws-sdk:ssm:startAutomationExecution.waitForTaskToken",
"Parameters": {
"DocumentName": "SfnRunCommandByInstanceIds",
"Parameters": {
"InstanceIds": [
"i-xxxxxxxxxxxxxxxxx"
],
"taskToken.$": "States.Array($$.Task.Token)",
"workingDirectory": [
"/home/ec2-user/sample-batch/"
],
"Commands": [
"./do-some2.sh"
]
}
},
"Next": "StartAutomationWaitForCallBack (Child Job 3)"
},
"StartAutomationWaitForCallBack (Child Job 3)": {
"Type": "Task",
"Resource": "arn:aws:states:::aws-sdk:ssm:startAutomationExecution.waitForTaskToken",
"Parameters": {
"DocumentName": "SfnRunCommandByInstanceIds",
"Parameters": {
"InstanceIds": [
"i-xxxxxxxxxxxxxxxxx"
],
"taskToken.$": "States.Array($$.Task.Token)",
"workingDirectory": [
"/home/ec2-user/sample-batch/"
],
"Commands": [
"./do-some3.sh"
]
}
},
"End": true
}
}
}
なお、子ステートマシンを同期して実行するために権限設定が必要のため以下を参照しました。
エラーなく実行できることも確認済です。
親側のステートマシン
子側のステートマシン
子ジョブ2の異常終了と再実行
異常終了が発生するように touch /home/ec2-user/sample-batch/filetest2
を行ってからステートマシンの実行を行います。
想定通り子ジョブ2が異常終了となりました。
親側のステートマシン
子側のステートマシン
親側のステートマシンをリドライブするのか、子側のステートマシンをリドライブするのかで挙動が変わりそうですね。両方とも実験してみましょう。
ケース1:親側のステートマシンからリドライブ
まずは親側のステートマシンからリドライブしてみます。子ステートマシン全体が再実行されそうですね。
親側からリドライブをすると、予想通り子ステートマシンについては新たに全体が実行されることになりました。先ほど失敗した実行はそのまま失敗として残っています。
親側のイベント
親側のイベントは以下の通り、リドライブがなされていることが確認できます。
子側のイベント
子側のイベントは以下の通りで、初回の異常終了が起こった実行はそのままで、新たにステートマシンが実行されています。
初回の実行
リドライブによる実行
ケース2: 子側のステートマシンからリドライブ
次に改めて異常終了を発生させて、子側のステートマシンでリドライブを行ってみます。異常終了したジョブから再実行がされそうですね。親側のステートマシンがどうなるか気になります。
リカバリを行った後、子側からリドライブをすると当然なが子側のステートマシンは子ジョブ2と子ジョブ3が実行されて、すべて正常終了となりました。
子側のステートマシンがすべて正常実行完了後に、元々の親側のステートマシンを見に行くと、異常終了で止まったままでした。これは困りますね。もしここで親側でリドライブすると、また子側のステートマシンが再実行されてしまうので子側のステートマシンをリドライブするのは避けた方が良さそうです。
ということで今回は親子構造を持ったジョブネットを想定して、AWS Step Functions の再実行を試してみました。