Dev Study
AWSサービスの内部原理 コース

87. 実行は追記されるイベントログである — 出来事の記録が『途中から再開』を可能にする

Step Functions の Standard 実行が「クラッシュしても続きから」を実現できる理由を、実行の内部で積み上がる出来事のログを図で追っていきます。

① 上書きせず、出来事を積む

実行が進むステップを一歩進む
追記の結果
状態の上書き「現在=ステップ3」を上書き保存
✗ やらないこと
出来事の追記遷移を1行ずつ記録
✓ やること
積み上がるログ開始→状態Aに入った→タスク予約→成功→状態Bに入った→…
以降も追記されつづける
  • 公式は Standard ワークフローについて「Execution state internally persists between state transitions(実行状態は状態遷移のたびに内部で永続化される)」と明記
  • 現在値を上書きするのではなく、遷移という出来事を記録していく設計

Standard 実行は「今どこにいるか」という状態値を保存するのではなく、「何が起きたか」という出来事を時系列に追記していく。これは DynamoDB 編で見た追記ログ(WAL)・可観測性編で見た追記専用ストリームと同じ「上書きせず追記する」原理を、今度はワークフローの実行そのものに適用したもの。

② イベントログの正体 — Events テーブルと GetExecutionHistory

イベントログ内部に積まれた1本の実体
どちらも同じログを映す
コンソールEvents テーブル
1ページ最大25件・総イベント数を表示
APIGetExecutionHistory
list of events を返す
イベント一覧ExecutionStarted → TaskStateEntered → TaskScheduled → TaskSucceeded → …
失敗したイベントは赤で色分け
  • Events テーブルは「the complete history for the selected execution as a list of events(選択した実行の完全な履歴をイベントのリストとして)」表示。1ページ最大25件
  • GetExecutionHistory API も「the history of the specified execution as a list of events」を返す
  • 失敗したイベントは赤で色分け表示される

コンソールの Events テーブルと GetExecutionHistory API は、別々の機能ではなく「内部に積まれた同じ追記ログ」を映す2つの窓口。だから人間が UI で追える履歴と、プログラムが API で取れる履歴は完全に一致する。ログが実体で、表示はその投影にすぎない。

③ ログには上限と寿命がある

1本の実行の履歴
上限に達すると / 90日を過ぎると
長さの上限最大 25,000 イベント
保持期間完了後 90日間
実行が失敗1実行に詰めすぎない設計が必要
次々レッスンの伏線: Map分散モードで子実行に逃がす
履歴は削除30日へ短縮する申請も可能
コンプライアンス目的
  • 「maximum event history count of 25,000 events」。この上限に達すると実行は失敗する(サービスクォータのページに「If the execution history reaches this quota, the execution will fail」と明記。ハードクォータで引き上げ不可)
  • Standard の実行履歴は「executions completed in the last 90 days」で利用可能(GetExecutionHistory も完了後90日まで)
  • 保持期間は AWS Support Center へのクォータ申請で30日へ短縮できる

追記ログである以上、無限には伸ばせない。1実行あたり最大25,000イベントという長さの上限と、完了後90日という寿命がある。この25,000という数字は、後の Map 分散(Distributed Map)モードが「なぜ子実行に分けるのか」を理解する伏線になる。

④ redrive — ログを畳み込んで『続きから』を復元する

元の実行ステップ1成功 → 2成功 → 3で失敗
完了(失敗)として記録
読みながら判定
ログを再生頭から読む(=畳み込み/replay)
同じ入力・同じ定義・同じARNで
ステップ1成功済み ✓ 再実行しない
ステップ2成功済み ✓ 再実行しない
ステップ3失敗 ✗ ここから再開
再実行ステップ3を予約しなおして続行
  • redrive は「didn't complete successfully in the last 14 days(failed / aborted / timed out)」の Standard 実行を対象。14日の起点は実行が完了した日
  • 「continues the failed execution from the unsuccessful step and uses the same input」
  • 「preserves the results and execution history of the successful steps, which are not rerun」。同じ state machine 定義・同じ実行ARNを使う

redrive の「続きから」は、チェックポイントという特別な魔法ではない。「頭から積まれたログを読めば、どこまで終わっていて次に何をすべきかが正確にわかる」という、追記ログ+再生(replay)の当然の帰結。成功済みステップをそもそも再実行しないので、メッセージング編で悩んだ冪等性の問題を「二度実行しない」ことで回避している。

⑤ redrive はログに追記される — だから条件も細部も決まる

元の実行の履歴event 1 … event N
成功済みステップの記録はここに残る
再実行される各ステップの細部
同じ履歴に追記… + ExecutionRedriven + 以降の再実行イベント
条件: 元の履歴が 24,999 イベント未満
リトライ回数0 にリセット
Parallel失敗/中止したブランチだけ再駆動
インラインMap失敗/中止した反復だけ再駆動
  • 「Redriven executions append their event history to the existing event history」
  • 条件は「execution event history count is less than 24,999」(ExecutionRedriven 履歴イベントと最低1件を収める余地のため)。ほかに、実行開始が2023年11月15日以降であること・最大オープン時間1年を超えていないことも条件
  • 再実行する Task / Parallel / インライン Map のリトライ試行回数は「reset to 0」
  • Parallel は「reschedules and redrives only those branches that failed or aborted」、インライン Map は「only those iterations that failed or aborted」を再駆動(例外: States.DataLimitExceeded で失敗した場合は成功済みブランチ/反復も含めて再実行される)

redrive が新しい実行を作らず既存の履歴に「追記」するからこそ、上限は25,000ではなく24,999未満になり、失敗した部分だけをピンポイントで再駆動できる。細かい仕様に見えるルールの一つ一つが、「実行はイベントの追記ログである」という一点から導かれている。

⑥ まとめ — 「続きから」は古典的な設計の帰結

上書きしない保存されるのは「現在の状態」ではない
この一点からの帰結
出来事を追記イベントが積まれつづける
だから
全履歴が見えるEvents テーブル・API
壊れても残る途中で壊れてもログは消えない
畳み込んで復元どこまで/次に何を が正確にわかる(=redrive)
続きから再開追記ログ+再生という古典的な設計の帰結

耐久実行(durable execution)の正体は、状態を賢く覚えておく特別な仕組みではなく、「上書きせず出来事を追記し、必要なとき頭から再生する」というイベントソーシングそのもの。DynamoDB の WAL、可観測性の追記ストリームと地続きの原理が、今度はワークフローの実行そのものを守っている。

公式ドキュメントで詳しく ↗