DEV/Spring Boot

Spring - Batch(배치)

wooki4307 2020. 2. 12. 13:37

Spring Batch(스프링 배치)

Batch의 장점


1. 대용량 처리 가능
2. 자동화 기능
3. 비즈니스로직에 대한 이해
  * 비즈니스 로직이란?
    - 사용자(유저)가 원하는 행위를 노출하는 방법.

Bacth의 구조


- 기본 Spring Boot Batch의 데이터 흐름은 Spring Batch의 데이터 흐름과 동일 
1. 읽기(Read)
  - 데이터 저장소(ex. DB)에서 레코드 읽기(SELECT)
2. 처리(Processing)
  - 읽은 레코드를 처리
3. 쓰기(Write)
  - 가공된 데이터를 데이터 저장소(ex. DB)에 쓰기(UPDATE,INSERT)

Batch의 Job? Step?


- Job: 하나의 전체 프로세스 단위을 정의
- Step: 프로세스 단위의 단계를 정의
-> 1개의 Job은 여러개의 Step으로 진행이 가능하다.(1:M = Job:Step)
   (Ex1. 1.푸시 발송 Job은 init Step(초기화 단계) 
        2.AOS,iOS에 대한 처리를 나누는 Step 
        3.AOS,iOS에 대한 데이터 처리 Step 
        4.중복값 처리에 대한 Step(Sample) 이에 대한 Step은 변경 가능)

해당 Job과 Step에 대해 새로운 예를 들자면 손쉽게 게시판을 예로 설명을 해보면 다음과 같습니다. 그 예에 대한 가정하는 사항은 다음과 같습니다.

  1. 게시판을 운영하는 사이트를 운영하고 있다.
  2. 휴면계정에 대한 데이터 처리를 하고 싶다.

2번 사항의 휴면계정에 대한 데이터 삭제를 하나의 Job으로 생각 ( job_delete_inactive의 JOB ) 쉽게 Step을 구성하면 해당 Step하나에 끝내자면 특정 기간동안 유입이 없던 데이터에 대한 가공 처리를 하는 Step으로 지정하면 되지만 Step을 좀더 세분화 하자면 다음과 같이 구성될 수 있다.


AS-IS:
Step 1 -> 특정 기간동안 미로그인 대상자 삭제...

상위 Step을 세분화 하였을 시 다음과 같이 세분화 가능할 것이다.


TO-BE:
Step 1 -> 특정 기간동안 미로그인 대상자 추출(고객에 대한 등급, 웹/앱별 미로그인 대상자 분류)
Step 2 -> 고객 등급별로 미로그인 대상자 분류
Step 3 -> 웹/앱 별 미로그인 대상자 분류
Step 4 -> 미로그인 대상자 삭제...

그렇다면 Job의 구조는 어떻게 되어있나?


- JobInstance
  -> Instance는 다른 우리말로 생성자라고 정의가능하다. JobInstance는 이러한 Job의 생성자가 실행하는 단위이다.
  -> JobInstance는 하나일때 여러 JobExecution상태를 가질 수 있다.
  -> 예를 들어, 휴면 계정 처리를 매달 1일 2번 처리를 한다고 할때, 1회차에 대한 JobInstance, 
     2회차에 대한 JobInstance를 생성하여 각각의 동일한 Instance(생성자)가 여러 Execution을 가질 수 있다.
- JobExcution
  -> 하나의 JobInstance가 여러 JobExecution을 가질 수 있다고 보면, 
     JobExecution은 무엇인가? 라는 물음에 JobExecution은 JobInstance가 실행하는 실행의 단위라고 정의할 수 있다.
  -> 정확히 말하자면, 위에 기재한것 처럼 동일하지만 각기 다른 시간에 실행된 JobInstance가 그때 실행된 상태의 정보
     (해당 JobInstance, 실행 상태, 시작 시간, 끝난 시간, 실패 메시지 등)를 담는다.
- JobParameter
  -> Job이 실행될때의 파라미터이다. 즉, JobParameters의 정보로 하나의 JobInstance를 생성.

쉽게 풀이를 내 나름대로 하자면 다음과 같다고 생각한다.


1개의 Job이 실행이 되면 각 실행마다 하나의 Instance를 생성,
그 Instance는 Execution의 상태에 따라 실행할지, 멈출지, 재실행할지에 대한 관계를 가지면서 1:N관계를 가진다. JobParameter의 경우 
Job이 실행되는 조건을 의미한다. 따라서 조건이 같은 경우는 같은 Job에서 같은 Instance를 재생성 하지 않으므로 
Instance와 Parameter는 1:1관계를 가진다. 이말인 즉, Parameter는 Instance를 구분하는 기준이다.

그러면 Step의 구조는 어떻게?


- Step은 Job을 처리하는 단계의 단위이다.
- StepExecution
  -> 특정 Job이 실행될때 각 Step별로 생성되는 실행 정보를 담는 Object이다.

Job의 처리 정보는 어디에?


- JobRepository
  -> 배치 처리 정보를 담고있는 원리구조이다.
- 배치가 처리하는 정보는 배치 처리 정보를 담고있다. 저장되는 정보로는 Job실행 횟수, 종료시간 등 메타데이터를 저장한다.
- 하나의 Job이 실행될때 JobRepository가 배치 실행에 관련된 도메인인 JobExecution을 실행한다.

Job의 실행시점은?


- JobLauncher
  -> 배치를 실행하는 인터페이스 이다. 해당 실행 기준은 Job과 JobParameter값을 기준으로 실행이 된다.

배치의 시나리오는 언제나와?


- 의문점은 배치는 읽기, 가공/처리 , 쓰기 순으로 진행이 된다고 했는데, 언제 해당 과정이 진행되는지 의문이 생겼다.
- 해당 배치의 효율을 담당하는 실질적인 부분이다. 해당 부분에서 어떤 데이터를 읽고 어떻게 처리하느냐에 따라 배치의 
  성능이 크게 좌지우지됨
- ItemReader
  -> 특정 스텝 실행시 읽어오는 데이터로, DB에 국한되지 않고 여러 형태의 데이터로 데이터를 읽어올 수 있음.
- ItemProcessor
  -> 배치의 데이터를 가공/처리하는 부분으로 데이터를 저장하기 전 가공하는 단계이다. 
  => Q. 왜 이 단계에서 저장을 안해?
  => A. 나만 든 의문일 수도 있는데, 왜 이 단계에서 쓰기 단계까지 안가느냐... 했는데 다음과 같은 경우때문에
        나눠지지 않았나 싶다. 일단 비즈니스로직 분류를 위해서 나뉘어졌다. 만약에 분류가 필요없다면 Processor에서 
        Reader부터 Writer 진행해도 되지만 역할을 명확히 구분하기 위해서 나뉘어졌고, 또 다른 이유는 
        책의 내용을 요약하자면 만약 Processor에서 한번에 처리한다면? 만약 DB로 읽고 쓰다가 File을 읽고쓴다면? DB로 읽고 File로 쓴다면?
        이런 경우를 대응하기 위해서 Processor부분에선 가공/처리만 진행한다고 정리할 수 있을 것 같다.
- ItemWriter
  -> Processor단계에서 가공/처리된 데이터를 저장하는 단계로 DB나 File등과 같은 형태로 저장하는 단계이다.

결론 요약


- 배치는 대용량의 데이터를 가공/처리하는 단계로 구성된다.
- 구성도는 다음과 같이 정리가 가능할 거 같다.
- 업무의 내용을 더 설명하자면 Step 안에는 하나이상의 Tasklet 단위로 움직인다.
  해당 Tasklet은 스레드 실행 단위이고 그 각각의 스레드는 트랜잭션 단위인 Chunk 단위로 실행됨

 

배치 프로세스 흐름도