PoC 手順
本番採用の前に、自社環境で確認する手順です。二重化の確認には、本番と同じ種類の共有ストレージを使ってください。
1. 準備
| 項目 | 内容 |
|---|---|
| ホスト | Linux 2 台 (二重化を確認する場合) |
| 共有ストレージ | NFS、hard,actimeo=0 でマウント |
| 時刻同期 | NTP または chrony |
| 対象のジョブ | 代表的なジョブネットを 3 から 5 個。依存関係のあるもの、休日を考慮するもの、失敗時の対応があるものを含めます。 |
| Dagu のバージョン | 2.26.0 より後のリリース |
2. インストール
高可用性の手順で、両方のホストにサービスを構成します。
3. 確認項目
3.1 ジョブ
既存の定義を YAML に書き換え、次を確認します。
| # | 確認内容 | 方法 | 合格基準 |
|---|---|---|---|
| 1 | 定義が正しい | dagu validate | エラーがない |
| 2 | スケジュールどおりに動く | dagu calendar fires と実際の実行 | 既存製品と同じ時刻に動く |
| 3 | 依存関係のとおりに動く | Web UI で確認 | 順序が既存製品と同じ |
| 4 | 失敗時の処理が動く | ステップをわざと失敗させる | handler_on.failure が動く |
| 5 | 再実行できる | dagu retry | 失敗したステップから再実行される |
| 6 | 運用担当者の権限 | operator ロールでログイン | 実行と停止はでき、定義は編集できない |
3.2 フェイルオーバー
毎分動く DAG を用意し、次の順で確認します。
yaml
type: graph
schedule: "* * * * *"
steps:
- id: record
run: date -u +%FT%TZ| # | 障害の種類 | 方法 | 合格基準 |
|---|---|---|---|
| 1 | 通常の停止 | sudo systemctl stop dagu-scheduler | 10 秒以内に、もう一方がアクティブになる |
| 2 | プロセスの強制終了 | sudo kill -9 "$(systemctl show -p MainPID --value dagu-scheduler)" | 45 秒以内に、もう一方がアクティブになる |
| 3 | ホストの電源断 | 仮想マシンを強制停止 | 45 秒以内に、もう一方がアクティブになる |
| 4 | ネットワークの遮断 | アクティブのホストで NFS への通信を 60 秒遮断 | 45 秒以内に、もう一方がアクティブになる。遮断されたホストのスケジューラは終了し、再起動後にスタンバイになる |
| 5 | NFS サーバーの再起動 | NFS サーバーを再起動 | 復旧後、アクティブが 1 台になる |
各試験の後、次を確認します。
bash
dagu history 〈DAG 名〉 --last 1h| 確認内容 | 合格基準 |
|---|---|
| 同じ時刻のスロットが 2 回実行されていない | 重複なし |
| 引き継ぎの間のスロットが実行されている | 回復ウィンドウ (既定 2 分) の範囲で欠落なし |
| アクティブが 1 台だけ | /health?role=active が 200 を返すホストが 1 台 |
3.3 バックアップと復旧
| # | 確認内容 | 合格基準 |
|---|---|---|
| 1 | 手順でバックアップを取得 | 完了する |
| 2 | 別のホストの同じパスに復旧 | 実行履歴が表示される |
| 3 | シークレットを使うジョブを実行 | 成功する |
3.4 アップグレード
手順に従って更新し、途中でスケジュールが止まらないことを確認します。
3.5 負荷
本番で想定する同時実行数で動かし、メモリ、CPU、ディスク、inode の使用量を記録します。実測値と比較してください。
4. 判定
| 区分 | 結果 | 備考 |
|---|---|---|
| ジョブ | 〈合格 / 不合格〉 | |
| フェイルオーバー | 〈合格 / 不合格〉 | |
| バックアップと復旧 | 〈合格 / 不合格〉 | |
| アップグレード | 〈合格 / 不合格〉 | |
| 負荷 | 〈合格 / 不合格〉 |
5. 本番までに決めること
- 再実行の判断基準
- 監視と通報の先
- バックアップの頻度と保管先
- バージョンアップの周期
- サポートの範囲 (サポート方針を参照)