Spring Batch

03. SpringBatch 핵심 개념

이번 포스트에서는 Spring Batch의 핵심 개념과 관련 용어를 살펴보자.

핵심 개념과 관련 용어

기본 흐름

다음 그림은 Spring Batch의 주요 요소들을 나타낸다. 파란색 계열은 Spring Batch Framework가 제공하는 인프라 및 관리 영역으로 개발자는 이 구조를 설정하고 구성한다. 노란색 계열을 실제 비지니스 로직이 들어가는 부분으로 개발자는 '어디서 데이터를 읽어서', '어떤 처리를 한 후', '어디에 저장할 지'를 구체적으로 작성한다.

계층 구조 및 흐름

JobOperator → Job
- JobOperator는 배치 작업을 제어(시작, 중지, 재시작)하는 인터페이스
- 사용자나 스케줄러가 JobOperator를 통해 Job을 실행한다.
Job (1) →(*) Step
- Job은 전체 배치의 껍데기(컨테이너)이고, 실제 처리는 Step들이 순서대로 수행한다.
- 하나의 Job이 여러 개의 Step으로 구성됨
Step → ItemReader /ItemProcessor/ ItemWriter
- 하나의 Step(특히 Chunk 기반 Step)은 기본적으로 하나의 ItemReader와 하나의 ItemWriter를 가진다
- ItemReader: 데이터를 읽어오는 역할
- ItemProcessor: 데이터를 가공하는 역할 (optional)
- ItemWriter: 데이터를 쓰는 역할

데이터 저장 및 상태 관리

JobRepository
- 모든 주요 컴포넌트(JobOperator, Job, Step)가 JobRepository와 양방향 통신
- 배치가 실행될 때마다 현재 상태(시작 시간, 종료 시간, 성공/실패 여부, 읽은 데이터 개수 등)를 DB에 저장(CRUD)
- 이를 위한 DB Schema는 Spring Batch에서 제공
- 이 저장된 정보 덕분에 배치가 실패했을 때, 어디서부터 재시작해야 할지 파악 가능

구성 요소

JobOperator와 JobParameters

JobOperator는 Job을 실행시키기 위한 객체이다. JobOperator는 Job을 실행하면서 필요한 파라미터를 전달하는데 이를 JobParameters라고 한다. Job이 특정 JobParameters와 결합된 논리적 실행 단위를 JobInstance라고 한다.

하나의 Job은 JobParameters에 따라 여러개가 생성될 수 있다. 즉 2007/05/05로 실행되는 JobInstance와 2007/05/06으로 실행되는 JobInstance는 다르다.

여기서 중요한 내용이 있는데 JobParameter는 Job을 구별하는 구분자가 된다. 내부적으로 JobParameters를 이용해서 키를 만들고 이것을 통해 JobInstance를 구별한다. 만약 동일한 키로 구성된 JobParameters 가 들어온다면 기존의 JobInstance를 반환한다. 물론 그 키에 해당하는 JobInstance가 없다면 새로 만들고 등록한다.

public JobInstance getJobInstance(final String jobName, final JobParameters jobParameters) {
  String jobKey = jobKeyGenerator.generateKey(jobParameters);
  ..
}

JobInstance의 실행 결과는 JobExecution 객체로 반환되는데 여기는 Job의 종료 상태(Status)가 저장된다.

2007/05/05일의 Job은 처음 시도에 성공할 수도 있다. 그럼 그 Job은 종료된다.

하지만 실패한다면 실패의 정보를 기록하고 네트워크 재시작 등 실패 원인에 대한 조치를 취하고 다시 시도할 수 있다. 이때도 2007/05/05를 Jobparameters로 전달할 꺼고 동일한 JobInstance가 생성된다. 이제 두 번째 시도에서 성공할 수도 있다. 이처럼 JobInstance는 여러개의 JobExecution을 가질 수 있다.

JobInstance는 일반 객체와 달리 identity를 결정하는 기준은 JobParameter이다. 즉 2007/05/05로 진행되는 JobInstance는 하나의 객체가 된다. 실패한 Job을 재시도 한다는 것은 마치 동일한 학번의 수강생이 재시험을 보는것과 같은 개념이다.

JobInstance와 JobExecution

Spring Batch의 중요한 특징 두 가지는 "동일한 작업은 중복되서 처리되면 안된다"와 "실패 후 재시작 시 원하는 지점에서 시작해야 한다"라고 볼 수 있다. 그러기 위해서는 JobParameters와 연관된 Job의 논리적인 단위인 JobInstance의 구분이 매우 중요하다.

이 JobInstance의 실행 결과물인 JobExecution은 작업의 종료 상태(Status: COMPLETED, FAILED, ...)를 갖는다. 하나의 JobInstance가 실패 후 다시 시도하고 다시 시도해서 성공할 수 있기 때문에 여러 개의 JobExecution을 가지며 결국 JobExecution은 '시도'라는 의미를 가지게 된다.

JobExecution(1)은 정의된 Step의 순서에 따라 Step A 실행 후 결과를 StepExecution(A)에 저장한다(성공이라고 가정). 다시 Step B를 실행하는데 여기서 실패하게 되면 StepExecution(B)는 실패하게 되고 JobExecution(1)의 최종 상태는 FAILED가 된다.

이후 에러가 고쳐지고 동일한 JobInstance로 두번째 시도가 재시작한다. 즉 JobExecution(2)가 생성되고 Spring Batch는 Repository를 확인해서 이전 성공 기록(Step A 성공)을 확인 후 건너뛰고 실패로 남아있던 Step B 부터 시작하게 된다.

최종적으로 모든 작업이 마무리 되면 JobExecution(2)는 COMPLETED가 된다.

Step

Step은 Job 내부의 독립적이고 순차적인 처리 단계로 모든 Job은 하나 이상의 Step으로 구성된다. 그리고 하나의 Step은 실제 비지니스 로직(데이터 읽기/처리/쓰기)을 담당하는 ItemReader, ItemProcessor, ItemWriter로 구성된다.

예를 들어 "매월말 결재 건에 대한 포인트 적립 Job"은 다음의 Step으로 구성할 수 있다.

Step을 구성하는 ItemReader, ItemProcessor, ItemWriter의 동작은 이름그대로이다.

컴포넌트	역할	예
ItemReader	원본(File, DB, API)에서 데이터를 읽어오는 역할	DB에서 결재 정보 얻기
ItemProcessor	읽은 데이터에 대한 가공	결재 금액 기준 Point 계산
ItemWriter	대상지(File, DB)등에 가공된 데이터 저장	DB에 Point 정보 저장

StepExecution

JobInstance는 Job에 등록된 Step들을 순차적으로 처리하는데 각 Step의 동작 결과는 StepExecution에 저장된다. 그리고 StepExecution의 최종 상태가 JobExecution에 취합된다.

ExecutionContext

ExecutionContext는 배치 작업 실행 중 상태 정보를 저장하고 복원하기 위해 사용하는 저장소이다. ExecutionContext는 Key-Value 형태로 데이터를 관리하며 배치가 중단되었을 때 어디까지 처리 되었는지를 기억하고 재시작할 수 있게 한다.

executionContext.putLong(getKey(LINES_READ_COUNT), reader.getPosition());

ExecutionContext는 범위(scope)에 따라 JobExecutionContext와 StepExecution으로 나뉜다.

JobExecutionContext: Job 전체에서 공유되는 정보로 모든 Step에서 접근 가능하며 DB의 BATCH_JOB_EXECUTION_CONTEXT에 저장된다.
StepExecutionContext: 특정 Step에서만 사용되는 정보로 해당 Step에서만 접근 가능하며 DB의 BATCH_STEP_EXECUTION_CONTEXT에 저장된다.

Batch 작업이 실행되는 동안 상태를 계속 갱신하다가 트랜젝션이 커밋되는 순간 DB에 정구히 저장된다.

Job 동작 시나리오

Step과 StepExecution

다음의 시나리오를 생각해보자.

Job이 Step A -> Step B의 순서로 진행된다고 생각해보자. 그런데 Step B를 실행하면서 오류가 발생한다. 개발자는 오류를 수정하고 도시 Job을 실행하면 이전 실패 지점부터 다시 시작해서 작업을 성공적으로 마무리 한다.

첫 번째 시도

2007/05/05를 JobParameters로 JobInstance가 생성된다.
Step A 실행 -> 성공 -> StepExecution A-1 생성(Status = COMPLETED)
Step B 실행 -> 실패 -> StepExecution B-1 생성(Status = FAILED)
- commit 시점에 성공한 지점까지의 정보는 BATCH_STEP_EXECUTION_CONTEXT에 저장
결과로 JobExecution A는 FAILED로 기록됨

DB 테이블의 상태 변화

BATCH_JOB_INSTANCE

JOB_INSTANCE_ID	JOB_NAME	JOB_KEY
1	pointJob	2007/05/05의 해시값

BATCH_JOB_EXECUTION

JOB_EXECUTION_ID	JOB_INSTANCE_ID	STATUS	START_TIME	END_TIME
1	1	FAILED	2024-01-01 00:00:00	2024-01-01 00:15:23

BATCH_STEP_EXECUTION

STEP_EXECUTION_ID	JOB_EXECUTION_ID	STEP_NAME	STATUS	COMMIT_COUNT
1	1	stepA	COMPLETED	16
2	1	stepB	FAILED	5

이후 개발자는 Step B 실패 원인을 디버깅

두 번째 시도

다시 2007/05/05를 JobParameters로 JobInstance 조회 및 재사용
Step A 확인 -> 이미 성공한 이력 확인 -> SKIP
Step B 확인 -> 지난번 시도가 실패함을 확인 -> StepExecution B-2 생성 및 실행
- 이때 시작 지점은 BATCH_STEP_EXECUTION_CONTEXT 에서 확인
결과로 JobExecution B는 COMPLETED로 반환