WantAirpod

배치 처리

퇴근 시간 이후 기계를 놀리면 이만저만 낭비가 아니므로 당일 처리할 업무를 모아놨다가 한꺼번에 처리하면 어떨까 고민하게 되었고 이것이 배치 처리의 발전으로 이어졌다.

배치 처리는 보통 대용량 데이터를 대상으로 실행되며 그 처리 시간이 아키텍처 및 구현상 결정적인 요소로 작용한다.

스프링 배치 등장 이유

스프링 배치 애플리케이션은 보통 대용량 데이터를 읽어 변환된 형식으로 다시 출력합니다. 드랜잭션 경계, 입력 크기, 동시성, 처리 단계의 차수 등 연계까지 생각하면 결정해야 할 요소가 많습니다. B2B거래, CSV파일을 로드해 DB레코드를 처리하는 일은 가장 흔한 배치 사례이다. DB레코드 자체를 수정하는 게 출력 결과인 경우도 있다.

스프링 배치가 하지 못하는 일

중요한 부분은 구현하는 개발자의 재량에 맡깁니다.  이미 있는 건 가급적 다시 안 만들겠다는 스프링 철학 토대

스프링 배치 저장소

JobRepository (메타 데이터 항목 저장 용도로 스프링 배치가 기본 제공하는 인터페이스)

.

런타임 메타데아터 모델

스프링 배치는 잡 단위로 모든 정보와 메티데이터를 총괄한 JobRepository를 중심으로 작동하며 각 잡은 하나 이상의 순차적인 스텝으로 구성됩니다.

스프링 배치 구조

스프링 배치는 백엔드의 배치처리 기능을 구현하는데 사용하는 프레임워크이다. 

배치의 일반적인 시나리오는 다음과 같은 3단계로 이루어집니다.

1. 읽기(Read) : DB에서 특정 데이터 레코드를 읽는다.
2. 처리(Processing) : 원하는 방식으로 데이터 가공/처리 합니다.
3. 쓰기(Write) : 수정된 데이터를 다시 저장소(DB)에 저장합니다.

배치 처리 

• job과 step은 1:M
• Step과 itemReader, itemProcessor, itemWirter 1:1 관계이다.
• Job이라는 하나의 큰 일감(Job)에 여러 단계 (Step)을 두고, 각 단계를 배치의 기본 흐름대로 구성합니다.

Job

• Job은 배치 처리 과정을 하나의 단위로 만들어 표현한 객체입니다. 또한 전체 배치 처리에 있어 항상 최상단 계층에 있습니다.
• 위에서 하나의 Job(일감) 안에는 여러 Step(단계)이 있다고 설명했던 바와 같이 스프링 배치에서 Job 객체는 여러 Step 인스턴스를 포함하는 컨테이너 입니다.
• Job 객체를 만드는 빌더는 여러 개 있습니다. 여러 빌더를 통합하여 처리하는 공장인 JobBuilderFactory로 원하는 Job을 쉽게 만들수 있습니다.

public SimpleJobBuilder start(Step step){
	/* (1) Step을 추가해서 가장 기본이 되는 SimpleJobBuilder를 생성합니다. */
    return new SimpleJobBuilder(this).start(step); 
}

public JobFlowBuilder start(Flow flow){
	/* (2) Flow를 실행할 JobFlowBulder를 생성한다. */
	return new JobFlowBuilder(this).start(flow);
}

public JobFlowBuilder flow(Step step){
	/* (3) Step을 실행할 FlowJobBulder를 생성한다. */
    return new JobFlowBuilder(this).start(step);
}

• JobBuilder는 직접적으로 Job을 생성하는 것이 아니라 별도의 구체적 빌더를 생성하여 변환하여서 경우에 따라 Job생성 방법이 모두 다를수 있는 점을 유연하게 처리할 수 있습니다.

JobInstance 

• JobInstance는 배치 처리에서 Job이 실행 될 때 하나의 Job 실행 단위이다.  만약 하루에 한 번 씩 배치의 Job이 실행된다면 어제와 오늘 실행 각각 Job을 JobInstance라고 부를 수  있습니다.
• 각각의 JobInstance는 하나의 JobExecution을 갖는 것은 아니다. 오늘 Job이 실행 했는데 실패했다면 다음날 동일한 JobInstance를 가지고 또 실행됩니다.
• Job 실행이 실패한다면 Jobinstance가 끝난것으로 간주하지 않기 때문입니다. 그렇다면 JobInstance는 어제 실패한 JobExecution과 오늘 성공한 JobExecution 두 개를 가지게 됩니다. 즉 JobExecution은 여러개 가질 수 있습니다.

요약
1. JobInstance는 Job이 실행 된다는 실행 단위
2. JobInstance는 어제 실행 한것이랑 오늘 실행한것이 같을수 없다는 것
3, JobInstance는 하나의 jobexecutiion을  갖는게 아니라는 것 왜냐면 성공,실패에 따라서 두 개의 JobExecution을 가질 수 있기 때문에. 그러면 JobExecution이란?

JobExcution

• JobExcution은 JobIstance에 대한 한 번의 실행을 나타내는 객체이다. 만약 오늘 Job이 실패해 내일 다시 동일한 Job을 실행하면 오늘/내일의 실행 모두 JobInstance 를 사용합니다.
• 실제로 JobExcution 인터페이스르 보면 Job 실행에 대한 정보를 담고 있는 도메인 객체가 있습니다.
• JobExcution은 JobInstace, 배치 실행 상태, 시작 시간, 끝난 시간, 실패했을 때 메시지 등의 정보를 담고 있습니다. JobExcution 객체 안에 어떤 실행 정보를 포함하고 있습니다. 

요약
1. JobExcution은 JobInstance의 한 번의 실행을 나타내는 객체이다. 
2. 오늘 Job이 실패하면 내일 동일한 Job이 실행된다. 그러면 오늘/내일 실행 모두 JobInstance를 사용한다.
3. JobExcution을 보면 Job에 대한 정보가 담겨있다.
4. JobExcution 에는 JobInstace, 배치 실행 상태, 시작 시간, 끝난 시간, 실패했을 때 메시지를 가지고 있다. 

JobParameters

• JobParameters는 Job이 실행될 때 필요한 파라미터들은 Map 타입으로 지정하는 객체입니다.
• JobParameters는 JobInstance를 구분하는 기준이 되기도 합니다.
• JobParameters와 Jobinstance는 1:1 관계이다.

Step

• Step은 실질적인 배치 처리를 정의하고 제어 하는데 필요한 모든 정보가 있는 도메인 객체, Job을 처리하는 실질적인 단위로 쓰인다.
• 모든 Job에는 1개 이상의 Step이 있어야한다.

요약
1. Job을 처리하는 실질적인 단위

StepExecution

• Job에 JobExecution Job 실행 정보가 있다면 Step에는 StepExecution이라는 Step 실행 정보를 담는 객체가 있다.

JobRepository

• JobRepository는 배치 처리 정보를 담고 있는 매커니즘입니다. 어떤 Job이 실행되었으면 몇 번 실행되었고 언제 끝났는지 등 배치 처리에 대한 메타데이터를 저장합니다.
• 예를들어 Job하나가 실행되면 JobRepository에서는 배치 실행에 관련된 정보를 담고 있는 도메인 JobExecution을 생성합니다.
• JobRepository는 Step의 실행 정보를 담고 있는 StepExecution도 저장소에 저장하여 전체 메타데이터를 저장/관리하는 역할을 수행합니다.

요약
1. 배치 처리 정보를 담고 있는 저장소이다. 
2. Job이 실행되면 JobExecution을 생성합니다.

JobLauncher

• JobLauncher는 Job, JobParameters와 함께 배치를 실행하는 인터페이스이다.

ItemReader

• ItemReader는 Step의 대상이 되는 배치 데이터를 읽어오는 인터페이스입니다. File, XML Db등 여러 타입의 데이터를 읽어올 수 있다.

ItemProcessor

• ItemProcessor는 ItemReader로 읽어 온 배치 데이터를 변환하는 역할을 수행합니다. 이것을 분리하는 이유는
• 비즈니스 로직의 분리 : ItemWriter는 저장을 수행하고, ItemProcessor는 로직 처리만 수행해 역할을 명확하게 분리합니다.
• 읽어온 배치 데이터와 씌여질 데이터의 타입이 다를 경우에 대응할 수 있기 때문입니다.

요약
1. 읽어온 배치 데이터를 변환하는 역할을 한다.
2. 읽어온 배치 데이터와 씌여질 데이터의 타입이 다를 경우에 대응가능.

ItemWriter

• ItemWriter는 배치 데이터를 저장합니다. 일반적으로 DB나 파일에 저정합니다.
• ItemWriter도 ItemReader와 비슷한 방식으로 구현합니다. 제네릭으로 원하는 타입을 받고 write() 메서드는 List를 사용해서 저장한 타입의 리스트를 매개변수로 받습니다.

잡은 보통 실행 시점에 JobParameter와 엮어 Job 자신의 런타임 로직을 매개변수화합니다.
(예를 들면 특정 날짜에 해당되는 레코드만 처리하는 잡이 그런 경우이다.)
그리고 잡 실행을 식별하기 위해 JobInstance를 생성합니다. 
JobParameter가 연관 되어 있으니 JobInstance는 하나밖에 없겠죠.
같은 JobInstance(즉, 같은 Job+ JobParameter 세트가 실행되는 것을 jobExecution이라고 부릅니다.)
JobExecution은 잡 버번에 대한 런타임 컨텍스트로, 이상적으로는 JobInstance당 하나의 jobExecution은 잡 (제일 처음 JobInstance가 실행될 때 만들어진 JobExecution)이 존재합니다. 
그러나 도중 에러가 나면 JobInstance는 다시 시작해야하고 그러다 보면 jobExecution이 하나 더 만들어지겠죠.
초기 잡에 속한 각 스템의 JobExecution에는 SteExecution이 있습니다.

배치 애플리케이션

배치를 적용한 애플리케이션

• 매출 데이터를 이용한 일매출 집계
• 매우 큰 데이터를 활용한 보험급여 결정
• 트랜잭션 방식으로 포맷, 유효성 확인 및 처리가 필요한 내부 및 외부 시스템에서 수신한 정보를 기록 시스템으로 통합

배치(Batch)란 일괄처리 란 뜻을 가지고 있다.

시사점
웹 어플리케이션 = Tomcat + Spring MVC 라고 떠올리면 큰 데이터를 읽고, 가공하고, 저장한다면 해당 서버는 순식간에 CPU, I/O, 등을 다 써버려서 Request처리를 하지 못하게 됩니다.집계기능은 하루에 1번 수행하게 됩니다. 이를 위해 API를 구성하는 것은 너무 낭비이다. 여기서 추가로 데이터가 너무 많아서 처리가 실패하면 비효율적이게 된다.(끝판왕)또한, 누군가 집계 함수를 실행시켰는데 다른 누군가 또 실행시켜 집계 데이터가 2배로 뻥튀기 될 수도 있다. 

따라서 같은 파라미터로 같은 함수를 실행할 경우 이미 실행한 적이 있어 실패하는 기능을 지원하면 좋을 것 같음.

바로 이런 단발성으로 대용량의 데이터를 처리하는 어플리케이션을 배치 어플리케이션이라고 합니다.

Spring MVC를 사용하기 때문에 비즈니스 로직에 최대한 집중 할 수 있다.

Spring 진영에선 Spring Batch가 있다.

대용량 데이터 - 배치 어플리케이션은 대량의 데이터를 가져오거나, 전달하거나, 계산하는 등의 처리

자동화 - 심각한 문제 해결을 제외하고는 사용자의 개입 없이 실행
견고성 - 잘못된 데이터를 충돌/중단 없이 처리할 수 있어야한다.

신뢰성 - ?

성능 - 지정한 시간 안에 처리를 완료하거나 동시에 실행하는 다른 App을 방해하지 않도록 수행

Spring의 3대요소 : 1) DI, 2)AOP, 3)서비스추상화

현재 Spring Batch 4.0 (Spring Boot 2.0) 에서 지원하는 Reader & Writer 

일매출 집계

많은 거래가 이루어지는 커머스 사이트의 경우 하루 거래건이 50만~100만까지 나옵니다. 이럴 경우 이와 관련된 데이터는 최소 100만~200만 row 이상입니다. 한달이면 5000만 ~1억까지 될수도 있습니다. 이를 실시간으로 집계 쿼리로 해결하기엔 조회시간이나 서버 부하가 심합니다. 그래서 매일 새벽에 전날 매출 집계 데이터를 만들어서 외부 요청이 올 경우 미리 만들어준 집계 데이터를 바로 전달하면 성능과 부하를 모두 잡을 수 잇습니다. 

Spring Batch 프로젝트 개발 환경

• IntelliJ IDEA
• Spring Boot
• Java 8
• Gradle

lombok 기능을 많이 사용한다. lombok 플러그인을 본인의 IDE에 맞게 설치하면 좋다.

배치의 도메인 용어

JobLaucncher <-> jobRepository

Job <-> jobRepository

Stop <-> jobRepository

• ItemReader
• ItemProcessor
• ItemWirter