「durable workflows を作るのに、最初から大げさな仕組みは要らない。
小さな SQLite ファイル + バックアップ + 安い worker で、意外と十分なことが多いよ」という話です。
これ、かなり面白いです。
ふつう「重要なシステムを作るなら、まずは堅牢なDB、冗長化、監視、フェイルオーバー…」と考えがちですが、この記事はそこにちょっと待ったをかけています。
“本当に守るべきものは何か？” を見直すと、守るべきなのは高価なサーバー群ではなく workflow の履歴や状態 なんですよね、という発想です。私はこの割り切り方、かなり筋がいいと思います。
まず用語をやさしく言うと、durable execution は「途中で落ちても、あとから続きから再開できる実行」のことです。
たとえば AI agent が、
みたいな処理をしている途中でサーバーが落ちても、どこまで終わったか が残っていれば、最初からやり直さずに済みます。
この「どこまで進んだか」を残すのが workflow state です。
この記事の大事な主張はここで、
壊れない実行に必要なのは、必ずしも壊れにくい巨大インフラではない。 workflow state さえ durable にしておけばよい
という考え方です。
元記事は Obelisk という仕組みを前提にしています。
ざっくり言うと、workflow の進行状況を execution log として残し、そこから replay（記録をたどって再実行）できるようにする設計です。
こういう設計だと、計算する worker 自体は安くてよくて、壊れてもまた立ち上げればいい。
私はこの「compute は使い捨てでよい、状態だけ守る」という発想が、今の AI 時代にすごく合っていると思います。AI agent の仕事って、かなり試行錯誤的で、しかも失敗しやすいですからね。
この記事が面白いのは、ここでいきなり SQLite を持ち上げるところです。
SQLite は、みんながよく知る軽量DBです。
でも軽量だからといって侮れなくて、ちゃんと transactional durable state を持てます。
transactional というのは、ざっくり言えば「途中で失敗したら中途半端な状態のまま残さず、きれいに成功か失敗かを扱える」という性質です。
SQLite のいいところは、この記事の文脈では次の通りです。
つまり、ローカルのDBファイル1個で済む。
これは地味ですが、かなり強いです。システムは複雑になるほど壊れやすくなるので、「本当に必要な機械だけ残す」というのは合理的です。
個人的には、ここは“正しさ”より“運用の気楽さ”が勝つ場面がかなりあると思います。
理屈では高機能な分散DBが魅力的でも、実際には「設定が面倒」「障害時に見たい情報が散らばる」「小さな実験に重すぎる」ということがよくあります。SQLite はその逆で、気軽さが武器です。
とはいえ、SQLite はローカルファイルなので、バックアップや持ち運びをどうするかが気になります。
そこで出てくるのが Litestream です。
Litestream は、SQLite の変更を S3-compatible object storage に非同期で流してくれる仕組みです。
ここでの object storage は、ファイルを置いておく倉庫のようなものだと思えばだいたい合っています。S3 は AWS の代表的な object storage ですね。
これがあると、
という構成ができます。
ただし、この記事はちゃんと caveat も書いています。
Litestream の replication は asynchronous、つまり「即時に完全同期」ではありません。
なので、SQLite の volume が消えるタイミングが悪いと、まだコピーされていない最新の書き込みは失われる可能性 があります。
ここは大事です。
つまりこの記事の提案は「絶対に一切失敗しないシステム」ではなく、多くの AI / 実験ワークロードにはこれで十分 という現実的なラインを狙っています。
この割り切りが良いんですよね。過剰な可用性を求めすぎず、でも最低限の durability は確保する、というバランス感覚です。
記事では、こういう運用モデルが想定されています。
ここでの observer は、たとえば「この agent は何をしたのか調べたい人」だと思えばOKです。
SQLite のファイルがそのまま残るので、local replay も debug もやりやすい。
これはかなり実務的です。ログがバラバラのサービスに散らばるより、「このファイルを見れば分かる」のほうが、後から圧倒的に楽なことが多いです。
この記事が強く推しているのが、AI agents や AI-generated workflows への適性です。
その理由はシンプルで、
からです。
つまり、巨大な共有システムを1個作るより、
小さな server をたくさん並べて、それぞれに SQLite を持たせる ほうが合っているケースがある、というわけです。
私はこれはかなり納得感があります。
AI 系のワークロードって、よくも悪くも「まだ未成熟」なので、最初から大規模な共通基盤に押し込むと、かえって動かしづらいんですよね。
小さい単位で独立しているほうが、失敗の切り分けもしやすいし、「この agent だけ止める」がやりやすい。地味ですが、これが大きいです。
もちろん、そんなことはありません。
記事もはっきり Postgres のほうが適している場合がある と言っています。
たとえば、
こういう場合は Postgres を選ぶべきです。
ここが重要で、「SQLite が万能」という話ではないんです。
むしろこの記事の姿勢は逆で、最初から大きいものを選ぶな。状態の要求に合わせてインフラを選べ というものです。
この考え方、派手さはないけれど、かなり健全だと思います。
個人的には、この記事のメッセージは「durability = 巨大インフラ」ではない、というところが一番刺さりました。
システム設計って、気を抜くとどんどん豪華になります。
でも本当に必要なのは、
であって、必ずしも分散システム全部入りではないんですよね。
SQLite は地味ですが、**“ちゃんとした最小構成”** としてかなり強い。
Litestream を組み合わせると、なおさらその強さが見えてきます。
この記事の結論をひとことで言うなら、
多くの durable workflows、特に AI agents 向けのものは、SQLite + Litestream + 安い worker で十分いける
ということです。
もちろん、これは全てのケースに当てはまるわけではありません。
でも「まずは小さく、状態を守ることに集中する」という考え方は、実装も運用もずっと楽にしてくれます。
派手なアーキテクチャより、よくできた小さな仕組み。
この記事は、その価値をかなり上手に言語化していると思いました。
