Spring Batch Architecture

Spring Batch Architecture

 

이 계층형 아키텍처는 세 가지 주요 고수준 컴포넌트로 구성된다.

 

1. Application (애플리케이션 계층)

• 사용자 정의 코드가 포함됨.
• 실무에서 작성하는 Job, Step, ItemReader, ItemWriter 등이 여기 해당됨.

 

2. Batch Core (배치 코어 계층)

• Batch Job을 실행하고 제어하기 위한 핵심 런타임 클래스들이 포함됨.
• JobLauncher, Job, Step 등의 구현체가 여기에 포함됨.
• 애플리케이션 계층이 위에서 정의한 배치 잡을 실행하기 위해 사용하는 실행 엔진 역할

 

3. Batch Infrastructure (배치 인프라 계층)

• Core와 Application이 모두 공통으로 사용하는 계층
• 대표적으로 ItemReader, ItemWriter 등 공통적으로 사용되는 읽기/쓰기 컴포넌트가 이 레이어에 있음.
• RetryTemplate과 같은 서비스 유틸리티도 여기에 포함

 

 

 

General Batch Principles and Guidelines

배치 솔루션을 구축할 때 고려해야 할 핵심 원칙, 가이드라인, 일반적인 주의사항을 서술

 

• 배치 아키텍처는 일반적으로 온라인 아키텍처에 영향을 미치며, 그 반대도 마찬가지입니다.
  • 배치 작업은 주로 야간이나 비사용 시간대에 대량 데이터를 처리
  • 그런데 이 작업이 DB에 큰 부하를 주면, 온라인 서비스의 성능에도 영향을 줄 수 있음
  • 반대로, 온라인 시스템의 데이터 구조나 설계가 비효율적이면, 배치 처리도 복잡해지고 느려질 수 있음.
• 가능한 한 단순하게 설계하고, 하나의 배치 애플리케이션에 복잡한 논리 구조를 만들지 마세요.
• 데이터 처리와 저장 위치를 물리적으로 가까이 유지하세요. 다시 말해, 처리하는 위치에 데이터를 두세요.
• 시스템 리소스 사용(특히 I/O)을 최소화하고, 가능한 많은 작업을 내부 메모리에서 수행하세요.
• 불필요한 물리적 I/O가 발생하지 않도록 애플리케이션의 I/O(SQL문)를 분석하세요.
  • 매 트랜잭션마다 데이터를 읽지 말고, 한 번만 읽고 캐시하거나 작업 메모리에 저장하세요.
  • 같은 트랜잭션 안에서 이미 읽은 데이터를 다시 읽지 마세요.
  • 불필요한 테이블 또는 인덱스 스캔이 발생하지 않도록 하세요.
  • SQL의 WHERE절에 키 값을 명시하지 않는 실수를 피하세요.
• 배치 실행 중 동일한 작업을 두 번 하지 마세요.
  • 리포트를 위해 데이터 집계가 필요하다면, 초기 처리 시 누적값을 저장해 두세요.
  • 그래야 리포트 애플리케이션이 같은 데이터를 다시 처리하지 않아도 됩니다.
• 처리 중 시간을 잡아먹는 재할당을 피하기 위해, 배치 애플리케이션 시작 시 충분한 메모리를 할당하세요.
• 데이터 무결성에 대해서는 항상 최악의 상황을 가정하세요.
  • 무결성을 유지하려면 적절한 검사 및 레코드 검증 로직을 삽입하세요.
• 가능한 경우 체크섬(Checksum)을 통해 내부 유효성 검사를 구현하세요.
  • 예를 들어, flat file은 레코드 개수 및 주요 필드의 합계를 담은 트레일러 레코드를 포함해야 합니다.
• 실제 데이터 양을 갖춘 운영 환경 유사 조건에서 가능한 빨리 스트레스 테스트를 계획하고 실행하세요.
• 대규모 배치 시스템에서 백업은 쉽지 않습니다.
  • 특히 시스템이 24시간 온라인 애플리케이션과 병행 실행될 경우 더욱 그렇습니다.
  • 시스템이 flat file에 의존한다면, 파일 백업 절차를 마련하고 문서화해야 합니다.
  • 정기적인 테스트도 반드시 수행해야 합니다.

 

 

 

Batch Processing Strategies

서론

• 배치 시스템을 설계하고 구현하기 위해
  • 구조도나 코드 템플릿 형태로 기본적인 빌딩 블록과 패턴을 개발자에게 제공해야 함.
• 배치 잡을 설계할 때는
  • 업무 로직을 여러 단계로 나누고,
  • 아래의 Std Building Blocks을 활용해 구현해야 함.

 

Standard Building Blocks

1. Conversion Applications
   • 외부 시스템에서 받은 파일이 있을 경우
   • 이를 처리하기 위해 표준 포맷으로 변환하는 애플리케이션이 필요함.
2. Validation Applications
   • 입력 및 출력 레코드가 정확하고 일관된지 검사. 
   • 체크섬, 헤더 유효성, 필드 검사 등
3. Extract Applications
   • 데이터베이스나 입력 파일에서 레코드를 추출하고, 규칙에 따라 선택, 출력 파일로 기록.
4. Extract/Update Applications
   • 데이터를 읽고, DB나 파일을 업데이트까지 수행하는 추출/갱신 애플리케이션.
5. Processing and Updating Applications
   • 실제 비즈니스 로직이 포함된 애플리케이션.
   • 입력을 기반으로 DB 조회, 갱신, 레코드 생성 등을 수행.
6. Output/Format Applications
   • 처리된 데이터를 출력용 포맷으로 변환하고, 다른 시스템으로 전송하거나 파일로 출력.

위 빌딩 블록만으로 구현이 어려운 로직은, 기본 애플리케이션 템플릿을 따로 제공해야 함.

 

 

기본적인 처리 유틸리티

각 배치 애플리케이션은 다음과 같은 유틸리티 단계를 사용할 수 있음

• Sort : 입력 파일을 읽고, 정렬된 출력 파일 생성(예: 키 필드 기준 정렬)
• Split : 입력 파일을 읽고, 특정 필드 값을 기준으로 여러 개의 파일로 분할.
• Merge : 여러 개의 입력 파일을 읽고, 합쳐진 하나의 파일로 출력.

 

입력 소스에 따른 분류

배치 애플리케이션은 입력 소스에 따라 다음과 같이 분류할 수 있음:

• Database-driven: DB의 row 또는 값 기반
• File-driven: 파일에서 레코드 기반으로 처리
• Message-driven: 메시지 큐에서 수신한 메시지 기반

 

배치 처리 전략 (Processing Strategy)

배치 시스템의 핵심은 처리 전략. 선택에 영향을 주는 요소들:

• 배치 시스템의 예상 규모
• 온라인 시스템이나 다른 배치와의 동시성
• 사용 가능한 배치 처리 시간
  • 참고: 기업들이 24/7 운영을 원하면서 명확한 배치 시간 확보가 어려워짐

 

배치 처리 방식 (단순 → 복잡 순서)

 

1. 오프라인 모드에서의 일반 배치 처리
2. 온라인 동시 처리(batch + online)
3. 여러 배치 잡 또는 인스턴스를 동시에 실행
4. 하나의 잡을 여러 인스턴스로 나눠 처리 (Partitioning)
5. 위 전략들을 조합한 방식

 

 

잠금 전략(Locking Strategy

 

• DB 잠금만 사용할 수도 있고,
• 사용자 정의 잠금 서비스 구현 가능 (예: 잠금 정보용 테이블 따로 만들어 사용)
• 잠금 전략은 사후에 생각할 게 아니라, 아키텍처 설계 단계에서부터 고려해야 함
• 잠금 실패 시 retry 로직도 설계에 포함될 수 있음