왜 스프링(자바)로 배치를 사용할까?
- 로깅/추적, 트랜잭션 관리, 작업 처리 통계, 작업 재시작, 건너뛰기, 리소스 관리 등 대용량 레코드 처리에 필수적인 기능을 제공한다
- 배치가 실패하여 작업을 재시작하게 된다면 처음부터가 아닌 실패한 시점부터 실행
- 중복 실행을 막기 위해 성공한 이력이 있는 Batch는 동일한 Parameters로 실행 시 Exception 발생
유지보수
- 스프링의 의존성 주입을 통한 객체 간 결합 제거 및 추가 테스트 도구 사용 가능
- JDBC 코드를 직접 작성하거나 자바의 파일 IO API를 다룰 필요 없음
- 트랜잭션 및 커밋 횟수를 어플리케이션에서 제공해서 따로 관리할 필요 없음
유연성
- "한 번 작성하면 어디서든 실행 가능"한 자바의 유연성
- 웹 어플리케이션에서 이미 테스트 및 디버깅된 로직을 배치 처리에서 동일하게 사용 가능
스프링 배치의 사용 사례
데이터 마이그레이션
간단한 배치 잡을 사용할 때 많은 코딩이 필요하지 않다
커밋 횟수 측정이나 롤백 기능 등을 제공한다
병렬 처리
멀티 코어 또는 멀티 서버에 처리를 분산하는 기능을 제공
웹 어플리케이션에서 사용하는 것과 동일한 객체 및 데이터소스에 접근
무중단 처리 또는 상시 데이터 처리
큐에서 메세지를 읽은 뒤 청크 단위로 배치 처리를 수행하는 과정을 끝없이 반복한다
배치 아키텍처
스프링 배치 구조
- 어플리케이션 레이어: 개발자가 개발한 코드, 코드 레이어와 상호작용
- 코어 레이어: 배치 영역을 구성하는 실제적인 여러 컴포넌트
- 인프라스트럭처 레이어:
ItemReader와ItemWriter를 비롯하여 재시작과 관련된 문제를 해결할 수 있는 클래스와 인터페이스
잡과 스텝
- 자바나 xml을 사용해 구성된 배치 잡은 상태를 수집하고 이전 상태에서 다음 상태로 전환
- 스프링 배치에서 가장 일반적으로 상태를 보여주는 단위가 스텝
- 각 스텝은 잡을 구성하는 독립된 작업의 단위
스텝 (태스크릿과 청크)
스텝에는 태스크릿 기반 스텝과 청크 기반 스텝이 있다
-
태스크릿 기반 스텝
스탭이 중지될 때까지 execute 메서드가 반복 수행
tasklet 클래스가 재사용될 수 있는 상황에 적합
초기화/저장프로시저/알림 전송 같은 데서 사용
단계 내에서 단일 태스크를 수행하기 위한 것 -
청크 기반 스텝
한번에 고정된 양의 레코드(청크)를 읽고 처리
트랜잭션 경계 내에서 청크 단위(트랜잭션)로 데이터를 읽고 생성
청크를 사용하는 이유? -> 한 건의 실패에 대한 청크로부터 뒤에까지만 영향을 받게 되어 실패한 청크 앞의 영역은 영향을 받지 않음, 트랜잭션 범위를 줄임
따라서 데이터 일괄 변경이나 많은 양의 데이터에 변화를 주는 작업에 사용하면 좋음
참고로 아이템을 읽어올 때 paging 을 해서 읽어오는 것이 좋다
ItemReader,ItemProcessor,ItemWriter로 구성
보통 ItemProcessor가 없는 경우가 있는데 데이터 마이그레이션인 경우 해당 -
chunk 단위로 배치가 수행되는 과정
스텝을 분리하면서 제공하는 기능
- 유연성: 개발자가 재사용이 가능하게 구성할 수 있도록 여러 빌더 클래스 제공
- 유지보수성: 스텝의 코드가 독립적, 서로 영향을 미치지 않음, 단위테스트 및 디버깅 용이
- 확장성: 스텝 내에서 처리할 일을 여러 스레드가 나눔-> 병렬처리 가능
- 신뢰성: 스텝의 여러 단계에 적용할 수 있는 오류 처리방법 제공,
retry,skip등
잡 실행
- JobRepository: 수치데이터(시작,종료,상태,읽기쓰기횟수)와 잡의 상태 유지관리, 관계형 데이터베이스
- Job Launcher: 잡을 실행, 재실행가능 여부 검증/파라미터 유효성 검증
- 잡 실행의 동작 원리
- 스프링부트에는
JobLauncherCommandLineRunner라는 컴포넌트가 존재 - 스프링배치가 클래스 경로에 있다면 실행 시에 로딩, JobLauncher를 사용해 ApplicationContext에서 찾아낸 모든 잡을 실행시킴
- 따라서 메인 메서드에서 ApplicationContext가 생성되고 JobLauncherCommandLineRunner가 실행되면 잡이 수행된다
실행 과정
- 잡을 실행하면 해당 잡은 각 스텝을 실행
- 각 스텝이 실행되면 JobRepository는 현재 상태로 갱신( 상태가 JobRepository에 저장)
- 여러 아이템으로 이뤄진 청크의 처리가 스텝 내에서 완료될 때 JobRepository 내에 있는 JobExecution 또는 StepExecution을 현재 상태로 갱신
- 스텝은 ItemReader가 읽은 아이템의 목록을 따라감
- 스텝이 각 청크를 처리할 때마다 JobRepository에 StepExecution업데이트
- 현재까지의 커밋수, 시작 및 종료시간 등이 JobRepository에 저장
- Job또는 스텝이 완료되면 JobRepository 내에 있는 JobExecution 또는 SetpExecution이 최종상태로 업데이트
- JobExecution: 스프링 배치 잡의 실제 실행, 실행 실패 후 재실행시 새로 만들어진다
- JobInstance: 하나의 job의 논리적 실행, 실행 실패시 새로 만들어지지 않는다
- SetpExecution: 하나의 스텝 실행, 하나의 JobExecution에 여러개가 연관된다
참고한 링크
https://khj93.tistory.com/entry/Spring-Batch%EB%9E%80-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B3%A0-%EC%82%AC%EC%9A%A9%ED%95%98%EA%B8%B0
https://velog.io/@gkskaks1004/%EC%8A%A4%ED%94%84%EB%A7%81-%EB%B0%B0%EC%B9%98%EC%9D%98-Tasklet-%EB%B0%A9%EC%8B%9D%EA%B3%BC-Chunk-Tasklet-%EB%B0%A9%EC%8B%9D
