Systemd 타이머 vs. Cron: 올바른 스케줄러 선택하기

Linux 서버에서 백업, 정리, 상태 확인 또는 보고서를 정기적으로 실행해야 할 때 일반적으로 cron과 systemd 타이머 중에서 선택합니다. Cron은 여전히 간단하고 이식성이 뛰어납니다. Systemd 타이머는 작업이 관리되는 서비스처럼 동작하고 로그, 종속성 또는 리소스 제어가 필요할 때 더 적합합니다.

올바른 선택은 실행 중인 시스템, 작업의 실패 동작 및 필요한 운영 가시성 수준에 따라 달라집니다.

Cron 작업 이해하기

cron은 Unix 계열 운영 체제의 시간 기반 작업 스케줄러입니다. 사용자는 고정된 시간, 날짜 또는 간격으로 명령이나 스크립트를 주기적으로 실행하도록 예약할 수 있습니다. cron 데몬(crond)은 백그라운드에서 실행되며 예약된 작업이 있는지 crontab 파일을 확인합니다.

Cron 작동 방식

각 사용자는 crontab 명령으로 관리되는 고유한 crontab 파일을 가질 수 있습니다. 시스템 전체 작업은 일반적으로 /etc/crontab 또는 /etc/cron.d/ 내의 파일에 구성됩니다.

crontab 항목은 특정 형식을 따릅니다:

* * * * * 실행할_명령어
│ │ │ │ │
│ │ │ │ └───── 요일 (0 - 6) (일요일=0 또는 7)
│ │ │ └─────── 월 (1 - 12)
│ │ └───────── 일 (1 - 31)
│ └─────────── 시 (0 - 23)
└───────────── 분 (0 - 59)

예시: 매일 오전 2시에 백업 스크립트를 실행하려면:

0 2 * * * /usr/local/bin/backup.sh

Cron의 장점

보편성: 거의 모든 Unix 계열 시스템에서 사용 가능합니다.
간단한 구문: crontab 형식은 기본적인 스케줄링에 비교적 배우기 쉽습니다.
사용자별 작업: 개별 사용자를 위한 작업을 쉽게 설정할 수 있습니다.

Cron의 단점

제한된 유연성: 주로 고정된 시간 간격을 기반으로 합니다. 복잡한 종속성이나 이벤트 기반 스케줄링을 처리하기 어렵습니다.
종속성 관리 부재: 다른 작업이 성공적으로 완료된 후에만 실행되도록 정의하기 어렵습니다.
리소스 제어 부재: 예약된 작업이 소비하는 리소스(CPU, 메모리)를 거의 제어할 수 없습니다.
로깅 및 모니터링: 종종 명령에서 메일 출력, syslog 또는 명시적인 리디렉션에 의존합니다.
유닛 파일 통합: systemd의 서비스 관리 기능과 직접 통합되지 않습니다.

Systemd 타이머 이해하기

systemd 타이머는 systemd의 유닛 파일 기능을 활용하여 작업을 예약하는 더 발전되고 유연한 방법입니다. 별도의 데몬 대신 systemd 타이머는 systemd init 시스템 자체의 일부로 관리됩니다.

Systemd 타이머 작동 방식

systemd 타이머는 두 개의 유닛 파일로 구성됩니다:

서비스 유닛 (.service): 실행할 작업 또는 명령을 정의합니다.
타이머 유닛 (.timer): 해당 서비스 유닛이 활성화되어야 하는 시기를 정의합니다.

이러한 파일은 일반적으로 /etc/systemd/system/ 또는 ~/.config/systemd/user/에 위치합니다.

예시: 매일 오전 3시에 정리 스크립트를 실행하도록 예약합니다.

먼저 서비스 파일(cleanup.service)을 생성합니다:

# /etc/systemd/system/cleanup.service

[Unit]
Description=매일 정리 작업

[Service]
Type=oneshot
ExecStart=/usr/local/bin/cleanup.sh

다음으로 타이머 파일(cleanup.timer)을 생성합니다:

# /etc/systemd/system/cleanup.timer

[Unit]
Description=매일 정리 작업 실행

[Timer]
# 부팅 후 25분 후, 그 다음 매일 오전 3시에 실행
OnBootSec=25min
OnCalendar=*-*-* 03:00:00
# 대안: 마지막 실행 후 24시간 후에 실행
# OnUnitActiveSec=24h

[Install]
WantedBy=timers.target

이 파일들을 생성한 후 systemd를 다시 로드하고, 향후 부팅 시 타이머를 활성화한 후 지금 시작합니다:

sudo systemctl daemon-reload
sudo systemctl enable cleanup.timer
sudo systemctl start cleanup.timer

다음 명령을 사용하여 타이머의 상태와 다음 트리거 시간을 확인할 수 있습니다:

sudo systemctl status cleanup.timer

주요 `systemd` 타이머 지시어:

OnCalendar=: 캘린더 이벤트 시간을 지정합니다(cron 구문과 유사하지만 더 강력함).
- *-*-* 03:00:00: 매일 오전 3시.
- Mon..Fri *-*-* 09:00:00: 평일 오전 9시.
- hourly: 매시간.
- daily: 하루에 한 번.
- weekly: 일주일에 한 번.
- monthly: 한 달에 한 번.
- yearly: 1년에 한 번.
OnBootSec=: 시스템 부팅 후 지정된 시간 후에 트리거됩니다.
OnUnitActiveSec=: 해당 유닛(서비스)이 마지막으로 활성화된 후 지정된 시간 후에 트리거됩니다.
OnUnitInactiveSec=: 해당 유닛(서비스)이 비활성화된 후 지정된 시간 후에 트리거됩니다.
AccuracySec=: 타이머의 정밀도입니다. 값이 낮을수록 더 많은 전력을 소비할 수 있습니다.
Persistent=: 캘린더 타이머의 경우 true로 설정하면 시스템이 꺼져 있는 등 타이머가 비활성화된 동안 예약된 실행이 누락된 경우 systemd가 따라잡도록 합니다.

Systemd 타이머의 장점

systemd와의 통합: systemd의 서비스 관리, 로깅(journalctl), 리소스 제어 및 종속성 관리와 완벽하게 통합됩니다.
유연성: 고정된 간격 외에도 캘린더 이벤트, 부팅 후 상대 시간, 이전 활성화 후 상대 시간 등 다양한 스케줄링 옵션을 지원합니다.
종속성 관리: 다른 systemd 유닛(예: 네트워크 가용성)에 대한 종속성을 정의할 수 있습니다.
리소스 제어: 리소스 제한(CPU, 메모리)을 위해 systemd의 cgroups를 활용할 수 있습니다.
로깅: 포괄적이고 중앙 집중식 로깅을 위해 journald와 통합됩니다.
오류 처리: Restart=, OnFailure=와 같은 서비스 유닛 동작과 해당 패턴이 작업에 적합한 종속성 순서를 사용할 수 있습니다.
상태 인식: 작업이 실행되어야 했던 시기를 추적하고 Persistent=true가 설정된 경우 시스템 시작 시 실행할 수 있습니다.

Systemd 타이머의 단점

가파른 학습 곡선: systemd 유닛 파일 구문과 개념은 초보자에게 cron보다 더 복잡할 수 있습니다.
Systemd 종속성: systemd를 실행하는 시스템이 필요합니다(대부분의 최신 Linux 배포판은 그렇습니다).

Systemd 타이머 vs. Cron: 주요 차이점 요약

기능	Cron 작업	Systemd 타이머
관리	`crontab` 명령, 시스템 파일	`systemctl` 명령, 유닛 파일
스케줄링	고정된 분, 시, 일, 월, 요일	캘린더 이벤트, 상대 시간, 부팅 기반
통합	독립형 데몬	`systemd`와 통합
로깅	메일, 스크립트 리디렉션	`journald`
종속성	없음	`systemd` 유닛 종속성
리소스 제어	없음	`systemd` cgroups
오류 처리	기본	서비스 유닛 실패 처리
상태 추적	제한적	`Persistent=` 옵션
복잡성	기본 작업에 더 간단함	더 강력하지만 학습 곡선이 가파름

각 스케줄러를 선택해야 하는 경우

Cron을 선택해야 하는 경우:

systemd를 사용하지 않는 매우 오래되었거나 최소한의 시스템에서 작업하는 경우.
고정된 반복 일정으로 매우 간단한 일회성 작업을 예약해야 하고 고급 기능보다 단순성을 우선시하는 경우.
자체 로깅 및 오류를 처리하는 명령에 대한 빠른 일정이 필요한 경우.

Systemd 타이머를 선택해야 하는 경우:

systemd를 사용하는 최신 Linux 배포판에서 작업하는 경우.
작업이 실행되는 시기를 더 많이 제어해야 하는 경우(예: 부팅 기준, 마지막 실행 기준, 네트워크 연결 후).
더 나은 로깅, 모니터링 및 오류 처리가 필요한 경우.
리소스 제어 및 종속성 관리를 포함한 systemd의 강력한 서비스 관리 기능으로 작업 실행을 관리하려는 경우.
이미 systemd로 다른 서비스를 관리하고 있으며 일관된 스케줄링 방식을 원하는 경우.
작업이 다른 시스템 서비스나 이벤트에 종속된 경우.

실용적인 경험 법칙

작업이 짧고 명확한 명령이며 이식성이 중요할 때 cron을 사용하십시오. 작업이 서비스의 일부이거나, journalctl 로그가 필요하거나, 네트워크를 기다리거나, 리소스 제한 및 종속성 순서 지정의 이점을 얻을 수 있을 때 systemd 타이머를 사용하십시오.

야간 백업이 좋은 예입니다. 소규모 레거시 서버에서는 0 2 * * * /usr/local/bin/backup.sh로 충분할 수 있습니다. systemd 기반 프로덕션 호스트에서는 backup.service와 backup.timer를 통해 더 명확한 상태, 로그, Persistent=true를 사용한 부팅 후 따라잡기, 그리고 나중에 종속성을 추가할 수 있는 더 깔끔한 경로를 제공합니다.