Batch + Scheduler vs Batch + Quartz
Quartz를 사용하면 Clustering 기능, DB 값을 기준으로 동작 제어가 가능하다
Batch vs Quartz?
간혹 Spring Batch와 Spring Quartz를 비교하는 글을 보게 되는데요.
둘은 역할이 완전히 다릅니다.
Quartz는 스케줄러의 역할이지, Batch 와 같이 대용량 데이터 배치 처리에 대한 기능을 지원하지 않습니다.
반대로 Batch 역시 Quartz의 다양한 스케줄 기능을 지원하지 않아서 보통은 Quartz + Batch를 조합해서 사용합니다.
정해진 스케줄마다 Quartz가 Spring Batch를 실행하는 구조라고 보시면 됩니다.
배치 어플리케이션은 다음과 같은 조건을 만족해야 한다.
1.대용량 데이터 - 배치 어플리케이션은 대량의 데이터를 가져오거나, 전달하거나, 계산하는 등의 처리를 할 수 있어야 합니다.
2.자동화 - 배치 어플리케이션은 심각한 문제 해결을 제외하고는 사용자 개입 없이 실행되어야 합니다.
3.견고성 - 배치 어플리케이션은 잘못된 데이터를 충돌/중단 없이 처리할 수 있어야 합니다.
4.신뢰성 - 배치 어플리케이션은 무엇이 잘못되었는지를 추적할 수 있어야 합니다. (로깅, 알림)
5.성능 - 배치 어플리케이션은 지정한 시간 안에 처리를 완료하거나 동시에 실행되는 다른 어플리케이션을 방해하지 않도록 수행되어야합니다.
Spring Batch Job 구성
Job
⨀ 배치처리 과정을 하나의 단위로 만들어놓은
⨀ 배치처리 과정에 있어 전체 계층 최상단에 위치합니다.
JobInstance
⨀ Job의 실행 단위
⨀ 2/23일, 2/24일 실행 시 각각의 JobInstance가 생성됩니다.
⨀ 앞서 이야기한것 처럼 2/23 실행 실패시 2/23에 대한 데이터만 처리하게 됩니다.
JobParameters
⨀ JobInstance를 구별할 때 사용합니다.
⨀ String, Double, Long, Date 4가지 형식을 지원합니다,
JobExecution
⨀ JobInstance에 대한 실행 시도에 대한 객체입니다.
⨀ 실패하여 재실행 시킨 경우 동일한 JobInstance이나 2번 실행에 대한 JobExecution은 개별로 생기게 됩니다.
⨀ JobInstanced 실행에 대한 상태, 시작시간, 종료시간, 생성시간 등의 정보를 담습니다.
Step
⨀ Job의 배치 처리를 정의하고 순차적인 단계를 캡슐화합니다.
⨀ Job은 최소한 1개 이상의 Step을 가져야 하며 Job의 실제 일괄처리를 제어하는 모든 정보가 들어있습니다.
StepExecution
⨀ Step 실행 시도에 대한 객체입니다.
⨀ 이전 단계의 Step이 실패하면 StepExecution은 생성되지 않습니다.
⨀ 실제 시작이 될 때만 생성됩니다.
⨀ StepExecution은 JobExecution에 저장되는 정보 외에 read 수, write 수, commit 수, skip 수 등의 정보들이 저장됩니다.
ExecutionContext
⨀ Job에서 데이터를 공유 할 수 있는 데이터 저장소
⨀ Spring Batch에서 제공하는 ExecutionContext는 JobExecutionContext, StepExecutionContext 2가지 종류가 있으나 이 두가지는 지정되는 범위가 다릅니다.
⨀ JobExecutionContext의 경우 Commit 시점에 저장되는 반면 StepExecutionContext는 실행 사이에 저장이 되게 됩니다.
⨀ ExecutionContext를 통해 Step간 Data 공유가 가능하며 Job 실패시 ExecutionContext를 통한 마지막 실행 값을 재구성할 수 있습니다.
JobRepository
⨀ 위의 모든 배치 처리 정보를 담고있는 매커니즘
⨀ Job이 실행되게 되면 JobRepository에 JobExecution과 StepExecution을 생성하게 되며 JobRepository에서 Execution 정보들을 저장하고 조죄하며 사용하게 됩니다.
JobLauncher
⨀ JobLauncher는 Job과 JobParameters를 사용하여 Job을 실행하는 객체입니다.
ItemReader
⨀ Step에서 Item을 읽어오는 인터페이스
⨀ ItemReader에 대한 다양한 인터페이스가 존재하며 다양한 방법으로 Item을 읽어올 수 있습니다.
ItemWriter
⨀ 처리된 Data를 Writer할 때 사용합니다.
⨀ 처리 결과물에 따라 Insert, Update, Queue의 Send 등이 될 수 있습니다.
⨀ 기본적으로 Item을 Chunk로 묶어 처리하고 있습니다.
ItemProcessor
⨀ Reader에서 읽어온 Item을 데이터 처리하는 역할을 합니다.
⨀ Processor는 배치를 처리하는데 필수 요소는 아니며 Reader, Writer, Processor 처리를 분리하여 각각의 역할을 명확하게 구분합니다.
Tasklet vs Chunk
실제 처리 로직이 들어가 있는 빈이다. 스프링배치에 처리를 하는 방식은 크게 Chunk 방식과 Tasklet 방식으로 나눌수 있다. Chunk 방식은 세가지 클래스 빈 ItemReader, ItemProcessor, ItemWriter 를 구현하고 이미 스프링 배치에서 작성해놓은 클래스들이 있어 그것을 이용하면 된다. 물론 직접 상속받아 구현할 수도 있다. Tasklet 방식은 Tasklet 인터페이스만 구현하면 되고 개발자가 직접 작성한다. for loop 를 돌면 숫자를 출력하고 종료되면 RepeatStatus.FINISHED 를 반환 배치에 정상 종료를 전달한다.
Tasklet
: 데이터 처리과정이 tasklet안에서 한번에 이뤄진다.
배치 처리과정이 쉬운 경우 쉽게 사용되며, 대량처리 경우 더 복잡해질 수 있다.
Chunksize
: chunksize 단위로 데이터가 페이징처럼 처리된다.
대용량 데이터를 처리할때 사용되며, reader / processor / writer 로 구분되어 처리된다.
(reader와 writer는 필수이며, processor는 사용안해도 된다.)
- reader
: (파일/DB) 데이터(item)를 읽어오며, reader안에서도 페이징처리가 가능한 bean들이 있다.
ItemReader, MybatisPagingItemReader, JpaPagingItemReader, ...- processor
: reader에서 읽어온 데이터(item)를 필터/처리 하고 write로 보내는 역할.
item을 필터 도중 null로 리턴하면, 그 item은 write로 전달되지 못한다.
ex) 10개 read 후 processor에서 4개 필터링 해서 6개만 리턴하면 write에서는 6개만 처리한다.- writer
: processor에서 처리된 데이터들(items : List<item>)을 파일이나 DB에 적재하는 역할.
writer는 기본으로 List단위로 처리되며, List는 chunksize에 의해 처리된다.
참고 : https://warpgate3.tistory.com/entry/Spring-Batch-Sample-Code-1
