ジョブネットをStep Functionsで組み直す — 先行後続・リラン・エラー処理の翻訳

ジョブスケジューラの移行（前記事）で「書き換える」を選んだ場合の各論です。ジョブネットの制御構造はStep Functionsのステートマシンにきれいに翻訳できます。ただし、オンプレ運用の生命線だった「途中からのリラン」を殺さない設計が必要です。

01制御構造の対応表

• 直列実行（A→B→C） → ステートの連鎖
• 並列実行と合流 → Parallelステート
• 条件分岐（正常時／異常時で後続を変える） → Choiceステート
• リトライ（3回まで・間隔を空けて） → ステート組み込みのRetry定義。スケジューラ側で作り込んでいたリトライ制御が、宣言1行になるのは書き換えの分かりやすい利点です

02リラン設計：ステートの分割粒度が生命線

オンプレ運用の「ジョブ3から流し直し」に相当するのは、ステートマシンの再実行です。ここで重要なのが分割粒度で、複数の処理を1つのLambdaに詰め込むと、その途中からは再開できません。「オンプレで1ジョブだったものは1ステートに」が原則です。加えて各処理をべき等（同じ入力で再実行しても壊れない）にしておくと、「最初から流し直す」という選択肢も安全になり、リラン運用が大幅に単純化します。

03重い処理は15分の壁の外へ

Lambdaの実行上限は15分です。数時間級の集計・変換は、Step FunctionsからECSタスク（RunTask）またはAWS Batchを呼び出す形にします。制御はStep Functions、実行はコンテナという分担にすると、既存のシェルやJavaバッチをコンテナに包んだだけでジョブネットに組み込めます。書き換え範囲を制御層だけに絞れるのがこの構成の妙です。

04運用者への引き継ぎが最大の山

Step Functionsの実行履歴はグラフィカルに表示され、どのステートで失敗したかが一目で分かります——オンプレ運用者が慣れ親しんだ「ジョブ流れ図で赤くなっている箇所を見る」体験に意外なほど近い。とはいえ操作体系は別物なので、異常時対応手順書（どの画面で・何を確認し・どう再実行するか）を移行成果物に含めることが定着の条件です。

05定義はコードで管理する

ステートマシン定義（ASL）はCloudFormation／Terraformで管理し、変更はレビューを通す——ここまでやって書き換えの価値が完成します。ジョブ定義の変更履歴が残らない問題は、オンプレ時代からの宿痾でした。IaC化はそれを根治します（変更統制の仕組みと相性のいい領域です）。