02. Spring Batch 계층 구조

이번 포스트에서는 Spring Batch의 Architecture에 대해 알아보자.

 

Spring Batch 계층 구조

 

계층 구조

Spring Batch는 Application, Batch Core, Batch Infracture 3가지 계층으로 구성된다.

• Application: 개발자가 Spring Batch를 사용해 작성한 모든 배치 작업과 커스텀 코드

 

• Batch Core: 배치 작업을 실행하고 제어하는 핵심 런타임 클래스 (JobOperator, Job, Step 등)

 

• Infrastructure: 애플리케이션 개발자와 코어 프레임워크가 함께 사용하는 공통 서비스(ItemReader, ItemWriter, RetryTemplate 등)

배치 시스템 설계 원칙

일반적으로 배치 솔루션을 구축할 때는 다음의 사항들이 고려되어야 한다.

아키텍쳐 설계 원칙

• 온라인과 배치 통합 고려: 배치 아키텍처는 온라인 아키텍처에 영향을 주고 그 반대도 마찬가지. 가능한 공통 빌딩 블록 사용
• 단순함 추구: 단일 배치 애플리케이션에서 복잡한 논리 구조를 만들지 말 것
• 데이터와 처리의 물리적 근접성: 데이터를 처리하는 곳에 데이터를 가까이 둘 것(서버의 리전 등 물리적 위치)

배치와 함께 사용되는 온라인 이라는 용어는 사용자가 지금 당장 요청하고 즉시 응답을 받아야 하는 일반적인 웹 요청을 이야기 한다.  반면 배치는 사용자 없이 대량의 데이터를 한번에 처리한다. 이 둘이 서로 영향을 준다는 것은 어떤 의미일까?

만약 두 작업이 동일한 주문 DB를 사용한다고 할 때 온라인에서는 고객의 주문을 orders 테이블에 insert하고 batch는 밤에 주문 통계를 위해 orders 테이블을 select 하게 된다. 이런 경우 일관성을 위해 동일한 Order Entity를 사용하는 등 처음 부터 함께 고려해서 설계 해야 한다.

 

성능 최적화 원칙

• 시스템 리소스 최소화: 특히 I/O를 최소화하고 가능한 많은 작업을 메모리에서 수행
• 불필요한 I/O 방지: SQL 문을 분석하여 불필요한 물리적 I/O 제거
  • 캐시 가능한 데이터를 매 트랜잭션마다 읽지 말 것
  • 같은 트랜잭션에서 이미 읽은 데이터를 다시 읽지 말 것
  • 불필요한 테이블이나 인덱스 스캔 방지
  • SQL의 WHERE 절에 키 값 명시
• 중복 작업 방지: 배치 실행 중 같은 작업을 두 번 하지 말 것

 

데이터 무결성 원칙

• 최악의 상황 가정: 데이터 무결성에 대해 항상 최악을 가정하고 적절한 검증 로직 구현
• 체크섬 구현: 가능한 곳에서 내부 검증을 위한 체크섬 구현 (예: 데이터 총 건수 확인, MD5/SHA 해시 검증)
• 스트레스 테스트: 실제와 유사한 환경에서 현실적인 데이터 볼륨으로 가능한 빨리 스트레스 테스트 실행