88. StandardとExpressは帳簿の付け方が違う — exactly-onceは毎遷移の永続化の対価である
Step Functionsの2つのワークフロータイプの違いを、「実行状態を毎回の状態遷移ごとに永続化するか、しないか」というたった1つの設計判断から図で追っていきます。
① 分かれ道はひとつ — 実行状態を遷移のたびに帳簿に書くか
- 公式の言い回し(Standard):「Execution state internally persists between state transitions.」
- 公式の言い回し(Express):「Execution state doesn't persist between state transitions.」
- タイプは作成後に変更できない(immutable):「The workflow type can not be updated after you create a state machine.」
StandardとExpressの全ての違いは、ここから派生します。Standardは1状態を終えるたびにその実行状態を内部に永続化し、Expressは永続化しません。この1点の設計判断が、以下で見る保証・寿命・履歴・課金のすべてを決めます。そして一度選ぶと後から変えられません。
② 永続化が実行セマンティクスを決める — exactly-once / at-least-once / at-most-once
- Standard:「Standard Workflows follow an exactly-once model, where your tasks and states are never run more than once, unless you have specified Retry behavior in ASL.」
- 非同期Express:「At-least-once workflow execution.」「an execution could potentially run more than once.」
- 同期Express:「At-most-once workflow execution.」「Step Functions waits once an execution starts and returns the state machine's result on completion. Workflows don't restart if an exception occurs.」
メッセージング編で見た配信保証の4軸マップ(SQS標準キューのat-least-once、FIFOのexactly-once処理)と同じ語彙が、ここではワークフロー全体の実行保証として再登場します。強い保証(exactly-once)は「毎遷移で帳簿を付ける」という記録コストを払って初めて買えるもので、記録を省いたExpressでは保証がat-least-once(非同期)/at-most-once(同期)まで弱まります。
③ 永続化された帳簿は、同名実行の冪等応答も支える
- Standard:「Automatically returns an idempotent response on starting an execution with the same name as a currently-running workflow. The new workflow doesn't start and an exception is thrown once the currently-running workflow is complete.」
- Express:「Idempotency is not automatically managed. Starting multiple workflows with the same name results in concurrent executions. Can result in loss of internal workflow state if state machine logic is not idempotent.」
「どの実行名が今走っているか」を帳簿が知っているからこそ、Standardは同名の二重開始を自動で弾けます。永続化された記録は、状態の再実行を防ぐだけでなく、実行開始そのものの冪等性まで無償で提供します。Expressにはこの帳簿がないので、同じ名前でも二重に走ります。
④ だから向く仕事が分かれる — 非冪等な編成 vs 冪等な大量処理
- Standard:「The exactly-once model makes Standard Workflows suited to orchestrating non-idempotent actions, such as starting an Amazon EMR cluster or processing payments.」
- Express:「The at-least-once model makes Express Workflows better suited for orchestrating idempotent actions, such as transforming input data to store in Amazon DynamoDB using a PUT action.」「high-volume, event-processing workloads such as IoT data ingestion, streaming data processing and transformation.」
決済やEMRクラスタ起動は「2回やると二重課金・二重起動になる」非冪等なアクションなので、2回走らないことを保証するStandardに任せます。DynamoDBへのPUTは同じ値を何度書いても結果が同じ冪等なアクションなので、重複を許すExpressで速く大量にさばけます。保証の強さは、アクションが冪等かどうかで選ぶのです。
⑤ 帳簿の重さが天秤になる — 寿命・履歴・課金・機能のすべてに波及
- 最長時間:「Maximum duration | One year | Five minutes」
- 履歴保持:「You can retrieve the full execution history using the Step Functions API for up to 90 days after your execution completes.」「Execution history data removed after 90 days.」(コンプライアンス要件がある場合はクォータ申請で保持期間を30日に短縮可能、と公式に明記)/ Express「Execution history is not captured by Step Functions. Logging must be enabled through Amazon CloudWatch Logs.」
- 課金:「Standard Workflow executions are billed according to the number of state transitions processed.」/「Express Workflow executions are billed by number of executions, total duration of execution, and memory consumed during execution.」
- レート(welcome側の記述):「2,000 per second execution rate / 4,000 per second state transition rate」(Standard)、「100,000 per second execution rate / Nearly unlimited state transition rate」(Express)。なお choosing-workflow-type 側の比較表は数値を載せず Service Quotas ページ参照に置き換わっている(Expressの遷移レートのみ「No limit」と明記)。厳密な数値はリージョン・アカウントで変動するため、公式の Service Quotas を参照
- 機能:「Express Workflows do not support Job-run (.sync) or Callback (.waitForTaskToken) service integration patterns.」「Distributed Map … Express: Not supported」「Activities … Express: Not supported」
毎遷移で帳簿を付けるStandardは、その記録処理があるぶん遅く・高頻度なイベントには弱いですが、最長1年走れて、履歴を90日Step Functions自身が保持し、確実で監査できます。帳簿を省くExpressは、実行開始レートが桁違い(2,000/秒 対 100,000/秒)で速く大量にさばけますが、寿命は5分、履歴は自前でCloudWatch Logsに出す必要があり、.syncや分散Mapといった「途中で待つ・状態を持ち回る」機能は使えません。どちらが優れているかではなく、帳簿というコストを払うか否かの一貫したトレードオフです。
⑥ 縦の接続 — 「強い保証は記録のコストで買う」という一貫した原理
- 本編で見た背骨: exactly-onceを支えているのは、Standardが状態遷移のたびに永続化する実行状態(帳簿)である。「Execution state internally persists between state transitions.」がその根拠
DynamoDB編の「強い整合性は同期レプリケーションの対価」、メッセージング編の「FIFOのexactly-once処理」、そして本編の「Standardのexactly-onceは毎遷移の永続化の対価」は、すべて同じ原理の別の顔です。強い保証はタダでは手に入らず、必ずどこかで記録=永続化のコストを払っています。この縦の接続を押さえると、新しいサービスに出会っても「この保証は何を記録して買っているのか」を自分で読めるようになります。