# Durable Execution ## 定義 Durable Execution(耐久実行)とは、複数のサービス呼び出しにまたがる一連の処理(ワークフロー、各ステップはタスクまたはアクティビティと呼ばれる)を、途中の失敗を挟んでも exactly-once(正確に一度)に近いセマンティクスで完遂させるための実行モデルである。サービス指向アーキテクチャでは、決済処理(不正検知 → クレジットカード引き落とし → 銀行口座入金)のように複数サービスをまたぐ操作を単一のデータベーストランザクションで包めない上、サードパーティの決済ゲートウェイのように制御が及ばない外部サービスとも連携する必要があるため、この種のトランザクション性を提供する仕組みとして [[Temporal]]・Restate のような Durable Execution フレームワークが用いられる。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 5 Encoding and Evolution]] "Durable Execution and Workflows") ## 実現方式: RPC・状態変化のログとリプレイ Durable Execution フレームワークは、ワークフロー実行中に発生する全ての RPC 呼び出しと状態変化を、write-ahead log のような耐久ストレージへ記録する。タスクが失敗すると、フレームワークはそのタスクを再実行するが、失敗前に既に成功していた RPC 呼び出しや状態変化は実際には再実行せず、ログに記録された結果を返す「振り(pretend)」をする。これにより外部から見て各操作が一度だけ実行されたかのように振る舞う。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 5 Encoding and Evolution]] "Durable Execution and Workflows") ## 制約: べき等性と決定的実行 この仕組みは2つの前提を要求する。第一に、外部サービス自体はべき等な API を提供する必要があり、開発者は一意な ID を使って重複実行を防がなければならない(→ [[べき等性]])。第二に、フレームワークはログを記録順にそのまま再生することを前提とするため、コードは決定的(同じ入力から同じ順序で同じ呼び出しをする)でなければならない。乱数生成やシステム時刻の参照のような非決定的コードは問題になり、フレームワークは決定的な代替実装や静的解析ツールを提供する。稼働中のワークフローのコードをその場で書き換える(呼び出し順序の変更等)のは未定義動作を招くリスクがあるため、新バージョンは既存コードとは別デプロイとして追加し、実行中のインスタンスは旧バージョンのまま完走させるのが安全とされる。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 5 Encoding and Evolution]] "Durable Execution and Workflows") ## ワークフローエンジンの構成と周辺製品 ワークフローエンジンは一般に、タスクのスケジューリングを担う**オーケストレータ**と、実際にタスクを実行する**エグゼキュータ**から構成される。実行のトリガーは時刻ベースのスケジュール・外部のウェブサービス・人手のいずれもありうる。用途によって設計思想が異なるワークフローエンジンが複数存在する: Airflow・Dagster・Prefect はデータシステムと統合し ETL タスクをオーケストレーションする、Camunda・Orkes は BPMN のようなグラフィカル記法を非エンジニアにも提供する、Temporal・Restate は本頁で扱う Durable Execution を提供する。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 5 Encoding and Evolution]] "Durable Execution and Workflows") ## 横断的知見 (1ソース目。今後 DDIA 2E の他章や他ソースとの突き合わせで蓄積する。) ## 未解決の問い - [[サーバーレスワークフロー]](CNCF の Function Workflow パターン: 単純トリガー・ファンアウト・連鎖等)と Durable Execution の状態機械は、どちらもオーケストレータ+エグゼキュータ構成を取るが、決定的リプレイという Durable Execution 固有の制約はサーバーレス FaaS のワークフロー定義にも当てはまるか。 - [[ワークフロー自動化]] が扱う SRE/AIOps 領域の TSG 自動化・Runbook 実行エンジンは、Durable Execution のような exactly-once セマンティクスを必要とするか、それとも at-least-once + べき等性で十分か。 - Temporal の Workflow Check のような非決定性の静的解析は、どこまで一般のプログラミング言語の副作用検出手法(純粋関数境界の型検査等)に一般化できるか。 ## 関連 - ソース: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 5 Encoding and Evolution]] - エンティティ: [[Temporal]] - 概念: [[べき等性]] / [[ワークフロー自動化]] / [[サーバーレスワークフロー]] ## 出典 - [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 5 Encoding and Evolution]]("Durable Execution and Workflows")