예약 작업이 겹칠 때: 파일 존재 검사와 flock의 차이

정해진 시간마다 실행하는 수집·백업 작업이 평소보다 오래 걸리면 다음 실행 시각이 먼저 올 수 있다. 실행 간격을 늘리는 것만으로 모든 겹침을 막았다고 보기는 어렵다. 작업 시작을 허용할지 판단하는 장치를 두고, 실행하지 못한 회차를 어떻게 처리할지 정해야 한다.

시간을 재는 대신 겹치는 상태를 확정했다

이번 실험은 실제 cron이나 수집기를 수정하지 않았다. Python 자식 프로세스 두 개를 만들고 첫 번째가 작업 구간에 진입한 뒤 표준 입력을 기다리게 했다. 첫 프로세스가 끝나지 않은 상태에서 두 번째를 시작했으므로, 기계 속도와 짧은 sleep 타이밍에 기대지 않고 실행 겹침을 비교할 수 있었다. 두 프로세스는 같은 임시 로컬 파일을 열었다.

잠금을 쓰지 않는 경우에는 두 작업 모두 ENTER를 출력했다. flock의 배타 잠금과 비차단 옵션을 사용한 경우에는 첫 작업만 ENTER를 출력하고 두 번째는 SKIP으로 끝났다. 이 표시는 실험을 위한 약속이다. SKIP을 실제 작업 성공으로 해석해서는 안 된다.

파일이 있다는 것과 잠금을 잡고 있다는 것은 다르다

job.lock 파일이 보이면 작업 중이라고 간주하는 방식은 파일 자체를 상태 표시로 쓴다. 작업이 파일을 지우기 전에 종료되면 표시만 남을 수 있다. 존재 여부 확인과 생성 사이에 다른 작업이 끼어드는 문제도 따져야 한다. 이 글의 실험은 그 존재 검사 구현을 실행한 것은 아니며, 아래에서는 커널 잠금이 남은 파일과 어떻게 구분되는지 확인했다.

잠금을 가진 자식 프로세스를 os._exit(17)로 종료시켰다. 종료 후 job.lock 파일은 남아 있었지만 다음 프로세스는 잠금을 잡고 ENTER를 출력했다. 파일을 지워야 다시 시작할 수 있는 상태가 아니었다. 이번 자식은 잠금 파일 디스크립터를 다른 자식에게 넘기지 않았다. Linux 문서에 따르면 잠금과 연결된 모든 파일 디스크립터가 닫히는 조건이 중요하므로, 별도 하위 작업을 실행하는 구조에는 이 결과를 그대로 확대하면 안 된다.

작업 본문을 잠금이 살아 있는 범위 안에 둔다

import fcntl

def run_job():
    # 모든 실행이 동일한 로컬 파일을 사용해야 한다.
    with open('/tmp/example-job.lock', 'a') as lock:
        try:
            fcntl.flock(lock, fcntl.LOCK_EX | fcntl.LOCK_NB)
        except BlockingIOError:
            print('SKIP: previous run still active')
            return False
        # 이 범위 안에서 실제 작업을 동기적으로 완료한다.
        print('RUN')
        return True

run_job()

LOCK_EX는 배타 잠금, LOCK_NB는 잠금을 바로 얻지 못하면 기다리지 않는 선택이다. 예제 경로는 동작 설명용이다. 운영에서는 서비스 계정만 관리할 수 있는 고정 로컬 경로를 정하고, 스케줄러 실행과 수동 실행도 같은 파일을 사용해야 한다. 잠금을 잡지 않는 다른 프로그램의 쓰기까지 이 예제가 막아 주지는 않는다.

with 블록을 나온 뒤 별도 백그라운드 프로세스가 실제 작업을 이어가게 만들면 잠금 보유 시간과 작업 시간이 달라질 수 있다. 잠금 파일을 실행할 때마다 삭제·재생성하는 방식도 피해야 한다. 이름은 같아도 다른 파일을 열게 되면 동일한 대상에 대한 잠금이라는 전제가 깨질 수 있다.

건너뛰기와 대기는 업무에 따라 선택한다

이번 스크립트는 비차단 건너뛰기만 시험했다. 대기열이나 모든 회차 실행을 구현한 것이 아니다. “중복 프로세스가 없다”와 “입력을 한 번만 반영했다”는 서로 다른 확인이다. 외부 작업이 끝난 직후 완료 표시 전에 프로세스가 죽으면 재시도 시 같은 일을 다시 할 수 있어, 잠금 외의 결과 관리가 필요하다.

• 터미널에서는 되는데 예약 작업에서는 실패한다면: 경로와 환경부터 비교하기

  같은 스크립트가 다른 계정·작업 디렉터리로 실행되는지도 점검한다.

운영에서 잠금 다음으로 봐야 할 신호

모니터링은 ‘프로세스가 실행됐다’보다 마지막 정상 완료 시각을 봅니다. 가상으로 09시가 마지막 완료이고 10·11시가 모두 SKIP이면, 11시에 로그가 남아도 새 결과는 두 시간 동안 만들어지지 않은 상태입니다. 시간은 설명용 가정이고 이 실험의 실행 지연 측정이 아닙니다. 실제 기록에서는 시작·완료·실패·건너뛰기를 나누고, 완료에만 결과 버전과 시각을 연결하세요. 이번 비차단 잠금은 건너뛴 두 회차를 대기열로 복구하는 기능을 구현하지 않았습니다.

단일 서버의 로컬 파일을 공유하는 작은 작업이라면 이 방식의 전제를 이해하기 쉽다. 여러 서버에서 같은 작업을 실행하거나 네트워크 파일시스템을 사용하는 경우에는 잠금 범위와 동작을 별도로 검증해야 한다. 여기서는 한 Linux 호스트의 로컬 임시 파일만 사용했다.

python3 lab-job-lock.py --output new-observations.json