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

ほとんどの耐久性のある実行システムは、履歴を再生することによって復旧します。ワーカーが失敗した後、新しいワーカーは履歴をロードし、現在の位置を再構築するまでプログラムを再実行します。これは有用なモデルです。エフェメラルなワーカーを許可しながら、耐久性のある進捗を提供します。しかし、それはまた、累積された履歴を復旧パスの一部とします。このトレードオフは、数時間または数日実行されるプログラム、多くのツールを呼び出すプログラム、外部イベントを待つプログラム、子実行を作成するプログラム、動的に方向を変えるプログラムでは、より顕著になります。長期間実行されるエージェントは、ますますこの形状を帯びています。 私は、履歴から再構築するのではなく、プログラムの継続状態をチェックポイント化するという、異なる復旧プリミティブを構築し、評価しました。 透過的継続チェックポインティング このアプローチを透過的継続チェックポインティング、またはTCCと呼びます。耐久性のある境界で、コンパイラとランタイムはライブ継続状態（プログラムが現在の位置から続行するために必要な制御状態）をキャプチャします。障害後に実行が再開されると、ランタイムはコミットされた継続状態をロードし、プログラムを直接復元します。 履歴再生はTCCの再開を再構築します 履歴再生は現在の位置を再構築します。TCCはコミットされた継続状態を復元し、再開します。 違いは次のとおりです。 履歴再生 履歴をロード → プレフィックスを再実行 → 現在の位置を再構築 TCC コミットされた継続状態をロード → ライブ実行状態を復元 → 再開 外部効果は明示的な耐久性のある操作のままです。完了した耐久性のある作業は、復旧後に繰り返されず、サポートされていない言語構造は、曖昧な実行時動作を生成するのではなく、コンパイル中に失敗します。現在のプロトタイプは、耐久性のある効果、外部待機とイベント、子実行、キャンセル、構造化された並行処理、およびクラッシュからの回復をサポートしています。 何が変わるか TCCは復旧を定数時間にはしません。復旧は、ライブ継続状態のサイズと構造に影響を受け続けます。意図された変更は、復旧が何に依存するかという点です。再生では、復旧は現在の位置を再構築するために保持された実行履歴に影響されます。TCCでは、復旧はプログラムがまだ必要とする状態に主に影響されます。1万回の操作を実行したが、小さなライブ継続状態を保持しているプログラムは、その過去が長いという理由だけで、復旧が難しくなるべきではありません。 予備評価 ライブ継続状態を約固定したまま、耐久性のある境界の深さを10から1,000に増やした制御された比較を実行しました。 TCC復旧 時間的再構築 制御された評価 〜4 KBのライブ状態 その評価では、TCCの復旧は、約0.6ミリ秒から0.9ミリ秒の間にとどまりました。評価されたTemporalベースラインでの新規ワーカーによる再生再構築は、約61ミリ秒から1.7秒に増加しました。ワーカーの作成は除外され、ライブ状態は約4 KBであり、これらの結果は一般的な本番速度向上と解釈されるべきではありません。それらはテストされた条件下での復旧スケーリングの違いを示していますが、すべてのTCCワークロードがすべての再生ベースのシステムを上回るわけではありません。 方法論と制限 また、50,000の生成されたケース全体で実行セマンティクスを実行しましたが、評価されたサブセットではセマンティックな失敗は観察されませんでした。 依然として困難なこと プロトタイプを本番インフラストラクチャに変えるには、まだかなりの作業が必要です。 ポータブルな継続状態表現 プログラムとチェックポイントのバージョン管理 より大きなライブ状態の効率的な処理 耐久性のあるストレージとコミットプロトコル 運用上のオブザーバビリティ 言語フロントエンド間の互換性 フレームワーク統合 長期間の正確性と障害テスト チェックポイントの保持、以前の継続状態からの分岐、ランタイムバージョンの移行、および実行表現のどの程度が言語間で安定しているべきかに関する設計上の問題もあります。 私はこのモデルを中心にTrigoraを構築しており、当初は長期間実行されるAIエージェント向けです。より広範な疑問は、継続状態ベースの復旧が、動的で長寿命のソフトウェアに対してより良い実行基盤を提供できるかどうかということです。アーキテクチャ、セマンティクス、ベンチマーク設定、および現在の制限については、技術論文でより詳細に説明されています。現在のTCCコンパイラ/ランタイムの制御されたデモンストレーションで継続復旧が実際に動作している様子も確認できます。ワークフローエンジン、コンパイラ、チェックポイントシステム、または分散ランタイムで作業した経験のある方からの批判に特に興味があります。