스프링 배치 아키텍쳐

잡과 스탭

잡은 여러개의 스탭으로 구성된다.

스탭은 태스크릿 기반 스탭과 청크 기반 스탭 으로 나뉜다.

테스크릿 기반 스탭
- 테스크릿 기반 스탭은 구조가 간단하다. Tasklet 인터페이스를 구현하면 된다.
- 스탭이 중지될때 까지 execute 메서드가 계속 반복해서 수행된다.
  - execute 메서드를 호출할 때 마다 독립적인 Tx을 얻는다.
- 태스크릿 기반 스탭은 초기화, 저장 프로시저 실행, 알림 전송등과 같은 잡에서 주로 사용된다.
청크 기반 스탭
- 아이템 기반 처리에 주로 사용한다.
- ItemReader, ItemProcessor, ItemWriter 3개의 주요부분으로 구성됨.
  - ItemProcessor는 필수는 아님 (optional 이다)

스프링의 잡 구조화 방법이 가진 장점 중 하나는 각 스탭이 서로 독립적으로 처리될 수 있도록 분리했다는 점이다.

이처럼 스탭을 분리함으로써 많은 기능을 제공할 수 있다.

유연성: 복잡한 로직을 가진 복잡한 작업 플로우를 구성할 때, 개발자가 재사용이 가능하게 구성할 수 있도록 여러 빌더 클래스를 제공한다.
유지 보수성: 각 스탭의 코드는 이전 스탭이나 다음 스탭과 독립적으로 다른 스탭에 거의 영향을 미치지 않고, 쉽게 단위 테스트, 디버그, 변경을 할 수 있다.
확장성: 잡 내에 존재하는 독립적인 스탭은 확장 가능한 다양한 방법을 제공한다. 예를 들면 병렬로 하나의 스탭내에서 처리할 일을 여러 스레드에 나눠서 해당 스탭을 병렬로 실행할 수 있다.
신뢰성: 스프링 배치는 스탭의 여러단계에 적용할수 있는 오류처리 방법을 제공한다. 예외 발생시 해당 아이템의 처리를 재시도(retry)하거나 건너뛰기(skip)하는 등의 동작을 수행할 수 있다.

JobRepository

스프링 배치 아키텍쳐 내에서 공유되는 주요 컴포넌트인 JobRepository
JobRepository 컴포넌트는 다양한 배치 수행과 관련된 수치 데이터 (시작시간, 종료 시간, 상태, 읽기/쓰기 횟수) 뿐만 아니라 잡의 상태를 유지 관리한다.
jobRepository는 일반적으로 RDB 를 사용하며 스프링 배치 내의 대부분의 주요 컴포넌트가 공유한다.

JobLauncher

잡을 실행하는 역할을 담당 한다.
Job.execute 메서드를 호출하는 역할 이외도, 다음과 같은 처리를 수행한다.
- 잡의 재실행 가능 여부 검증
- 잡의 실행 방법
- 파라미터 유효성 검증

JobExecution, StepExecution

여러 아이템으로 이뤄진 청크의 처리가 스탭내에서 완료될때, 스프링 배치는 JobRepository 내에 있는 JobExecution 또는 StepExecution을 현재 상태로 갱신한다.

JobExecution과 StepExecution 관계

JobInstance는 스프링 배치 잡의 논리적인 실행이다.
JobInstance는 "잡의 이름"과 "잡의 논리적 실행을 위해 제공되는 고유한 식별 파라미터 모음"으로써 유일하게 존재한다.
잡을 처음 실행하면 새로운 JobInstance 및 JobExecution을 얻는다. 실행에 실패한 이후 다시 실행하면, 해당 실행은 여전히 동일한 논리적 실행(파라미터가 동일함)이므로 새 JobInstance를 얻지 못한다. 그 대신 두 번째 실제 실행을 추적하기 위한 새로운 JobExecution을 얻을 것이다. 이처럼 JobInstance는 여러개의 JobExectuions를 가질 수 있다.
StepExecution은 스탭의 실제 실행을 나타낸다.