履歴再生なしの耐久性のある実行

履歴再生なしの耐久性のある実行

ほとんどの耐久性のある実行システムは、保持された実行履歴を再生することによって復旧します。ワーカーが失敗した後、新しいワーカーは履歴をロードし、現在の位置を再構築するまでプログラムを再実行します。

これは有用なモデルです。エフェメラルなワーカーを維持しながら、耐久性のある進捗を提供します。しかし、それはまた、累積された履歴を復旧パスの一部とします。

このトレードオフは、数時間または数日実行されるプログラム、多くのツールを呼び出すプログラム、外部イベントを待つプログラム、子実行を作成するプログラム、動的に方向を変えるプログラムでは、より顕著になります。長時間実行されるエージェントは、ますますこの形状になっています。

私は、履歴から再構築するのではなく、プログラムの継続をチェックポイント化するという、異なる復旧プリミティブを構築し、評価しました。

透明な継続チェックポイント

私はこのアプローチをTransparent Continuation Checkpointing、またはTCCと呼んでいます。

耐久性のある境界で、コンパイラとランタイムはライブの継続（プログラムが現在の位置から続行するために必要な制御状態）をキャプチャします。障害後に実行が再開されると、ランタイムはコミットされた継続をロードし、プログラムを直接復元します。

履歴再生は現在の位置を再構築します。TCCはコミットされた継続を復元して再開します。

その違いは次のとおりです。

履歴再生

保持された履歴をロード → プレフィックスを再実行 → 現在の位置を再構築

TCC

コミットされた継続をロード → ライブ実行状態を復元 → 再開

外部効果は、引き続き明示的な耐久性のある操作です。完了した耐久性のある作業は、復旧後に繰り返されることはなく、サポートされていない言語構造は、曖昧な実行時動作を生成するのではなく、コンパイル中に失敗します。

その研究プロトタイプは、耐久性のある効果、外部待機とイベント、子実行、キャンセル、構造化された並行処理、およびクラッシュリカバリをサポートしました。ポータブルエンジンは現在、宣言されたTypeScript、Python、およびRustのサブセットに対して同じモデルを実装しています。

変更点

TCCは復旧時間を定数時間にするものではありません。復旧は、ライブの継続のサイズと構造に影響を受け続けます。

意図された変更は、復旧が何に依存するかという点です。

再生では、復旧は現在の位置を再構築するために保持された実行履歴に影響されます。TCCでは、復旧は主にプログラムがまだ必要とする状態に影響されます。

1万回の操作を実行したが、小さなライブの継続を保持しているプログラムは、その過去が長いという理由だけで、復旧が必然的に困難になるべきではありません。

事前評価

私は、ライブの継続状態がほぼ固定されたままで、耐久性のある境界の深さが10から1,000に増加した、制御された比較（今日出荷されているポータブルTCCエンジンではなく、研究プロトタイプ）を実行しました。

[画像: Recovery latency vs prior durable-boundary depth 1ms 10ms 100ms 1s 10 100 1000 durable-boundary depth]

TCC recovery Temporal reconstruction Controlled evaluation · ~4 KB live state

そのプロトタイプ評価では、TCCの復旧は約0.6ミリ秒から0.9ミリ秒の間で推移しました。評価されたTemporalベースラインでの新規ワーカーによる再生再構築は、約61ミリ秒から1.7秒に増加しました。

ワーカーの作成は除外され、ライブ状態は約4KBであり、これらの結果は一般的な本番環境でのスピードアップの主張として解釈されるべきではありません。それらは、テストされた条件下での復旧スケーリングの違いを示しているのであって、すべてのTCCワークロードがすべての再生ベースのシステムを上回ることを示しているのではありません。

Methodology and limitations

また、50,000件の生成されたケースで実行セマンティクスを行使しましたが、評価されたサブセットではセマンティックな失敗は観察されませんでした。

残る困難

ポータブルエンジンは現在、ローカル実行のためのネイティブSQLiteホストを含む、バージョン管理されたアーティファクトに対してそれらのサブセットを実行しています。本番インフラストラクチャには、依然としてかなりの作業が必要です。

• 本番クラウドパフォーマンス
• 分散運用
• 言語仕様がまだ拒否する構造
• より大きなライブ状態の効率的な処理
• 運用上の可観測性と強化
• フレームワーク統合
• 長期にわたる正確性と障害テスト

また、チェックポイントの保持、以前の継続からの分岐、ランタイムバージョンの間の移行、および実行表現のどの程度が言語間で安定しているべきかといった設計上の問題もあります。

私はこのモデルを中心にTrigoraを構築しており、当初は長期間実行されるAIエージェント向けです。より広範な疑問は、継続ベースの復旧が動的で長寿命のソフトウェアに対して、より良い実行基盤を提供できるかどうかです。

アーキテクチャ、セマンティクス、ベンチマーク設定、および現在の制限については、technical paperでより詳細に説明されています。現在のTCCコンパイラ/ランタイムの制御されたデモンストレーションで、continuation recovery in actionを見ることもできます。

ワークフローエンジン、コンパイラ、チェックポイントシステム、または分散ランタイムで作業した経験のある方々からの批判に特に興味があります。

長期間実行されるエージェントを構築していますか？実際のワークロードでTCCをテストするための3〜5社のデザインパートナーを探しています。