스프링 배치(spring batch)

스프링 배치 소개

엔터프라이즈 도메인 내의 많은 애플리케이션은 미션 크리티컬 환경에서 비즈니스 운영을 수행하기 위해 대량 처리가 필요합니다. 이러한 비즈니스 운영에는 다음이 포함됩니다.

• 사용자 상호 작용 없이 가장 효율적으로 처리되는 대량 정보의 자동화된 복잡한 처리. 이러한 작업에는 일반적으로 시간 기반 이벤트(예: 월말 계산, 통지 또는 서신)가 포함됩니다.
• 매우 큰 데이터 세트에서 반복적으로 처리되는 복잡한 비즈니스 규칙의 주기적 적용(예: 보험 혜택 결정 또는 요율 조정).
• 일반적으로 형식 지정, 유효성 검사 및 트랜잭션 방식의 처리가 필요한 내부 및 외부 시스템에서 받은 정보를 기록 시스템에 통합합니다. 일괄 처리는 기업에서 매일 수십억 건의 트랜잭션을 처리하는 데 사용됩니다.

Spring Batch는 엔터프라이즈 시스템의 일상적인 운영에 필수적인 강력한 배치 애플리케이션의 개발을 가능하게 하도록 설계된 가볍고 포괄적인 배치 프레임워크입니다. Spring Batch는 사람들이 기대하는 Spring Framework의 특성(생산성, POJO 기반 개발 접근 방식 및 일반적인 사용 용이성)을 기반으로 하는 동시에 개발자가 필요할 때 보다 고급 엔터프라이즈 서비스에 쉽게 액세스하고 활용할 수 있도록 합니다. Spring Batch는 스케줄링 프레임워크가 아닙니다. 상용 및 오픈 소스 공간 모두에서 사용할 수 있는 좋은 엔터프라이즈 스케줄러(예: Quartz, Tivoli, Control-M 등)가 많이 있습니다. 스케줄러를 대체하는 것이 아니라 스케줄러와 함께 작동하기 위한 것입니다.

Spring Batch는 로깅/추적, 트랜잭션 관리, 작업 처리 통계, 작업 재시작, 건너뛰기, 리소스 관리 등 대용량 레코드 처리에 필수적인 재사용 가능한 기능을 제공합니다. 또한 최적화 및 파티셔닝 기술을 통해 대용량 및 고성능 일괄 작업을 가능하게 하는 고급 기술 서비스 및 기능을 제공합니다. Spring Batch는 단순한 사용 사례(예: 데이터베이스로 파일 읽기 또는 저장 프로시저 실행)와 복잡한 대용량 사용 사례(예: 데이터베이스 간에 대용량 데이터 이동, 변환 등)에서 사용할 수 있습니다. 에). 대용량 일괄 작업은 확장성이 뛰어난 방식으로 프레임워크를 활용하여 상당한 양의 정보를 처리할 수 있습니다.

배경

오픈 소스 소프트웨어 프로젝트 및 관련 커뮤니티가 웹 기반 및 마이크로서비스 기반 아키텍처 프레임워크에 더 많은 관심을 기울이는 동안 Java 기반 배치 처리 요구 사항을 수용하기 위해 재사용 가능한 아키텍처 프레임워크에 대한 관심이 현저히 부족했습니다. 기업 IT 환경 내에서 처리합니다. 재사용 가능한 표준 배치 아키텍처의 부재로 인해 클라이언트 엔터프라이즈 IT 기능 내에서 개발된 많은 일회성 사내 솔루션이 확산되었습니다.

SpringSource(현재 Pivotal)와 Accenture는 이를 변경하기 위해 협력했습니다. 일괄 아키텍처 구현에 대한 Accenture의 실무 산업 및 기술 경험, SpringSource의 깊이 있는 기술 경험, Spring의 입증된 프로그래밍 모델이 함께 자연스럽고 강력한 파트너십을 통해 엔터프라이즈 Java의 중요한 격차를 메우기 위한 고품질의 시장 관련 소프트웨어를 만들었습니다. . 두 회사는 Spring 기반 배치 아키텍처 솔루션을 개발하여 유사한 문제를 해결하는 많은 클라이언트와 협력했습니다. 이는 클라이언트가 제기한 실제 문제에 솔루션을 적용할 수 있도록 하는 몇 가지 유용한 추가 세부 정보와 실제 제약 조건을 제공했습니다.

Accenture는 이전에 독점적인 배치 처리 아키텍처 프레임워크를 Spring Batch 프로젝트에 기여했으며 지원, 향상 및 기존 기능 세트를 구동하기 위한 커미터 리소스를 제공했습니다. Accenture의 기여는 COBOL/Mainframe, C++/Unix 및 현재 Java/anywhere 플랫폼과 같은 지난 몇 세대의 플랫폼으로 배치 아키텍처를 구축한 수십 년의 경험을 기반으로 합니다.

Accenture와 SpringSource 간의 공동 작업은 일괄 응용 프로그램을 만들 때 엔터프라이즈 사용자가 일관되게 활용할 수 있는 소프트웨어 처리 접근 방식, 프레임워크 및 도구의 표준화를 촉진하는 것을 목표로 했습니다. 엔터프라이즈 IT 환경에 입증된 표준 솔루션을 제공하고자 하는 회사 및 정부 기관은 Spring Batch의 이점을 누릴 수 있습니다.

사용 시나리오

일반적인 배치 프로그램은 일반적으로 다음과 같습니다.

• 데이터베이스, 파일 또는 대기열에서 많은 수의 레코드를 읽습니다.
• 어떤 방식으로 데이터를 처리합니다.
• 수정된 형식으로 데이터를 다시 씁니다.

Spring Batch는 이 기본 배치 반복을 자동화하여 일반적으로 사용자 상호 작용 없이 오프라인 환경에서 유사한 트랜잭션을 세트로 처리할 수 있는 기능을 제공합니다. 배치 작업은 대부분의 IT 프로젝트의 일부이며 Spring Batch는 강력한 엔터프라이즈급 솔루션을 제공하는 유일한 오픈 소스 프레임워크입니다.

비즈니스 시나리오

• 주기적으로 일괄 처리 커밋
• 동시 일괄 처리: 작업의 병렬 처리
• 단계적 엔터프라이즈 메시지 기반 처리
• 대규모 병렬 배치 처리
• 실패 후 수동 또는 예약된 재시작
• 종속 단계의 순차적 처리(워크플로 기반 배치에 대한 확장 포함)
• 부분 처리: 레코드 건너뛰기(예: 롤백 시)
• 전체 배치 트랜잭션, 배치 크기가 작거나 기존 저장 프로시저/스크립트가 있는 경우

기술적 목표

• 일괄 개발자는 Spring 프로그래밍 모델을 사용합니다. 비즈니스 로직에 집중하고 프레임워크가 인프라를 처리하도록 합니다.
• 인프라, 배치 실행 환경 및 배치 애플리케이션 간의 문제를 명확하게 분리합니다.
• 모든 프로젝트가 구현할 수 있는 인터페이스로 공통의 핵심 실행 서비스를 제공합니다.
• '즉시' 사용할 수 있는 핵심 실행 인터페이스의 단순하고 기본 구현을 제공합니다.
• 모든 계층에서 스프링 프레임워크를 활용하여 서비스를 쉽게 구성, 사용자 정의 및 확장할 수 있습니다.
• 기존의 모든 핵심 서비스는 인프라 계층에 영향을 주지 않고 쉽게 교체하거나 확장할 수 있어야 합니다.
• Maven을 사용하여 구축된 애플리케이션과 완전히 분리된 아키텍처 JAR로 간단한 배포 모델을 제공합니다.

스프링 배치 아키텍처

Spring Batch는 확장성과 다양한 최종 사용자 그룹을 염두에 두고 설계되었습니다. 아래 그림은 최종 사용자 개발자를 위한 확장성과 사용 편의성을 지원하는 계층화된 아키텍처를 보여줍니다.

그림 1. Spring Batch 계층화 아키텍처

이 계층화된 아키텍처는 애플리케이션, 코어 및 인프라의 세 가지 주요 상위 수준 구성 요소를 강조합니다. 애플리케이션에는 Spring Batch를 사용하여 개발자가 작성한 모든 배치 작업과 사용자 정의 코드가 포함되어 있습니다. Batch Core에는 배치 작업을 시작하고 제어하는 ​​데 필요한 핵심 런타임 클래스가 포함되어 있습니다. JobLauncher여기에는 , Job및 에 대한 구현이 포함됩니다 Step. 애플리케이션과 코어는 모두 공통 인프라 위에 구축됩니다. RetryTemplate이 인프라에는 응용 프로그램 개발자(예: ItemReader및 ItemWriter)와 핵심 프레임워크 자체(자체 라이브러리인 재시도) 가 사용하는 공통 판독기 및 작성기 및 서비스(예: )가 포함됩니다.

일반 배치 원칙 및 지침

배치 솔루션을 구축할 때는 다음과 같은 주요 원칙, 지침 및 일반적인 고려 사항을 고려해야 합니다.

• 배치 아키텍처는 일반적으로 온라인 아키텍처에 영향을 미치며 그 반대의 경우도 마찬가지입니다. 가능하면 공통 빌딩 블록을 사용하여 아키텍처와 환경을 모두 염두에 두고 설계합니다.
• 가능한 한 단순화하고 단일 배치 애플리케이션에서 복잡한 논리적 구조를 구축하지 마십시오.
• 데이터의 처리 및 저장을 물리적으로 가깝게 유지합니다(즉, 처리가 발생하는 위치에 데이터를 유지).
• 시스템 리소스 사용, 특히 I/O를 최소화합니다. 내부 메모리에서 가능한 한 많은 작업을 수행합니다.
• 애플리케이션 I/O를 검토(SQL 문 분석)하여 불필요한 물리적 I/O를 방지합니다. 특히 다음 네 가지 일반적인 결함을 찾아야 합니다.
• • 데이터를 한 번 읽고 작업 저장소에 캐시하거나 보관할 수 있는 경우 모든 트랜잭션에 대한 데이터 읽기.
  • 동일한 트랜잭션에서 이전에 데이터를 읽은 트랜잭션에 대한 데이터 다시 읽기.
  • 불필요한 테이블 또는 인덱스 스캔을 유발합니다.
  • SQL 문의 WHERE 절에 키 값을 지정하지 않습니다.
• 배치 실행에서 작업을 두 번 수행하지 마십시오. 예를 들어 보고 목적으로 데이터 요약이 필요한 경우 데이터를 처음 처리할 때 (가능한 경우) 저장된 합계를 늘려 보고 응용 프로그램에서 동일한 데이터를 다시 처리할 필요가 없도록 해야 합니다.
• 프로세스 중에 시간이 많이 걸리는 재할당을 방지하기 위해 배치 응용 프로그램을 시작할 때 충분한 메모리를 할당합니다.
• 데이터 무결성과 관련하여 항상 최악의 상황을 가정하십시오. 데이터 무결성을 유지하기 위해 적절한 검사를 삽입하고 유효성을 기록합니다.
• 가능한 경우 내부 유효성 검사를 위한 체크섬을 구현합니다. 예를 들어 플랫 파일에는 파일의 총 레코드와 키 필드의 집계를 알려주는 트레일러 레코드가 있어야 합니다.
• 실제 데이터 볼륨이 있는 프로덕션과 유사한 환경에서 가능한 한 빨리 스트레스 테스트를 계획하고 실행합니다.
• 대규모 배치 시스템에서는 특히 시스템이 연중무휴로 온라인과 동시에 실행되는 경우 백업이 어려울 수 있습니다. 데이터베이스 백업은 일반적으로 온라인 설계에서 잘 처리되지만 파일 백업도 마찬가지로 중요하게 간주되어야 합니다. 시스템이 플랫 파일에 의존하는 경우 파일 백업 절차를 마련하고 문서화해야 할 뿐만 아니라 정기적으로 테스트해야 합니다.

일괄 처리 전략

배치 시스템을 설계하고 구현하는 데 도움이 되도록 기본 배치 애플리케이션 빌딩 블록과 패턴이 샘플 구조 차트 및 코드 쉘의 형태로 설계자와 프로그래머에게 제공되어야 합니다. 배치 작업 설계를 시작할 때 비즈니스 로직은 다음 표준 빌딩 블록을 사용하여 구현할 수 있는 일련의 단계로 분해되어야 합니다.

• 변환 응용 프로그램: 외부 시스템에서 제공하거나 외부 시스템에 생성된 각 유형의 파일에 대해 제공된 트랜잭션 레코드를 처리에 필요한 표준 형식으로 변환하려면 변환 응용 프로그램을 만들어야 합니다. 이러한 유형의 배치 애플리케이션은 부분적으로 또는 전체적으로 번역 유틸리티 모듈로 구성될 수 있습니다(기본 배치 서비스 참조).
• 검증 애플리케이션: 검증 애플리케이션은 모든 입력/출력 기록이 정확하고 일관성이 있는지 확인합니다. 유효성 검사는 일반적으로 파일 헤더 및 트레일러, 체크섬 및 유효성 검사 알고리즘, 레코드 수준 교차 검사를 기반으로 합니다.
• 응용 프로그램 추출: 데이터베이스 또는 입력 파일에서 레코드 집합을 읽고 사전 정의된 규칙에 따라 레코드를 선택하고 출력 파일에 기록을 쓰는 응용 프로그램입니다.
• 추출/업데이트 응용 프로그램: 데이터베이스 또는 입력 파일에서 레코드를 읽고 각 입력 레코드에서 찾은 데이터에 의해 구동되는 데이터베이스 또는 출력 파일을 변경하는 응용 프로그램입니다.
• 응용 프로그램 처리 및 업데이트: 추출 또는 유효성 검사 응용 프로그램의 입력 트랜잭션에 대한 처리를 수행하는 응용 프로그램입니다. 처리에는 일반적으로 처리에 필요한 데이터를 얻기 위해 데이터베이스를 읽고, 잠재적으로 데이터베이스를 업데이트하고, 출력 처리를 위한 레코드를 만드는 작업이 포함됩니다.
• 출력/형식 응용 프로그램: 입력 파일을 읽고, 표준 형식에 따라 이 레코드의 데이터를 재구성하고, 다른 프로그램이나 시스템으로 인쇄하거나 전송하기 위해 출력 파일을 생성하는 응용 프로그램입니다.

또한 앞서 언급한 빌딩 블록을 사용하여 구축할 수 없는 비즈니스 로직을 위한 기본 애플리케이션 셸을 제공해야 합니다.

기본 빌딩 블록 외에도 각 애플리케이션은 다음과 같은 표준 유틸리티 단계 중 하나 이상을 사용할 수 있습니다.

• 정렬: 입력 파일을 읽고 레코드의 정렬 키 필드에 따라 레코드의 순서가 다시 지정된 출력 파일을 생성하는 프로그램입니다. 정렬은 일반적으로 표준 시스템 유틸리티에 의해 수행됩니다.
• 분할: 단일 입력 파일을 읽고 필드 값을 기반으로 여러 출력 파일 중 하나에 각 레코드를 쓰는 프로그램입니다. 분할은 매개변수 기반 표준 시스템 유틸리티에 의해 조정되거나 수행될 수 있습니다.
• 병합: 여러 입력 파일에서 레코드를 읽고 입력 파일에서 결합된 데이터로 하나의 출력 파일을 생성하는 프로그램입니다. 병합은 매개변수 기반 표준 시스템 유틸리티에 의해 조정되거나 수행될 수 있습니다.

배치 애플리케이션은 입력 소스별로 추가로 분류할 수 있습니다.

• 데이터베이스 기반 애플리케이션은 데이터베이스에서 검색된 행 또는 값에 의해 구동됩니다.
• 파일 기반 애플리케이션은 파일에서 검색된 레코드 또는 값에 의해 구동됩니다.
• 메시지 기반 애플리케이션은 메시지 대기열에서 검색된 메시지에 의해 구동됩니다.

모든 배치 시스템의 기초는 처리 전략입니다. 전략 선택에 영향을 미치는 요인은 다음과 같습니다. 예상 배치 시스템 볼륨, 온라인 시스템 또는 다른 배치 시스템과의 동시성, 사용 가능한 배치 창. (24x7 가동 및 실행을 원하는 기업이 늘어남에 따라 명확한 배치 창이 사라지고 있습니다.)

배치에 대한 일반적인 처리 옵션은 다음과 같습니다(구현 복잡성이 증가하는 순서).

• 오프라인 모드의 일괄 처리 창에서 정상적인 처리.
• 동시 배치 또는 온라인 처리.
• 동시에 많은 다른 배치 실행 또는 작업의 병렬 처리.
• 파티셔닝(동시에 동일한 작업의 여러 인스턴스 처리).
• 이전 옵션의 조합입니다.

이러한 옵션 중 일부 또는 전부는 상용 스케줄러에서 지원될 수 있습니다.

다음 섹션에서는 이러한 처리 옵션에 대해 자세히 설명합니다. 일반적으로 배치 프로세스에서 채택한 커밋 및 잠금 전략은 수행되는 처리 유형에 따라 다르며 온라인 잠금 전략도 동일한 원칙을 사용해야 합니다. 따라서 일괄 아키텍처는 전체 아키텍처를 설계할 때 단순히 사후 고려 사항이 될 수 없습니다.

잠금 전략은 일반 데이터베이스 잠금만 사용하거나 아키텍처에서 추가 사용자 지정 잠금 서비스를 구현하는 것일 수 있습니다. 잠금 서비스는 데이터베이스 잠금을 추적하고(예: 전용 db-table에 필요한 정보를 저장하여) db 작업을 요청하는 응용 프로그램에 권한을 부여하거나 거부합니다. 잠금 상황의 경우 일괄 작업이 중단되는 것을 방지하기 위해 이 아키텍처에서 재시도 논리를 구현할 수도 있습니다.

1. 배치 창에서 일반 처리 온라인 사용자나 다른 배치 프로세스에서 업데이트 중인 데이터가 필요하지 않은 별도의 배치 창에서 실행되는 간단한 배치 프로세스의 경우 동시성은 문제가 되지 않으며 단일 커밋은 배치 실행 종료.

대부분의 경우 보다 강력한 접근 방식이 더 적합합니다. 배치 시스템은 복잡성과 처리하는 데이터 볼륨 측면에서 시간이 지남에 따라 증가하는 경향이 있음을 명심하십시오. 잠금 전략이 없고 시스템이 여전히 단일 커밋 지점에 의존하는 경우 배치 프로그램을 수정하는 것이 어려울 수 있습니다. 따라서 가장 단순한 배치 시스템의 경우에도 재시작-복구 옵션에 대한 커밋 논리의 필요성과 이 섹션의 뒷부분에서 설명하는 보다 복잡한 경우에 대한 정보를 고려하십시오.

2. 동시 일괄 처리 또는 온라인 처리 온라인 사용자가 동시에 업데이트할 수 있는 데이터를 처리하는 일괄 응용 프로그램은 온라인 사용자가 필요로 할 수 있는 데이터(데이터베이스 또는 파일)를 1시간 이상 잠그면 안 됩니다. 몇 초. 또한 몇 번의 트랜잭션이 끝날 때마다 데이터베이스에 업데이트를 커밋해야 합니다. 이렇게 하면 다른 프로세스에서 사용할 수 없는 데이터 부분과 데이터를 사용할 수 없는 경과 시간이 최소화됩니다.

물리적 잠금을 최소화하는 또 다른 옵션은 낙관적 잠금 패턴 또는 비관적 잠금 패턴을 사용하여 논리적 행 수준 잠금을 구현하는 것입니다.

• 낙관적 잠금은 레코드 경합 가능성이 낮다고 가정합니다. 일반적으로 일괄 처리 및 온라인 처리에서 동시에 사용되는 각 데이터베이스 테이블에 타임스탬프 열을 삽입하는 것을 의미합니다. 애플리케이션이 처리를 위해 행을 가져올 때 타임스탬프도 가져옵니다. 그런 다음 애플리케이션이 처리된 행을 업데이트하려고 할 때 업데이트는 WHERE 절의 원래 타임스탬프를 사용합니다. 타임스탬프가 일치하면 데이터와 타임스탬프가 업데이트됩니다. 타임스탬프가 일치하지 않으면 다른 애플리케이션이 가져오기와 업데이트 시도 사이에 동일한 행을 업데이트했음을 나타냅니다. 따라서 업데이트를 수행할 수 없습니다.
• 비관적 잠금은 레코드 경합 가능성이 높기 때문에 검색 시 물리적 또는 논리적 잠금을 얻어야 한다고 가정하는 잠금 전략입니다. 비관적 논리적 잠금의 한 유형은 데이터베이스 테이블의 전용 잠금 열을 사용합니다. 애플리케이션이 업데이트를 위해 행을 검색할 때 잠금 열에 플래그를 설정합니다. 플래그를 설정하면 동일한 행을 검색하려는 다른 응용 프로그램이 논리적으로 실패합니다. 플래그를 설정하는 애플리케이션이 행을 업데이트하면 플래그도 지워져 다른 애플리케이션에서 해당 행을 검색할 수 있습니다. 예를 들어 db 잠금(예:SELECT FOR UPDATE). 또한 이 방법은 레코드가 잠겨 있는 동안 사용자가 점심을 먹으러 가는 경우 잠금을 해제하는 시간 제한 메커니즘을 구축하는 것이 다소 쉽다는 점을 제외하고는 물리적 잠금과 동일한 단점이 있습니다.

이러한 패턴은 일괄 처리에 적합하지 않을 수 있지만 동시 일괄 처리 및 온라인 처리(예: 데이터베이스가 행 수준 잠금을 지원하지 않는 경우)에 사용할 수 있습니다. 일반적으로 낙관적 잠금은 온라인 응용 프로그램에 더 적합하고 비관적 잠금은 일괄 응용 프로그램에 더 적합합니다. 논리적 잠금을 사용할 때마다 논리적 잠금으로 보호되는 데이터 엔터티에 액세스하는 모든 응용 프로그램에 대해 동일한 체계를 사용해야 합니다.

이 두 솔루션 모두 단일 레코드 잠금만 해결합니다. 종종 논리적으로 관련된 레코드 그룹을 잠글 필요가 있습니다. 물리적 잠금을 사용하면 잠재적 교착 상태를 피하기 위해 이러한 잠금을 매우 신중하게 관리해야 합니다. 논리적 잠금을 사용하는 경우 일반적으로 보호하려는 논리적 레코드 그룹을 이해하고 잠금이 일관성 있고 교착 상태가 아님을 확인할 수 있는 논리적 잠금 관리자를 구축하는 것이 가장 좋습니다. 이 논리적 잠금 관리자는 일반적으로 잠금 관리, 경합 보고, 시간 초과 메커니즘 및 기타 문제를 위해 자체 테이블을 사용합니다.

3. 병렬 처리 병렬 처리를 사용하면 여러 배치 실행 또는 작업을 병렬로 실행하여 경과된 총 배치 처리 시간을 최소화할 수 있습니다. 작업이 동일한 파일, DB 테이블 또는 인덱스 공간을 공유하지 않는 한 문제가 되지 않습니다. 그렇다면 이 서비스는 분할된 데이터를 사용하여 구현해야 합니다. 또 다른 옵션은 제어 테이블을 사용하여 상호 의존성을 유지하기 위한 아키텍처 모듈을 구축하는 것입니다. 제어 테이블에는 각 공유 리소스에 대한 행과 애플리케이션에서 사용 중인지 여부가 포함되어야 합니다. 배치 아키텍처 또는 병렬 작업의 애플리케이션은 해당 테이블에서 정보를 검색하여 필요한 리소스에 액세스할 수 있는지 여부를 결정합니다.

데이터 접근에 문제가 없다면 병렬 처리를 위해 추가 스레드를 사용하여 병렬 처리를 구현할 수 있습니다. 메인프레임 환경에서는 모든 프로세스에 적절한 CPU 시간을 보장하기 위해 전통적으로 병렬 작업 클래스가 사용되었습니다. 그럼에도 불구하고 솔루션은 실행 중인 모든 프로세스에 대한 시간 조각을 보장할 수 있을 만큼 충분히 강력해야 합니다.

병렬 처리의 다른 주요 문제에는 로드 밸런싱과 파일, 데이터베이스 버퍼 풀 등과 같은 일반 시스템 리소스의 가용성이 포함됩니다. 또한 제어 테이블 자체가 쉽게 중요한 리소스가 될 수 있습니다.

4. 파티셔닝 파티셔닝 을 사용하면 여러 버전의 대규모 배치 애플리케이션을 동시에 실행할 수 있습니다. 이것의 목적은 긴 배치 작업을 처리하는 데 필요한 경과 시간을 줄이는 것입니다. 성공적으로 분할될 수 있는 프로세스는 입력 파일을 분할할 수 있는 프로세스 및/또는 기본 데이터베이스 테이블을 분할하여 애플리케이션이 다른 데이터 세트에 대해 실행할 수 있도록 하는 프로세스입니다.

또한 분할된 프로세스는 할당된 데이터 세트만 처리하도록 설계해야 합니다. 파티셔닝 아키텍처는 데이터베이스 디자인 및 데이터베이스 파티셔닝 전략과 밀접하게 연결되어야 합니다. 대부분의 경우 권장되지만 데이터베이스 분할이 반드시 데이터베이스의 물리적 분할을 의미하는 것은 아닙니다. 다음 그림은 분할 방식을 보여줍니다.

그림 2. 분할된 프로세스

아키텍처는 파티션 수를 동적으로 구성할 수 있을 만큼 충분히 유연해야 합니다. 자동 구성과 사용자 제어 구성을 모두 고려해야 합니다. 자동 구성은 입력 파일 크기 및 입력 레코드 수와 같은 매개변수를 기반으로 할 수 있습니다.

4.1 분할 방식 분할 방식 선택은 사례별로 수행되어야 합니다. 다음 목록은 몇 가지 가능한 분할 방식에 대해 설명합니다.

1. 기록 세트의 고정 및 균등 분할

여기에는 입력 레코드 세트를 짝수 부분으로 나누는 작업이 포함됩니다(예: 각 부분이 전체 레코드 세트의 정확히 1/10인 경우 10). 그런 다음 각 부분은 일괄/추출 응용 프로그램의 한 인스턴스에서 처리됩니다.

이 접근 방식을 사용하려면 레코드 설정을 분할하기 위한 전처리가 필요합니다. 이 분할의 결과는 처리를 해당 부분으로만 제한하기 위해 배치/추출 응용 프로그램에 대한 입력으로 사용할 수 있는 하한 및 상한 배치 번호가 됩니다.

전처리는 레코드 세트의 각 부분의 경계를 계산하고 결정해야 하므로 큰 오버헤드가 될 수 있습니다.

2. 키 열로 나누기

여기에는 위치 코드와 같은 키 열로 설정된 입력 레코드를 분리하고 각 키의 데이터를 배치 인스턴스에 할당하는 작업이 포함됩니다. 이를 달성하기 위해 열 값은 다음 중 하나일 수 있습니다.

• 분할 테이블에 의해 배치 인스턴스에 할당됩니다(이 섹션의 뒷부분에서 설명됨).
• 값의 일부에 의해 배치 인스턴스에 할당됩니다(예: 0000-0999, 1000 - 1999 등).

옵션 1에서 새 값을 추가한다는 것은 새 값이 특정 인스턴스에 추가되도록 배치/추출을 수동으로 재구성하는 것을 의미합니다.

옵션 2에서 이렇게 하면 일괄 작업의 인스턴스를 통해 모든 값이 포함됩니다. 그러나 한 인스턴스에서 처리하는 값의 수는 열 값의 분포에 따라 다릅니다(0000-0999 범위에는 많은 수의 위치가 있고 1000-1999 범위에는 소수의 위치가 있을 수 있음). 이 옵션에서 데이터 범위는 분할을 염두에 두고 설계해야 합니다.

두 옵션 모두 배치 인스턴스에 대한 최적의 균일한 레코드 분배를 실현할 수 없습니다. 사용되는 배치 인스턴스 수에 대한 동적 구성은 없습니다.

3. 조회수별 분류

이 접근 방식은 기본적으로 키 열을 기준으로 하지만 데이터베이스 수준에서 분리됩니다. 여기에는 레코드 집합을 보기로 나누는 작업이 포함됩니다. 이러한 보기는 처리 중에 배치 응용 프로그램의 각 인스턴스에서 사용됩니다. 분리는 데이터를 그룹화하여 수행됩니다.

이 옵션을 사용하면 배치 애플리케이션의 각 인스턴스가 특정 보기(마스터 테이블 대신)를 조회하도록 구성되어야 합니다. 또한 새 데이터 값이 추가되면 이 새 데이터 그룹이 보기에 포함되어야 합니다. 인스턴스 수가 변경되면 보기가 변경되므로 동적 구성 기능은 없습니다.

4. 처리 지표 추가

여기에는 표시기 역할을 하는 입력 테이블에 새 열을 추가하는 작업이 포함됩니다. 전처리 단계로 모든 지표는 처리되지 않은 것으로 표시됩니다. 일괄 적용의 레코드 가져오기 단계에서는 해당 레코드를 미처리로 표시한 상태에서 레코드를 읽고, 일단 읽히면(잠금) 처리 중으로 표시됩니다. 해당 레코드가 완료되면 표시기가 완료 또는 오류로 업데이트됩니다. 추가 열은 레코드가 한 번만 처리되도록 보장하므로 일괄 응용 프로그램의 많은 인스턴스를 변경 없이 시작할 수 있습니다.

이 옵션을 사용하면 테이블의 I/O가 동적으로 증가합니다. 배치 응용 프로그램을 업데이트하는 경우 어쨌든 쓰기가 발생해야 하므로 이러한 영향이 줄어듭니다.

5. 플랫 파일로 테이블 추출

여기에는 테이블을 파일로 추출하는 작업이 포함됩니다. 그런 다음 이 파일을 여러 세그먼트로 분할하고 배치 인스턴스에 대한 입력으로 사용할 수 있습니다.

이 옵션을 사용하면 테이블을 파일로 추출하고 분할하는 추가 오버헤드가 다중 분할 효과를 상쇄할 수 있습니다. 파일 분할 스크립트를 변경하여 동적 구성을 수행할 수 있습니다.

6. 해싱 열의 사용

이 체계에는 드라이버 레코드를 검색하는 데 사용되는 데이터베이스 테이블에 해시 열(키/인덱스)이 추가됩니다. 이 해시 열에는 이 특정 행을 처리하는 일괄 처리 응용 프로그램의 인스턴스를 결정하는 표시기가 있습니다. 예를 들어 시작할 배치 인스턴스가 세 개 있는 경우 'A' 표시기는 인스턴스 1에서 처리할 행을 표시하고 'B' 표시기는 인스턴스 2로 처리할 행을 표시하며 표시기 'C '는 인스턴스 3에서 처리할 행을 표시합니다.

레코드를 검색하는 데 사용되는 프로시저 WHERE에는 특정 표시기로 표시된 모든 행을 선택하는 추가 절이 있습니다. 이 테이블의 삽입에는 마커 필드의 추가가 포함되며 기본적으로 인스턴스 중 하나(예: 'A')로 설정됩니다.

다른 인스턴스 간에 부하를 재분배하는 것과 같이 표시기를 업데이트하는 데 간단한 배치 응용 프로그램이 사용됩니다. 충분히 많은 수의 새 행이 추가되면 이 배치를 실행하여(배치 창을 제외하고 언제든지) 새 행을 다른 인스턴스에 재배포할 수 있습니다.

배치 애플리케이션의 추가 인스턴스는 이전 단락에서 설명한 대로 배치 애플리케이션을 실행하기만 하면 지표를 재배포하여 새로운 인스턴스 수와 함께 작동합니다.

4.2 데이터베이스 및 애플리케이션 설계 원칙

키 컬럼 접근 방식을 사용하여 파티션된 데이터베이스 테이블에 대해 실행되는 다중 파티션된 애플리케이션을 지원하는 아키텍처에는 파티션 매개변수를 저장하기 위한 중앙 파티션 저장소가 포함되어야 합니다. 이는 유연성을 제공하고 유지보수성을 보장합니다. 저장소는 일반적으로 파티션 테이블이라고 하는 단일 테이블로 구성됩니다.

파티션 테이블에 저장된 정보는 정적이며 일반적으로 DBA가 유지 관리해야 합니다. 테이블은 다중 파티션된 응용 프로그램의 각 파티션에 대한 하나의 정보 행으로 구성되어야 합니다. 테이블에는 프로그램 ID 코드, 파티션 번호(파티션의 논리 ID), 이 파티션에 대한 db 키 열의 낮은 값 및 이 파티션에 대한 db 키 열의 높은 값에 대한 열이 있어야 합니다.

프로그램 시작 시 프로그램 id과 파티션 번호는 아키텍처(특히, Control Processing Tasklet에서)에서 애플리케이션으로 전달되어야 합니다. 키 열 접근 방식을 사용하는 경우 이러한 변수는 애플리케이션이 처리할 데이터 범위를 결정하기 위해 파티션 테이블을 읽는 데 사용됩니다. 또한 파티션 번호는 처리 전반에 걸쳐 다음을 위해 사용해야 합니다.

• 병합 프로세스가 제대로 작동하려면 출력 파일/데이터베이스 업데이트에 추가하십시오.
• 배치 로그에 정상적인 처리를 보고하고 아키텍처 오류 처리기에 모든 오류를 보고합니다.

4.3 교착 상태 최소화

응용 프로그램이 병렬로 실행되거나 분할되면 데이터베이스 리소스 경합 및 교착 상태가 발생할 수 있습니다. 데이터베이스 디자인 팀은 데이터베이스 디자인의 일부로 가능한 한 잠재적인 경합 상황을 제거하는 것이 중요합니다.

또한 개발자는 데이터베이스 인덱스 테이블이 교착 상태 방지 및 성능을 염두에 두고 설계되었는지 확인해야 합니다.

교착 상태 또는 핫스팟은 로그 테이블, 제어 테이블 및 잠금 테이블과 같은 관리 또는 아키텍처 테이블에서 종종 발생합니다. 이들의 의미도 고려되어야 합니다. 현실적인 스트레스 테스트는 아키텍처에서 가능한 병목 현상을 식별하는 데 중요합니다.

충돌이 데이터에 미치는 영향을 최소화하기 위해 아키텍처는 데이터베이스에 연결할 때 또는 교착 상태가 발생할 때 대기 및 재시도 간격과 같은 서비스를 제공해야 합니다. 이는 특정 데이터베이스 반환 코드에 반응하고 즉각적인 오류를 발생시키는 대신 미리 결정된 시간 동안 기다렸다가 데이터베이스 작업을 재시도하는 내장 메커니즘을 의미합니다.

4.4 매개변수 전달 및 검증

파티션 아키텍처는 애플리케이션 개발자에게 비교적 투명해야 합니다. 아키텍처는 다음을 포함하여 분할 모드에서 애플리케이션 실행과 관련된 모든 작업을 수행해야 합니다.

• 애플리케이션 시작 전에 파티션 매개변수를 검색합니다.
• 애플리케이션 시작 전에 파티션 매개변수 검증.
• 시작 시 애플리케이션에 매개변수 전달.

유효성 검사에는 다음을 확인하는 검사가 포함되어야 합니다.

• 응용 프로그램에는 전체 데이터 범위를 포괄할 수 있는 충분한 파티션이 있습니다.
• 파티션 사이에는 간격이 없습니다.

데이터베이스가 파티션된 경우 단일 파티션이 데이터베이스 파티션에 걸쳐 있지 않은지 확인하기 위해 몇 가지 추가 유효성 검증이 필요할 수 있습니다.

또한 아키텍처는 파티션 통합을 고려해야 합니다. 주요 질문은 다음과 같습니다.

• 다음 작업 단계로 넘어가기 전에 모든 파티션을 완료해야 합니까?
• 파티션 중 하나가 중단되면 어떻게 됩니까?

 

 

 

Reference

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