Spring Batch로 대용량 배치를 운영하면서 가장 많이 받는 질문이 "chunk size를 얼마로 잡아야 하나요"입니다. 정답은 없지만, 무작정 키우는 게 항상 유리하지는 않습니다.
chunk size를 키울 때 생기는 트레이드오프
- 메모리 사용량 증가: 청크 단위로 메모리에 적재하므로, 사이즈가 클수록 힙 사용량이 늘어남
- 트랜잭션 범위 확대: 커밋 인터벌이 길어지면 실패 시 롤백 비용이 커지고, 재시작 시 처리해야 할 양도 늘어남
- DB 락 경합: 대량 업데이트가 한 트랜잭션에 몰리면 락 대기 시간이 늘어나 오히려 전체 처리량이 떨어질 수 있음
실제로 튜닝한 방식
- 초기값은 보수적으로(100~500) 잡고 처리량을 측정
- 처리량이 포화되는 지점까지 점진적으로 증가시키며 벤치마크
- DB 커넥션 풀 크기와 격리 수준(isolation level)을 함께 조정
파티셔닝과의 조합
단일 청크 사이즈 튜닝보다, PartitionHandler로 데이터를 나눠 병렬 처리하는 편이 전체 처리 시간 단축에 더 효과적이었습니다. 청크 사이즈는 각 파티션 내에서 안정적인 처리량을 내는 수준으로만 맞추고, 병렬도를 확보하는 쪽으로 우선순위를 뒀습니다.