【第5回】タスク自動化：cronとsystemd timerの実践：AlmaLinux 9/10環境対応

こんにちは！「LINUX工房」管理人の「リナックス先生」です。
前回の第4回では、systemd-journaldの仕組みとjournalctlコマンドを駆使した高度なログ管理・トラブルシューティング手法を学びました。
サーバーの監視やログ調査ができるようになったところで、今回はインフラ運用の効率を劇的に高める重要テーマを取り上げます。第5回は「タスク自動化：cronとsystemd timerの実践」です。

バックアップ、ログのクリーンアップ、定期的なバッチ処理など、サーバー管理におけるルーチンワークを人の手で行うことは、ヒューマンエラー（うっかりミス）の元です。今回は、AlmaLinux 9/10環境における伝統的な「cron」と、次世代の標準である「systemd timer」を使い分け、確実にタスクを自動化するプロの技術を徹底解説します。

コウ君

先生！毎日夜中にデータベースのバックアップを取る作業を、ついつい忘れそうになって冷や汗をかくんです……。こういう面倒な作業って、やっぱり自動で動かせるんですよね？

リナックス先生

当たり前でしょ、コウ君！インフラエンジニアの仕事の半分は「手作業（トイル）の撲滅」、つまり自動化よ。
Linuxには古くから愛用されている「cron」があるし、最新のAlmaLinux 9/10ではさらに強力な「systemd timer」という選択肢もあるわ。今日は、ただ自動化するだけじゃなくて、二重起動や実行漏れを防ぐプロのテクニックまでしっかり教えてあげるわね！

📚 本連載のカリキュラム（全8回）

1. Linuxインフラにおけるタスク自動化の重要性

24時間365日稼働するWebシステムにおいて、人間が手動で行わなければならない作業（ルーチンワーク）は、運用コストを増大させるだけでなく、重大なヒューマンエラーの温床となります。「夜間バッチの実行を忘れた」「古いログの削除を怠りディスクがフルになった」といったトラブルは、すべて適切なタスク自動化によって完全に防ぐことが可能です。

Linux環境には、古くから親しまれてきた軽量なスケジューラである cron と、近年のエンタープライズOSで標準となっている高度な systemd timer の2つの強力な選択肢が存在します。それぞれの特性を理解し、要件に応じて適切に使い分けるスキルがプロのインフラエンジニアには求められます。

2. 伝統的なcronの基礎知識と記述ルール

長年にわたり多くのLinuxディストリビューションで標準採用されてきたのが cron です。バックグラウンドで常駐する crond デーモンが、指定されたスケジュールに従ってコマンドやスクリプトを自動実行します。

Crontabの記述フォーマット

Cronの設定は crontab -e コマンドを用いて編集します。スケジュールは5つのフィールド（分・時・日・月・曜日）で定義します。

* * * * * 実行するコマンド
┬ ┬ ┬ ┬ ┬
│ │ │ │ │
│ │ │ │ └ 曜日 (0 - 7) (0と7は日曜日)
│ │ │ └─ 月 (1 - 12)
│ │ └─── 日 (1 - 31)
│ └───── 時 (0 - 23)
└─────── 分 (0 - 59)

実務で頻出する記述例

# 1. 毎日深夜3時30分にバックアップスクリプトを実行する
30 3 * * * /usr/local/bin/backup.sh

# 2. 毎時間15分ごとに一時ファイルのクリーンアップを実行する
15 * * * * /usr/bin/find /tmp -type f -mtime +1 -delete

⚠️ 初心者が必ずハマるCronの罠（パスの指定）
Cronは、ユーザーが普段ターミナルでログインしている環境（対話型シェル）とは全く異なる最小限の環境変数で実行されます。そのため、スクリプトやコマンドのパスは省略せず、すべて /usr/bin/php や /usr/local/bin/backup.sh のように絶対パスで記述することが鉄則です。

3. 次世代標準「systemd timer」のアーキテクチャとメリット

伝統的なcronは非常にシンプルで便利ですが、「実行結果のログ管理が不便」「サーバーがダウンしていた時間帯のジョブがスキップされてしまう」「リソース制限（CPU/メモリ上限）がかけられない」という弱点がありました。
これらを完全に克服した次世代の仕組みが systemd timer です。

systemd timerの仕組み

systemd timerでは、実際に処理を行う「サービス定義（.service）」と、実行タイミングを制御する「タイマー定義（.timer）」の2つのファイルを作成して連携させます。

# 1. サービス定義ファイル (/etc/systemd/system/db_backup.service)
[Unit]
Description=Database Backup Service

[Service]
Type=oneshot
ExecStart=/usr/local/bin/db_backup.sh
# リソース制限（CPU使用率を50%以内に抑える）
CPUQuota=50%
# 2. タイマー定義ファイル (/etc/systemd/system/db_backup.timer)
[Unit]
Description=Run Database Backup Daily

[Timer]
# 毎日午前3時30分に実行
OnCalendar=*-*-* 03:30:00
# サーバー停止等で実行できなかった場合、次回起動時に即座に実行する
Persistent=true

[Install]
WantedBy=timers.target

設定後は sudo systemctl enable --now db_backup.timer で有効化します。
Persistent=true を指定しておけば、メンテナンス等でサーバーを落としていた間にスルーされてしまったタスクを、再起動後に自動キャッチアップして実行してくれるため、エンタープライズ環境において極めて強力な武器となります。

PR

ITエンジニア1年生のための まんがでわかるLinux コマンド＆シェルスクリプト基礎編 [ Piro ]

価格:2420円
(2026/7/17 19:14時点)
感想(0件)

4. 実践：flockコマンドによるバッチ処理の二重起動防止

定期実行スクリプトを運用するうえで、プロが必ずと言っていいほど組み込む防衛策が「二重起動の防止」です。

コウ君

二重起動って、そんなに危ないものなんですか？何が起きるのかイメージできなくて……。

リナックス先生

想像してみてちょうだい。例えば「10分おき」に実行する重いデータ集計バッチがあったとするわね。もしある日、データが多すぎて処理に「15分」かかってしまったらどうなる？
1回目の処理が終わる前に、2回目のバッチが裏で同時に起動してしまうのよ！同じデータベースに対して同時に書き込みが走れば、データが破損（デッドロック）したり、サーバーのCPUが完全にパンクしたりするわ。

この惨事を防ぐために用いるのが、Linuxの flock（ファイルロック）コマンド です。

flockを用いた安全なcron設定例

# 10分おきに実行。すでにロックファイルが存在する場合は今回の実行をスキップ(-n)する
*/10 * * * * /usr/bin/flock -n /tmp/heavy_batch.lock /usr/bin/php /var/www/html/batch.php >> /var/log/heavy_batch.log 2>&1

flock -n を挟むだけで、「前の処理がまだ動いている最中であれば、今回の実行は見送る」という安全弁が機能し、システムの暴走を未然に防ぐことができます。

5. 【プロの視点】自動化スクリプト運用のベストプラクティス

タスク自動化を構築・運用するにあたり、プロの現場で共通して守られているベストプラクティスをいくつか紹介します。

  • 標準出力・エラーの必ず的確なリダイレクト： スクリプトが内部でエラーを出した際、出力先がないとcronはデフォルトでローカルメールを飛ばそうとしますが、メールサーバー未設定の環境ではログがゴミとして溜まります。必ず >> /path/to/logfile.log 2>&1 でファイルに集約しましょう。
  • systemd timerの積極的な活用： ログを journalctl で一元管理でき、リソース制限（CPUQuota等）や細やかな依存関係（ネットワークが確立してから実行等）を定義できるため、現代のAlmaLinux 9/10環境ではcronよりもsystemd timerの採用が推奨されます。
  • 失敗時の通知仕組み： スクリプトの終了コード（$?）を判定し、異常終了（exit 1等）が検知された場合にSlackやWebhookへエラー通知が飛ぶ例外処理を必ず実装します。

総まとめ：システムに自律的なメンテナンス性を宿す

第5回の解説、お疲れ様でした。

今回は、AlmaLinux 9/10における伝統的なcronの書き方、次世代のsystemd timerのアーキテクチャ、そしてflockコマンドによる二重起動防止と運用のベストプラクティスを網羅しました。
自動化を正しく設計・実装することで、サーバーは人間の手を借りずとも自律的にメンテナンスを行い、いつでも健全な状態を保ち続ける「手のかからない優秀なシステム」へと進化します。

次回、番外編的な重要テーマ、あるいは【第6回】確実なデータ保護：バックアップ戦略とrsync活用 では、システム障害やランサムウェアの脅威からデータを完全に守り抜くためのプロフェッショナルなバックアップ設計手法を深く掘り下げていきます。
お楽しみに！LINUX工房の「リナックス先生」でした。

▼ 【安定した自動化・バッチ処理基盤を構築しよう】 ▼

24時間バッチも安心の稼働率
「高コスパおすすめVPS」

VPSランキングを見る

自動化・インフラ運用スキルを武器に
「ITエンジニア専門転職」

転職エージェントを見る

コメント