Spring Batch - 개요 및 아키텍처
배치 처리란?
상호작용이나 중단 없이 유한한 양의 데이터를 처리하는 것
스프링 배치 소개
스프링 배치 탄생 배경
자바 기반 표준 배치 기술 부재.
I/O, Network, TCP, UDP, Thread, JDBC 등은 자바에서 표준으로 정해져있지만 (*표준으로 정해져있다? => JSR(Java Specification Requests)에 있다.) 배치와 관련된 기술적인 표준은 없었다.
스프링 배치 프레임워크의 역사
- Accenture사와 스프링소스(SpringSource)사 간의 협업으로 개발됐다.
- Accenture사의 배치 아키텍처를 구현하면서 쌓은 기술적인 경험과 노하우
- SpringSource(현재는 Pivotal)사의 깊이 있는 기술적 기반과 스프링의 프로그래밍 모델
배치 처리에 관련된 문제
일반적인 소프트웨어 아키텍처는 공통적으로 사용성(usability), 유지보수성(maintainablility), 확장성(scalability)등 여러 속성을 갖는다. 배치는 GUI 애플리케이션이 갖는 대부분의 문제가 유효하지 않지만 이러한 속성들이 기존과는 다른 측면으로 관련되어 있다.
- 사용성(usability)
: 코드에 관한, 즉 오류 처리 및 유지 보수성과 관련이 있다.- 공통 컴포턴트를 쉽게 확장해 새로운 기능을 추가할 수 있는가?
- 기존 컴포턴트를 변경할 때 시스템 전체에 미치는 영향을 알 수 있도록 단위 테스트가 잘 마련되어 있는가?
- 잡이 실패할 때 디버깅에 오랜 시간을 소비하지 않고 언제, 어디서, 왜 실패했는지 알 수 있는가?
- 확장성(scalability)
: 기업이 밤새 100만 건 이상의 트랜잭션을 처리하는 배치를 갖고 있는 것은 그리 드문 일이 아니다. 배치가 처리할 수 있어야 하는 규모는 과거에 개발했던 웹 애플리케이션보다 몇 자리 수 이상 큰 경우가 많다. - 가용성(availability)
: 배치 처리는 일반적으로 항상 실행되는 것이 아닌, 보통 약속이 정해져있다. 주어진 시간에 잡이 실행된다.- 필요할 때 바로 배치 처리를 수행할 수 있는가?
- 허용된 시간 내에 잡을 수행함으로써 다른 시스템에 영향을 미치지 않게 할 수 있는가?
- 보안
: 배치 처리에서 보안의 역할은 데이터를 안전하게 저장하는 것이다.- 민감한 데이터베이스 필드는 암호화되어 있는가?
- 실수로 개인 정보를 로그로 남기지는 않는가?
- 외부 시스템으로의 접근 자격이 적절한 방식으로 보안을 유지하고 있는가?
배치 핵심 패턴
- Read - 데이터 베이스, 파일, 큐에서 다량의 데이터를 조회.
- Process - 특정 방법으로 데이터를 가공.
- Write - 데이터를 수정된 양식으로 저장.
Read, Process, Write는 데이터베이스의 ETL 처리 용어와 동일하다. Extract(추출), Transform(변환), Load(적재)
스프링 배치의 청크 기반 처리 및 압도적인 확장 기능은 ETL 워크로드에 자연스럽게 들어맞는다.
배치 시나리오
- 배치 프로세스를 주기적으로 커밋
: 대용량의 데이터를 한번에 커밋하게되면 메모리에 부담이 되고 리스크가 크다. 어떤 단위로 데이터를 쪼개서 커밋할 것인지, 커밋 전략이 중요하다. 최소한의 자원으로 최대한의 성능을 낼 수 있어야 한다. - 동시 다발적인 Job의 배치 처리, 대용량 병렬 처리
: Job간의 간섭이 없어야 하며 멀티 스레드로 병렬 처리를 할 수 있어야 한다. - 실패 후 수동 또는 스케줄링에 의한 재시작
: 예외나 오류로 인해 얼마든지 실패할 수 있다. 얼만큼 빨리 대처를 하느냐가 중요하다. - 의존 관계가 있는 Step 여러 개를 순차적으로 처리
: Step1, Step2, Step3, … 순차적으로 처리하는 것이 시나리오에 포함이 되어야 한다. - 조건적 Flow 구성을 통한 체계적이고 유연한 배치 모델 구성
: 경우에 따라 Step1 처리 후 조건에 의해 Step2 또는 Step3로 분기처리 될 수 있다. 조건에 의한 흐름을 유연하게 구성하는 것을 flow 라고 한다. - 반복, 재시도, Skip 처리
: 즉시 복구될 수 있는 잠깐의 네트워크 장애로 인해 Job이 실패하지 않기 위해 재시도 처리를 한다.
또, 중요하지 않은 예외는 skip 처리하여 전체 Job이 실행될 수 있도록 한다.
아키텍처
- Application
스프링 배치 프레임 워크를 통해 개발자가 만든 모든 Batch Job, custom code를 포함한다. 공통적인 기반 기술은 프레임워크가 담당하므로 개발자는 업무 로직의 구현에만 집중할 수 있다.
Application 레이어가 최상위에 있는 것이 아니라, 다른 두 레이어인 Core 레이어와 Infrastructure 레이어를 감싼다. 이유는 개발자가 개발하는 대부분의 코드가 Core 레이어와 함께 동작하는 Application 레이어이지만, 때로는 커스텀 Reader나 커스텀 Writer와 같이 인프라인스트럭처의 일부를 만들기도 하기 때문이다.
- Batch Core
Job을 실행, 모니터링, 관리하는 API로 구성된다. Job을 어떻게 구성 하겠다는 Job 명세서 구성과 설정을 위한 클래스들이 속해있다. 배치 도메인을 정의하는 모든 부분이 포함된다.
Job, Step, Flow, 잡 실행에 사용되는 인터페이스 (JobLauncher 및 JobParameters)등이 속한다.
- Batch Infrastructure
Application, Core 모두 공통 Infrastructure 위에서 빌드된다.
어떤 처리를 수행하려면 파일, 데이터베이스 등으로부터 읽고 쓸 수 있어야 하며 잡 수행에 실패한 이후 재시도될 때 어떤 일을 수행할지를 다룰 수 있어야 한다. 이러한 부분을 공통 인프라스트럭처로 간주하며 프레임 워크의 Infrastructure 컴포넌트 내에 들어있다.
Job 실행의 흐름과 처리를 위한 틀을 제공한다.
Reader, Processor, Writer, Skip, Retry등이 속한다.
ref.