Cronを超えて：なぜsystemd Timersを使うべきなのか

数十年にわたり、Unix系システムにおけるスケジュールされたタスクのゴールドスタンダードは「cron job」でした。それはあまりに根本的なコンピューティングのプリミティブであるため、実際に実行しているデーモンに関わらず、ほぼすべてのスケジュールされたアクションを「cron job」と呼ぶほど、その言葉自体が代名詞となっています。しかし、システム管理が進歩するにつれ、従来のcronの限界がより明白になってきました。

現代のLinuxエコシステムにおいて、systemd timersは、cronの欠点を解消しつつ、以前は実装が困難または不可能であった機能を導入する、強力で統合された代替手段を提供します。もしあなたがまだcrontabに頼っているなら、今こそ移行すべき理由がここにあります。

従来のCronの限界

cronはシンプルで成熟していますが、プロフェッショナルな環境では摩擦を生じさせることがよくあります。一般的な問題点は以下の通りです：

環境の曖昧さ: cronにおける$PATH設定は予測不能なことがあり、シェルでは動作するがデーモンによって実行されると失敗するスクリプトの原因となります。
出力の「ブラックホール」: デフォルトでは、stdoutとstderrは失われるか、ほとんど監視されないローカルメールシステムに送信されることがよくあります。あるコミュニティメンバーが指摘したように、多くの管理者はsyslogでの可視性を確保するために、すべてをloggerにパイプで渡すという手段に訴えています。
不透明な実行履歴: ジョブが実行されたか、なぜ失敗したのか、あるいは最後にいつ実行されたのかを判断するには、バラバラなログを掘り起こす必要があります。
難解な構文: 強力ではありますが、cronのスケジューリング文法（例：01,31 04,05 1-15 1,6 *）は直感的ではなく、解読するために外部ツールを必要とすることがよくあります。

systemd Timersの仕組み

スケジュールとコマンドを一行にまとめるcronとは異なり、systemdはこれらを2つの別々のユニットに分離（デカップリング）します：Service unit (.service) と Timer unit (.timer) です。

1. Service Unit

Service unitは「何を」実行するかを定義します。これは、実行ファイルとその引数を指定する標準的なsystemd serviceファイルです。この分離により、デバッグのためにタイマーの起動を待たずに、systemctl startを介して手動でタスクをトリガーすることが可能になります。

2. Timer Unit

Timer unitは「いつ」サービスを実行するかを定義します。デフォルトでは、タイマーは同じ名前のサービスユニットを探します（例：backup.timerはbackup.serviceをトリガーします）。

高度なスケジューリング機能

systemd timersの最も大きな利点の一つは、そのスケジューリングロジックの柔軟性です。主に2つのタイプのトリガーをサポートしています：

カレンダーイベント

これらはcronの壁時計スケジュール（例：OnCalendar=daily）に似ています。しかし、systemdはより人間が読みやすい構文と、強力な検証ツールであるsystemd-analyze calendarを提供します。これにより、スケジュールをデプロイする前に、時間表現をテストして、次にいつ経過するかを正確に確認することができます。

モノトニックタイマー（相対時間）

これこそが、タイマーがcronを真に凌駕する部分です。壁時計ではなく、他のイベントからの相対的な時間でタスクをスケジュールできます：

OnBootSec=: システムの起動からX時間後に実行。
OnUnitActiveSec=: サービスが最後にアクティブになった後、X時間後に実行。

これは、/tmpのクリーニングのようなタスクに理想的です。システムスパイクが発生する可能性がある固定時刻ではなく、起動から1時間後に実行し、その後は1時間ごとに実行するという方が理にかなっています。

エンタープライズ級の機能

Systemd timersには、一般的な分散システムの課題を解決するいくつかの組み込み機能が含まれています：

「サンダリング・ハード」問題の解決

数千台のマシンがちょうど真夜中にタスクを実行するようにスケジュールされている場合、中央サーバーがクラッシュする可能性があります。SystemdはRandomizedOffsetSec=を使用することでこれを解決します。これは実行を均一な分布に分散させ、アップデートやチェックインがネットワークに一度に集中して負荷をかけるのを防ぎます。

永続性と信頼性

スケジュールされたイベントの期間中にマシンが電源オフになっていた場合、従来のcron jobは単にスキップされてしまいます。Persistent=trueを設定することで、systemdは最後にトリガーされた時間をディスクに保存します。もしタイマーが起動し、ダウンタイム中にスケジュールされた実行を逃したことが判明した場合、サービスを即座にトリガーします。

システム統合

WakeSystem=: タイマーは、重要なタスクを実行するためにシステムをサスペンド状態から復帰させるように設定できます。
Journal Integration: すべての出力は自動的にjournalctlによってキャプチャされ、中央集約化され、検索可能な、すべての実行の履歴を提供します。
Visibility: systemctl list-timersコマンドは、すべての稼働中のスケジュールを俯瞰的に表示し、各ジョブが最後にいつ実行され、次にいつ実行される予定かを正確に示します。

コミュニティの視点とトレードオフ

利点がある一方で、systemd timersへの移行には議論もあります。一部のユーザーは、crontab -lのシンプルさが失われると主張しています。タイマーは/etc/systemd/system/や/usr/lib/systemd/system/内のユニットファイルに分散しているためです。

他のユーザーは、ユニットファイルの構文が「醜い」あるいはcrontabの一行よりも実体感が乏しいと感じています。あるユーザーが指摘したように、初心者に対して、個別のサービスユニットとタイマーユニットという概念を概念的に説明することは、cronの一行を説明することよりも複雑です。

しかし、複雑なインフラストラクチャを管理している人々にとって、トレードオフの重みはsystemdに大きく傾いています。ネイティブな条件付き実行のためのExecCondition=を使用できる能力や、Ansibleのようなデップロイメントツールとの統合により、タイマーは本番環境においてより堅ロストな選択肢となります。

実装のためのサマリーチェックリスト

もしあなたがcronからsystemd timersへ移行するなら、以下のヒントを覚えておいてください：

systemd-analyze calendarを使用して、スケジュールを検証してください。
Persistent=trueを活用して、ダウンタイム中にスキップされてはいけないジョブに対して設定してください。
RandomizedOffsetSec=を使用して、ネットワークAPIや共有リソースに負荷をかけるタスクに対して設定してください。
systemctl list-timersを定期的にチェックして、システムのスケジューリングの健全性を監視してください。