Spring Batch 성능의 핵심: 대용량 처리용 Chunk Size 설정 가이드

안녕하세요.

Spring Batch를 사용하여 수백만, 수천만 건의 데이터를 처리할 때 가장 고민되는 숫자가 하나 있습니다.
바로 Chunk Size입니다.

.chunk(10, transactionManager) // 10? 100? 1000? 도대체 몇이 좋을까?

“그냥 크게 잡으면 빠른 거 아냐?”라고 생각하기 쉽지만, 잘못 설정하면 OOM(Out Of Memory)으로 서버가 죽거나, 반대로 DB 커넥션을 너무 오래 잡고 있어서 타임아웃이 발생할 수 있습니다. 오늘은 이 Chunk Size의 황금비를 찾는 방법을 알려드립니다.

1. Chunk Size란 정확히 무엇인가?

Chunk Size는 “한 번의 트랜잭션에서 처리할 아이템의 개수”입니다.

  • Read: Chunk Size만큼 데이터를 읽어옵니다 (Paging Reader의 경우).
  • Process: 메모리 위에서 루프를 돌며 가공합니다.
  • Write: Chunk Size만큼 모인 데이터를 한 번에(Bulk) DB에 씁니다.
  • Commit: 트랜잭션을 커밋합니다.
Spring Batch 성능의 핵심: 대용량 처리용 Chunk Size 설정 가이드 이미지 1

즉, chunk(100)이라면 100개를 읽고, 가공하고, 저장한 뒤 커밋하는 과정을 반복합니다.

2. Chunk Size가 성능에 미치는 영향

2.1 너무 작을 때 (예: 1~10)

  • 문제점: 트랜잭션 커밋이 너무 빈번하게 일어납니다. DB 입장에서 커밋은 꽤 무거운 작업(디스크 I/O 발생)입니다.
  • 결과: 전체적인 배치 수행 시간이 느려집니다.

2.2 너무 클 때 (예: 10,000 ~ 100,000)

  • 문제점 1 (메모리): 읽어온 10만 개의 객체를 모두 메모리에 들고 있어야 합니다. 힙 메모리가 부족해지면 GC(Garbage Collection)가 빈번해지고, 결국 OOM이 발생합니다.
  • 문제점 2 (시간): 10만 개를 처리하는 동안 트랜잭션이 열려 있습니다. DB 타임아웃 설정에 걸려 롤백될 위험이 큽니다. 에러 발생 시 10만 개 데이터를 롤백하고 다시 해야 하므로 복구 비용도 큽니다.

3. 적정 Chunk Size 찾는 공식 (Rule of Thumb)

절대적인 값은 없지만, 실무에서 통용되는 가이드라인은 있습니다.

3.1 Page Size와 일치시켜라

가장 중요한 원칙입니다. JpaPagingItemReader 등을 사용할 때, Page Size와 Chunk Size가 다르면 페이징 처리에 문제가 생길 수 있습니다.

int chunkSize = 1000;

return new StepBuilder("step", jobRepository)
    .<In, Out>chunk(chunkSize, txManager)
    .reader(new JpaPagingItemReaderBuilder()
        .pageSize(chunkSize) // 여기도 1000
        .build())
    ...

3.2 데이터 크기에 반비례하라

  • 가벼운 데이터 (ID, 이름 정도): 500 ~ 1000 추천
  • 무거운 데이터 (큰 JSON, 이미지 바이너리 포함): 10 ~ 100 추천

객체 하나의 크기가 클수록 Chunk Size는 줄여야 메모리를 보호할 수 있습니다.

3.3 JPA vs JDBC

  • JPA Writer: 영속성 컨텍스트 관리 비용이 있으므로 100 ~ 500 정도가 적당합니다.
  • JDBC Batch Writer: 순수 쿼리만 날리므로 1000 ~ 2000까지 늘려도 성능 효과를 볼 수 있습니다.

4. 성능 테스트로 최적값 찾기

이론은 이론일 뿐, 실제 환경에서 테스트해봐야 합니다.

  1. 초기값 100으로 시작합니다.
  2. 500, 1000으로 늘려가며 수행 시간을 기록합니다.
  3. 어느 순간 성능 향상 폭이 줄어들거나(임계점), 메모리 사용량이 급증하는 지점이 옵니다. 그 직전 값이 최적값입니다.
Spring Batch 성능의 핵심: 대용량 처리용 Chunk Size 설정 가이드 이미지 2

위 그래프(예시)처럼 1000개까지는 시간이 급격히 줄어들지만, 5000개가 넘어가면 오히려 GC 때문에 느려지는 현상을 볼 수 있습니다.

5. 결론

“무조건 1000개”라는 정답은 없습니다.
하지만 “시작은 1000개, 무거운 객체면 100개”라는 기준점은 가질 수 있습니다.

여러분의 배치 서버 힙 메모리 크기(Xmx)와 처리할 데이터의 뚱뚱함(?)을 고려하여, 우리 시스템만의 황금 비율을 찾아보시기 바랍니다.

관련 글 보기