Batch Scheduler Cron
3줄 요약
Batch Scheduler Cron 챕터는 온라인 요청에서 분리해야 할 반복 작업을 배치와 스케줄러로 실행하고 중복 실행, 재시작, 알림을 통제한다.- 목표는 cron 표현식을 외우는 것이 아니라, 늦게 처리해도 되는 작업을 사용자 요청 경로에서 분리하고 안전하게 재시작하는 기준을 세우는 것이다.
- Java/Spring 백엔드 개발자는
@Scheduled와 Spring Batch를 언제 나눠 쓰고, lock, chunk, retry, alert를 어디에 둘지 설명할 수 있어야 한다.
핵심 정리
Batch와 Online Request 경계: 온라인 요청은 사용자 응답 경로이고 batch는 늦게 처리해도 되는 반복 작업이다. 경계를 흐리면 API 지연이 운영 작업에 끌려간다.Scheduler Cron 설계: cron은 실행 시각만 정할 뿐 중복 실행, 장기 실행, 실패 재시작, timezone 문제를 자동으로 해결하지 않는다.Spring Scheduler와 Spring Batch 기본: Spring Scheduler는 단순 트리거에 적합하고 Spring Batch는 chunk, reader, writer, restart metadata가 필요한 작업에 적합하다.Batch Lock 중복 실행 방지: 배치는 같은 시간에 두 번 실행될 수 있다고 보고 lock, lease, idempotent writer, 실행 이력을 함께 설계한다.실패 재시도 알림 운영: 재시도는 실패를 숨기는 장치가 아니라 일시 오류를 흡수하는 장치다. 최종 실패는 알림과 runbook으로 이어져야 한다.- 이 챕터의 모든 문서는 Web-Database의 OLTP 판단을 넘어, 데이터 이동과 재처리 가능성을 중심으로 읽어야 한다.
헷갈리는 지점
- cron을 등록하면 배치 운영이 끝난다고 보기 쉽다.
- cron은 실행 시각만 정하고, 중복 실행과 장기 실행, 실패 재시작은 따로 설계해야 한다.
- 같은 작업이 두 번 떠도 안전한 lock과 idempotent writer가 필요하다.
- 온라인 요청 안에서 무거운 작업을 처리해도 된다고 보기 쉽다.
- 사용자가 기다릴 필요 없는 정산, 만료, 동기화, 리포트 갱신은 batch 후보가 된다.
- 경계를 나누지 않으면 batch 지연이 API latency와 장애 전파로 이어진다.
- 재시도 횟수만 늘리면 안정해진다고 오해하기 쉽다.
- 재시도는 일시 오류를 흡수할 뿐이고, 최종 실패는 알림과 runbook으로 연결되어야 한다.
- 재시작 위치와 검증 SQL이 없으면 다시 실행해도 안전하지 않다.
확인 질문
- 이 챕터의 핵심 판단 기준은 무엇인가?
- 사용자 요청에서 분리할 작업인지, 어떤 chunk와 checkpoint로 다시 시작할 수 있는지, 중복 실행을 어떻게 막는지다.
- Web-Database와의 경계는 무엇인가?
- Web-Database는 DB query와 transaction 자체의 안전성 중심이고, 이 챕터는 반복 작업을 별도 실행 흐름으로 운영하는 기준 중심이다.
- 개인 프로젝트에서 최소로 챙길 것은 무엇인가?
job_run_history, 대상 범위, 마지막 성공 시각, 실패 메시지, 수동 재실행 방법, 간단한 lock이다.