지난번에는 간단하게 스프링 배치가 무엇인지, 무슨 역할을 하는지에 대해 글을 읽어보았다.
이번에는 스프링 배치의 구조에 대해 공부하려고 한다.
1. 스프링 배치 구조(Spring Batch Architecture)
스프링 배치는 확장 가능성(extensibility)와 다양한 최종 사용자를 염두해 설계했다.
아래 이미지는 최종 사용 개발자(end-user developers)의 편의성과 확장 가능성을 지원하기 위한 계층화 구조이다.
이 계층형 아키텍처(layered architecture)는 세 개의 주요 상위레벨 (high-level) 구성들을 강조한다. (Application, Core, Instrastructure).
어플리케이션(Application)은 모든 배치 잡(batch job)들과 스프링 배치를 사용한 개발자의 커스텀 코드(custom code)를 포함한다.
배치 코어(Batch core)는 배치 잡을 실행하고 통제하는데 필요한 핵심 런타임 클래스들을 포함한다.
JobLauncher, Job 그리고 Step을 포함한다. 어플리케이션과 코어 둘 다 상단에 공통의 인프라(infrastructure)로 구성되어있다.
이 인프라는 공통의 reader, writer그리고 service들을 포함하는데, 어플리케이션 개발자와 코어 프레임워크 두 곳에서 다 사용된다.
글을 읽는 중에 기본 설명을 먼저 듣고 가야 더 이해가 될 것 같아서 정리하고 넘어가려고 한다.
Job, Step, JobLauncher, reader, writer 등 이러한 용어가 계속 나오는데 Spring Batch Docs를 순서대로(in order) 읽다보면 이해가 안되기 때문이다.
* Job
배치처리 과정을 하나의 단위로 만들어 놓은 객체
* Step
Batch Job을 구성하는 독립적인 하나의 단계로서 실제 배치 처리를 정의하고 컨트롤하는 데 필요한 모든 정보를 가지고 있는 도메인 객체
* Tasklet
Step에서 수행되는 독립적인 단일 작업
다음과 같이 생각하면 편리하다.
일상 생활에서 특정 일을 한다고 생각해보자. 예를 들어 집을 청소한다고 하자.
그러면 집을 청소한다는 일 자체를 Job이라고 볼 수 있는데,
청소를 한다고 하면 여러 장소를 청소할 수 있다.
거실, 안방, 화장실, 세탁실 등등... 이것을이 Step인 것이다.
집을 완벽히 청소한다는 일(Job)을 처리하기위해 단계들(Step)이 있는 것이다.
거실의 경우 소파나 모니터가 있고, 화장실의 경우에는 락스칠을 하고 변기 솔질을 해야 할 것이다.
즉, 각각의 장소(혹은 Step)에서 독립적으로 처리되어야 하는 단일 작업들이 존재한다.
다음을 좀 더 보기 쉽게 정리하면 다음과 같다.
* JobLauncher
배치 job을 실행시키는 역할
*Chunk
데이터 덩어리로 작업 할 때 각 커밋 사이에 처리되는 row 수
*reader & writer
데이터를 입력 받는것을 reader, 데이터를 쓰는 것을 writer라고 한다. 우선은 이렇게만 보고 파악하자.
아! 뭔가 작업을 처리하려고 데이터를 읽는것을 reader, 가공한 데이터로 무언가 처리할 때 writer 가 필요하구나! 대강 파악하면 된다.
2. 일반 배치 원칙과 가이드라인 (General Batch Principles and Guidelines)
다음의 핵심 원칙, 가이드 라인, 그리고 일반적인 고려사항들이 배치 솔루션을 구축하는데 고려되야만 한다.
1) 배치 구조가 전형적으로 온라인 아키텍처에 그리고 반대로도 영향을 준다는 점을 기억해라. 가능하면 공통의 building block 을 사용하면서 아키텍처와 환경 둘 다 고려해라.
2) 가능한 간단하게 만들고 하나의 배치 어플리케이션에서 복잡한 논리 구조를 만드는 것을 피하라.
3) 물리적으로 가까운 데이터의 저장과 처리를 함께 유지하라. 다시말해서, 처리가 발생하는 곳의 데이터를 유지하라.
4) 시스템 자원 사용을 최소화하라. 내부 메모리에서 가능한한 많은 작업을 하라.
<< 시스템 자원 사용을 최소화하라. 내부 메모리에서 가능한한 많은 작업을 하라. >>
라는 가이드라인이 궁금해서 왜 그런지 GPT에게 물어보았다.
출처는 어디냐고 물어보니 Spring Batch의 공식 문서에서 상세히 다루고 있다고 한다. (아직 내가 덜 읽어서 그런가... ㅠㅠ)
<이유 1> 시스템 자원의 효율적 사용
대규모 배치 처리에서는 일반적으로 많은 양의 데이터를 처리해야 합니다. 따라서, 시스템 자원(예: CPU, 메모리, I/O)을 효율적으로 사용하는 것이 중요합니다. 자원 사용을 최소화하면 시스템의 부하를 줄이고, 다른 애플리케이션과 자원을 공유할 때 발생할 수 있는 간섭을 최소화할 수 있습니다.
<이유2> 성능 최적화
내부 메모리에서 가능한 많은 작업을 수행하는 것은 디스크 I/O를 줄이고, 네트워크 통신을 최소화하여 성능을 향상시키는 방법입니다. 메모리는 디스크나 네트워크에 비해 훨씬 빠른 액세스 속도를 가지고 있으므로, 데이터를 메모리 내에서 처리하는 것이 성능 측면에서 훨씬 유리합니다.
<이유3> 안정성과 복구 용이성
배치 작업은 오랜 시간 동안 실행될 수 있으며, 중간에 실패할 가능성이 있습니다. 시스템 자원을 최소화하여 사용하면, 작업 중단 시 복구가 더 쉬워집니다. 또한, 메모리 내에서 작업을 처리함으로써, 작업의 상태를 보다 쉽게 관리하고 필요한 경우 재시작할 수 있습니다.
<이유 4> 확장성과 유연성
효율적인 자원 사용은 시스템의 확장성을 높여줍니다. 작은 시스템 자원으로 많은 작업을 처리할 수 있다면, 시스템의 규모를 크게 늘리지 않고도 더 많은 작업을 처리할 수 있습니다. 이는 특히 클라우드 환경과 같이 자원이 유동적인 환경에서 매우 중요합니다.
5) 불필요한 물리적 I/O가 없는지 확실히 하도록 application I/O (SQL 상태를 분석하라)를 리뷰하라. 특히, 다음 네 개의 공통 결함을 봐야 한다.
* 데이터가 할번 읽힐 때 또는 작업중 스토리지(working storage)에 유지된 모든 트랜젝션에 대한 데이터를 읽을 때
* 동일한 트랜잭션에서 이전에 데이터를 읽은 트랜잭션의 데이터를 다시 읽을 때
* 불필요한 테이블 혹은 인덱스 스캔이 발생할 때
* SQL 문의 where절에 키 값을 지정하지 않을 때
6) 배치 실행을 작업을 두 번 하지 마라. 예를 들어, 리포팅 목적의 데이터 요약을 필요로 하면 데이터가 초기에 처리중일 때 저장된 총 수를 증가시켜야 한다. 그래서 리포팅 어플리케이션은 같은 데이터를 다시 처리하지 않는다.
7) 처리동안 시간 소모적인 재할당을 피하기 위해 배치 어플리케이션 초기에 충분한 메모리를 할당하라.
8) 항상 데이터 통합성에 대해 최상의 경우를 가정하라. 데이터 통합성을 유지하기 위해 적절한 체크를 넣고 벨리데이션(validation)을 기록하라.
9) 가능한 곳에 내부 벨리데이션을 위해 체크섬(checksum)을 실행하라.
10) 실제 데이터 크기를 가진 운영 환경 같은 곳에서 가능한한 일찍 부하 테스트를 계획하고 실행하라.
11) 거대한 배치 시스템에서 백업은 큰 난관일 수 있는데, 특히 시스템이 항상 온라인 어플리케이션에서 동시레 돌아가고 있으면 큰 난관이다. 데이터베이스 백업은 전형적으로 온라인 디자인에 잘 고려되는데 파일 백업도 마찬가지로 중요하다고 생각해야 한다. 만약 시스템이 flat file에 의존한다면, 백업 처리는 준비되어 있거나 기록되는것 뿐만 아니라 규칙적으로 테스트되어야 한다.
* flat file?
플랫파일은 아무런 구조적 상호관계가 없는 레코드들이 들어 있는 파일로 소프트웨어 개발에서 주로 데이터 저장, 교환 및 처리 작업을 위한 다양한 용도로 사용됨.
휴... 읽어보니 그러려니 할 정도로 다 좋은 내용들이다.
3. 배치 처리 전략 (Batch Processing Strategies)
배치 시스템의 실행과 디자인을 돕기 위해, 블록(blocks) 과 패턴(patterns) 으로 만든 기본 배치 어플리케이션은 샘플 구조 차트와 코드 쉘 형식으로 디자이너나 개발자에게 제공되어야 한다. 배치 잡의 디자인을 시작할 때, 비즈니스 로직이 다음의 표준 구성 블록을 사용해서 실행되는 일련의 스텝들로 분해되야한다.
(그러니까 기존의 코드를 배치를 적용하기 위해 분해가 되어야 한다는 말을 하는 것 같음)
여기서 buliding block라는 용어가 나오는데 이는 배치 처리 프로세스를 구성하는 핵심 요소들을 의미한다.
위에 언급한 Job, Step, Tasklet이 그런 것인데 기존에 만들어진 것들을 쌓아 batch를 구성한다는 의미에서 block이라고 말하는것 같다. 우리가 결국 block처럼 끼워 맞추는 거니까 말이다.
- Conversion Application(변환 어플리케이션) : 외부 시스템에서 공급되고 생성된 각각의 파일의 형태에 대해 제공된 거래 기록을 처리에 필요한 표준 형식으로 변환하는 conversion application이 필요하다. 이 형식의 배치 어플레키이션은 부분적으로 또는 전체적으로 translation utility 모듈로 구성할 수 있다. (Batch Service를 보세요)
- Validation Application(확인 어플리케이션) : valdation application은 모든 입력 및 출력 기록이 정확하고 일관적인지 확인한다. validation은 일반적으로 file 헤더와 trailer, checksum과 validation 알고리즘 그리고 record-level의 크로스체크(cross-check)에 기반을 둔다.
- Extract Application(추출 어플리케이션) : extranct application은 데이터베이스 혹은 입력 파일의 레코드들을 읽고 미리 정의된 규칙에 따라 레코드를 선택한다.
- Processing and Updating Application(처리와 업데이팅 어플리케이션) : 처리 및 업데이트 애플리케이션은 추출 또는 검증 애플리케이션의 입력 트랜잭션에 대한 처리를 수행한다. 처리는 보통 처리에 필요한 데이터를 얻기 위해 데이터데이터베이스를 읽고 잠재적으로 데이터베이스를 업데이트하고 출력 처리를 위해 레코드를 생성하는 작업을 포함한다.
- Output/Format Application(출력/포맷 어플리케이션) : output/format 어플리케이션은 입력 파일을 읽고 표준 포맷에 따라 이 레코드로부터 데이터를 재구성한다. 그리고 다른 프로그램이나 시스템에 프린트하거나 전송하기 위해 출력 파일을 생성한다.
추가적으로, 기본 어플리케이션 shell은 이전에 언급된 구성 블록을 사용해 만들어질 수 없는 비즈니스 로직을 제공받아야 한다.
주요 빌딩 블록에 더하여 각각의 어플리케이션들은 하나 혹은 더 많은 표준 유틸리티 스텝을 사용할수도 있다. 다음과 같은 것처럼...
- Sort : 입력 파일을 읽고 레코드들이 레코드 안에 sort key field에 따라 다시 순번이 매겨지는 출력 파일을 생성 프로그램. sort들은 보통 표준 시스템 유틸리티가 실행한다.
- Split : 하나의 입력 파일을 읽고 필드값에 근거해 몇 개의 출력 파일 중 하나로 각각의 레코드를 적는 프로그램. Split은 파라미터 기반의 표준 시스템 유틸리티를 통해 맞춤화되거나 수행될 수 있다.
- Merge : 다수의 입력 파일로 레코드를 읽고 입력 파일들로부터 결합된 데이터를 가지고 하나의 결과 파일을 생성하는 프로그램. Merge는 파라미터 기반의 표준 시스템 유틸리티를 통해 맞춤화되거나 실행될 수 있다.
배치 어플리케이션은 추가적으로 입력 소스로 분류될 수 있다.
- 데이터베이스 기반 어플리케이션들이 데이터베이스로부터 가져온 값들과 row에 의해 구동된다.
- 파일 기반 어플리케이션들은 파일로부터 가져온 레코드나 값으로 구동된다.
- 메시지 기반 어플리케이션들은 메시지 큐로부터 가져온 메세지에 의해 구동된다.
모든 배치 시스템의 기초는 처리 전략이다. 전략 선택에 영향을 주는 요인은 다음과 같다.
=> 예측된 배치 시스템 크기, 온라인 시스템들의 동시성 또는 다른 배치스시템과의 동시성, 사용가능한 배치 윈도우
(더 많은 기업들이 24시간 7일 돌아가길 원해서 명확한 batch windows가 사라지고 있다.)
* batch window? window batch?
윈도우 배치파일(batch file)은 명령 프롬프트(cmd)에서 순서대로 실행할 명령어들을 한번에 일괄로 실행 실행할 목적으로 만드는 명령어들의 집합 파일아다.
batch window는 명령어들의 집합이라고 보면 될 것 같다.
전형적인 배치 처리 옵션들은 다음과 같다.
- 오프라인 모드에서 배치 윈도우 동안 보통 처리
- 동시성 배치 혹은 온라인 처리
- 동시에 많은 다른 배치 실행의 병렬 처리
- 파티셔닝(동시에 같은 많은 같은 잡의 인스턴스 처리)
- 선행하는 옵션의 조합
이러한 옵션들은의 몇 개 혹은 모두가 상업적인 스케줄러에 의해 지원된다.
이 섹션의 나머지는 더 자세하게 이러한 처리 옵션들에 대해 논의한다. 경험상 배치 프로세스에 적용된 커밋(commit) 과 락킹(locking) 전략은 실행된 프로세스의 형태에 의존하고 온라인 락킹 전략이 또한 같은 원칙을 사용한다는것을 유의하라.
그러므로 배치 아키텍처는 전체 아키텍처를 설계할 때 단순히 부가적으로 고려되어서는 안된다.
마지막 문단이 도통 무슨 말인지 모르겠다.
해석을 해봐도, 영어로 읽어봐도 이해가 안되서 GPT에게 이게 무슨 말인지 살명좀 해달라고 했는데 다음과 같은 답변을 달아주었다.
<< 처리 옵션의 상세 논의 >>
배치 처리에는 여러 가지 옵션이 있으며, 각각의 옵션은 설계 및 구현의 복잡성에 따라 다릅니다.
<< 커밋과 락킹 전략의 중요성 >>
배치 프로세스에서 사용되는 데이터 커밋과 락킹 전략은 프로세스의 유형에 따라 달라집니다. 이 전략들은 데이터의 일관성과 시스템의 안정성을 보장하는 데 중요합니다.
<< 온라인 시스템과의 일관성 >>
배치 처리 시스템과 실시간(온라인) 시스템 간에 일관된 락킹 전략을 사용하는 것이 중요합니다. 이는 두 시스템 간의 간섭을 최소화하고, 전체적인 시스템 성능을 향상시키는 데 도움이 됩니다.
<< 설계 초기 단계에서의 배치 아키텍처 고려>>
전체 시스템 아키텍처를 설계할 때 배치 아키텍처를 뒤늦게 고려하는 것이 아니라, 처음부터 함께 고려해야 합니다. 이는 시스템의 효율성, 확장성 및 유지 보수성을 높이는 데 기여합니다.
이게 정확히 왜 그래야하는지, 그래서 어떤 장점이 있는지를 사실 잘 몰라서 필자는 너무 궁금했다.
1. 배치 윈도우의 보통 처리 (Normal processing in a batch window)
데이터가 업데이트 되는곳의 각각의 배치 원도우에서 작동하는 간단한 배치 처리들은 온라인 사용자나 다른 배치 처리에 필요하지 않고 동시성은 이슈가 아니며 싱글 커밋이 배치 작업 마지막에 될 수 있다.
대부분의 경우, 더 확고한 접근이 더 적절하다. 배치 시스템들이 복잡성과 그들이 다루는 데이터 용량 둘 다의 관점에서 시간이 감에 따라 커지는 경향이 있다는 것을 명심해라.
락킹 전략이 준비되어 있지 않고 시스템이 여전이 싱글 커밋 포인트에 의존한다면 배치 프로그램을 수정하는것은 고통스러울 수 있다.
따라서 가장 간단한 배치 시스템을 사용하더라도 재시작-복구 옵션에 대한 커밋 논리의 필요성과 이 섹션 뒷부분에서 설명하는 더 복잡한 사례에 관한 정보를 고려하라.
2. 동시성 배치 또는 온라인 처리 (concurrent batch or on-line processing)
동시적으로 온라인 유저에 의해 업데이트 될 수 있는 데이터를 처리하는 배치 어플리케이션들은 몇 초 이상 동안 온라인 유저에게 필요할 수 있는 데이터를 락해서는 안된다. 또한, 업데이트가 모든 트랜잭션의 끝에 데이터비이스에서 커밋되야만 한다. 이렇게 하면 다른 프로세스에서 사용할 수 없는 데이터 부분과 데이터를 사용할 수 없는 경과 시간이 최소화된다.
...
이 이후 내용은 솔직히 내가 그렇게까지 봐야 하는 내용이 많았다.
글도 너무 길거니와 아직 사용법도 잘 모르는데 글이 길다보니 흥미가 너무 떨어졌다.
추후에 더 흥미가 생기고 글을 더 읽게 되면 다시 추가할 계획이다.
출처:
https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-%EB%B0%B0%EC%B9%98#