1. 스프링 배치의 주요 구성 요소 및 처리 전체 흐름
1–1. 중앙처리 흐름
- 작업 스케줄러에서 JobLauncher이 시작된다.
- JobLauncher에서 Job을 실행한다.
- Job에서 Step을 실행한다.
- Step은 ItemReader에 의해 입력 데이터를 얻을 수 있다.
- Step은 ItemProcessor에 의해 입력 데이터를 가공한다.
- Step은 ItemWriter 의해 가공 된 데이터를 출력한다
1–2. 작업과 관련된 메타 정보 처리 흐름
- JobLauncher는 JobRepository를 통해 Database에 JobInstance를 등록한다.
- JobLauncher는 JobRepository를 통해 Database에 작업의 실행 시작을 등록한다.
- JobStep는 JobRepository를 통해 Database에 입출력 건수 나 상태 등 각종 정보를 업데이트한다.
- JobLauncher는 JobRepository를 통해 Database에 작업의 실행 종료를 등록한다.
2. job의 영속화와 관련된 구성 요소
* 영속화 : 단순하게 설명하면 애플리케이션의 데이터가 애플리케이션의 프로세스보다 더 오래 지속하게끔 하려는 것을 말한다.
2–1. Job
하나의 배치 작업을 정의하며, 예를들면 “push알람을 보내는 배치” 정도가 되겠다.
2–2. Job instance
배치가 실제 실행되면, 각각의 실행을 instance라 한다. 예를들어 job이 매주 한번씩 수행된다 하면, 각각 수행되는 job들이 job instance들이 된다.
job instance를 생성하면 필요한 job parameter들을 함께 넘겨주는데, 이 ‘job parameter(key와 value로 구성됨)’와 ‘Job 의 이름’으로 각각의 instance들을 식별하는데 사용한다.
즉, job 이름 & job parameter 가 같으면 동일한 job instance로 인식하여, 이전 작업 상태에 이어서 진행을 하게 된다.
ex) 재 실행을 지원하지 않는 Job 또는 대상 Job Instance가 이미 정상적으로 처리가 완료된 경우 — > 예외가 발생하며(Job Instance Already Complete Exception), java 프로세스가 비정상적으로 종료된다.
2–3. Job execution & execution context
Job execution : Job instance와 달리, 동일한 job instance를 실행할때도 다른 execution이 된다.
job instance : job execution = 1: N
Job execution context : Step execution 간의 처리 진행 사항 등의 메타 데이터들을 공유하는 공간이다.
2–4. Step execution & execution context
하나의 job 은 여러 step들로 세분화 되어진다.
job execution : Step execution = 1: N
step execution context : 여러 step 끼리 공유하지 않아도 되는 정보들을 각 step 내에서만 공유 시, 사용하는 공간이다.
2–5. Job repository
배치 응용 프로그램 실행과 상태를 관리하며, 데이터 관리 유지 기능을 제공한다.
** 메타데이터를 관리하는 이유? 이전 실행을 이어서 다시 실행하기 위해서 이다. 재 실행을 위해서는 이전 실행 당시의 스냅샷을 남길 필요가 있다. 메타데이터들이 바로 스냅샷과 같은 것이다.
3. Job instance 의 등록 및 복원 과정
Job launcher 가 job repository에서 job name & job parameter와 일치하는 job instance를 검색한다.
— > 이미 동일한 job instance가 존재하는 경우 : instance와 연결된 job execution & context 정보를 읽어 프로세스를 복원한다.
— > 동일한 job instance가 존재하지 않는 경우 : job launcher가 job instance를 신규 등록한다.
참고) job instance가 매일 실행되도록 하기위해서는, 매번 job instance가 유일한 것으로 인식하도록 해야한다.
그러기 위해 job paramter에 시간 또는 난수의 값을 추가한다.
4. 프로세스 기동부터 배치 프로세스 ‘시작’ 까지의 처리 흐름
5. step에서 tasklet으로의 흐름
Tasklet 구현 방법은 위의 그림처럼 2가지가 있다.
- Chunk model 방식
- Xxx Tasklet 방식 (custom)
6. chunk oriented Tasklet 과 chunk 단위로 commit 하는 과정
전술한 것처럼 청크 모델이란 처리 대상이 되는 데이터를 1건씩 처리하는 것이 아니라, 일정수의 덩어리(chock)를 단위로 하여 처리하는 방식이다.
Chunk Oriented Tasklet가 바로 청크 처리를 지원하는 Tasklet의 구상 클래스이다.
이 클래스가 가지는 commit-interval 라고 하는 설정값에 의해, chank에 포함될 데이터의 최대 건수(이후, 「chank수」라고 부른다)를 조정할 수 있다. ItemReader, Item Processor, Item Writer는 모두 청크 처리를 전제로 한 인터페이스이다.
7. Spring Batch에서 제공하는 Item Reader, Item Processor, Item Writer의 대표적인 구상 클래스들
ItemReader나 ItemWriter는 다양한 구상 클래스가 Spring Batch로부터 제공되고 있다. 그러나, 특수한 형식의 파일을 입출력하거나 할 경우, 독자적인 ItemReader 나 ItemWriter 의 구상 클래스를 작성해 사용할 수 있다.
참고 사이트 :