エッセイ

Cron と Airflow の間にある空白

Cron は小さすぎ、Airflow は大きすぎる。多くのチームはその間で、bash スクリプトをつなぎ合わせたり、Python 前提のオーケストレーターと格闘したりしています。

Yota Hamada
シェア

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 時間で分かります。

· · ·

執筆者

Yota Hamada

Dagu を開発中。信頼性と移植性のある自動化のためのセルフホスト型ワークフローオーケストレーションエンジン。

Yota Hamada のその他の記事