ワークフローエンジン比較 — Airflow・Temporal・Step Functionsの設計思想
要点
- Airflow、Temporal、AWS Step Functionsは、いずれも処理の流れを管理するが、記述の前提と失敗の扱いが異なる。
- Airflowはスケジュール駆動のデータパイプライン、Temporalは長時間の状態保持、Step Functionsはマネージドな状態遷移に強みを置く。
- 選択の軸は「どれが優れているか」ではなく、扱う処理が時間とどう関わるかである。
- どのエンジンも、再試行と冪等性（同じ処理を繰り返しても結果が変わらない性質）の設計から逃れられない。
ワークフローエンジンを比べるとき、機能の一覧表を並べても性格はつかめない。同じ「処理を順序立てて実行する」道具に見えて、設計者が何を一番こわいと考えているかが製品ごとに違うからだ。ここではApache Airflow、Temporal、AWS Step Functionsの三つを、思想の違いという観点から並べてみる。
Airflow：時刻と依存のグラフ
Apache Airflowは、もともとデータパイプラインのために生まれた。公式ドキュメントが中心に据えるのは、処理の依存関係を有向非巡回グラフ（DAG）で書き、決まった時刻に走らせるという発想である。「毎日午前3時に、前日のログを集計し、その結果を集約テーブルへ書き込む」といった定型の流れに向く。
強みは流れの可視化にある。どのタスクがどのタスクを待つのかが図として見える。一方で、Airflowはスケジュール起点の発想が強いため、利用者の操作にその場で反応するような、いつ始まるか読めない処理には必ずしも噛み合わない。得意分野が明確であることは、不得意分野も明確だということでもある。
Temporal：止まらない状態
Temporalが解こうとするのは、別の不安だ。数時間、ときに数日にわたって続く処理の途中で、サーバーが落ちたらどうするか。注文の受付から決済、出荷、配送完了までを一つの流れとして扱おうとすると、その間にプロセスは何度も再起動されうる。Temporalの公式ドキュメントは、処理の実行履歴を保存し、障害から再開しても同じ続きから進める仕組みを中核に説明している。
この設計は、開発者に冪等性を強く意識させる。再開のたびに同じ外部呼び出しが二重に走らないよう、処理は「何度繰り返しても安全」に書く必要がある。裏を返せば、Temporalは長く生きる処理の難しさを引き受ける代わりに、利用者に規律を求める道具だといえる。
Step Functions：マネージドな状態遷移
AWS Step Functionsは、状態遷移をJSONで定義し、クラウド側がその実行を管理する。AWSの公式ドキュメントは、各ステップを「状態」とみなし、成功・失敗・再試行をその定義のなかで宣言的に記述する方式を採る。自前でワーカーを運用しなくてよい点が、運用負荷を下げる。
もっとも、マネージドであることは制約とのセットだ。記述形式や実行時間の上限はサービスの枠組みに従う。自由度を手放す代わりに運用を肩代わりしてもらう——その交換に納得できるかどうかが、採否の分かれ目になる。
共通して残る問い
三つを並べると、表面的な違いの下に共通の課題が見えてくる。どのエンジンも、ネットワークの一時的な失敗からは逃れられない。だから再試行をどう書くか、そして再試行しても壊れない冪等な処理をどう設計するかが、結局はどの製品でも中心になる。これはリトライとバックオフの設計と同じ地平の話だ。
エンジン選びは、機能比較表の勝敗ではない。扱う処理が「決まった時刻に走る」のか「長く生き続ける」のか「クラウドに任せたい」のか——時間との関わり方が、ふさわしい道具を決める。オーケストレーションへの移行を考えるとき、まず問うべきは製品名ではなく、自分たちの処理がどんな時間軸で動くのかという点である。
出典
- Apache Airflow 公式ドキュメント（DAGとスケジューリング）
- Temporal 公式ドキュメント（実行履歴と障害再開）
- AWS Step Functions 公式ドキュメント（状態遷移の宣言的記述）