Spring Batch와 Scheduler

Spring Batch와 Scheduler의 차이점이 궁금해져서 관련 내용에 대해 작성해보겠다.

 

결론부터 말하자면 Spring Batch는 실제 데이터 처리 로직과 비즈니스 처리를,

Scheduler는 작업들을 정해진 시점에 실행하도록 관리한다.

Spring Batch는 스케줄러를 대체하기보다는 스케줄러와 함께 작동하도록 설계돼있다.

(Spring Batch is intended to work in conjunction with a scheduler rather than replace a scheduler.)

 

아래와 같은 순서로 작성할 예정이다.

1. Spring Batch

   1-1. Spring Batch의 핵심 구성 요소

   1-2. 배치 처리 전략

   1-3. 배치 시스템의 처리 전략

2. Scheduler

---

1. Spring Batch?

Spring Batch는 엔터프라이즈 시스템의 일상적인 운영에 필수적인 견고한 배치 애플리케이션 개발을 가능하게 하는 경량의 포괄적 배치 프레임워크이며, Spring Framework의 특성(생산성, POJO 기반 개발 방식, 사용의 용이성)을 기반으로 하면서, 필요할 때 개발자들이 보다 고급의 엔터프라이즈 서비스를 쉽게 활용할 수 있도록 설계되었다.

 

엔터프라이즈 환경의 많은 애플리케이션은 mission-critical(사업 운영 또는 단체에 필수적인 요인)한 비즈니스 운영을 수행하기 위해 대량 처리를 필요로 한다. 비즈니스 운영에는 다음 내용이 포함된다.

• 자동화되고 복잡한 대량 정보 처리
  사용자 상호작용 없이 가장 효율적으로 처리할 수 있는 대용량 정보의 자동화되고 복잡한 처리. 이러한 작업에는 보통 월말 계산, 통지 또는 서신 발송과 같은 시간 기반 이벤트가 포함.
• 복잡한 비즈니스 규칙의 주기적 적용
  매우 큰 데이터 집합에 대해 반복적으로 복잡한 비즈니스 규칙을 적용하는 작업.
• 내부 및 외부 시스템의 정보 통합
  일반적으로 포맷 변경, 검증 및 트랜잭션 방식의 처리가 필요한 내부 및 외부 시스템에서 수신된 정보를 기록 시스템에 통합하는 작업. 엔터프라이즈에서는 매일 수십억 건의 트랜잭션을 배치 처리하는 경우도 존재.

 

Spring Batch는 대량의 레코드를 처리하는 데 필수적인 재사용 가능한 기능들을 제공한다.예를 들어 로깅 및 트레이싱, 트랜잭션 관리, 작업 처리 통계, 작업 재시작, 스킵, 그리고 리소스 관리 기능 등이 포함되며 이외에도, 최적화 및 파티셔닝 기법을 통해 매우 높은 처리량과 성능을 요구하는 배치 작업을 지원하는 고급 기술 서비스 및 기능들을 제공한다.

 

Spring Batch는 스케줄링 프레임워크가 아니다. Spring Batch는 스케줄러를 대체하기보다는 스케줄러와 협력하여 사용되도록 설계되었다.(Spring Batch is intended to work in conjunction with a scheduler rather than replace a scheduler)

 

Spring Batch의 핵심 구성 요소

• Job
  배치 처리의 최상위 단위로, 하나 이상의 Step으로 구성. Job은 실행 순서, 실패 시 재시작 정책 등 전체 흐름을 정의.
• Step
  Job을 구성하는 단위 작업. 일반적으로 한 개의 Step은 하나의 단위 작업(예: 파일 읽기, 데이터 처리, 기록 등)을 수행하며, 내부에 Chunk 기반 처리 패턴을 포함 가능.
• JobRepository
  배치 작업의 실행 정보를 영속화하는 저장소. Job 및 Step의 실행 상태, 메타데이터를 저장하여 재시작이나 모니터링 기능 지원.
• JobLauncher
  Job 실행을 트리거하는 컴포넌트로, Job을 시작하고 실행 상태를 관리.

 

배치 처리 전략

배치 시스템을 설계하고 구현하는 데 도움을 주기 위해, 기본 배치 애플리케이션 구성 요소와 패턴을 샘플 구조 차트와 코드 스켈레톤 형태로 설계자와 개발자에게 제공해야 한다.

배치 작업 설계를 시작할 때, 비즈니스 로직은 아래 standard building blocks을 사용하여 구현할 수 있는 일련의 단계로 분해되어야 한다.

 

standard building blocks

• 변환(Conversion) Applications
  외부 시스템에서 제공되거나 외부 시스템에 생성되는 각 유형의 파일에 대해, 해당 거래 기록을 처리에 필요한 표준 형식으로 변환하는 변환 애플리케이션을 만들어야 한다. 이 유형의 배치 애플리케이션은 번역 유틸리티 모듈(기본 배치 서비스 참조)로 일부 또는 전부 구성될 수 있다.
• 검증(Validation) Applications
  모든 입력 및 출력 기록이 정확하고 일관성이 있는지 확인한다. 검증은 일반적으로 파일 헤더와 트레일러, 체크섬 및 검증 알고리즘, 그리고 레코드 수준의 교차 검증을 기반으로 한다.
• 추출(Extract) Applications
  데이터베이스나 입력 파일에서 일련의 레코드를 읽어 미리 정의된 규칙에 따라 레코드를 선택한 후, 해당 레코드를 출력 파일에 기록한다.
• 추출/갱신(Extract/Update) Applications
  데이터베이스나 입력 파일에서 레코드를 읽어, 각 입력 레코드에 기반하여 데이터베이스나 출력 파일을 변경한다.
• 처리 및 갱신(Processing and Updating) Applications
  추출, 검증 애플리케이션에서 가져온 입력 거래에 대해 처리를 수행한다. 이 처리는 보통 처리를 위해 필요한 데이터를 얻기 위해 데이터베이스를 읽고, 데이터베이스를 갱신하며, 출력 처리를 위한 레코드를 생성하는 과정을 포함한다.
• 출력/포맷(Output/Format) Applications
  입력 파일을 읽어 해당 기록의 데이터를 표준 형식에 맞게 재구조화하고, 인쇄 또는 다른 프로그램이나 시스템으로 전송하기 위한 출력 파일을 생성한다.

 

배치 시스템의 처리 전략

모든 배치 시스템의 기초는 적절한 처리 전략이다. 처리 전략 선택에 영향을 주는 요인으로는 예상 배치 시스템의 처리량, 온라인 시스템 또는 다른 배치 시스템과의 동시성, 사용 가능한 배치 윈도우 등이 있다.

 

배치 처리의 일반적인 옵션은 구현 복잡도에 따라 증가하는 순서로 다음과 같다

1. 배치 윈도우 내 오프라인 모드의 일반 처리
   단순 배치 프로세스의 경우, 별도의 배치 윈도우에서 실행되며, 업데이트되는 데이터가 온라인 사용자나 다른 배치 프로세스에 의해 필요하지 않다면 동시성 문제가 없고 배치 작업이 끝난 후 단일 커밋을 수행할 수 있다.
   다만, 대부분의 경우 좀 더 견고한 접근 방식이 필요하며, 재시작 및 복구 옵션을 위한 커밋 로직을 고려해야 한다.
2. 동시 배치 또는 온라인 처리
   온라인 사용자에 의해 동시에 업데이트될 수 있는 데이터를 처리하는 배치 애플리케이션은, 온라인 사용자에게 필요한 데이터를 몇 초 이상 잠그지 않아야 한다.
   또한, 업데이트는 몇 개의 거래마다 데이터베이스에 커밋하여, 다른 프로세스가 사용할 수 없는 데이터 범위를 최소화해야 한다.
   물리적 잠금 대신, 낙관적 잠금(optimistic locking)이나 비관적 잠금(pessimistic locking)과 같은 논리적 행 수준 잠금이 사용될 수 있다.
   • 낙관적 잠금
     낮은 충돌 가능성을 전제로 하여, 각 테이블에 타임스탬프 컬럼을 추가하고, 업데이트 시 타임스탬프를 비교.
   • 비관적 잠금
     높은 충돌 가능성을 가정하고, 행을 검색할 때 물리적 또는 논리적 잠금 설정.
     예시로, 전용 잠금 컬럼을 사용하여 해당 행에 대한 접근을 제한한 후, 업데이트 완료 시 잠금을 해제하는 방법이 있다.
   두 방식 모두 단일 레코드 잠금에 대한 해결책을 제시하지만, 관련된 레코드 그룹에 대한 잠금이 필요할 경우 추가적인 논리적 잠금 관리자(logical lock manager)가 필요할 수 있다.
3. 병렬 처리 (Parallel Processing)
   여러 배치 작업이나 작업(job)을 병렬로 실행하여 전체 배치 처리 시간을 단축한다.
   작업들이 동일한 파일, 데이터베이스 테이블 또는 인덱스 영역을 공유하지 않는다면 문제가 없지만, 공유되는 경우 파티셔닝을 통해 해결해야 한다.
   또는 제어 테이블(control table)을 이용해 자원 간의 상호 의존성을 관리할 수도 있다. 제어 테이블(Control Table)은 배치 처리 시스템에서 여러 작업이나 프로세스가 공유 자원에 접근할 때, 그 사용 상태나 의존성을 관리하기 위해 사용하는 데이터베이스 테이블.
   병렬 처리 시 고려해야 할 주요 사항은 로드 밸런싱 및 시스템 자원(파일, 데이터베이스 버퍼 등)의 가용성이다.제어 테이블 자체가 중요한 자원이 될 수 있음을 유념해야 함.
4. 파티셔닝 (Partitioning)
   파티셔닝을 사용하면 동일한 대형 배치 애플리케이션의 여러 인스턴스를 동시에 실행할 수 있어, 긴 배치 작업의 처리 시간을 줄일 수 있다.
   파티셔닝이 가능한 프로세스는 입력 파일을 분할하거나 주요 데이터베이스 테이블을 파티셔닝하여 서로 다른 데이터 집합에 대해 동시에 실행할 수 있는 경우.
   파티셔닝된 프로세스는 할당된 데이터 집합만 처리하도록 설계되어야 하며, 이는 데이터베이스 설계 및 파티셔닝 전략과 밀접하게 연계되어야 함.
   데이터베이스 파티셔닝은 반드시 물리적인 파티셔닝을 의미하지는 않지만, 대부분의 경우 권장.
   아키텍처는 파티션 수를 동적으로 구성할 수 있도록 유연하게 설계되어야 하며, 자동 구성 또는 사용자 제어 구성을 모두 고려해야 함.
   자동 구성은 입력 파일 크기나 입력 레코드 수와 같은 파라미터를 기반으로 할 수 있다.

배치 처리 전략은 배치 애플리케이션의 구조와 처리 방법을 체계적으로 설계하기 위한 다양한 빌딩 블록과 패턴을 제공하며, 시스템의 규모와 동시성, 배치 윈도우 등 환경적 요인에 따라 적절한 처리 옵션(일반 처리, 동시/온라인 처리, 병렬 처리, 파티셔닝, 또는 이들의 조합)을 선택할 수 있다.

---

2. Scheduler

Batch와 다르게 Scheduler docs는 설명보다는 어떻게 사용하는지가 주된 내용이므로 간단한 설명만 작성하겠다.

 

스케줄링 어노테이션은 애플리케이션이 간단하고 선언적인 방식으로 주기적 작업을 설정할 수 있도록 해주며, 필요에 따라 TaskScheduler를 통해 스케줄러의 동작을 세밀하게 커스터마이징이 가능하다. 이를 통해 데이터 정리, 모니터링, 배치 작업 트리거 등 다양한 반복 작업을 안정적으로 구현할 수 있다.

• 주기적 데이터 정리
  예를 들어, 임시 데이터나 로그 파일을 주기적으로 정리하는 작업을 스케줄링하여 시스템 성능 저하를 방지할 수 있다.
• 모니터링 및 상태 점검
  서버의 상태나 서비스의 동작 여부를 주기적으로 체크하여, 문제가 발생하면 경고를 발송하거나 로그를 남기는 작업에 활용할 수 있다.
• 정기적인 배치 작업 트리거
  Spring Batch와 함께 사용될 경우, @Scheduled 어노테이션을 이용해 배치 작업을 정해진 시간마다 실행할 수 있다. 이 경우, 배치 작업은 스케줄러에 의해 주기적으로 트리거되어 실행되며, 배치 처리의 시작 시점을 제어할 수 있다.

 

출처

https://docs.spring.io/spring-batch/reference/spring-batch-intro.html

https://docs.spring.io/spring-framework/reference/integration/scheduling.html