Postgres / SQLite で作る Durable Workflow ── Temporal なしで受託の長時間処理を堅牢化する 2026 | GH Media
URLがコピーされました

Postgres / SQLite で作る Durable Workflow ── Temporal なしで受託の長時間処理を堅牢化する 2026

TECH 18分で読めます
# Durable Workflow# PostgreSQL# SQLite# バックエンド# 受託開発
URLがコピーされました
Postgres / SQLite で作る Durable Workflow ── Temporal なしで受託の長時間処理を堅牢化する 2026

2026 年 5 月末、Hacker News で SQLite is all you need for durable workflows と Building durable workflows on Postgres が 同時期に揃って上位入りしました。2 つの記事が共通して主張するのは、「長時間処理を堅牢にするために、Temporal / AWS Step Functions / Azure Logic Apps のような専用基盤を最初から導入する必要はない」という点です。多くの業務処理は、手元の PostgreSQL / SQLite に “実行状態” を永続化するだけで、再起動・障害・デプロイをまたいで安全に再開できるようになります。

受託で中堅企業の 業務システム / SaaS バックエンドを支える立場では、これは 「注文処理 / 請求バッチ / 外部 API 連携 / 承認フロー」といった **「途中で失敗すると困る長時間処理」を、過剰なインフラを増やさずに堅牢化できる現実的な選択肢を意味します。これまで Cloudflare Workflows v2 受託 で扱った バックエンドオーケストレーション、Cloudflare Dynamic Workflows 受託 で扱った マルチテナント耐障害ワークフロー、「論理削除」をやめる DB 設計受託 で扱った 状態モデル設計と接続して、「軽量 Durable Workflow 設計」**を新しい受託パッケージとして整理します。

なぜ「RDB ベースの Durable Workflow」が分水嶺なのか

観点専用基盤（Temporal / Step Functions）RDB ベース（Postgres / SQLite）
導入コストクラスタ構築 / SaaS 契約 / 学習既存 RDB に table 追加のみ
運用負荷専用基盤の監視・バージョン管理既存 DB 運用に吸収
状態の所在専用ストア（ブラックボックス化）自社 DB（SQL で可視化）
デバッグ専用 UI / 独自概念普段の SQL + ログ
ベンダーロック強い弱い（標準 RDB）
適用規模大規模 / 高スループット中小〜中規模で十分
障害復旧基盤側の仕組みに依存トランザクション + 冪等性で自前
コスト予測性従量 / クラスタ費用で変動既存 DB のスケールに連動

つまり RDB ベースの Durable Workflow は、**「堅牢な長時間処理＝重厚な専用基盤が必須」という思い込みを捨て、「中小〜中規模の受託案件は手元の RDB で十分堅牢にできる」**という現実的な分水嶺を示しています。

受託案件で活きる 3 つの構造変化

構造 1: 「専用基盤の導入」から「既存 RDB の活用」へ

これまで受託で 「失敗できない長時間処理」を堅牢化するには、Temporal クラスタや Step Functionsを提案するのが定石でした。しかし中堅企業の多くは **「専用基盤を運用できる人材がいない」ため、導入後に 属人化・塩漬けするリスクを抱えていました。RDB ベースなら 既存の PostgreSQL 運用知識に吸収でき、退場後も顧客が自走できます。これは Cloudflare Workflows v2 受託 で扱った オーケストレーションを、「専用基盤を持てない規模の顧客向け」**に翻訳する発想です。

構造 2: 「状態のブラックボックス化」から「SQL で可視化」へ

専用基盤の最大の弱点は 「実行状態が独自ストアに隠れる」ことです。RDB ベースでは ワークフローの状態が自社の table に SQL で見えるため、障害調査・監査・データ修正がすべて 普段の運用ツールで完結します。これは 「論理削除」をやめる DB 設計受託 で扱った 「状態をテーブルで明示する」思想と完全に一致し、ワークフロー状態も第一級のデータとして設計します。

構造 3: 「ベストエフォート再実行」から「冪等性 + チェックポイント」へ

障害時に **「とりあえず最初からやり直す」運用は、二重課金・二重発注・重複通知といった事故を生みます。RDB ベースの Durable Workflow では 各ステップを冪等に設計 + チェックポイントを永続化することで、「失敗した地点から安全に再開」できます。これは Kafka / Flink スキーマ乱立受託 で扱った イベント整合性を、「ワークフロー単位の整合性」**に落とし込む発想です。

RDB ベース Durable Workflow の設計パターン

受託で再利用できる最小構成を整理します。

パターン 1: ステップテーブル + ステータス遷移

ワークフローを workflow_runs（実行単位） と workflow_steps（各ステップ） の 2 テーブルで表現し、各ステップに pending / running / completed / failed のステータスを持たせます。ワーカーは 「未完了の最古ステップ」をポーリングして処理します。

CREATE TABLE workflow_runs (
  id            UUID PRIMARY KEY,
  workflow_type TEXT NOT NULL,
  status        TEXT NOT NULL DEFAULT 'running',
  payload       JSONB NOT NULL,
  created_at    TIMESTAMPTZ NOT NULL DEFAULT now(),
  updated_at    TIMESTAMPTZ NOT NULL DEFAULT now()
);

CREATE TABLE workflow_steps (
  id          BIGSERIAL PRIMARY KEY,
  run_id      UUID NOT NULL REFERENCES workflow_runs(id),
  step_name   TEXT NOT NULL,
  status      TEXT NOT NULL DEFAULT 'pending',
  attempts    INT NOT NULL DEFAULT 0,
  result      JSONB,
  run_after   TIMESTAMPTZ NOT NULL DEFAULT now(),
  UNIQUE (run_id, step_name)
);

パターン 2: 行ロックによる排他制御（Postgres）

複数ワーカーが同じステップを二重処理しないよう、SELECT ... FOR UPDATE SKIP LOCKED で安全にジョブを取り合います。これは Postgres の標準機能で、専用キューを入れずにワーカープールを実現できます。

SELECT * FROM workflow_steps
WHERE status = 'pending' AND run_after <= now()
ORDER BY id
FOR UPDATE SKIP LOCKED
LIMIT 1;

パターン 3: 冪等キーで二重実行を防ぐ

外部 API 呼び出し（決済・発注・メール送信）には 冪等キーを必ず付与し、「同じステップが 2 回走っても結果が 1 回分」になるよう設計します。SQLite の場合も INSERT OR IGNORE + UNIQUE 制約で同等の防御が可能です。

パターン 4: リトライとバックオフ

attempts をインクリメントし、run_after を指数バックオフで先送りします。一定回数を超えたら failed にして デッドレター相当のテーブルへ退避し、人手 or 別フローでリカバリします。

どの案件に RDB ベースが向くか / 向かないか

RDB ベースが向く案件専用基盤を検討すべき案件
中小〜中規模 SaaS / 業務システム秒間数千超の高スループット
既に Postgres / MySQL を運用数万並列の長時間ワークフロー
専任の基盤運用者がいない専任 SRE / プラットフォームチームあり
状態を SQL で見たい / 監査要件あり複雑な fan-out / fan-in が大量
退場後の顧客自走を重視ベンダー基盤前提で問題ない

「まず RDB ベースで始め、スループットが限界に来たら専用基盤へ」という 段階的アプローチが、受託では最もリスクが低い選択になります。

受託で提供する「軽量 Durable Workflow」5 フェーズ

フェーズ 1: 対象処理の棚卸し（1〜2 週間）

  • 「失敗すると困る長時間処理」の洗い出し
  • 現状の実装（cron / 手動再実行 / 専用基盤）調査
  • 障害履歴 + 二重実行事故の有無
  • スループット / SLA 要件
  • 冪等性の現状評価
  • 優先度マップ

フェーズ 2: 設計（1〜2 週間）

  • ステップテーブル + ステータス遷移設計
  • 冪等キー設計（外部 API ごと）
  • リトライ / バックオフ / デッドレター方針
  • 可観測性（ステータス可視化 SQL / ダッシュボード）
  • 既存 DB への影響評価
  • 移行方針（段階導入）

フェーズ 3: 実装（3〜5 週間）

  • ワークフローランタイム実装（ポーリング / ロック）
  • 既存処理の冪等化リファクタ
  • リトライ + デッドレター実装
  • 状態可視化ダッシュボード（Metabase / Grafana）
  • 統合テスト + 障害注入テスト
  • ランブック整備

フェーズ 4: 段階移行（2〜3 週間）

  • 影響の小さい処理から順次切り替え
  • 旧実装との並行稼働 + 検証
  • 監視アラート設定
  • 運用ドキュメント
  • 顧客チームへの引き継ぎ

フェーズ 5: 月次運用 + 改善（継続）

  • 失敗ステップ / リトライ傾向の分析
  • デッドレターの定期レビュー
  • スループット監視（専用基盤移行の判断材料）
  • 新規処理の Durable Workflow 化
  • 半期ごとの設計見直し

受託向け技術スタック標準セット

レイヤ推奨技術代替
状態ストアPostgreSQL / SQLiteMySQL
排他制御FOR UPDATE SKIP LOCKED / 行ロックアドバイザリロック
ランタイム自前ワーカー（Go / Node.js / Python）River / Oban / Graphile Worker
冪等性冪等キー + UNIQUE 制約分散ロック（Redis）
可視化Metabase / Grafana / Superset内製管理画面
監視Prometheus + AlertmanagerDatadog / Sentry
テスト障害注入 + 冪等性テストTestcontainers
将来移行先Temporal / Cloudflare WorkflowsStep Functions

受託契約に書く 5 つの条項

条項内容顧客が確認すべきこと
対象処理範囲Durable 化する処理リスト範囲外の追加申請
スループット前提想定処理量と限界値超過時の専用基盤移行判断
冪等性責任分界外部 API 側の冪等対応有無ベンダー API の仕様確認
退場時引き渡しランタイム + スキーマ + ランブック自社運用継続性
障害時運用再実行 / デッドレター対応 SLA24h / 営業時間

価格モデル — 軽量 Durable Workflow 受託パッケージ

プラン金額対象内容
診断 / 設計100 万円〜（3 週間）対象処理棚卸し + 設計書レポート + スキーマ設計
Lite250 万円〜（一括）処理 3〜5 本の Durable 化実装 + 冪等化 + 可視化
Standard500 万円〜（一括）処理 5〜15 本 + 段階移行+ デッドレター + 監視 + ランブック
運用サポート30 万円〜 / 月稼働後の継続運用月次レビュー + 改善 + 移行判断支援

顧客側 ROI 試算（中規模 SaaS / 長時間処理 10 本想定）

項目既存（cron + 手動再実行）軽量 Durable Workflow 導入後差分
処理失敗時の手動復旧工数月 50 時間月 6 時間-44 時間
二重実行事故（年）年 8 件年 0〜1 件-7 件
障害調査時間（1 件あたり）平均 3 時間平均 0.5 時間-83%
専用基盤の運用 / 学習コスト導入時 + 月次負担0（既存 DB 運用に吸収）専用基盤費削減
新規処理の堅牢化リードタイム2〜3 週間3〜5 日-75%
年間効果——約 800 万円相当 + 事故リスク低減

時給 8,000 円換算で 年間 500 万円超の工数削減 + 二重実行事故の回避。Standard プラン（一括 500 万円）でも 1 年強で回収可能で、専用基盤を入れない分の運用コスト削減が継続的に効きます。

ハマりやすい 5 つの落とし穴

落とし穴 1: 冪等性を後回しにする

「まず動かす」を優先して冪等キーを省くと、リトライ時に二重課金・二重発注が発生します。冪等性は最初から設計に含めます。

落とし穴 2: ロングトランザクションでロックを長持ち

1 ステップを 長大なトランザクションで囲むと、ロック競合とコネクション枯渇を招きます。ステップは小さく分割し、トランザクションは短く保ちます。

落とし穴 3: ポーリング間隔とインデックス設計の軽視

status / run_after に 適切なインデックスがないと、ステップが増えた途端に 遅延します。部分インデックス（WHERE status = 'pending'）で軽量化します。

落とし穴 4: デッドレターを放置

失敗ステップを failed にするだけで 誰も見ないと、サイレント障害が積み上がります。定期レビュー + アラートを運用に組み込みます。

落とし穴 5: スケール限界を測らずに塩漬け

RDB ベースは万能ではありません。スループットの監視を怠ると、限界到達時に突然詰まります。移行判断の閾値を最初に合意します。

まとめ — 「重厚な基盤」から「手元の RDB で堅牢化」へ

「SQLite is all you need」「Building durable workflows on Postgres」が同時に話題になったことは、「長時間処理の堅牢化＝専用基盤の導入」という固定観念が 2026 年に崩れつつあることを示しています。受託で中堅企業のバックエンドを支える立場では、冪等性 + チェックポイント + 状態可視化を一体で提供する **「軽量 Durable Workflow 設計」が、「専用基盤を持てない規模の顧客」**に刺さる新しい主力サービスになります。

弊社では 診断 / Lite / Standard / 運用サポートの段階で本パッケージを提供しています。「バッチ処理が途中で失敗すると毎回手動復旧している」「Temporal を入れたいが運用人材がいない」「二重発注事故をなくしたい」というご相談は お問い合わせフォーム からお気軽にどうぞ。

Sources

URLがコピーされました

グリームハブ株式会社は、変化の激しい時代において、アイデアを形にし、人がもっと自由に、もっと創造的に生きられる世界を目指しています。

記事を書いた人

鈴木 翔

鈴木 翔

技術の可能性に魅了され、学生時代からプログラミングとデジタルアートの分野に深い関心を持つ

関連記事