본문 바로가기

Reading Record/스프링 배치 완벽 가이드

2장 스프링 배치

2장 스프링배치

배치 아키텍쳐

  • 애플리케이션 레이어: 개발자가 개발한 코드
  • 코어 레이어: 배치 영역을 구성하는 실제적인 컴포넌트
  • 인프라스트럭쳐 레이어: ItemReader, ItemWriter와 같이 여러 문제를 해결할 수 있는 클래스와 인터페이스

잡과 스텝 (코어 레이어)

잡 = 스텝 집합의 절차


스탭

  • 태스크릿(Tasklet) 기반: 스텝이 중지될 때 까지 execute 메서드를 실행하고, 실행될 때 마다 새로운 트랜잭션으로 실행된다.
    • 초기화, 저장 프로시저 실행, 알림전송등에 사용
  • 청크(Chunk) 기반: 청크단위(처리 단위)로 아이템(Resource, DB...) 기반의 처리를 한다. 아래 3개의 구성요소로 이루어 질 수 있다.
    • ItemReader: 아이템의 입력을 담당하는 인터페이스
    • ItemProcessor(Optional): 아이템의 처리(ex.비지니스 로직)를 담당하는 인터페이스
    • ItemWriter: 아이템의 저장을 담당하는 인터페이스

각 스텝은 서로 독립적으로 처리될 수 있도록 설계되어 있다.

특징
  • 유연성: 재사용이 가능하게 구성할 수 있는 여러 빌더 클래스를 제공한다.
    • StepFactoryBuilder
  • 유지 보수성: 각 스탭은 다른 스탭에게 영향을 받지 않도록 독립적인 구성이 가능하고 테스트, 디버그, 재사용이 가능하다.
  • 확장성: 독립적으로 구성된 스탭의 병렬 실행이 가능하다.
  • 신뢰성: 예외 발생시 재처리 혹은 건너뛰기등의 강력한 오류 처리방법이 가능하다.

잡 실행

JobRepository: 배치 수행, 잡의 상태 관리, 메타 데이터(시작시간, 종료시간, 상태, 읽기/쓰기 횟수 등). 일반적으로 RDS를 사용한다.

  • JobLuancher
    • 잡 실행
    • 재실행 가능 여부 검사
    • 실행 방법 선택
    • 파라미터 유효성 검증

구조
  • Job
    • JobInstance - parameter1
      • JobExecution1 - FAILED
        • StepExecution1
      • JobExecution2 - FAILED
        • StepExecution2
      • JobExecution3 - COMPLETED
        • StepExecution3
    • JobInstance - parameter2
      • JobExecution1 - COMPLETED
        • StepExecution2

JobInstance는 [잡 이름]+[잡 파라미터]의 조합으로 유일하게 존재한다. 따라서 동일한 잡은 파라미터가 달라지면 여러개의 JobInstance가 생성된다.

JobExecution은 실제 잡의 수행을 의미하며 잡을 실행할때마다 새롭게 생성된다. StepExecution 또한 동일하다.


병렬화

단순한 배치작업은 단일 스레드로 처리된다. 하지만 병렬로 처리할 수 있는 요구사항에서는 병렬로 처리할 수 있는 방법이 존재한다.


다중 스레드 스텝

하나의 스텝에서 여러개의 청크로 작업이 이루어진다고 했을때 각 청크단위로 독립적인 트랜잭션을 얻게 된다. 이렇게 독립적인 트랜잭션을 얻게된 청크단위의 작업을 멀티 스레드를 이용해 병렬로 처리하는 방식이다.


전체 스텝의 병렬 실행

여러개의 스탭으로 이루어진 잡에서 특정 스탭은 동기적으로 실행될 이유가 없을 수 있다. 이럴 경우 동기적으로 실행될 필요가 없는 스탭들을 병렬로 실행해서 처리할 수 있다.


비동기 ItemProcessor/ItemWriter

연산에 시간이 오래걸리는 작업이나 외부 시스템과 엮여 네트워크 통신을 ItemProcessor에서 작업해야하는 경우 AsynchronousItemProcessor를 이용해 결과를 ItemWriter에게 넘기는 것이 아니라 Future를 넘겨 줄 수 있다.

마찬가지로 ItemWriter에서는 Future를 처리하기 위해 AsynchronousItemWriter를 사용하여 처리하면된다.


원격 청킹

청크단위의 작업을 하나의 인스턴스에서 모두 처리하는 것이 아닌 마스터 노드가 청크를 메세지로 구성(메세지 브로커와 같은)하여 여러 워커 노드에게 전달하고 그 결과를 마스터에게 다시 알려줌으로써 작업을 마치는 작업이다. 워커 노드가 작업을 마치고 다시 마스터 노드에게 결과를 전송해야하므로 네트워크 사용량을 고려해야한다.


파티셔닝

원격 청킹과 다르게 같은 마스터 노드는 워커 노드에게 메세지 발행을 따로 하지 않고 작업을 생성(ExecutionContexts)하여 지시한다. 마스터 노드가 작업을 지시하면서 JobRepository에 어떠한 작업이 자신이 지시한 작업인지 알게됨으로써 워커노드들의 작업이 끝나고 별도의 내구성이 있는 통신을 통해 보고할 필요가 없다.


프로젝트 설정

@EnableBatchProcessing 애너테이션은 배치작업을 위한 인프라스트럭쳐 스프링 빈에 대한 부트스트랩 역할을 한다.

대표적으로 아래 빈을 모두 사용할 수 있다.

  • JobRepository
  • JobLauncher
  • JobExplorer
  • JobRegistry
  • PlatformTransactionManager
  • JobBuilderFactory
  • StepBuilderFactory

기초적인 컴포넌트 스캔, 스프링의 자동설정을 위한 @SpringBootApplication 도 사용하도록 하자.
그리고 JobRepository를 사용하기 위한 DataSource를 선언해줘야한다.


잡 실행하기

스프링 배치 잡의 실행은 JobLauncherCommandLineRunnerJobLauncher 을 이용해 진행한다.

스터디내 질문