배치 잡, 크론, 데드 레터, 멱등 | 스케줄러 장애 전에 채울 항목은?

스케줄러 장애의 절반은 “누가 돌리는 잡인지 모름”에서 시작한다. 서비스 단위로 한 장만 만들어도 온콜 시간이 줄어든다.

주기가 5분인데 평균 실행이 7분이면 항상 겹친다. 크론 문법보다 “한 번에 하나만”이 먼저다. 멀티 파드·오토스케일 환경에서는 스케줄 트리거가 인스턴스 수만큼 복제되기도 한다. 중앙 스케줄러 한 곳만 발행하고 워커는 소비만 하게 나누면 중복 기동 면적이 줄어든다.

정각 동시 폭주도 흔하다. 매시 0분에 정산·캐시 워밍·리포트가 한꺼번에 붙으면 DB CPU와 외부 API 한도가 같이 터진다. 잡마다 분 단위 오프셋이나 지터를 주면 피크가 평탄화된다.

네트워크 타임아웃 후 재시도는 거의 항상 온다. “성공했을 수도 있는 실패”를 전제로 설계한다. 외부 콜백과 같은 문제는 웹훅 멱등 키 글과 동일하다. 결제·포인트·알림처럼 부작용이 큰 경로는 유니크 제약 없이 재시도만 늘리면 비용 사고가 난다.

재시도 간격은 지수 백오프에 상한과 지터를 같이 둔다. 모든 워커가 같은 초에 다시 때리면 재시도 폭풍이 난다. 최대 시도 횟수를 넘기면 본 큐에서 빼고 DLQ로 보내 사람이 보게 한다.

DLQ는 휴지통이 아니다. 사람이 보고, 수정하고, 재투입하는 두 번째 파이프라인이다. 비어 있으면 좋은 날이 아니라, 모니터링이 꺼져 있을 수도 있다.

잡마다 로그 문장만 찍으면 검색이 안 된다. 메트릭 네 개와 구조화 필드 몇 개면 온콜이 증상에서 원인으로 넘어간다. “배치 실패” 한 줄 알림보다 job_id·attempt·duration_ms·처리 건수가 붙은 이벤트가 원인 추적 시간을 줄인다.

완료 건수가 0인데 exit code 0인 실행을 성공으로 치면 안 된다. 비즈니스 검증(최소 처리 건수, 금액 합 범위, 행 수 급변)을 잡 끝에서 한 번 더 돌리고, 실패로 올려 DLQ·페이지와 연결한다.

한 트랜잭션에 10만 행을 넣으면 락과 롤백 비용이 폭발한다. 배치 크기는 성능 튜닝이 아니라 장애 반경 조절이다. 청크 단위로 커밋하면 실패 지점부터 재개할 수 있고, 장시간 열린 트랜잭션이 일반 API 쓰기와 락을 다투는 시간도 줄어든다.

읽기 무거운 집계는 복제본·야간 윈도우·사전 집계 테이블 중 하나로 부하를 옮긴다. 백필은 일일 잡과 코드를 공유하되, 날짜 범위·쓰로틀·최대 건수 상수를 별도로 둔다. 실수로 전체 기간을 한 번에 돌리는 스위치를 기본값으로 켜 두지 않는다.

자정 알람이 울렸을 때 위키를 검색하지 않게, 잡 ID별로 한 페이지를 둔다. 온콜 교대 시 “어제 정산 잡 상태”를 구두로만 넘기면 빈칸이 생긴다. 대시보드 링크·중지 방법·재투입 명령을 같은 문서에 모은다.

비즈니스 마감이 있는 잡은 지연 분 단위로 에스컬레이션 단계를 적는다. 예: 15분 지연은 엔지니어 티켓, 30분은 페이지, 60분은 사업 담당 공유. 숫자 없이 “빨리 봐줘”만 있으면 매번 논쟁이 난다.

애플리케이션 API PR과 같은 리뷰 기준으로는 부족하다. 스케줄·부작용이 있는 변경은 체크리스트 한 블록을 필수 코멘트로 둔다. 주기만 바꾼 PR도 겹침 시뮬레이션과 알람 임계 재검토가 필요하다.

첫 프로덕션 실행은 트래픽이 낮은 창에 두고, 담당자가 메트릭 화면을 보며 한 사이클을 지킨다. “배포 후 내일 아침 확인”은 이미 중복 정산이 끝난 뒤인 경우가 많다. 피처 플래그로 잡을 끈 상태로 배포한 뒤 플래그만 켜는 순서를 쓰면 롤백이 단순해진다.

• Kubernetes Docs — CronJob — 스케줄·동시성 정책(Allow/Forbid/Replace)·타임존
• AWS SQS — Dead-letter queues — DLQ 이동 조건·재처리 개념
• BullMQ Documentation — 큐 잡 재시도·지연·실패 처리 패턴
• Google SRE Book — Managing Overload — 부하·백프레셔·과부하 시 시스템 보호

내부 연계: 웹훅 멱등·재시도 · SLO·온콜 · 회로 차단기 · 카나리 배포 · Sentry