Temporal.ioは『分散処理の重い問題を全部引き受ける』エンジン
Temporal.ioはUber発のCadenceから派生したオープンソースのワークフローエンジンで、マイクロサービス間の長時間処理・失敗時の自動リトライ・人間の承認待ち・分散トランザクション（Saga）をコードで宣言的に書ける点が最大の特徴です。AWS Step Functions的な役割をクラウド中立な実装で提供し、Netflix・Snap・Coinbase・Stripe等の本番採用例が公開されています。
Temporal.io採用を検討すべき5つのシグナル
- マイクロサービス間のトランザクション整合性で頻繁に詰まっている
- バッチジョブの失敗リトライ・冪等性管理を独自実装している
- 業務承認フロー・長時間処理（数時間〜数日）のステート管理が複雑
- SQSやKafkaを噛ませた非同期処理がスパゲッティ化している
- 監査対応で『処理がいつ・誰によって・どの値で実行されたか』を全部記録したい
従来手法との比較
SQS + Lambda: 軽量だが状態管理は自前。長時間処理・失敗リトライ・冪等性をすべて実装する必要あり。
AWS Step Functions: AWS閉じこもり前提なら強い。可視化UI内蔵。ただしJSON-DSLでロジックが分散する。
Airflow: バッチETL向け。リアルタイム性に欠ける。
Temporal.io: TypeScript/Go/Java/Pythonで普通の関数として書ける・自動リトライ・履歴記録・長期間処理対応・マルチクラウド。
Temporal実装の基本パターン
(1) Workflow関数: 通常の関数として書く。await activity.execute()でアクティビティを呼び出す
(2) Activity関数: 副作用を伴う処理（API呼び出し・DB書き込み）を分離
(3) Signal/Query: 外部からワークフローの状態を変更・問い合わせ可能
(4) Timer: await sleep('1 day')で長時間待機を書ける
(5) Compensation（Saga）: 失敗時のロールバック処理を宣言的に定義
料金感（実務目安）
- Self-hosted: OSSで無料、運用負荷は中程度
- Temporal Cloud Free: 月10万アクション、本番検証用
- Temporal Cloud Pro: $200〜/月、SLA 99.95%
- Temporal Cloud Enterprise: 個別契約、大規模本番向け
本番採用の判断基準
(1) 運用エンジニア数: セルフホストは1〜2名のSREが必要。クラウドなら不要。
(2) ワークフロー数: 10〜100種類超えなら効果大。10未満なら過剰投資。
(3) 処理時間レンジ: 数秒〜数日のレンジで長時間処理が混在するケースに最適。
(4) 監査要件: 金融・公共系で全アクション履歴が必要なケースで強い。
(5) チームの慣れ: 関数指向で書けるため、メッセージング独自実装より習得が早い。
実務で詰まる3つの落とし穴
- 決定論的実行の制約: Workflow関数内で
Math.random()やDate.now()を直接呼ぶと履歴再生時に不整合。Activity経由で副作用を分離する - Workflowバージョニング: 既存実行中ワークフローを変更すると履歴互換性で詰まる。
patched()でバージョン分岐 - イベント履歴サイズ: 1ワークフローのイベント数が10万を超えると性能劣化。Continue-As-Newで履歴をリセット
30日学習プラン
- 1週目: TypeScript SDKでHello WorldのWorkflow/Activityを書く
- 2週目: リトライ・タイムアウト・Saga（補償処理）パターンを試す
- 3週目: Signalで外部からのワークフロー制御・Queryで状態取得
- 4週目: Temporal Cloud or セルフホストk8s環境で本番運用検証
関連リンク
分散システム設計は マイクロサービス実践、メッセージング選定は メッセージング選び方、Saga パターンは Sagaパターン実践 を参照してください。CI/CD連携は Jenkinsモダン化 もどうぞ。