まず、ここがいちばん大事です。
durable execution は、ざっくり言うと「処理の途中経過をちゃんと保存しておいて、落ちても続きからやり直せる仕組み」のことです。
ゲームでいうセーブポイントみたいなものですね。敵に負けても、最後にセーブしたところから再開できるあれです。
たとえば、
みたいな処理は、途中でサーバーが落ちると面倒です。
普通のプログラムだと「最初からやり直し」になりがちですが、durable execution ならどこまで終わったかを保存しているので、そこから復元できるわけです。
これはかなり実用的です。
というのも、現実のシステムは普通に落ちるからです。人間の理想より、障害のほうがよほど現実的なんですよね。
この記事がまず紹介しているのは、従来よくある方式です。
Temporal、Airflow、AWS Step Functions などがこの系統に入ります。
このモデルでは、ワークフローはだいたい次のように動きます。
つまり、司令塔がいて、worker を指揮する構造です。
これはわかりやすい反面、DBOSの記事はここにかなりはっきりした疑問を投げています。
それって、ちょっと複雑すぎない？
というわけです。
記事の核はここです。
DBOSは、durable workflows の本質は「DBに状態を保存すること」なのだから、わざわざ別の orchestrator server を立てる必要はないと主張しています。
この考え方、かなり筋がいいと思います。
なぜなら、やっていることを分解すると、結局は
を管理しているだけだからです。
それなら、その管理を得意とするデータベースに寄せたほうが自然ではないか、という理屈です。
DBOSの記事では、Postgresに workflows テーブルを作り、アプリケーションサーバーがそこから仕事を取りに行く形を説明しています。
worker がステップを実行するたびに、その結果を Postgresへ checkpoint します。
もし worker が落ちても、別の worker がその checkpoint を見て続きから再開できます。
要するに、Postgresを中心にみんなで協調して動く構成です。
これ、発想としてはすごく地味なんですが、その地味さが逆に強い。
「中央の賢い司令塔」を増やさないというのは、システム設計ではかなり効きます。
気になるのは、「複数の worker が同じ仕事を取ってしまったらどうするの？」という点です。
記事では、Postgresの locking clause（ロック機構） や integrity constraints（整合性制約） を使うと説明しています。
簡単に言うと、
という仕組みです。
ここが面白いのは、ワークフローの正しさを、アプリの知恵だけでなくDBの機能で担保していることです。
アプリ側で全部の整合性を頑張るより、データベースに得意なことをやらせるほうが、たしかに合理的です。
記事があえて Postgres に絞っているのは、単なる好みではありません。
理由はちゃんとあります。
つまり、Postgresは「新しい奇抜な土台」ではなく、すでに現場で鍛えられている土台なんですよね。
この安心感は大きいです。
さらに記事では、Postgresのスケーリングについても触れています。
ここで大事なのは、「Postgresならもう終わり」ではなく、既に成熟した運用の選択肢が揃っているという点です。
新しい orchestrator を1から運用するより、既存のデータベース運用の延長で考えられるのはかなり大きいと思います。
個人的にこの記事でかなり面白いのは、この部分です。
Postgres-backed durable execution では、workflow や step の checkpoint が そのままテーブルに入るので、観測しやすい、という話です。
つまり、「今どのワークフローがどうなっているか」をSQLで直接見られるわけです。
これは強いです。かなり強い。
たとえば、
みたいなものを、SQLで柔軟に集計できます。
SQLはちょっと古臭く見えるかもしれませんが、こういうときは本当に頼もしいです。
「結局、最後はSQLが勝つ」みたいな場面、現場では意外と多いんですよね。
記事は、従来の orchestrator が使うシンプルな key-value store では、こういう分析的な問い合わせが難しいことを対比しています。
たしかに、観測しやすさは運用のしやすさに直結します。
作るときより、本番で何が起きているかを知れることのほうが大事だったりしますから。
記事では、外部 orchestrator を使う場合の問題も指摘しています。
外部 orchestrator 方式では、少なくとも
が重要な中枢になります。
つまり、故障点が増えるし、守るべき対象も増えるということです。
しかも、ワークフローの checkpoint には機密データが含まれることもあるので、セキュリティ上も気を使う必要があります。
アクセス制御、監査、ハードニングなど、やることは増えます。
一方で Postgres-backed なら、データは最初から Postgres の中だけにある。
別のシステムをまたいで情報が移動しないので、新しい攻撃面や障害点を増やしにくいわけです。
ここはかなり現実的なメリットだと思います。
システムを大きくすると、理屈よりも「守る場所が増える」ことのほうがしんどいので、部品を増やさないのは正義です。
ただし、これは「Postgresだけで全部解決！」という単純な話ではないと思います。
この記事の主張は筋が通っていますが、実運用では、
によって、外部 orchestrator のほうが向いているケースもあるはずです。
たとえば、専用のワークフローUIや大規模なジョブ管理機能が最初から欲しいなら、成熟した外部製品のほうが楽なこともあるでしょう。
なので私は、この記事を「外部 orchestrator は不要」と読むより、
「多くのケースで、まず Postgres を中心に考えると設計がかなり素直になる」という提案として受け取るのがよいと思います。
この文章を読んで感じたのは、DBOSの主張はかなり地に足がついているということです。
派手な新機能で勝負するというより、
という、すごくまっとうな方向に寄せています。
個人的には、こういう「新しいことを足す」のではなく「不要なものを減らす」タイプの設計思想は好きです。
システム設計って、しばしば機能を増やすほど賢く見えるのですが、実際には減らしたほうが強いことが多いんですよね。
DBOSの記事は、durable execution を考えるときに
“Orchestratorを別に持つのが当たり前” という前提を疑ってみよう
と投げかけている、そんな内容でした。
