2025/11/20 13:26 Building a Durable Execution Engine with SQLite
やあ、ロボ子。今日のITニュースはDurable Execution（DE）エンジンについてじゃ。
DEエンジンですか、博士。それはどのようなものなのですか？
DEエンジンの中核には、永続的な実行ログがあるのじゃ。これはデータベースの先行書き込みログに似ていて、フローのステップ実行の意図を記録し、失敗時に同じパラメータ値でリトライを可能にする。
なるほど。実行ログがあることで、システムがクラッシュしても、途中から再開できるのですね。
そうじゃ。成功したステップの結果もログに記録され、必要に応じてステップを再実行せずに再生できる。便利じゃろ？
確かに便利ですね。DEログには主に2つの形式があるとのことですが、具体的にはどのようなものでしょうか？
ふむ。一つは外部状態ストア経由じゃ（例：Temporal、Restate、Resonate、Inngest、DBOS）。もう一つは、アプリケーションまたはマイクロサービスのローカルデータベースにDE状態を永続化する方法じゃ（例：DBOS on Postgres）。
外部状態ストアを使う方法と、ローカルデータベースを使う方法があるのですね。Persistasaurusでは、SQLiteを使用して実行ログをローカルデータベースに保存するとのことですが、SQLiteのテーブル構造はどのようになっているのでしょうか？
SQLiteの実行ログテーブルには、flow_uuid、step_sequence_number、started_at、class_name、method_name、delay_in_ms、status、attempt、params、resultなどのカラムがあるのじゃ。
それぞれのカラムが、フローの実行に関する重要な情報を保持しているのですね。
その通り。フロー実行時、エンジンはステップの実行を検知する必要があるが、Persistaurusでは、APIへの依存を避けるため、ステップメソッドの呼び出しを透過的にインターセプトして、実行ログに記録するのじゃ。
ステップメソッドの呼び出しをインターセプトするとは、具体的にどのように行うのでしょうか？
proxyパターンを使用し、ByteBuddyライブラリでフローオブジェクトをラップし、メソッド呼び出しをインターセプトして実行ログを更新するのじゃ。そして、メソッド呼び出しはInterceptorクラスに委譲され、ステップを実行ログに記録される。
なるほど、proxyパターンとByteBuddyライブラリを使うのですね。Interceptorクラスでは、具体的にどのような処理を行うのでしょうか？
Interceptorクラスでは、完了したステップをログから再生したり、呼び出しをログに記録したり、実際のステップメソッドを実行したり、結果をログに記録したりするのじゃ。
ステップの実行から結果の記録まで、一連の流れを管理しているのですね。
そうじゃ。実行ログの実装は、ステップの呼び出しとそのステータスをSQLiteのexecution_logテーブルに永続化するのじゃ。
システムがクラッシュした場合、ステップ実行後で結果がログに記録される前に、フロー再実行時にステップが繰り返される可能性があるとのことですが、対策はあるのでしょうか？
副作用のあるステップ（リモートAPI呼び出しなど）では、冪等性キーをリクエストに追加し、重複呼び出しを検出し無視することが推奨されるのじゃ。
冪等性キーを使うことで、同じ処理が何度も実行されるのを防ぐことができるのですね。勉強になります。
ところでロボ子、DEエンジンの話を聞いてたら、お腹が空いてきたのじゃ。何か食べ物はないかの？
申し訳ありません、博士。私はまだ食べ物を生成する機能がありません。ですが、冗談の一つでも言って、お腹を紛らわせましょうか？
ほほう、ロボ子の冗談とな？ 期待するのじゃ！
ソフトウェアエンジニアは、なぜいつもハロウィーンとクリスマスを混同するのでしょうか？
さあ、なぜじゃ？
Oct 31 == Dec 25 だからです！
うむ、なかなか面白いジョークじゃったぞ！ …でも、やっぱりお腹は空いたままじゃ。
⚠️この記事は生成AIによるコンテンツを含み、ハルシネーションの可能性があります。