2:00시와 3:00시 크론 작업을 피하라 (2013)

• 리눅스 서버에서 일광 절약 시간제(DST) 전환 시 발생하는 크론(cron) 작업 오류를 경고하는 글
• 매년 두 번, 일요일 새벽 2시 또는 3시에 시간대가 변경되면서 크론 작업이 중복 실행되거나 누락되는 문제 발생
• 실제 사례로, vixie-cron 환경에서 3:00~3:01 사이 작업이 1초 간격으로 60회 반복 실행되어 이메일 혼잡 발생
• 해결책으로 UTC 시간대 설정 또는 해당 시간대 작업 회피, 더 나은 오픈소스 스케줄러 개발 제안
• 서버 운영자와 DevOps 엔지니어에게 시간대 전환 리스크 관리의 중요성을 상기시키는 사례

일광 절약 시간제와 크론 작업의 충돌

• 일요일 새벽 2시 또는 3시에 크론 작업을 설정하면 일광 절약 시간제(DST) 전환 시점과 겹쳐 예기치 않은 실행 오류 발생
  • DST 시작 시 시계가 한 시간 앞으로 이동하거나, 종료 시 한 시간 뒤로 이동하면서 시간 중복 또는 누락 현상 발생
  • 이로 인해 특정 시간대의 작업이 두 번 실행되거나 아예 실행되지 않는 문제가 생김
• 특히 매주 일요일 새벽에 실행되는 작업은 연 2회 DST 전환 시점에 영향을 받음
  • 일반적으로 문제없이 동작하지만, DST 전환일에는 비정상적인 반복 실행이 발생할 수 있음

실제 사례: vixie-cron의 반복 실행 문제

• Linux 환경의 vixie-cron에서 DST 시작 시 3:00~3:01 사이 작업이 1초 간격으로 약 60회 실행된 사례 보고
  • 각 작업이 서로 충돌하며 이메일 알림 폭주와 같은 혼란 발생
  • 다행히 해당 작업이 치명적이지 않아 시스템 손상은 없었음
• 이러한 문제는 크론의 단순한 시간 기반 스케줄링 구조에서 비롯됨
  • 크론은 시간대 변경이나 DST 전환을 인식하지 못하고, 단순히 지정된 시각에 맞춰 실행

가능한 해결책과 대안

• 가장 간단한 방법은 일요일 새벽 2시와 3시 시간대에 작업을 설정하지 않는 것
  • 해당 시간대를 피하면 DST 전환으로 인한 중복 실행 문제를 완전히 회피 가능
• 서버의 시간대를 UTC로 설정하는 것도 효과적인 대안
  • UTC는 일광 절약 시간제를 적용하지 않으므로 시간 변경이 발생하지 않음
• 더 근본적인 해결책으로는 보다 지능적인 작업 스케줄러 개발 제안
  • 중복 실행 방지, 실행 시간 제한, 시간대 인식 기능 등을 갖춘 오픈소스 대체 도구 필요

장기적 제안: 일광 절약 시간제 폐지

• 글의 저자는 정부 차원의 DST 폐지를 가장 바람직한 해결책으로 제시
  • 매년 두 번의 시간 변경이 시스템 운영과 인간 생활 모두에 불필요한 복잡성을 초래
• 그러나 현실적으로 DST가 유지되는 한, 시스템 관리자와 DevOps 엔지니어가 예방 조치를 취해야 함
  • 특히 자동화된 배치 작업, 백업, 로그 회전 등 시간 의존적 작업 관리에 주의 필요

결론: 안전한 크론 스케줄링 원칙

• DST 전환 시점의 2:00~3:00 시간대 작업은 피해야 함
• 가능하면 UTC 기반 서버 운영으로 시간대 문제를 제거
• 크론의 한계를 인식하고, 보다 견고한 스케줄링 도구 도입 검토 필요
• DevOps 환경에서 시간대 관리와 자동화 신뢰성 확보는 필수 과제