중복 실행 방지
한 줄 정의
중복 실행 방지는 같은 배치 작업이 동시에 또는 반복 실행되어 같은 대상이 두 번 처리되지 않도록 제어하는 설계다.
실무에서 왜 문제 되는가
- 스케줄이 겹치면 같은 데이터가 두 번 처리될 수 있다.
- 서버가 여러 대이면 각 인스턴스가 같은 배치를 실행할 수 있다.
- lock만 믿고 로직 자체의 멱등성을 놓치면 lock 실패 시 데이터가 깨질 수 있다.
- 이전 실행이 비정상 종료되면 lock이나 processing 상태가 남을 수 있다.
실무 판단 기준
| 상황 | 선택 |
|---|---|
| Kubernetes CronJob | concurrencyPolicy |
| 단일 스케줄러 | 실행 중 플래그 또는 스케줄러 옵션 |
| 다중 인스턴스 | DB lock 또는 distributed lock |
| 대상별 중복 방지 | unique constraint |
| 재실행 허용 | 멱등한 상태 전이 |
자주 나는 실수
- scheduler가 한 번만 실행된다고 가정한다.
- lock TTL을 작업 시간보다 짧게 둔다.
- lock 획득 실패를 성공처럼 처리한다.
- 중복 실행 방지를 lock 하나로만 해결하려 한다.
확인 방법
- 같은 배치를 동시에 두 번 실행해 결과가 깨지지 않는지 확인한다.
- lock 만료, 프로세스 종료, 재시작 상황을 테스트한다.
- unique 제약이나 상태 전이가 중복 결과를 막는지 확인한다.
핵심 요약
배치는 스케줄 중복, 다중 인스턴스, 수동 재실행 때문에 중복 실행될 수 있다.
중복 실행 방지는 스케줄러 정책, lock, unique 제약, 멱등성을 함께 고려해야 한다.
lock은 실행 자체를 줄이지만 데이터 정합성을 완전히 보장하지 않는다.
대상별 처리 결과는 unique 제약이나 상태 전이로 한 번 더 보호하는 것이 좋다.
비정상 종료 후 lock과 processing 상태 복구 기준이 필요하다.
꼬리 질문
- 배치 중복 실행은 어떤 상황에서 발생하는가?
- Distributed lock만으로 충분하지 않은 이유는 무엇인가?
- 중복 실행 테스트는 어떻게 할 것인가?