Spring Batch의 도메인 이해

Spring Batch의 도메인 이해

1) Job

1. 배치 계층 구조에서 가장 상위에 있는 개념으로, 하나의 배치 작업 자체를 의미함.
2. 배치 작업을 어떻게 구성하고 실행할지 전체적으로 설정하고 명세헤 놓은 객체
3. 최상위 인터페이스로서 스프링 배치가 기본 구현체를 제공한다.
4. JobLauncher가 run을 통해 job을 실행시킨다.
5. 내부에 List<Step> 이라는 steps를 가지고 step을 거기다 add한다.
6. build는 실제 job
7. 기본 구현체
   1. SimpleJob
      1. 순차적으로 step을 실행시키는 job.
      2. 스텝을 포함하고 있는 컨테이너 역할
      3. 모든 job에서 유용하게 사용 가능한 표준 기능을 가진다.
   2. FlowJob
      1. 특정 조건과 흐름에 따라 step을 구성해서 실행시키는 job
      2. Flow 객체를 실행시켜서 작업을 진행한다.

• Job 인터페이스 내부에 선언된 필드들

2) JobInstance

1. Job이 실행될 때 생성되는 Job의 논리적 실행 단위 객체, 고유하게 식별 가능한 작업 실행을 나타냄.
2. Job의 설정과 구성은 동일하지만 Job이 실행되는 시점에 처리하는 내용은 다르니까 Job의 실행 자체를 구분해야 한다.
   1. 하루에 한번씩 배치 Job이 실행된다면 매일 실행되는 각각의 Job이 job instance임.
3. JobInstance 생성 및 실행
   1. JobLauncher가 잡을 실행할 때 job 이름과 job Parameter로 인자를 두 개 받는다.
   2. 처음 시작하는 job + jobParameters일 때 새로운 job instance를 생성
   3. 이전과 동일한 job + jobParaemters일 때 이미 존재하는 job instance를 반환하고 수행에 실패한다!! 예외를 반환한다. 다시 수행할 필요가 없으니까.
      1. 내부적으로 jobName + jobKey(jobParameers의 해시값)을 가지고 job instance 객체를 얻는다.
   4. Job과 Job Instance = 1 : N 관계
4. BATCH_JOB_INSTANCE 테이블과 관계
   1. JOB_NAME(job)과 JOB_KEY(job Parameters의 해시값)이 동일한 데이터는 이 테이블에 중복 저장할 수 없다.
5. JobRepository가 현재 실행 중인 이 job이 처음 실행하는건지, 이전에 한번이라도 실행된 job인지를 확인한다.3) JobParamter

1. Job을 실행할 때 함께 포함되어 사용되는 파라미터를 가진 도메인 객체
2. 하나의 Job에 존재할 수 있는 여러개의 JobInstance를 구분하기 위한 용도
3. JobParameter와 JobInstance는 1:1 관계
4. 생성 및 바인딩 방법
   1. 애플리케이션 실행 시 주입 (Java -jar LogBatch.jar requestDate=20210101)
   2. 코드로 생성(JobParameterBuilder,DefaultJobParametersConeverter)
   3. SpEL 이용 @Value(”#JobParameter[requestDate]})”), @JobScope, @StepScope 선언 필수
5. BATCH_JOB_EXECUTION_PARAM 테이블과 JobParameter는 1:M 관계

하나의 job execution id에 대해 그때 실행될 때 들어갔던 파라미터들이 위 테이블에 저장됨.

step execution 안에 job execution이 있으니 거기서 jobParameters를 참조할 수 있다.

jobParamters는 LinkedHashMap으로 되어 있다.

4) JobExecution

• JobInstance에 대한 한번의 시도를 말한다. Job 실행 중에 발생한 정보들을 저장하고 있는 객체.
  • 시작시간, 종료시간, 상태(시작됨, 완료, 실패), 종료 상태의 속성을 가짐
• JobInstance와 JobExecution의 관계와 차이점
  • 동일한 파라미터로 실행을 시도할때, 그에 관한 job exectuion 의 실행상태 결과가 Failed 였다면 이 job instance에 대한 실행이 완료되지 않은 것으로 간주한다. 그래서 재실행이 가능하다. 여기서 재실행한다는 건, job instance 객체가 새로 생성되는 것이 아니라 실행 된다는 말임. 이에 따라 Job execution도 실행이 되는데, execution은 실행할 때마다 새롭게 생성된다.
  • Job Execution 상태가 Completed가 될때까지 하나의 job instance 내에서 여러 번의 시도가 생길 수 있다. 그리고 여러 시도마다 execution이 생성된다.
• BATCH_JOB_EXECUTION 테이블
  • job instance와 job execution의 관계는 1:M 관계이고, job instance에 대한 성공/실패의 내역을 가지고 있다.
  • 그림
  • 
  • 그림2
    1. 서로 다른 파라미터로 instance A. B가 만들어짐.
    2. A에 해당하는 execution 객체가 생성됨. 이건 completed야.
    3. B의 경우, job이 재실행됐으니 execution이 2개 생성된거야. 이 말은 실패가 있었단거야.
    4. job executionId는 새로 생성됐으니 하나 늘었음. completed됐으니 이제 동일한 파라미터로 잡 실행 불가능해졌어.
    5. 테이블 execution params는 execution이 2번 있었으니 각각에 대한 같은 파라미터가 들어가있음.
    6. execution 테이블은 세번
    
  • 속성
  • 

5) Step

• Batch Job을 구성하는 독립적인 하나의 단계로, 실제 배치 처리를 정의하고 컨트롤하는 데 필요한 모든 정보를 가지고 있는 도메인 객체임.
• 단순한 단일 테스크 뿐 아니라 입력과 처리 출려고가 관련된 복잡한 비즈니스 로직을 포함하는 설정을 담는다.
• 배치 작업을 어떻게 구성하고 실행할지 job의 세부작업을 task 기반으로 설정하고 명세한 객체.
• 모든 job은 하나 이상의 step으로 구성된다.
• Step 인터페이스의 기본 구현체
  • TaskletStep
    • 가장 기본이 되는 클래스로, Tasklet 타입의 구현체를 제어
  • PartitionStep
    • 멀티 스레드 방식으로 step을 여러 개로 분리해서 실행한다
  • JobStep
    • Step 내에서 Job을 실행하도록 한다.
  • FlowStep
    • Step 내에서 Flow를 실행하도록 한다.
• 그림 (구현체와 가진 메소드)
• 

6) StepExecution

• Step에 대한 한번의 시도를 의미하는 객체, Step 실행 중에 발생한 정보를 저장하는 객체
  • 시작시간, 종료시간, 상태, commit count, rollback count 등의 속성을 가짐
• Step이 실행될 때마다 새로 생성된다. 각 step 별로.
• Job이 재시작하더라도 이미 성공적으로 완료된 step은 재실행되지 않고 실패한 step만 실행된다.
• 이전 단계 step이 실패해서 현재 step을 실행하지 않았다면 stepExecution을 생성하지 않는다. step이 실제로 시작됐을 때만 stepExecution을 생성한다
• Job Execution과의 관계
  • Step의 StepExecution이 모두 정상적으로 완료되어야 JobExecution이 정상적으로 완료된다.
  • Step의 StepExecution 중 하나라도 실패하면 Job Execution은 실패한다.
• Batch_Step_Execution 테이블과 매핑
  • Job Execution 과 Step Execution은 1:M 관계
  • 하나의 job 에 여러개의 step으로 구성할 경우 각 step execution은 하나의 job Execution을 부모로 가진다.
• 그림
  1. job execution이 생성됨.
  2. step1, step2 가 각각 실행될 때 step execution이 각각 completed가 되면 그때 job이 completed로 종료됨.
  3. 또하나 1월2일로 다른 파라미터 넣었으니 다시 job instance 새로 생성되고 job execution도 생성돼. 여기서 step 중 하나가 fail 하면 job도 최종적으로 fail됨.
  
• 그림2
  1. job이 있고 step이 2개가 있음
  2. job Parameter로 1월 1일 넣으면 job instance 생성됨,
  3. 하위에 execution을 가진다. job instance에 대한 한번의 시도니까.
  4. 그 job execution 하위에 각 step 별 step execution이 생성된다.
  5. 두번째 파라미터 1월 2일로 하면 job instance 생성되고
  6. job exection 생성됨. 얘가 failted라면, 내부 step execution 안에 하나 이상이 failed 인거야.
  7. step execution 여기까지가 총 4개가 있는 상태. 이 중 마지막거가 failed 니까….
  8. job execution이 fail이니 한번 더 실행이 가능
  9. 이때 하위 스텝이 모두 completed가 되니까 job 도 completed가 잘 된 거임.
  
• 속성
• 

7) StepContribution

• 청크 프로세스의 변경 사항을 버퍼링한 뒤 stepExecution 상태를 업데이트하는 도메인 객체
• 청크 커밋 직전에 step execution의 apply 메소드를 호출해서 상태를 업데이트 한다.
• exit status의 기본 종료 코드 외에 사용자 정의 종료코드를 생성해서 적용할 수 있다.
• 각각 reader processor writer 등의 과정에서 count 값들이 step contribution에 들어간다. 마지막에 apply를 통해 execution에 contribution의 개수들을 넣는다.
• stepExecution.apply(contribution)
• 
• 그림
• 
• 속성
• 

8) ExecutionContext

• Job이나 Step에 포함된 도메인은 아님. 프레임워크에서 유지 및 관리하는 key-value로 된 컬렉션으로, step execution 또는 job execution 객체의 상태(그 객체의 속성 값)를 저장하는 공유 객체,
• 내부에 Map<String, Object> map = new ConcurrentHashMap를 가진다. 각 step 마다 이 map을 가진 execution context가 있고, 다시 이 execution context를 step execution 내에 저장한다.
• DB에 직렬화한 값으로 저장된다 JSON 형태로.
• 공유 범위
  • step 범위 : 각 step 마다 가지는 stepExecution에 execution context가 저장되고, step 간 서로 공유 안된다.
  • job 범위: 각 job 마다 job execution에 execution context가 저장되고 job끼리는 서로 공유가 되지 않는데, 해당 job 내의 step 끼리는 공유가 된다.
  • 따라서 step 간 공유되어야할 데이터를 Job Execution에 저장된 ExecutionContext에 해당 공유할 데이터들, 즉 어떤 상태들을 저장하면 이를 활용할 수 있음.
  ⇒ Job 재시작 시 이미 처리한 row 데이터는 건너뛰고 이후부터 수행시키고 싶을 때 상태정보를 활용한다.
  • 그림
  • 

9) JobRepository

• 배치 작업 중의 정보를 저장하는 저장소
• job이 언제 수행됐고 언제 끝났고 몇번 실행됐고 실행 결과는 어떤지 배치 작업의 수행과 관련된 모든 메타 데이터를 저장한다.
• job launcher, job 구현체 , step 구현체 내부에서 crud 기능을 처리한다.
• 메소드들
• 
• @EnableBatchProcessing 어노테이션만 선언하면 job repository가 자동으로 빈으로 생성된다.
• batch configurer 인터페이스를 구현하거나 basic batch configurer을 상속해서 job repository 설정을 커스터마이징할 수 있다.
  • JDBC 방식 : JobRepositoryFactoryBean
    • 내부적으로 AOP 기술로 트랜잭션 처리를 해준다.
    • isolation 기본 값이 serializable 로 최고수준임. read committed나 repeatable read로 지정 가능
      • 테이블 락이 엄격하게 정해지므로 속도나 성능에 이슈가 있음. 배치의 경우 많은 사용자가 동시 접근하거나 트래픽이 몰리는게 아니기 때문에 엄격 수준으로 isolation을 설정해도 가능한…
    • 메타 테이블의 Table Prefix도 변경할 수 있는데 기본값이 BATCH_ 임.
  • In Memory 방식 : MapJobRepositoryFactoryBean
    • 성능 등의 이유로 도메인 오브젝트를 굳이 DB에 저장하고 싶지 않을 때 사용
    • 테스트나 프로토타입의 빠른 개발 필요할 때 사용

10) Job Launcher

• 배치 잡을 실행시키는 역할
• job과 job parameter를 인자로 받으며 요청된 배치 작업을 수행한 후 최종 클라이언트에게 job execution을 반환한다.
• 스프링부트 배치가 구동되면 job Launcher 빈이 자동생성된다.
• 안에 job과 job parameters를 인자로 받는 run이라는 메소드가 있다.
• 동기적 실행
  • 스케줄러에 의한 배치처리에 적합하고, 배치 처리 시간이 길어도 상관 없는 경우.
  • taskExecutor를 SyncTaskExecutor로 설정한 경우.
  • JobExecution을 획득하고 배치 처리를 최종 완료하면 client에게 job execution을 반환한다.
• 비동기적 실행
  • HTTP 요청에 의한 배치 처리에 적합함. 배치 처리 시간이 길 경우 응답이 늦어지지 않도록, client에게 일단 execution 주고 나서 내부적으로 배치 처리.
  • taskExecutor가 SimpleAsyncTaskExecutor로 설정한 경우
  • job execution을 획득한 후 바로 client에게 일단 job execution을 반환하고, 내부적으로 배치를 완료한다.
• 그림
  1. 동기는 클라이언트가 배치 수행 요구하면
  2. job Launcher가 job을 수행하고 하위 비즈니스를 실행한 뒤 exit status와 함게 execution을 반환.
  3. 비동기는 unknown으로 일단 응답하고 나중에 exit Status 를 반환.