피드로 돌아가기
A Cron Job Took Our Server to Load 41 by Attacking Itself
Dev.toDev.to
Infrastructure

flock-n 도입을 통한 Cron Job 중복 실행 방지 및 Load 41 장애 해결

A Cron Job Took Our Server to Load 41 by Attacking Itself

Anguishe2026년 6월 23일5intermediate

Context

1분 간격의 rsync 작업이 NFS 지연으로 인해 실행 시간이 20초에서 90초로 증가하며 프로세스가 누적된 상황. Cron의 상태 비저장 특성으로 인해 이전 작업 완료 여부와 무관하게 새 프로세스가 생성되어 서버 Load Average 41에 이르는 자가 공격(Self-attack) 발생.

Technical Solution

  • PID 파일 기반 락킹의 한계(Race Condition 및 프로세스 강제 종료 시 고립된 락 파일 잔류)를 극복하기 위한 Kernel-level File Descriptor Lock 채택
  • exec 200>/run/lock/job.lock 구조를 통해 파일 디스크립터에 락을 할당하여 프로세스 종료 시 커널이 자동으로 락을 해제하는 무상태 설계 구현
  • flock -n 옵션을 사용하여 락 획득 실패 시 대기 없이 즉시 종료함으로써 프로세스 큐잉 현상 원천 차단
  • /run/lock(tmpfs) 경로 활용을 통해 재부팅 시 잔류 락 파일이 자동으로 제거되는 환경 구축
  • 기존 배포된 스크립트 수정 없이 flock 명령어로 래핑하여 즉각적인 Hot-fix 적용 가능 구조 설계

- Cron 작업의 실행 간격보다 최대 처리 시간이 길어질 가능성이 있는가? - PID 파일 대신 커널이 관리하는 `flock`을 사용하여 락 해제 보장책을 마련했는가? - 락 획득 실패 시 대기(`-w`) 대신 스킵(`-n`)을 선택하여 프로세스 누적을 방지했는가? - 무한 락 상태를 방지하기 위해 `timeout` 설정과 재시도 전략을 결합했는가?

원문 읽기