LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

分散ワークフローの耐障害基盤としてのTemporal

Temporal（テンポラル）とは、分散アプリケーションの処理手順をコードで記述し、プロセスの異常終了やサーバー障害が起きても実行状態を保持したまま処理を継続できるようにする、Durable Execution（永続実行）基盤である^*1。決済処理・注文処理・データ連携など、複数のサービスをまたぐ一連の処理を「途中で止まらない・止まっても再開できる」形で実装するために使う。

この記事では、Temporal特有の仕組みであるWorkflow・Activityの分業、イベント履歴によるリプレイ、リトライポリシーと冪等性、長時間処理やSaga（分散トランザクション補償）への適用、Temporalクラスタの自社運用とTemporal Cloudの選択、外注・内製の判断軸までを整理する。Airflow等のデータパイプライン向けオーケストレーションや、AWS Step Functionsのようなマネージド型サービスとは異なり、Temporalはアプリケーションそのものの状態遷移を長期にわたって永続化する点が特徴である。

Workflow・Activity・リプレイが支える永続実行の仕組み

Temporalのアプリケーションは、大きく2種類のコードで構成される。Workflowは処理のステップ順序を定義するコードで、Temporal Platform上で実行される^*2。Activityは外部システムとやり取りする処理を担当し、API呼び出し・データベース操作・ファイルI/Oなど「外の世界」に触れる処理はすべてActivityに切り出す^*2。

Workflow ExecutionはTemporalアプリケーションの実行単位であり、耐久性・信頼性・スケーラビリティを備えた関数実行として位置づけられている^*3。耐久性とは「課される時間制限が存在しないこと」を指し、処理が数秒で終わるか数年にわたるかにかかわらず、実行が完了するまでコードの状態を保持し続ける^*3。

この永続性を支えているのがリプレイ（Replay）である。Workflow実行が中断した際、Temporalはコードを最初から動かし直しつつ、記録済みのイベント履歴を1件ずつ再生し、その履歴に沿って実行状態を中断直前まで復元する^*4。復元後は履歴に存在しない箇所から処理が継続される仕組みだ。

リプレイが正しく機能するためには、Workflowコードが決定論的でなければならない。同じイベント履歴を与えられたとき、常に同じ判断を下す必要がある^*4。そのため、Workflowのコード内で現在時刻を直接取得したり、乱数を生成したり、記録されない外部呼び出しを行うことは避ける必要がある^*4。これらの処理はActivityに切り出すことで、決定論性を保ったままWorkflowの外側で実行できる。

リトライ・タイムアウト・冪等性で耐障害性を実装する

Activityは失敗を前提とした設計になっている。Activityは「少なくとも1回」実行されるモデルで動作し、Workerが処理を完了させた後にTemporal Serviceへの通知前にクラッシュした場合、同じActivityが再実行される可能性がある^*5。この特性のため、Activityの処理内容は冪等（何度実行しても同じ結果になる）に設計することが推奨されている^*5。

冪等性を確保する代表的な方法は、外部サービスが対応する冪等性キーの利用である。Workflow Run IDとActivity IDを組み合わせた値は、同一Activityのリトライ中は一定に保たれ、かつWorkflow実行間では一意になるため、キーとして活用できる^*5。決済処理を例にすると、冪等性キーがないと再送要求のたびに二重課金が発生しかねないが、キーを使えば同じ結果を返すだけで済む^*5。

タイムアウトも耐障害性の重要な要素である。Activityには4種類のタイムアウトがある。Schedule-To-Startはタスクキューに置かれてからWorkerに取得されるまでの上限、Start-To-Closeは1回の実行試行に許される上限、Schedule-To-Closeはリトライを含めた全体の上限、Heartbeat Timeoutは長時間実行するActivityが定期的な生存通知を送る間隔の上限である^*6。特にStart-To-Closeは、Workerのクラッシュによる無応答を検知してリトライを発生させる主要な手段として機能する^*6。

リトライポリシーにはInitial Interval・Backoff Coefficient・Maximum Interval・Maximum Attemptsの4パラメータがある。デフォルトはInitial Intervalが1秒、Backoff Coefficientが2.0（指数的にリトライ間隔を延ばす）、Maximum IntervalがInitial Intervalの100倍、Maximum Attemptsは無制限である^*7。これらはActivityに自動適用され、リトライ回数や間隔を業務要件に合わせて調整できる^*7。

長時間ワークフローとSagaによる分散トランザクション補償

Temporalが向いている領域の一つが、数時間から数か月にわたる長時間ワークフローである。バッチ処理の待ち合わせ、承認待ちのある業務フロー、段階的なデプロイなど、処理の途中で長い待機が発生する業務でも、Durable Executionの特性上、時間制限を課されずに状態を保持できる^*3。

複数サービスをまたぐ処理で一貫性を保つ手法として、Sagaパターンがある。Sagaは分散トランザクションの一種で、一連の処理をステップごとに実行し、途中のステップが失敗した場合は、それまでに成功したステップを打ち消す補償アクションを実行して整合性を保つ^*8。例えば「在庫確保→決済→配送手配」という順で処理し、配送手配が失敗したら決済取消・在庫解放を逆順で実行するような構成である。

Temporal上でSagaを実装する場合、進捗の追跡とリトライは基盤側が担うため、開発者が書くのは補償ロジック自体に絞られる^*8。補償は登録した順序と逆順に実行することで、後から積み上げた処理から順に取り消す一貫性を保てる^*8。並列に補償を走らせるか、直列に一つずつ取り消すかも設計判断の一つになる。

Sagaを使う場面では、各ステップのActivityが冪等であることが前提になる。補償処理自体もリトライされる可能性があるため、取消処理を二重に実行しても壊れない設計が欠かせない。分散トランザクションの整合性は、DBのトランザクション機能では扱えない範囲であり、Sagaのような補償設計とTemporalの実行保証を組み合わせて初めて実務的に成立する。

TemporalクラスタとTemporal Cloud、運用形態の選択

Temporalを使う際の運用形態は大きく2つに分かれる。1つはTemporal Server（オープンソース）を自社でホストするTemporalクラスタ、もう1つはTemporal社が提供するフルマネージドサービスのTemporal Cloudである。

Temporal Cloudは、永続化・レプリケーション・アップグレード・可用性の管理をプラットフォーム側が担い、利用者はアプリケーション開発に専念できる構成になっている^*9。標準で3ゾーンへの同期レプリケーションを備え、99.9%のSLAが提供される^*9。ワークフロー状態とイベント履歴の暗号化、mTLS・APIキー認証、プライベート接続にも対応する^*9。一方でワーカー自体は利用者側の環境で動かす構成で、計算処理とオーケストレーション基盤が分離されている点も特徴である^*9。

Temporal Cloudの課金は消費量ベースで、ワークフロー開始やハートビート記録などの操作単位である「Actions」と、稼働中・保持中のワークフロー履歴を計測する「Storage」が主な単位になる^*10。プランはEssentials・Business・Enterprise・Mission Criticalの4種で構成されている^*10。具体的な単価・最低利用料はプランや利用規模によって変わるため、契約時は公式の料金ページで最新条件を確認する必要がある^*10。

外注と内製、Temporal導入をどの軸で判断するか

Temporalは仕組みそのものは強力だが、導入初期に判断すべき論点が多い。外注か内製かを検討する際は、次の3つの軸で整理すると判断しやすい。

第一に、決定論性を守れる設計・実装体制があるかという軸である。Workflowコード内で現在時刻取得や乱数生成、記録されない外部呼び出しを書いてしまうと、リプレイ時に処理経路がずれて不具合につながる^*4。この制約を理解した設計レビュー体制がない場合、初期の数本のワークフローで誤りが混入しやすい。

第二に、Saga設計や冪等性設計といった分散システム特有の知見が社内にあるかという軸である。補償ロジックの実行順序、冪等性キーの設計、タイムアウトの組み合わせは、いずれも一度の実装ミスが本番障害に直結する領域だ^*5*8。

第三に、Temporalクラスタの運用体制を用意できるかという軸である。自社運用を選ぶ場合はデータベース選定・監視・アップグレード対応が発生し、Temporal Cloudを選ぶ場合は消費量に応じたコスト管理が必要になる^*9*10。どちらを選ぶにせよ、既存のインフラ運用チームの知見だけでは判断が難しい部分が残る。

これら3軸のいずれかで社内に知見が不足している場合は、設計段階から外部パートナーを交えて進める方が、後工程での手戻りを避けやすい。特にSagaや冪等性の設計は、実装後に不整合を発見してからの手直しが難易度・コストともに高くなりやすい領域である。

導入でつまずきやすい設計ポイントと必要スキル

Temporalの導入を内製で進める場合、必要になる知識は一つの言語やフレームワークの習熟にとどまらない。Workflow/Activityの分業設計、決定論的コードの制約、リトライ・タイムアウトの調整、Saga設計、クラスタ運用（自社運用の場合）と、複数の専門領域が重なる。これらを短期間で立ち上げようとすると、設計担当者が兼務で複数の役割を抱え込み、レビューが行き届かなくなる状況が生じやすい。

典型的な失敗パターンは、Activityの冪等性を後回しにしたまま本番投入し、リトライによる二重実行が決済や在庫更新で表面化するケースである^*5。もう一つは、Workflowコード内に非決定的な処理を書いてしまい、SDKやTemporal Serviceのバージョンアップ後にリプレイが失敗するケースだ^*4。いずれも設計段階でのレビューがあれば防げるが、初導入のチームでは気づきにくい。

LASSIC IT事業部では、こうした分散システム特有の設計レビューを含めた形で、Temporalを用いたワークフロー基盤の設計・構築を元請として支援する体制を整えている。Workflow/Activityの切り出し設計からSaga補償の実装、Temporalクラスタの構築支援、Temporal Cloud移行の技術検証まで、要件に応じて対応領域を調整可能である。

まとめ：Temporal導入で押さえる3つの判断軸

本稿では、TemporalのDurable Executionが分散アプリケーションの耐障害性をどう実現するかを、Workflow/Activityの分業、リプレイの仕組み、リトライ・タイムアウト・冪等性、Sagaによる分散トランザクション補償という観点で整理した。要点を3つに集約すると、第一に決定論的なWorkflow設計がリプレイの前提になること、第二にActivityの冪等性設計が耐障害性の実質的な支柱になること、第三にTemporalクラスタとTemporal Cloudのどちらを選ぶかが運用体制の負荷を左右することである。これらの設計判断を自社の知見だけで完結させにくい場合は、導入初期から外部パートナーを交えて進める選択が、本番運用後の手戻りを抑える。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：Temporal「The definitive guide to Durable Execution」https://temporal.io/blog/what-is-durable-execution
2. *2　出典：Temporal Platform Documentation「Temporal Workflow」https://docs.temporal.io/workflows
3. *3　出典：Temporal Platform Documentation「Temporal Workflow Execution overview」https://docs.temporal.io/workflow-execution
4. *4　出典：Temporal Platform Documentation「Temporal Workflow」（決定論性・リプレイに関する記載）https://docs.temporal.io/workflows
5. *5　出典：Temporal「What is idempotency? And why it matters for durable systems」https://temporal.io/blog/idempotency-and-durable-execution
6. *6　出典：Temporal Platform Documentation「Detecting Activity failures」https://docs.temporal.io/encyclopedia/detecting-activity-failures
7. *7　出典：Temporal Platform Documentation「What is a Temporal Retry Policy?」https://docs.temporal.io/encyclopedia/retry-policies
8. *8　出典：Temporal「Saga Design Pattern Explained for Distributed Systems」https://temporal.io/blog/saga-pattern-made-easy
9. *9　出典：Temporal Platform Documentation「Overview – Temporal Cloud」https://docs.temporal.io/cloud/overview
10. *10　出典：Temporal Platform Documentation「Temporal Cloud pricing」https://docs.temporal.io/cloud/pricing

Tweet