JP1/AJS3 代替
マネージャー専用サーバーも、ノードごとのエージェントも、ノード単位ライセンスもなしでジョブを回す。
Dagu は、すでに自社サーバーでバッチを運用している情報システム部門向けの JP1/AJS3 代替です。ジョブネットは Git 上の YAML になり、マネージャー用データベースはなくなり、運用画面はブラウザになります。移行の進め方と、Dagu が向かない領域もこのページに書いています。
# nightly-closing.yaml
schedule: "0 2 * * *"
max_active_runs: 1
# Business-day calendar
preconditions:
- eval: "$(date +%u)"
expected: "re:[1-5]"
# Run on the business server without a resident agent
ssh:
user: batch
host: app01.corp.local
key: ~/.ssh/batch_key
steps:
- id: closing
run: /opt/batch/run-closing.sh
retry_policy:
limit: 2
interval_sec: 300
- id: transfer
run: /opt/batch/send-to-core.sh
depends: [closing]
# Recovery job
handler_on:
failure:
run: /opt/batch/recovery.sh
mail_on:
failure: true単一バイナリ、運用する DB なし
ライセンスは Dagu サーバー単位、ワーカーは無制限
ジョブネットはレビュー可能な YAML でバージョン管理
オンプレミスと閉域ネットワークで動作
一目で比較
情シスのバッチ運用における JP1/AJS3 と Dagu
状態をファイルに持つ単一バイナリ。キューとワーカーは任意。
マネージャー、ノードごとのエージェント、独自 DB を持つ基盤製品。
Git でレビューする宣言的 YAML。
GUI での定義が主で、テキストの出力と取り込みは補助的な経路。
OS を問わず使えるブラウザ UI と CLI。
運用担当ごとに導入する専用クライアント。
サーバー数無制限で無料。有償版は Dagu サーバー単位でワーカーは無制限。
ノード単位のライセンスと年間保守契約。
スケジューラーは単一インスタンス。可用性の設計は自社で組む。
クラスタ構成と待機系の実績がある。
コミュニティ Discord、有償プランはメールサポート。
日本語対応のベンダー保守契約。
詳細
それぞれの強みと向き不向き
ジョブネットの考え方は残し、運用コストだけ落とす
JP1/AJS3 はマネージャー、実行ノードごとのエージェント、専用の運用クライアントに分かれます。Dagu は同じスケジューリングの概念を、状態をファイルに持つ 1 プロセスの中に収めます。
- ジョブネットは DAG、ジョブはステップ、先行後続関係は depends に対応します
- リカバリージョブは handler_on.failure に相当します。再実行は同じ実行 ID なら dagu retry、新しい実行 ID なら dagu restart、スケジュールの停止は UI から DAG 単位で行えます
- スケジューラーと並べて維持するマネージャー用データベースがありません
移行は 1 ジョブネットグループから始める
自動の移行ツールはありません。長年積み上げた資産をワンクリックで変換できると言う製品があれば、それは誇張です。現実的な進め方は、パイロットで検証しながらスクリプトで変換することです。
- 既存のユニット定義をテキストで出力し、機械的に対応づけます。ユニットはステップ、先行後続はdepends、リカバリーユニットは handler_on.failure です
- 変換先がプレーンな YAML なので、変換処理は自社で持って何度でも流し直せるスクリプトになります。手作業での再登録ではありません
- 生成した定義は dagu validate にかけ、パイロット対象は既存製品と並行稼働させてから切り替えます
エージェントを入れずに既存サーバーへ届かせる
バッチ処理は多くの場合すでにあるサーバーの上にあります。Dagu は SSH でそれらを実行でき、常駐する実行基盤が要る場合はワーカーを配置します。
- SSH ステップで Linux や UNIX のホストを常駐エージェントなしに実行します
- セグメント化されたネットワーク内で動かす場合はコーディネーターとワーカーを配置します
- ノード単位のライセンスではなく、worker_selector でラベル付けしたワーカーにステップを割り当てます
運用担当と定義変更者を分ける
情シスでは、落ちたジョブを再実行する人と、その定義を変更する人を分ける必要があります。ロール、SSO、監査ログはライセンス版のセルフホストに含まれます。
- operator ロールは実行と停止はできますが定義は変更できません。viewer は参照のみ、developer と manager はワークフローを変更できます
- OIDC で既存の ID 基盤にログインを寄せられるため、利用者情報を二重管理せずに済みます
- 監査ログに管理操作とセキュリティ上重要な操作が記録されます
ノード単位ではない費用構造
コミュニティ版のセルフホストはサーバー数もワーカー数も無制限で、永続的に無料です。ライセンス版は実行ノードではなく Dagu サーバー単位の課金で、どのプランでもワーカーは無制限です。
- コミュニティ版でオーケストレーション本体、Web UI、cron スケジュール、Docker と SSH と HTTP のステップまで使えます
- ライセンス版のセルフホストはサーバーライセンス 3 つで年額 500 ドルから。SSO、RBAC、監査ログ、インシデント連携、メールサポートが付きます
- 実行ホストを増やす作業はワーカーを 1 つ起動することであり、ライセンス数は変わりません
Dagu のほうが不利な領域
良いところだけ並べた比較は検討の役に立ちません。JP1 を使っている組織が追加の作業を見込むべき、あるいは移行しないほうがよい領域です。
- スケジューラーは単一インスタンスで動きます。リーダー選出の仕組みは内蔵していないため、可用性の設計はプロセス監視と共有ストレージを含めて自社で組む必要があります
- サポートは無料版が Discord コミュニティ、有償プランが標準のメールサポートです。日本語での 24/365 保守契約に相当するものはありません
- JP1 は統合スイートです。監視や資産管理、全体運用まで依存している場合、Dagu が置き換えるのはジョブ管理の部分だけです
FAQ
Dagu を導入する前によくある質問
Dagu は JP1 をすべて置き換えられますか？
いいえ。JP1 は監視や資産管理、ベンダー保守契約まで含むスイートです。Dagu が置き換えるのはジョブ管理の部分で、ジョブがすでにスクリプト、バイナリ、コンテナ、サービス呼び出しになっており、自社で運用できる小さなランタイムを求める場合に向きます。
既存の定義を自動変換するツールはありますか？
ありません。あると謳う製品があれば疑ってください。変換を現実的にしているのは、変換先がプレーンな YAML だという点です。手元の定義を出力し、DAG ファイルを生成するスクリプトを書き、dagu validate で結果を確認します。データ移行ではなく開発作業として工数を見積もってください。
カレンダー定義や営業日ルールはどう移行しますか？
Dagu は cron 式でスケジュールし、preconditions で実行可否を判定します。営業日や月末の条件はワークフローまたはステップの条件として表現します。カレンダーを外部システムが持っている場合は、ステップからそれを取得して条件に使えます。
ファイル到着などの起動条件はどう置き換えますか？
主に 2 つの方法があります。wait 系のアクションでファイルの出現や HTTP エンドポイントの応答をステップとして待ってから後続に進める方法と、webhook で外部から実行を起動しペイロードをワークフローで参照する方法です。
多重度の制御はできますか？
同一ワークフローの同時実行数は max_active_runs、実行内の並列ステップ数は max_active_steps で制限します。複数のジョブでまとめて上限を共有したい場合は、名前付きキューに割り当てます。
閉域ネットワークでも動きますか？
はい。Dagu は外部データベースやブローカーを必須としない自己完結のバイナリなので、オンプレミスやインターネット非接続の環境でも動作します。分散実行も自社ネットワーク内のコーディネーターとワーカーの間の gRPC で完結します。
次の一歩
まず 1 つのワークフローから。
Dagu をインストールし、不安定なスクリプトやエージェントタスクを 1 つ YAML に移して、実際の実行履歴を見て判断できます。