개요

본 장에서는 배치의 용어, 종류, 처리구조, 구성요소에 대해 설명한다.

1. 배치 용어

다음은 배치에서 사용하는 용어에 대하여 간략하게 설명하는 표이다.

용어	설명
배치작업(JOB)	배치 업무를 처리하기 위한 플로우로 구성된 배치작업의 실행 및 재실행 단위로 플로우를 기술하는 XML 설정으로 작성된다. 흔히 규모가 큰 배치작업은 외부 프로그램을 호출하는 것을 포함하여 복잡한 처리절차로 구성되지만 배치 어플리케이션에서 정의하는 배치작업은 배치 어플리케이션으로 구현된 단위 Step을 호출하는 플로우만으로 한정한다.
스텝(Step)	배치작업을 구성하는 업무 구현의 최소단위이다. 배치 작업의 구성요소로만 동작할 뿐 개별적으로 실행될 수 없으며 배치작업의 재실행 시 개별 Step은 조건에 따라 재실행되거나 실행에서 제외될 수 있다.
아이템(Item)	배치 Step에서 업무 요건에 따라 처리할 데이터의 최소단위이다. DB 또는 파일 리소스에서 건 별로 추출된다. 일반적으로 IO 형태의 데이터 객체로 변환되어 전달되며 특히 파일처리 시에는 IO의 메시지 변환기능을 이용하기 위해 반드시 IO형태로 사용하도록 한다.
아이템리더(ItemReader)	배치 Step에서 처리할 데이터를 DB 또는 파일 등의 리소스에서 획득하여 ItemProcessor나 ItemWriter에 전달하는 역할을 수행한다. DB에서 아이템을 가져올 때는 DBIO를 이용하여 아이템리더를 업무 개발자가 직접 작성한다. 반면 파일 리소스에서 아이템을 가져올 때는 배치 프레임워크에서 제공하고 있는 파일리더 XML을 사용 한다. 단, 파일리더 XML을 사용 할 수 없을 경우에는 업무 개발자가 직접 작성하여야 한다.
아이템프로세서(ItemProcessor)	배치 업무개발자는 업무데이터를 업무요건에 따라 처리/가공하는 절차와 결과 데이터를 기록하거나 전송하는 절차로 구분하여 역할을 명확하게 정리할 필요가 있는데 이 경우 ItemProcessor를 별도로 정의하여 처리 할 수 있다.
아이템라이터(ItemWriter)	ItemReader 혹은 ItemProcessor에서 전달받은 아이템을 저장 매체인 DB 또는 파일에 기록하거나 배치 처리 결과 데이터를 아이템별로 외부 시스템에 전송하는 등의 역할을 수행한다. 아이템을 업무 요건에 따라 처리하는 프로세서 역할을 포함하기도 한다. DB에 아이템을 기록하기 위해서는 DBIO를 사용하여 ItemWriter를 업무 개발자가 직접 작성하고, 파일 리소스에 아이템을 기록할 때는 배치 프레임워크에서 제공하고 있는 파일라이터 XML을 사용한다. 단 파일라이터 XML을 사용 할 수 없을 경우에는 업무 개발자가 직접 작성하여야 한다.
스콥(Scope)	객체가 생성되어 소멸될 때까지의 기간을 의미한다. 상기한 ItemReader, ItemProcessor, ItemWriter 객체들의 생성과 소멸은 실제 프레임워크에서 담당하므로 업무 개발자에게는 해당 객체의 인스턴스가 사용 가능한 상태로 유지되는 기간으로 이해될 수 있다. 배치 프레임워크에서는 배치 어플리케이션에서만 사용할 수 있는 "step"이라는 스콥을 제공하는데 이는 하나의 Step이 실행되는 기간 동안 해당 객체가 유지되고, 멤버데이터가 보존됨을 의미한다.
Item-Oriented Processing	배치 Step의 처리 절차는 ItemReader를 이용하여 추출한 아이템을 Step 정의에 따라 ItemProcessor, ItemWriter에 순차적으로 전달하여 처리하고 기록하는 과정으로 구성된다. 이처럼 Item-Oriented Processing은 프레임워크 기반의 배치 Step에서 아이템을 최소 처리단위로 하는 절차를 의미한다.
Chunk-Oriented Processing	데이터 처리와 기록을 매체에 최종적으로 반영하는 행위. 즉, 파일에 기록(write-flush)하거나 데이터 트랜잭션을 커밋(commit)하는 작업은 배치 처리의 성능 측면을 고려하여 구간별로 수행한다. 이때 데이터반영의 단위는 "commit-interval" 이라는 Step 속성으로 정의한다. "Item-Oriented Processing"을 보면 데이터의 처리는 아이템 단위로 구현되고 반영은 구간별로 수행되기 때문에 처리와 반영의 단위에 불일치가 발생하여 이를 보정하기 위한 부가적인 구현을 필요로 한다. 이를 보완하기 위해 프레임워크에서는 ItemReader에서 추출하고 ItemProcessor에서 처리된 아이템들을 내부 버퍼를 이용하여 반영단위로 ItemWriter에 전달하는 전략을 구현한다. 이 과정에서 반영 실패로 인한 보정작업의 구현을 프레임워크에서 수행할 수 있으며 이러한 처리 유형을 "Chunk-Oriented Processing"으로 정의한다.

용어

설명

배치작업(JOB)

배치 업무를 처리하기 위한 플로우로 구성된 배치작업의 실행 및 재실행 단위로 플로우를 기술하는 XML 설정으로 작성된다. 흔히 규모가 큰 배치작업은 외부 프로그램을 호출하는 것을 포함하여 복잡한 처리절차로 구성되지만 배치 어플리케이션에서 정의하는 배치작업은 배치 어플리케이션으로 구현된 단위 Step을 호출하는 플로우만으로 한정한다.

스텝(Step)

배치작업을 구성하는 업무 구현의 최소단위이다. 배치 작업의 구성요소로만 동작할 뿐 개별적으로 실행될 수 없으며 배치작업의 재실행 시 개별 Step은 조건에 따라 재실행되거나 실행에서 제외될 수 있다.

아이템(Item)

배치 Step에서 업무 요건에 따라 처리할 데이터의 최소단위이다. DB 또는 파일 리소스에서 건 별로 추출된다. 일반적으로 IO 형태의 데이터 객체로 변환되어 전달되며 특히 파일처리 시에는 IO의 메시지 변환기능을 이용하기 위해 반드시 IO형태로 사용하도록 한다.

아이템리더(ItemReader)

배치 Step에서 처리할 데이터를 DB 또는 파일 등의 리소스에서 획득하여 ItemProcessor나 ItemWriter에 전달하는 역할을 수행한다. DB에서 아이템을 가져올 때는 DBIO를 이용하여 아이템리더를 업무 개발자가 직접 작성한다. 반면 파일 리소스에서 아이템을 가져올 때는 배치 프레임워크에서 제공하고 있는 파일리더 XML을 사용 한다. 단, 파일리더 XML을 사용 할 수 없을 경우에는 업무 개발자가 직접 작성하여야 한다.

아이템프로세서(ItemProcessor)

배치 업무개발자는 업무데이터를 업무요건에 따라 처리/가공하는 절차와 결과 데이터를 기록하거나 전송하는 절차로 구분하여 역할을 명확하게 정리할 필요가 있는데 이 경우 ItemProcessor를 별도로 정의하여 처리 할 수 있다.

아이템라이터(ItemWriter)

ItemReader 혹은 ItemProcessor에서 전달받은 아이템을 저장 매체인 DB 또는 파일에 기록하거나 배치 처리 결과 데이터를 아이템별로 외부 시스템에 전송하는 등의 역할을 수행한다. 아이템을 업무 요건에 따라 처리하는 프로세서 역할을 포함하기도 한다. DB에 아이템을 기록하기 위해서는 DBIO를 사용하여 ItemWriter를 업무 개발자가 직접 작성하고, 파일 리소스에 아이템을 기록할 때는 배치 프레임워크에서 제공하고 있는 파일라이터 XML을 사용한다. 단 파일라이터 XML을 사용 할 수 없을 경우에는 업무 개발자가 직접 작성하여야 한다.

스콥(Scope)

객체가 생성되어 소멸될 때까지의 기간을 의미한다. 상기한 ItemReader, ItemProcessor, ItemWriter 객체들의 생성과 소멸은 실제 프레임워크에서 담당하므로 업무 개발자에게는 해당 객체의 인스턴스가 사용 가능한 상태로 유지되는 기간으로 이해될 수 있다. 배치 프레임워크에서는 배치 어플리케이션에서만 사용할 수 있는 "step"이라는 스콥을 제공하는데 이는 하나의 Step이 실행되는 기간 동안 해당 객체가 유지되고, 멤버데이터가 보존됨을 의미한다.

Item-Oriented Processing

배치 Step의 처리 절차는 ItemReader를 이용하여 추출한 아이템을 Step 정의에 따라 ItemProcessor, ItemWriter에 순차적으로 전달하여 처리하고 기록하는 과정으로 구성된다. 이처럼 Item-Oriented Processing은 프레임워크 기반의 배치 Step에서 아이템을 최소 처리단위로 하는 절차를 의미한다.

Chunk-Oriented Processing

데이터 처리와 기록을 매체에 최종적으로 반영하는 행위. 즉, 파일에 기록(write-flush)하거나 데이터 트랜잭션을 커밋(commit)하는 작업은 배치 처리의 성능 측면을 고려하여 구간별로 수행한다. 이때 데이터반영의 단위는 "commit-interval" 이라는 Step 속성으로 정의한다. "Item-Oriented Processing"을 보면 데이터의 처리는 아이템 단위로 구현되고 반영은 구간별로 수행되기 때문에 처리와 반영의 단위에 불일치가 발생하여 이를 보정하기 위한 부가적인 구현을 필요로 한다. 이를 보완하기 위해 프레임워크에서는 ItemReader에서 추출하고 ItemProcessor에서 처리된 아이템들을 내부 버퍼를 이용하여 반영단위로 ItemWriter에 전달하는 전략을 구현한다. 이 과정에서 반영 실패로 인한 보정작업의 구현을 프레임워크에서 수행할 수 있으며 이러한 처리 유형을 "Chunk-Oriented Processing"으로 정의한다.

2. 배치 아키텍처

다음은 배치의 기본 아키텍처에 대한 그림으로서 Script Layer, Runtime Layer, Business Layer로 구성이 된다.

Figure 1. 배치 거래처리 아키텍처

Layer	설명
Execution Layer	배치를 실행하는 job scheduler, web admin 과 배치를 연동해주는 영역이다. 프레임워크에서는 배치를 kubernetes에 실행하기 위한 template을 제공한다.
Runtime Layer	업무에서 작성한 배치 비즈니스(Business) 로직을 실행하기 위한 프레임워크의 실행(Runtime)영역이다. 해당 영역에서는 배치작업 관리, 배치 시스템 선/후처리, 배치 수행정보 관리 등을 수행한다.
Business Layer	배치 업무를 수행하기 위하여 배치 개발자들이 작성한 업무 프로그램에 대한 영역이다. 여기서 배치 개발자들이 작성하는 프로그램들은 배치작업 XML, 배치 Bean, DBIO 등이 있다.

Layer

설명

Execution Layer

배치를 실행하는 job scheduler, web admin 과 배치를 연동해주는 영역이다. 프레임워크에서는 배치를 kubernetes에 실행하기 위한 template을 제공한다.

Runtime Layer

업무에서 작성한 배치 비즈니스(Business) 로직을 실행하기 위한 프레임워크의 실행(Runtime)영역이다. 해당 영역에서는 배치작업 관리, 배치 시스템 선/후처리, 배치 수행정보 관리 등을 수행한다.

Business Layer

배치 업무를 수행하기 위하여 배치 개발자들이 작성한 업무 프로그램에 대한 영역이다. 여기서 배치 개발자들이 작성하는 프로그램들은 배치작업 XML, 배치 Bean, DBIO 등이 있다.

3. 배치 처리 패턴

3.1. Chunk-Oriented

DB 또는 파일로부터 한 건 단위로 입력 받는 ItemReader와 한 건 단위로 비즈니스 로직을 처리하는 ItemProcessor, 결과를 출력하는 ItemWriter로 구분되는 패턴이다.

Figure 2. 다건 처리 방식(Chunk-Oriented)

단일 Step의 일반적 형태는 ItemReader, ItemProcessor, ItemWriter로 구성된다.
One-Transaction 내에서 한번씩 데이터를 Read한 후 지정된 commit-interval(chunk) 단위로 Write 하는 방식이다.
예를 들어, Commit Interval이 100으로 설정이 되어 있으면, 입력 데이터 기준으로 ItemReader와 ItemProcessor가 100건의 데이터를 처리한 후 ItemWriter로 넘어온 chunk를 DB 또는 파일에 Writer한 후 해당 트랜잭션이 Commit이 된다.

3.2. Tasklet

단순 DB CRUD 수행이나 반드시 한번에 commit/rollback되어야 하는 배치에서 사용하는 패턴이다.

Figure 3. Tasklet

단순작업(단일 DB CRUD statement 실행 등) 처리나 One 트랜잭션으로 구성되는 비즈니스 로직을 구현할 때 사용하는 Step 유형으로 execute() 메소드를 가진 Tasklet interface를 사용하여 구현한다.
배치 Job 내의 Step 안에서 chunk 단위로 트랜잭션 처리를 하는 chunk-oriented processing과는 달리 Step 실행 시 단일 트랜잭션만 수행되는 구조로 input data를 한번에 commit/rollback 처리 할 때 쓰일 수 있다.

4. 배치의 종류

4.1. 일반 배치

Job Scheduler 등에 의해 정해진 시간에 주기적 혹은 비주기적으로 구동되는 배치프로그램으로서, 프레임워크에서 수행을 제어한다.

일반 배치로 개발하는 배치 업무 유형은 다음과 같다.(수행 프로젝트/업무 성격에 따라 다를 수 있음)

Self Check
초기화 작업
결산 작업
보고서 작업
Data 일괄 수정
Data 작성/취합 후 별도 Table에 반영, Sam파일 생성
Data Convert
오류처리/정정/취소 등 작업
파일/전문 작성 후 전송 및 자료수신 등
원장 Save/Load, Recovery, Dump용 프로그램 등

4.2. 온디맨드 배치

온라인 서비스에서 대량데이터 처리가 필요한 경우 API를 이용하여 Job Scheduler를 호출하여 배치를 실행하는 배치 프로그램으로 온라인 서비스에서 Async로 배치를 실행한다.

온디맨드 배치로 개발하는 배치 업무 유형은 다음과 같다.(수행 프로젝트/업무 성격에 따라 다를 수 있음)

수분 이내(Short Term Job)로 작업이 완료되는 배치(온라인 처리 시간보다 길고, 일반 배치로 처리하는 시간보다 짧은 배치가 대상)
온라인 프로그램에서 바로 배치를 실행해야 하는 경우

일반적으로 온디맨드 배치는 모니터링을 위하여 Job Scheduler를 이용하여 처리하며, Job Scheduler연계는 프로젝트에서 Job Scheduler에서 제공해주는 API를 이용한다.

4.3. 데몬 배치(현재 미구현)

데몬(Daemon)프로그램 형태로 기동된 상태에서 스케줄 시간에 따라 주기적으로 자동 수행되는 배치 프로그램이다.

데몬배치의 특징은 다음과 같다.

데몬 배치 업무 개발은 일반 배치 업무 모듈 작성과 같음
배치 실행 도중 시스템 상황에 따른 제어 가능
멀티노드처리 기능
스케줄 시간 정의

데몬 배치로 개발하는 배치 업무 유형은 다음과 같다.(수행 프로젝트/업무 성격에 따라 다를 수 있음)

모니터용 상주 데몬
업무 데이터 정정/취소 등을 위한 상주 데몬
자료수신 등

데몬 배치는 등록한 배치 작업마다 개별 프로세스로 동작을 하기때문에, 데몬 배치는 서버 자원 상황(CPU/메모리 등)에 따라 작업 등록에 대한 주의가 필요하다.

SWLab Bankware Global