Airflow 代替
Airflow が重すぎるなら、オーケストレーションを OS に近い場所へ戻す。
Dagu は、Python フレームワークや重いメタデータ基盤を持たずに、スケジュール、リトライ、依存関係、ログ、UI を求めるチーム向けです。
name: nightly-ops
schedule: "0 2 * * *"
steps:
- id: extract
run: python scripts/extract.py
- id: transform
run: ./bin/transform
retry_policy:
limit: 3
depends: [extract]
- id: notify
run: ./scripts/slack-success.sh
depends: [transform]Python DAG フレームワーク不要
開始時にメタデータ DB 不要
既存スクリプトやコンテナを直接実行
必要時だけ worker へ拡張
一目で比較
スクリプト中心チームにとっての Airflow vs. Dagu
コマンドを呼ぶ宣言的 YAML。
Python DAG 定義と operator 抽象。
単一バイナリとローカルファイルから開始。
Scheduler、webserver、metadata DB、executor 選定が必要。
運用自動化、スクリプト、コンテナ、Agent CLI、軽量パイプライン。
Airflow エコシステムが生きる大規模データ基盤ワークフロー。
詳細
それぞれの強みと向き不向き
ワークフロー境界をコマンドに置く
Airflow は強力ですが、多くのチームは既存コードを動かしたいだけです。Dagu はビジネスロジックをスクリプト側に残します。
- Python、Bash、Java、Go、PHP、コンテナ、HTTP、SSH を実行
- 専用 operator への変換を避ける
- 運用者にも読みやすい YAML を保つ
必要になるまで基盤を増やさない
Dagu はファイルベースの 1 バイナリから始まり、必要になったときだけキューや worker を追加できます。
- まずローカルで試してから展開を考えられる
- アップグレードやバックアップを単純化できる
- 1 台で足りなくなるまで分散構成を持ち込まない
混在したエンジニアリング作業に向く
運用ジョブ、ETL、AI タスク、レポート、自動化は 1 つの言語やフレームワークに収まりません。
- 各ステップが既存ランタイムを使える
- スケジュールとリトライをアプリ外で管理できる
- チーム横断で持ち運べるオーケストレーションを保てる
FAQ
Dagu を導入する前によくある質問
Dagu はあらゆる Airflow 導入の完全代替ですか？
いいえ。Airflow には大きなデータ基盤向けの強いエコシステムがあります。既存の仕事がスクリプトやコンテナ、サービス呼び出しで動く場合に Dagu が向いています。
データパイプラインも動かせますか？
はい。コマンド、コンテナ、HTTP、SSH、SubDAG で表現できるなら実行できます。Dagu はフレームワーク特有のデータ抽象ではなくオーケストレーションに集中します。
分散実行に対応していますか？
はい。ローカル、キュー、coordinator-worker の各モードに対応しています。
次の一歩
まず 1 つのワークフローから。
Dagu をインストールし、不安定なスクリプトやエージェントタスクを 1 つ YAML に移して、実際の実行履歴を見て判断できます。