エッセイ
Cron と Airflow の間にある空白
Cron は小さすぎ、Airflow は大きすぎる。多くのチームはその間で、bash スクリプトをつなぎ合わせたり、Python 前提のオーケストレーターと格闘したりしています。
Cron と Airflow の間にある空白
複数のスケジュールジョブを持つチームは、いつか同じ壁に当たります。最初は cron で十分です。単純で、どこにでもあり、理解しやすい。しかしジョブが増え、依存関係が生まれ、失敗時の通知や再実行が必要になると、cron だけでは足りなくなります。
そこで多くのチームは「ちゃんとしたワークフローエンジンが必要だ」と考えます。そして Airflow のような重量級の仕組みに向かいます。ところが、そこには別の問題があります。Python のフレームワーク、メタデータベース、スケジューラ、ワーカー、アップグレード、運用監視。夜間 ETL を数本動かしたいだけのチームには、あまりに大きすぎる場合があります。
真ん中のチームが本当に必要なもの
問いを削ると、真ん中にいるチームが欲しいものはそれほど多くありません。
- コマンド列をスケジュールで実行する
- 何が動き、何が失敗し、出力が何だったかを見る
- SSH せずに失敗したステップを再実行する
- ワークフローを Git に置けるファイルで定義する
- 新しいプログラミング言語やフレームワークを覚えなくてよい
- 夜間 ETL のためだけにデータベースとメッセージブローカーを運用しなくてよい
このリストは小さいですが、多くの会社、多くの業界、多くのワークフローで実際に必要なものです。
なぜ OS とファイルでよいのか
ワークフローとは、どのコマンドを、どの順序で、どんな入力とスケジュールで実行するかの記述です。その記述はデータベースである必要はありません。ファイルで十分です。
ファイルは OS の共通基盤です。cat でき、grep でき、差分を見られ、Git にコミットでき、レビューでき、別のマシンへコピーできます。コマンドもソフトウェアの共通基盤です。どの言語にも実行ファイルがあり、レガシーシステムにも CLI や HTTP エンドポイントがあり、ディスク上のスクリプトはすでにコマンドです。
エンジンが、YAML ファイルを読み、コマンドを順番に実行し、ログをディスクに書き、localhost に UI を出すだけの行儀のよいプロセスなら、従来のオーケストレーターが持つ運用面の多くを削れます。移行するデータベースも、監視するブローカーも、学ぶフレームワークもありません。
Dagu を平たく言うと
Dagu は単一の Go バイナリです。マシンに置けば動きます。ワークフローは YAML ファイルで、状態はディスク上のファイルに残り、UI は同じバイナリから提供されます。
ステップは「operator」ではなくコマンドです。Python、bash、Java、既存の PHP スクリプト、12 年動いている Perl cron。Dagu はそれらを書き換えさせません。実行し、状態を追跡し、結果を見えるようにします。
この形が AI 時代に合う理由
CLI ネイティブな形は AI 以前から便利でしたが、AI 時代にはさらに重要です。AI エージェントはコマンドを扱います。bash を書き、CLI を呼び、HTTP エンドポイントを叩きます。エージェントが自然に生成する作業単位は、Dagu が自然に実行する単位と同じです。
オーケストレーターが特定フレームワークのコードを要求すると、モデルとランタイムの間にずれが生まれます。オーケストレーターがコマンドを受け取れるなら、エージェントはそれを作れ、人間は読め、どちらも世界観を変換しなくて済みます。
オーケストレーションはビジネスロジックではない
スケジューリング、リトライ、可観測性、依存関係解決はインフラの問題です。重要ですが、アプリケーションのビジネスロジックそのものではありません。
オーケストレーターがビジネスロジックを自分のフレームワーク内に書かせると、関心が混ざります。ETL は Airflow のタスク抽象に絡まり、機械学習パイプラインはオーケストレーターのクラス階層に絡まります。移行したくなったとき、スケジューリング層の置き換えではなく、そこに育ったビジネスロジックの書き換えになります。
よいオーケストレーターはコードの外側にあります。コードを呼び、監視し、再起動し、報告します。コードを侵食しません。その境界は OS がすでに持つ、コマンド、引数、stdin、stdout、終了コードです。
結論
Cron は小さすぎ、Airflow は大きすぎます。その間こそ、多くのチームが実際に働いている場所です。
Dagu はそこに合う形をしています。賢すぎるからではなく、賢すぎようとしないからです。ディスク上のファイル。YAML の中のコマンド。単一バイナリ。自分でホストしなくてよい UI。必須のデータベースもブローカーもフレームワークも、言語ロックインもありません。
地味に聞こえるなら、それでよいのです。ワークフローオーケストレーションは地味であるべきです。既存のスクリプトを指して動かしてみれば、自分たちの空白に合うかどうかは 1 時間で分かります。
執筆者
Dagu を開発中。信頼性と移植性のある自動化のためのセルフホスト型ワークフローオーケストレーションエンジン。
Yota Hamada のその他の記事