▲

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

 (endpointdev.com)
4P by GN⁺ 5일전 | ★ favorite | 댓글 2개
  • 리눅스 서버에서 일광 절약 시간제(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 환경에서 시간대 관리와 자동화 신뢰성 확보는 필수 과제
▲
semjei 4일전  [-]

저도 새벽2시에 걸어놓은 작업에 문제 (한번은 두번 실행되고 한번은 실행되지 않고) 생긴뒤로는 꼭 피하고 있습니다.

답변달기
▲
GN⁺ 5일전  [-]
Hacker News 의견

  • DST(일광 절약 시간제) 는 완전히 잘못된 제도라고 생각함
    아무런 문제도 해결하지 못하고 오히려 불편만 초래함
    그냥 표준시(겨울 시간) 으로 고정하고, 대신 근무 시간을 여름 시간대처럼 한 시간 앞당기면 됨
    예를 들어 가게를 7시 대신 6시에 열고 10시 대신 9시에 닫는 식임
    어차피 1년에 두 번씩 적응 기간이 있으니, 한 번만 바꾸면 됨
    나는 퇴근 후에 햇빛을 더 보고 싶음. 겨울에는 특히 더 그렇고, 출근길에 해가 떠 있는 건 상관없음
    실내에 9시간 갇혀 있을 테니까, 자유 시간이 있을 때 햇빛을 보고 싶음

    • 모두가 DST를 싫어하지만, 제안된 대안들은 이미 시도된 적이 있음
      예를 들어 1973~1975년 미국의 연중 DST 실험이 있었음
      처음엔 에너지 절약과 범죄 감소 등의 이유로 찬성 여론이 높았지만,
      어두운 아침 통학길 사고로 여론이 급격히 악화되어 결국 폐지되었음
      (Wikipedia 인용)
    • 시계를 옮기지 말고 영업시간을 바꾸자는 건 결국 같은 효과를 내는 것 아닌가 하는 의문이 있음
      결국 더 큰 시간 이동을 원한다는 말처럼 들림
    • ‘겨울 시간’이라는 용어는 사실 존재하지 않음
      표준시와 일광 절약 시간만 있을 뿐임
      ‘겨울 시간’을 항상 유지하자는 표현은 심리적으로 매력적이지 않음
    • DST는 단순히 태양이 뜨는 시각에 맞추려는 임시방편일 뿐임
      사람들은 해가 떠 있을 때 하루를 시작하길 원함
      프로그래머들이 DST 때문에 고생하지만, 그건 엣지 케이스 처리를 잘 해야 하는 문제라고 생각함
    • 표준시냐 일광 절약 시간이냐의 논쟁은 결국 근무 시간 선택의 자유가 부족해서 생기는 문제임
      사람마다 수면 패턴이 다르니, 각자 맞는 근무 시간을 선택할 수 있으면 갈등이 줄어들 것임

  • 예전에 reddit 서버를 세팅할 때, 전부 Arizona 시간대로 설정했음
    Arizona는 DST를 사용하지 않아서, 캘리포니아와 1시간 차이만 있음
    UTC를 쓰지 않은 이유는 로그를 읽을 때 ‘8을 빼는 것보다 1을 빼는 게 쉽기 때문’이었음
    지금은 글로벌 팀이 생겨서 UTC로 바꾼 상태임

    • 비슷한 결정을 한 적이 있는데, 나중에 정리하느라 고생했음
      처음부터 전부 UTC로 통일하는 게 좋음
    • 하지만 Arizona처럼 시간대 정의가 바뀔 위험도 있음
      전 세계적으로 이런 변경이 자주 일어나서, 캘린더 앱 개발자 입장에서는 정말 골치 아픈 일임
    • 로그 뷰어 UI가 브라우저 언어 설정으로 12/24시간 형식을 강제하는 게 불만임
      UTC를 선택했으면 YYYY-MM-DD 24시간 형식을 이해할 줄 안다고 가정해야 함
    • Java에서는 JVM 단위로 기본 시간대를 설정할 수 있는데,
      조직 내에서 각자 PST로 바꿔 쓰다 보니 로그마다 시간이 달라지는 혼란이 생겼음
      결국 리더가 나서서 모든 애플리케이션과 DB를 PST로 통일시킴
    • UTC로 로그를 읽을 때 날짜가 바뀌지 않는 점은 여전히 헷갈림
      그래도 이제는 본능적으로 UTC를 해석하게 되었음

  • 예전에 회사 서버를 BST(영국 여름 시간) 으로 설정하고 cron을 많이 썼는데,
    매년 두 번씩 혼란이 반복되었음
    결국 회사가 망할 때까지 고치지 못했음
    교훈은 간단함 — UTC를 써라, 특별한 이유가 없다면

    • 책상 위에 UTC 아날로그 시계를 두고 로그를 볼 때 참고함
    • 고객이 UTC에 있지 않다는 이유로 현지 시간대를 쓰는 경우도 있음
      예를 들어 사용량 제한 리셋이나 청구 배치 작업은 지역 시간 기준으로 돌아감
    • cron 자체를 쓰지 말고, 데이터와 고객 설정을 인식하는 스케줄러를 쓰는 게 낫다고 생각함
    • 어떤 보고서는 현지 시간 기준으로 필요함
      예를 들어 영국 8시 보고서는 DST에 따라 UTC 기준이 달라짐
      따라서 UTC만으로는 해결되지 않으며, 시간대 정보를 함께 저장해야 함
    • 금융권처럼 시장 개장 시간이 중요한 경우에는 UTC만으로는 부족함

  • 일부 국가(Cuba, Egypt, Lebanon)는 DST 변경이 자정에 일어남
    (관련 링크)

    • DST 변경이 자정이 아닌 곳도 있다는 게 놀라웠음
      브라질에서는 00:00~01:00 또는 00:00~23:00에 바뀌는 게 일반적이었음
    • 시간대 규칙은 정말 예측 불가능한 일을 많이 함

  • DST 조정일에는 사망률과 응급실 방문이 급증한다는 연구가 있음
    (ScienceAlert 기사)
    단순히 cron 문제를 넘어서, DST는 건강에도 해로운 제도임

  • 이 문제는 오래전에 OpenBSD와 Debian에서 이미 해결된 적이 있음
    Debian의 cron(8) 매뉴얼에는 DST 조정 시 3시간 미만의 시간 이동 처리 로직이 설명되어 있음
    (패치 링크,
    매뉴얼,
    버그 리포트)

    • 그렇다면 원문 작성자는 이 패치가 적용되지 않은 배포판을 쓴 것 같음

  • 자정(00:00) 에 작업을 예약하지 말라는 조언임
    날짜가 헷갈리기 쉬우니 00:01이나 01:45처럼 어정쩡한 시각을 쓰는 게 좋음

    • 나도 cron 작업을 XX:13, XX:23, XX:42처럼 설정함
      시스템이 특정 시각에 이상해질 때 원인을 추적하기 쉬움
    • 00:00이 문제된 적은 거의 없었음
      다만 12시간제 시계를 쓰는 환경에서는 혼란이 생길 수 있음

  • 시간대 문제를 겪기 전까지는 몰랐는데,
    세상에는 존재하지 않는 시각과 모호한 시각이 있음
    예를 들어 2시에서 3시로 넘어갈 때 2:30은 존재하지 않고,
    반대로 시간을 되돌릴 때는 2:30이 두 번 생김
    국가마다 DST 조정 시각이 달라서, Chile처럼 자정이 사라지는 경우도 있음
    (관련 블로그)
    Java와 Ruby가 이 상황을 다르게 처리해서, Stripe 근무 초기에 3번 연속 사고를 냈던 기억이 있음

  • cron 작업은 정각을 피하고, 가능하면 새벽 4시 이후나 자정 이전에 설정함
    공유 인프라에서는 정각에 리소스 경쟁이 심하기 때문임

    • systemd의 RandomizedDelaySec 옵션을 쓰면 충돌을 줄일 수 있음
    • cron 명령 앞에 sleep $(( $(od -N1 -tuC -An /dev/urandom) % 60 ))m ;
      같은 코드를 붙여서 0~59분 랜덤 지연을 주는 것도 좋은 방법임

  • 중요한 예약 작업은 가능하면 idempotent(중복 실행 안전) 하게 만들어야 함
    특히 큐 시스템이 얽혀 있을 때 이런 설계가 문제 예방의 핵심임

답변달기