Temporal、失敗しても続くWorkflowを分散システムの標準部品にする設計

分散処理の失敗を前提にする

Temporalの共同創業者Maxim Fateevは、公式のプロダクト説明でTemporalを「reliable applications using workflows and activities」のためのdurable execution platformとして位置づけている。

これは創業者の問題意識を、失敗しても処理を続けられる実行基盤として表した説明だ。出典

WorkflowとActivityを分けた

Temporalは、決定的に再生できるWorkflowと、外部API・DBなど副作用を担うActivityを分離する。

Activityはretryやtimeoutの対象になり、Workflowは履歴から状態を復元する。出典

OSSからCloudへ

ServerをOSSとして公開し、複数言語SDKで開発者の入口を広げた。

運用を自社で抱えたくないチームにはCloudを提供し、durable executionをインフラ構築ではなく利用量に応じるserviceへ変えた。出典

信頼性を機能として売る

Temporalの転機は、queueやcronを個別に足すのではなく、処理の途中状態・再試行・可視化を一つのWorkflowモデルにまとめたことだ。

結果として、失敗時の復旧手順そのものをapplication architectureの部品として提供している。出典

次の課題

Workflowのdeterminism、versioning、retry設計は利用者の責任として残る。

Temporalは魔法の可用性ではなく、失敗を設計対象にするための強い抽象化だ。

Temporalの顧客は、決済・注文・AI jobなど、数秒で終わらず失敗時に途中状態を失うと事業影響が出る処理を持つ開発チームだ。

WorkflowとActivityを分け、状態を保存しながら再実行できるため、アプリ側に散らばりがちなretryやtimeoutを共通化する。出典

価値はqueue製品の置き換えではなく、「処理が何度でも安全に続く」実行モデルを開発者へ渡す点にある。

障壁は、Workflow history、scheduler、retry、visibility、複数SDKを一体で扱う実行基盤にある。

導入後のWorkflow定義と運用知識が蓄積するほど、単純なqueueへの置換では同じ復旧性を再現しにくい。出典

直接のnetwork effectは弱いが、OSS、SDK、sample、communityが増えるほど実装パターンと導入支援が厚くなるdeveloper ecosystem効果はある。出典

主対象は、複数サービスをまたぐ業務処理、支払い、データ同期、AI agent実行を担当するplatform team。

失敗時に手動再実行できない処理を持ち、queueとcronの寄せ集めから脱したい組織に向く。出典

第一に、Workflowの履歴をもとにdeterministicに再開するモデルが、障害復旧の実装を製品の中心へ置く。出典

第二に、Go、Java、TypeScript、Pythonなど複数SDKとOSS Serverを用意し、既存stackへ入る経路を広げた。出典

Workflowはdeterministic制約を守る必要があり、通常のアプリコードをそのまま移植できるわけではない。

外部APIやDBアクセスをActivityへ分離し、versioningを運用する設計負荷が残る。出典

またCloudのusage-based課金は実行量に比例するため、retry stormや長時間Workflowを監視しないとコストが増える。

導入前にtimeout、retry、retentionを定義すべきだ。出典

入口はOSS、docs、GitHub、サンプルで、開発者がself-hostedで試せる。

そこから運用負荷を減らしたいチームをTemporal Cloudへ移し、実行量に応じたusageへ接続する。出典

拡張の軸は単発jobから長期Workflow、scheduled task、human-in-the-loop、AI agentへ広げること。

機能を増やすほど、visibilityと運用ガードレールが重要になる。

主要チャネル: docs, github, community, content, developer_relations

PdMが学べるのは、reliabilityを非機能要件として後付けせず、ユーザーが価値を受け取るWorkflowの状態モデルに埋め込むことだ。

retryやtimeoutを設定項目にするだけでなく、どこから再開できるかを製品の主語にする。出典

日本では決済、物流、予約、審査など、再実行の重複が事故になる業務から導入しやすい。

日本語の運用runbook、監査ログの保持期間、障害時の手動介入権限をテンプレート化すると、OSSの技術検証から本番運用へ移りやすい。出典