1. 스프링 배치의 탄생

2007년, SpringSource 사와 Accenture 사의 공동작업으로 스프링 배치가 탄생했다. 

Accenture 사의 배치 프레임웍 관련 경험과 SpringSource 사의 기술적 전문지식 및 검증된 스프링 프로그래밍 모델이 스프링 배치에 녹아 있다고 한다. 스프링 배치를 이용하면, 대용량 배치에 맞는 읽기 방식과 Transaction 처리를 간단히 구현할 수 있다고 한다.

여기서 잠깐!

스프링 배치는 스케쥴러가 아니다! Batch Job을 관리하지만 스케쥴링에 따라 Job을 구동하는 기능은 지원하지 않는다. Quartz나 cron이 스케쥴러 역할을 하게된다.


2. 배치 작업이란?

  • 유한한 시간동안 수행된 후 종료되는 프로그램
  • 주기적으로 (일, 주) 수행되는 프로그램

3. 스프링 배치의 핵심 기능

  • 스프링 프레임웍 기반
  • 배치 기반 처리
  • 자체제공 컴포넌트
  • 견고함과 안정성
  • 파티셔닝

4. 스프링 배치가 지원하는 저장소 관련 기술

스프링 배치는 ItemReader, ItemWriter의 여러 구현체를 제공한다.

  • JDBC (Cursor & Driving Query) : 페이징, 커서, 일괄 업데이트 등
  • Hibernate : 페이징 커서
  • JPA(Java Persistence API) : 페이징
  • iBatis : 현재는 삭제됨
  • Flat File : 지정된 구분자로 파싱
  • XML : XML 파싱

(Spring Batch 4.0, Spring Boot 2.0 기준 / 버전에 따라 지원에 차이가 있을 수 있음)


5. 주요 용어

5.1. Tasklet

  • Read, Process, Write 등 Step의 과정들을 직접 처리하고자 할 때 사용하는 방식
  • 이러한 방식으로 동작하는 Step을 Tasklet Step이라고 한다.

5.2. Chunk 

  • 트랜잭션 내에서 처리할 Item의 단위(묶음)이다. 
  • commit-interval 10이면 트랜댁션 내에서 10개 item 단위로 처리하고 커밋.
  • 이러한 방식으로 동작하는 Step을 Chunk Step이라고 한다.

5.3. JobRepository

내부 인터페이스이다. 네임스페이스가 제공된다.

<batch:job-repository id="jobRepository" />

처리 중에 StepExecution 및 ExecutionContext를 주기적으로 저장한다.

5.4. Step

  • 실질적인 배치 처리를 정의하고 제어하는데 필요한 모든 정보가 들어있는 객체이다.
  • 즉 Job을 처리하는 실질적인 단위다. 모든 Job은 1개 이상의 Step이 있어야 한다.
  • DB의 트랜잭션 관리는 Step 단위로 수행된다. 따라서 각 Step 별로 개별적인 트랜잭션 설정이 가능하다.

6. 성능 개선

6.1. 성능

  • 스프링 배치 파티션 기능을 통해 배치 병렬 처리 적용
  • 탑 쿼리에 파티션 키 추가
  • 단 병렬 처리하더라도 배치간에 데이터 불균형이 있으면 결국 가장 느린 배치가 처리시간을 좌우한다. 따라서 데이터가 균등하게 분배되어야 한다.
    -> 대상 레코드 값 중 다양한 값을 가지고 있는 컬럼을 선택하여 해시 연산 후 별렬 수로 나눈 나머지 값으로 처리 배치를 할당 등

6.2. 처리 결과 건마다 DB 처리

  • 배치 타입의 SqlSessionTemplate 적용하여 ooo건 단위로 집합 처리
  • 개별 처리 시에 100,000건 처리 시 100,000건 디비 호출을 한다면, 100건 단위 집합 처리하면 1번 호출에 1,000건 데이터 처리.

6.3. 한번에 다량 처리

  • SqlSessionTemplated으로 다량건 처리하여 문제(OOM 등) 발생 가능
  • Cursor 방식인 MybatisCursorItemReader 사용 -> 자바 메모리에 무리를 주지 않게 함 (예: Fetch size = 100)
  • 단 Fetch Size를 증가하여 성능 향상을 얻는 경우도 있다.

6.4. 캐시

  • 배치는 동일 로직이 반복되는 경우가 많아 채번이나 공통 데이터를 캐시 적용할 수 있다.

6.5. 기동 지연

  • 원인은 스프링 빈 수가 많아 이를 로딩하느라 기동 시간이 오래 걸리게 되는 것이다.
  • 일반적으로는 스프링 빈을 찾는 범위를 줄여주는 것이 좋다.
    1) 모든 빈을 스프링 배치 xml에 기술 : 단 공통 모듈에서 사용하는 모든 빈을 기술하면 공통 모듈의 수정으로 전체 배치가 오류가 발생할 수 있음
    2) component-scan의 범위를 최대한 줄여서 설정 : 배치가 사용하는 빈들이 특정 패키지 하위에 있다는 전제 하에 사용하는 것으로 빈을 찾는 범위를 최대한 좁히는 것이 목적임

7. Spring Boot의 스프링 배치

spring.batch.initialize-schema=embedded
spring.batch.job.enabled=true
spring.batch.job.names=
spring.batch.table-prefix=