Spring Batch 발표자 : 유 상 민.

Spring Batch 발표자 : 유 상 민

목 차 배치 스프링 배치 Spring Batch 2.0 적용 사례 Sample Source Test Sample 향후 계획
아키텍쳐. 구조 Run Tier Job Tier Application Tier Data Tier Spring Batch 2.0 적용 사례 ADDR 처리 업무 ADDR 처리 Process ADDR 처리 사례 1 (접속 정보) ADDR 처리 사례 2 (Spring-Batch) Sample Source Test Sample 향후 계획

1. 배치

1. 배치 (Batch) 배치(Batch) 프로그램이란? 배치(Batch) 프로그램의 특징 일괄적인 반복 처리작업
대게 I/O에 대한 처리부터 내부적 비즈니스 로직 구현, Logging같은 부가기능까지 모두 개발자가 직접 개발이 필요. 배치(Batch) 프로그램의 특징 사용자와의 상호 작용이 없다. 정해진 시간 제약 내에 실행이 완료 되어야 한다. 많은 자원이 소모되는 대용량 작업이다. 테스트가 어렵고, 테스트에 많은 시간이 소요된다. 온라인 애플리케이션과 배치 애플리케이션이 구별되는 가장 큰 특징은, 사용자에 의해 실행이 결정되지 않는다는 것이다. 배 치 애플리케이션은 사용자와의 상호 작용이 없기 때문에 화면 개발로 인한 오버헤드가 없고, 사용자의 리뷰 과정에서 발생하는 요구사항 변경이 상대적으로 덜하다.

1. 배치 (Batch) 배치(Batch)시스템에 대한 대표적인 오해 (Pitfalls) 배치는 비교적 단순하고 덜 중요하다.
- 배치는 자동화된 대량 처리를 필요로 하는 온라인/정보계/대외계 모두와 밀접한 연관 관계를 갖고 있어 전사시스템이 유기적으로 업무를 처리하는 데 있어 촉매제와 같은 역할을 수행한다. (직접 사용자를 만족시키는 건 적으나, 부지런히 정보가 제때 처리되어야 한다.) 배치는 성능이 제일 중요하므로 C 같은 언어로 개발해야 한다 - 배치의 성능 최적화는 프로그래밍 언어나 프로그래밍 기법이 아닌 아키텍처 수준의 최적화를 통해 해결되어야 한다. - 최적화 기법의 적용순서 * 배치업무 최적화 : 유사 업무 통합, 불필요한 반복 작업 제거 * 관리 고도화 : 수작업 데이터 검증 최소화, 잘못된 결과로 재작업 최소화 * I/O 비용 최소화 : 배치 수행 시간의 80% 이상은 I/O 비용이며, I/O를 최소화 해야 최 적화 된 성능 향상. * 프로그램 최적화 : 일정 사이즈로 처리 데이터를 균일하게 Fetch해서 적정 횟수만큼 묶 어 Commit. 프로그램 튜닝 팁 적용

1. 배치 (Batch) 배치(Batch)시스템 구조 배치 관리 서비스 배치 스케줄링 서비스 대용량 배치 실행 서비스
일반적으로 In-House로 통합 관리 시스템을 구축 (배치 운영역량의 핵심) 배치 스케줄링 서비스 Control-M, TWS(Tivoli Workload Scheduler) 등 솔루션을 도입하거나 Cron, Quartz 같은 오픈 솔루션 이용 가능 대용량 배치 실행 서비스 쉘 프로그래밍을 통해 유닉스 기능을 활용 (처리 품질은 개발자 몫) 미들웨어를 이용해 실행 컨테이너 구축 서비스 프레임 워크 (온라인을 배치에서 사용) 또는 센터컷 (배치에서 온라인을 사용) 배치 애플리케이션 지원 서비스 대용량 SAM 파일 처리도구 (ex: Syncsort), DB 유틸리티 (ex: SQL 로더) 배치 처리 결과 검증도구 (ex:TeraStream) 등이 사용된다. CONTROL-M : BMC Software 에서는 이러한 비즈니스 요구를 충족하기 위하여 플랫폼 및 Application에 대해배치 프로세스를 연동하여 통합 솔루션을 제공 합니다. TWS (Tivoli Workload Scheduler) : IBM에서 만듦. 소프트웨어 자동화 도구, 자동 워크로드 관리 및 모니터링을 제공.

1. 배치 (Batch) 배치(Batch)시스템 성공 구축 전략

1. 배치 (Batch) 배치 처리를 돕는 다섯 가지 핵심 기법 배치처리 유형을 표준화 하고 패턴화한 구현방법 제공
반복처리 패턴 : 건 단위로 반복적으로 입/출력이 이루어지고 입/출력 유형에 따라 구분. 다수의 패턴 존재 로직 처리 패턴 : 비즈니스 로직 상에서 다른 시스템의 자원을 사용하는 패턴. 유틸리티 패턴 : FTP, Print,Tool을 이용한 데이터 변환, 쉘 스크립트 등을 이용하기 위한 패턴. 커스텀 패턴 : 위 세 가지 패턴에 포함되지 않는 패턴. 기본 빌딩 블럭을 통해 각각의 처리 유형을 동일한 개념으로 구현 - 처리 패턴은 실제로 몇 백 개나 되기에 각각의 패턴을 아래 그림과 같은 방식의 동일한 개념으로 구현 될 수 있도록 표준화 하여 개발이 가능하도록 한다. 반복 처리 패턴과 로직 처리 패턴은 유기적으로 연결되어 있는데 만일 입력 자원이 고정 길이 파일이고 출력 자원이 DB이면서 비즈니스 로직에서 Dao를이용한다면‘Fixedlength File To DB Using DaoConnector’와 같이 표현할 수 있다.

1. 배치 (Batch) SoC 방식을 최대한 적용해 개발자의 부담을 줄임 테스트를 최적화
반복적으로 처리되는 보안,로깅,예외 처리, 트랜잭션 처리 등과 같은 작업은 프레임 워크에서 담당하고 개발자는 비즈니스에 관련된 관심사만을 담당 할수 있도록 구현. 테스트를 최적화 - 배치 테스트를 수행하기 위해 기본적 모든 경우의 수를 고려한 데이터 필요하 지만 현실적으로 불가능. - 자동화 단위 테스트를 통해 쉽고 빠르게 배치의 기능을 검증하고 변경이 있을 경우 단위테스트를 통해 애플리케이션 검증. 운영 시스템의 고도화 - 기본적으로 모니터링, 배치 작업의 실행제어 , 스케줄링 , 통계 , 배치작업의 등록 , 경보 의 기능을 갖추고 있어야 한다. SOC 원칙 : Seperation of Concerns (관심사항의 분리)라고 부르며 각 모듈마다 특정 문제에만 집중해서, 해결할 수 있게 나누어서 생각하자는 것입니다.

1. 배치 (Batch) 배치 처리의 적용에 대한 주의사항
실 가동 상황 (몇 백 만건의 데이터를 가지고 성능 프로파일링을 수행하며 진행하는 테스트를 의미) 에서 철저한 테스트를 수행 실제 실무자들이 프로젝트 팀에 참여해서 각 팀별로 대표 사례를 수집 그 사례를 실제로 구현한 예제를 만들면서 프로젝트가 진행되어야 함. 프로젝트 종료 후 자연스럽게 그 사람들 이 팀의 구현 리더로서 교육 담당자가 되는 구조가 필요

2. 스프링 배치

2.1 스프링 배치 (Spring-Batch) 스프링 배치 탄생 배경
기존의 배치 어플리케이션은 웹 어플리케이션, ORM 같은 다른 어플리케이션이나 프레임워크에 비해 발전속도가 늦고 빠르게 변화하는 환경에 적응이 어려움. 매일 수만/수억 건의 데이터를 처리하므로 어플리케이션의 요구 수준이 높고 문제가 발생시 빠른 대처를 요구. 보다 유연한 시스템의 개발과 유지보수를 위해 프레임 워크의 필요성이 생김. Spring Source와 Accenture사는 공동으로 배치 작업에 필요한 기반 작업의 관리가 가능하고 스프링 기반의 POJO 프로그래밍을 통해 재사용이 가능하고 유연한 Spring Batch를 개발

2.1 스프링 배치 (Spring-Batch) 기존 배치 어플리케이션 VS 스프링 배치 기존 배치 어플리케이션
로깅,트랜잭션관리, 리소스관리 (I/O, Database Connection)와 같은 비기능적 요소도 개발자 작성이 필요. 성능은 천차만별이 되며 시간이 지날수록 개발자 조차 유지보수가 어려움. 처리되어야 하는 전체 작업을 하나의 단위로 처리하는 경우가 많기 때문에 에러가 발생시 디버깅에 어려움 발생. 실행중 예외 발생으로 작업 실패시 재시작을 위해 진행한 정도파악이 어렵고 이후 작업수행을 위해 부가적 작업의 수행이 필요. 모든 것을 하나의 클레스 또는 어플리케이션 안에 구현. 기본적으로 프레임 워크에서 로깅, 트랜잭션 관리 및 리소스 관리(I/O, Database, Connection)와 같은 기반요소 지원 덕분에 안정화가 가능하며 리소스를 포함하는 공통요소들에 대한 관리 일원화로 유지보수에 용이 설정으로 작업의 단계를 나누기 때문에 예외 발생시 디버깅이 쉽고 실패한 작업의 재시작을 하면 이전 실행 내용 중 실패부분을 skip 하고 진행가능

2.1 스프링 배치 (Spring-Batch) 스프링 배치의 기능
각종 읽기와 쓰기 기능의 구성요소를 같은 인터페이스들로 추상화시키고 기본 구현 클래스를 거기에 맞춰 제공 배치에 적합한 트랜잭션 처리를 위해 주기적 commit방식 지원 배치작업의 재시도,재시작,건너뛰기 등의 정책을 설정으로 적용가능 유연한 Exception 처리 가능 각종 이벤트 처리 가능 Commit 개수, Roillback 개수,재시도 횟수 등 배치실행 통계 정보를 제공 추가 코딩 없이 설정만으로 기존 모듈 활용이 가능 대용량 조회 처리를 위해 커서기반이나 Driving Query기반의 조회방식 지원 iBatis나 Hibernate를 사용해서 DB접근 모듈을 개발가능

2.2 Spring Batch 아키텍처 애플리케이션 배치 코어 인프라 스트럭처
모든 배치 잡과 스프링 배치를 사용하는 개발자가 작성한 커스텀 코드를 모두 포함. 배치 코어 배치 잡을 실행하고, 제어하는데 필요한 코어 런타임 클래스인 JobLauncher, Job, Step등을 포함 인프라 스트럭처 공통적으로 사용되는 reader, writer와RetryTemplate처럼 애플리케이션 개발자나 코어 프레임웍 자체에서 사용되는 RetryTemplate과 같은 service 등을 포함

2.2 Spring Batch 아키텍처 Run tier Application의 scheduling, 실행을 담당한다. 스프링배치에서는 따로 Scheduling의 기능은 제공하지 않고 Quartz같은 외부 모듈이나 Cron을 이 용하도록 권고 . Job Tier 전체적인 Job의 수행을 책임진다. Job내의 각 Step들을 지정한 상태와 정 책에 따라 순차적으로 수행. Application tier Job을 수행하는데 필요한 component로 구성. Data tier Database, File 등 물리적 데이터소스와 결합이 이루어지는 영역.

2.2.1 Run Tier Scheduler Request Job Script Job Configuration
주기적 실행이 가능. 자동 실행의 개념 Spring Batch 는 Scheduler를 제공하지 않음. 종류 Cron, Quarts, Spring-Scheduler 등 Request 수동 실행의 의미. 요청이 있을 시 실행. ex :Shell, Http 요청 등 Job Script Scheduler로 수행될 명령어들의 모음. Job Configuration 수행이 되는 Job의 설정을 하는 곳. 실제 Job의 모든 수행부분을 담당. JobLocator 수행이 되야 할 Job을 찾아 선택. (2.x : JobExplore) JobRunner Run Tier에서 얻은 모든정보를 JobLuncher에게 전달.

2.2.2 Job Tier JobLauncher JobRepository Job
주어진 Parameters로 Job을 실행시키는 단순한 인터페이스 JobRepository 모든 스테레오 타입에서 사용하는 영속화 메커니즘. StepExecution 과 JobExecution이 실행되는 동안 이곳에 저장되어져 영속화됨. Job 전체 배치 처리 과정을 캡슐화 하는 엔티티 Job 인터페이스를 구현하는 스프링 빈으로 표현 Job 설정 정보 간단한 Job의 이름 Step들의 정의와 순서 Job의 재시작 여부

2.2.2 Job Tier (Job) Job Job 이란 배치 어플리케이션 에서 처리해야 하는 업무 흐름 예) 매일 저녁마다
처리해야 하는 일 마감 업무. 여러 개의 Step으로 구성 논리적으로 JobParameter와 함께 JobInstance 형태로 변하게 됨. 이후 JobLauncher를 통해 Job을 실행시 JobExecution이 되어 메모리상에 동작된다.

2.2.2 Job Tier (Job) Job 구성 JobInstance JobParameters. JobExecution
논리적 Job 실행의 개념으로 이해. 이전 실행에 사용된 데이터중 State가 사용되는지에 따라 재사용과 새로 생성이 결정 JobParameters. JobInstance를 구분하기 위해 필요. Job이 실행되는 동안에 Job을 식별하거나 Job에서 참조하는 데이터로 사용 JobExecution 단 한번 시도되는 Job 실행을 의미하는 기술적 개념. 실행 자체는 성공이나 실패로 끝나지만 실행에 대응되는 JobInstance는 실행이 성공적 종료일시 완료. 프로퍼티 Status : 실행상태를 의미.실행중(BatchStatus.STARTED),실패(BatchStatus.FAILED), 성공(BatchStatus.COMPLETED) StartTime : 실행이 시작되는 당시 시스템 시간을 Java.util.Date 로 저장 endTime : 실행의 성공 여부에 관계 없이 실행이 끝나는 당시 시스템 시간을 Java.uitl.Date로 저장. exitStatus : 실행의 결과를 ExitStatus로 알림. 호출자에게 반환될 종료 코드를 포함하기 때문에 중요. createTime : JobExecution이 처음으로 영속화 됐을때 현재 시스템 시간을 Java.util.Date로 표현

2.2.2 Job Tier (Job) JobRepository 배치 처리 중의 정보를 저장하기 위해 사용
배치 실행 전반에 필수적 역할 JobExecution 클래스, StepExecution 클래스 ExecutionContext와 같은 구성요소들을 가지고 있는 정보들을 저장하고 갱신 테이블 정보 테이블명 정보 Batch_Job_ Execution 한 번의 Job의 실행 시도의 메타데이터를 나타냄 Execution_Context Job_Execution에 대한 영속화 상태를 저장하기 위해 Key-value쌍으로 값을 보관. Instance Job의 논리적 실행에 대한 값을 저장. Params Job을 실행하는 Parameter값 보관 Batch_Step_ Job을 구성하는 단계인 Step의 실행시도의 메타데이터를 나타냄 Step_Execution에 대한 영속화 상태를 저장하기 위해Key-value쌍으로 값을 보관 BATCH_JOB_EXECUTION BATCH_JOB_INSTANCE JOB_EXECUTION_ID VERSION JOB_INSTANCE_ID CREATE_TIME START_TIME END_TIME STATUS EXIT_CODE EXIT_MESSAGE LAST_UPDATE JOB_INSTANCE_ID VERSION JOB_NAME JOB_KEY BATCH_STEP_EXECUTION STEP_EXECUTION_ID VERSION STEP_NAME START_TIME END_TIME STATUS COMMIT_COUNT READ_COUNT JOB_EXECUTION_ID FILTER_COUNT WRITE_COUNT READ_SKIP_COUNT WRITE_SKIP_COUNT PROCESS_SKIP_COUNT ROLLBACK_COUNT EXIT_CODE EXIT_MESSAGE LAST_UPDATE BATCH_JOB_PARAMS JOB_INSTANCE_ID TYPE_CD KEY_NAME STRING_VAL DATE_VAR LONG_VAR DOUBLE_VAL BATCH_STEP_EXECUTION_CONTEXT STEP_EXECUTION_ID SHORT_CONTEXT SERIALIZED_CONTEXT BATCH_JOB_EXECUTION_CONTEXT JOB_EXECUTION_ID SHORT_CONTEXT SERIALIZED_CONTEXT

2.2.3 Application Tier Step ItemReader ItemWriter Data Access
Job의 독립적이고, 연속적인 단계를 캡슐화 하는 도메인 객체. 실제 배치 처리 과정을 정의, 제어하는 필요한 모든 정보 포함. 개발자 판단에 따른 Step의 구조변화의 다양성. ItemReader 한번에 하나의 아이템 별로 Step에서 입력을 받아오는 표현을 추상화. ItemWriter 한번에 하나의 아이템 별로 한 Step의 출력하는 표션을 추상화 Data Access 실제 Business Logic을 처리할때 실제 사용하는 영속화 메커니즘. Business Logic ItemReader와 ItemWriter간 처리해야 하는 Logic을 구현

2.2.3 Application Tier (Step)
Job안에 n개의 형태로 존재 실제적으로 수행하는 작업 단위. 예) 매일 저녁마다 처리해야 하는 일 마감 업무중에 일일 정산, 재고조사 등의 개체 단위 각각의 Step은 Item Reader/writer/processor를 가질 수 있다. Job이 메모리상에서 동작하면 StepExecution이 되어 실행됨.

2.2.3 Application Tier (Step)
StepExecution Step을 실행하는 한 번의 시도. 하나의 JobInstance가 다수의 StepExecution을 가질수 있다. JobExecution 과 같은 개념. 프로퍼티 List Status : 실행상태를 의미. 실행중(BatchStatus.STARTED), 실패(BatchStatus.FAILED), 성공(BatchStatus.COMPLETED) StartTime : 실행이 시작되는 당시 시스템 시간을 Java.util.Date 로 저장 endTime : 실행의 성공 여부에 관계 없이 실행이 끝나는 당시 시스템 시간을 Java.uitl.Date로 저장. exitStatus : 실행의 결과를 ExitStatus로 알림. 호출자에게 반환될 종료 코드를 포함하기 때문에 중요. executionContext : 실행 사이에 영속화 되야 할 필요가 있는 모든 사용자 데이터를 포함한 ‘프로퍼티 bag’ commitCount : 이번 실행에서 커밋된 트랜잭션의 개수 ItemCount : 이번 실행에서 처리된 아이템의 개수 RollbackCount : 롤백된 Step에 의해서 제어된 비즈니스 트랜잭션의 개수 ReadSkipCount : 읽기가 실패해서 결과적으로 지나친 아이템의 개수 WriteSkipCount : 쓰기가 실패해서 결과적으로 지나친 아이템의 개수. ExecutionContext StepExecution이나 Jobexecution 범위에서 영속화 상태를 저장하기 위해 프레임웍에 의해서 영속화 되고, 제어되는 키/값 쌍의 콜렉션으로 표현

2.2.3 Application Tier (ItemReader)
읽기 대상이 되는 타입에 관계없이 일관된 읽기 행위에 대한 인터페이스 대표적인 지원 타입 플랫 파일, XML, DB 등 Spring Batch에서 제공되는 Item Reader Reader 이름 설명 FlatfileItemReader 구분자 (csv와 같은)를 갖는 파일 또는 고정 길이 파일로부터 Item을 읽어 들인다. MultiResourceItemReade 여러 개의 파일로부터 Item을 읽어 들인다. JdbcCursorItemReader Jdbc를 이용해 cursor 방식으로 DB로부터 Item을 읽어 들인다. JdbcPagingItemReader Jdbc를 이용해 paging 방식으로 DB로부터 Item을 읽어 들인다. HIbernateCursorItemReader Hibernate를 이용해 cursor 방식으로 DB로부터 Item을 읽어 들인다. IbatisPagingItemReader Ibatis를 이용해 paging 방식으로 DB로부터 Item을 읽어 들인다 JpaPagingItemReader Jpa를 이용해 paging 방식으로 DB로부터 Item을 읽어 들인다. StaxEventItemReader XML 파일로부터 Item을 읽어 들인다.

FlatFleItemReader 플렛 파일을 읽고, 파싱하는 기본적인 기능 제공 필수 의존성 Resource, FieldSetMapper, LineTokenizer 처리 순서 FlatFile 1 line to String String to FieldSet FieldSet to Mapped Object By LineReader By LineTokenizer By FieldSetMapper

속성 FieldSet 플랫 파일을 데이터베이스 사용하듯이 컬럼과 행의 개념을 도입해서 객체(FieldSet) 생성 입력 파일에 대한 일관적인 파싱 제공 JDBC의 ResultSet과 비슷한 개념 속성명 설명 Resource 읽어들일 데이터의 위치를 지정 (파일이나 url) Encoding 읽을 인코딩 방식. 디폴트는 ‘ISO ’ Comments 각 열의 이름 fieldSetMapper 행을 읽어서 저장한 객체인 FieldSet을 다시 객체로 매핑시켜 주는 fieldSetMapper를 지정한다. RecordSeparator Policy 각 행을 어떻게 구분할 것인지를 정의하는 RecordSeparatorPolicy를 구현한 클래스를 지정한다. saveStatus ExcutionContext를 이용해 상태를 저장할지 지정. firstLineIsHeader 첫줄이 컬럼의 이름을 나타내는 헤더인지의 여부 lineToSkip 파일의 첫 부분에서 읽지 않고 넘길 라인의 수. lineTokenizer 각행을 읽어서 fieldSet 객체로 만들어주는 lineTokenizer를 지정해 준다.

LineTokenizer String -> FieldSet 으로 변환 종류 DelimitedLineTokenizer : 구분자에 의해서 각 레코드 구분 FixedLengthTokenizer : 정해진 길이로 각 레코드 구분 PrefixMatchingCompositeLineTokenizer : 앞 첨자로 레코드구분 (1.x)

2.2.3 Application Tier (ItemWriter)
대상 타입에 관계없이 일관된 쓰기 작업 행위에 대한 인터페이스 대표적인 지원 타입 XML,플랫 파일, DB 등 Writer 이름 설명 FlatFileItemWriter 구분자(csv와 같은)를 갖는 파일 또는 고정 길이파일로 Item을 Write한다. MultiResourceItemWriter 여러 개의 파일로 Item을 Write한다. JdbcBatchItemWriter Jdbc를 이용해 배치 Update의 형태로 DB로 Item을 Write한다. HibernateItemWriter Hibernate를 이용해 DB로 Item을 Write한다. IbatisBatchWriter Ibatis를 이용해 DB로 Item을 Write한다. StaxEventItemWriter XML 파일로 Item을 Write한다.

FlatFileWriter 데이터를 플랫 파일에 쓰는 기능 제공 의존성 Resource, LineAggregator, FieldSetCreator 처리 순서 Mapped Object to Field set FieldSet to String String to FlatFileItem`s one line By FieldSetCreator LineAggregator By FlatFileItemWriter

FieldSetCreator Mapped Object 를 FieldSet을 변환. (2.X 에는 삭제) LineAggregator FieldSet을 String으로 변환해줄때 사용. 종류

2.2.3 Application Tier (Data Access)
정의 Spring의 데이터 접근 지원(Data Access)을 위한 단계 종류 Jdbc 가장 기본적인 데이터 접근 지원 프레임워크 DriverManager 클래스, Connection, 다양한 구문 , ResultSet 클래스로 구성 특징 : 일괄처리 능력 Ibatis ORM도구로 자바 빈 프로퍼티 값을 생성하는 데 필요한 SQL코드 직접 작성. 각 데이터베이스에서 표준 SQL을 확장한 기능을 완벽히 사용가능. Hibernate 객체-관계 매핑 도구로 자바 코드에 최소한의 영향을 가하여 DB에 있는 일반 자바 객체를 찾고 저장하고 삭제가 가능

3 . Spring Batch 2.0

3. Spring Batch 2.0 Spring Batch 1.0 -> 2.0 Java 5 지원
Annotation, generic 지원. Spring Batch 가 지원하는 Annotation Chunk oriented processing 1.X 에서는 한 개의 Data를 의미하는 Item을 기반으로 작업을 처리했지만 Chunk기반의 처리는 지정한 크기만큼 Item을 읽고 처리한 후 이 결과를 List의 형태로 가지고 있다가 한번에 쓴다. @BeforeJob @AfterJob @BeforeStep @AfterStep @BeforeRead @AfterRead @OnReadError @OnProcessError @BeforeProcess @AfterProcess @OnWriteError @OnSkipInRead @BeforeWrite @AfterWrite @OnSkipInProcess @OnSkipInWrite

3. Spring Batch 2.0 Xml Namespace JobRepository browsing
1.x에서는 XML 설정 시 모든 설정은 Bean으로 설정되었지만 2.0에서 XML Namespace가 추가되어 XML 설정 상에서 Job과 Step과의 관계를 명시적으로 확인할 수 있으며 사용하고 있는 Item Reader/writer의 파악이 쉬워짐. [ Spring 1.X ] [ Spring 2.X) JobRepository browsing 1.x에서는 배치 작업을 실행하는 상태에서 JobRepository를 직접 접근 불가 JobExeplorer와 JobOperator 가 추가되었고 이를 통해 JobRepository에 접근할 수 있게 되 배치작업 수행도중 Meta Data를 조회하거나 실행 중인 Job을 멈추게 할수 있다.

3. Spring Batch 2.0 Conditional Step Execution
1.x의 경우 모든 Step의 실행이 순차적으로 이루어져 예외 상황 발생시 해당 Item은 건너뛰고 다음 Item을 처리하거나 해당 Job의 실패 처리를 Listener나 ItemProcessor를 통해 제어함. 2.0은 추가된 조건 처리를 이용하면 현재 진행 중인 작업의 처리 결과 상태에 따라 수행할 다음 Step을 지정하거나 우회된 Step으로 진행하거나 중지가 가능. 조건처리 Step 제어 방식의 변화

4 . 적용 사례

4-1. ADDR 처리 업무 처리 ADDR DB 구분자 “|” 로 ADDR Data 구분 예외 처리하기
ADDR 파일을 읽어 필요한 필드만 DBMS에 저장하는 배치 프로그램 처리 Read Write ADDR DB (tb_imp_addr) 구분자 “|” 로 ADDR Data 구분 예외 처리하기 RollBack , Commit 처리과정 및 상황 기록. Log 처리

4-2. ADDR 처리 Process ADDR Data 구조 ADDR Table 처리 Process
1. ADDRSEQ 2 BJSCODE 3 4 5 6. ADDR1 7. ADDR2 8. ADDR3 9. ADDR4 10. ADDR5 11. DONG CODE 12 13 14. ZIPCODE 15 16 | |14 | | N | 대구광역시| 서구 | 평리4동 | | | | | | | A | | |14 | | N | 대구광역시| 서구 | 평리5동 | | | | | | | A | ADDR Table 처리 Process Flat File 데이터 Addr.txt을 행단위로 Read Read된 행을 구분자 “| “ 로 분할 Write될 DB Table에 Read된 행의 기본키 유무 확인 분할된 값들의 길이, 데이터 형식 체크 DB의 tb_imp_addr Table에 Insert / Update. (DB작업중 예외 처리 및 Commit / Rollback 설정) DB작업이 끝난 후 처리 과정 Log에 기록. n2_addr.fmt table tb_imp_addr { ADDRSEQ integer; BJSCODE char (11); ADDR1 varchar (15); ADDR2 varchar (15); ADDR3 varchar (15); ADDR4 varchar (30); ADDR5 varchar (15); DONGCODE char (6); ZIPCODE char (8); }

4-3. ADDR 처리 사례 1 ( 접속정보 ) 환경 장점 단점 Java , iBatis 특별한 추가 지식 없이 설계 가능.
설정이 많지 않아 개발시간 단축. (소규모 프로젝트) 단점 정보(DATA 처리상황, 예외/DB 처리 등) 필요 시 일일이 소스 추가 필요 프로젝트 규모가 커질수록 소스의 가독성 저하 팀 프로젝트 시 결합도 저하

4-4 ADDR 처리 사례 2 ( Spring-Batch )
환경 Java , iBatis , Spring , Spring-Batch 장점 다양한 Data 처리시 Configration (commit , rollback, skip, restart, exception , Data 변환 등) 만으로 처리 가능. Data 처리과정 자동 DB처리. 프로젝트 변경 및 추가 시 쉬운 가독성으로 개발 편의 제공 장점 동시 배치 처리 가능. 규모가 큰 병행 배치 처리 실패 후에 수동 또는 스케줄을 적용한 재시작 전체적으로 적용되는 배치 트랜잭션 단점 1. 정교한 설계 필요. 단점 관련 정보 학습 필요. 복잡한 설정. 소규모 프로젝트 개발 시에도 많은 설정 필요.

5 . Sample Source

5. Sample Source

5. Sample Source(loop flow)
목표 Step들의 흐름을 보여주기 위해 구성되었다. JobExecutionDecider를 통해 설정된 step들의 repeat가 가능한 Job이 어떻게 구현되는지 보여준다. Step의 제어를 하기위해 필수로 이해해야 할 Sample 이다. 사용된 속성 Job – decision step- next tasklet- allow-startif-commplete , listeners ,

5. Sample Source(loop flow)
Job(loop flow) 흐름도. Listener DB 1 6 3 4 DB Listener Allow-start-if-complete = true Next = Decision 2 3 Step 2 Read/ Write 3 4 6 1 5 4 Limit = 3 NEXT = STEP1 END = COMPLETED 5 Read/ Write Step 1 Decision NEXT 2 2 END Allow-start-if-complete = true Next = Step2 Step 실행 순서. Step1 -> Step2 ->Decision -> Step1 –> Step2 -> Decision Decision의 Limit의 설 정값 만큼 반복. Client Job 1

5. Sample Source(Restart)
목표 작업 실패 후 실패 지점을 찾아 작업을 어떻게 재시작 하는지 알아본다. 설명 ExceptionThrowingItemReaderProxy의 클레스를 통해 Exception의 타이밍을 설정해 실패를 가장할 것이다. Job이 시작된후 설정된 위치에서 Exception이 생겨나 Job이 Failed로 종료될 것이다. 이후 우리는 같은 Instance를 사용해 Job을 Restart 할것이고 종료된 위치에서 시작되어 Job의 나머지를 수행할 것이다.

5. Sample Source(Restart)
Job(Restart) 흐름도. 7 Step 1 Step 2 Step 3 3 11Line Exception 11Line Start 4.End (State: FAILED) 6 8.End (State: Complete) 2 NEXT Job Client 1.start 5.Restart

5. Sample Source(Retry) 목표 사용 방법 예외 발생시 어떻게 자동으로 재시도 하는지 확인.
Retry-limit의 세팅을 통해 재시도 횟수를 설정 할 수 있다. ItemWriter에 관해서 가능하다. retryable-exception-classes 부분을 통해 재시도 되어야 할 exception을 설정해줄수 있다. (예제소스상 exception-classes의 java.lang.Exception은 모든 exception을 말하므로 모든 Exception에 대한 retry 처리가 된다.) <step id="step1"> <tasklet> <chunk reader="itemGenerator" writer="itemWriter" commit-interval="1" retry-limit="3"> <retryable-exception-classes> java.lang.Exception </retryable-exception-classes> </chunk> </tasklet> </step>

5. Sample Source(retry) Job(restart) 흐름도. DB Read Step 1 Processor
Configration Retry =3 3 4 Step 1 Processor 5 2 Write 6. If (Exception) { retry until 3 count } Job 7. Complete or Exception Client 1. Job 실행 요청 DB

5. Sample Source(parallel) 병행처리
목표 parallel Sample은 Step의 멀티 스레드를 하기위해 사용됨. TaskExecutor 의 설정에 의해 사용됨. 제약 사항이 많기 때문에 많이 사용되지 않는다. TaskExecutor 실행자(Executor)는 쓰레드 풀링의 개념을 위한 Java 5의 이름이다. 많은 경우 실행자는 쓰레드 하나로 이루어 진다. 사용하는곳 ApplicationEventMulticaster와 같은 컴포넌트인 JMS의 AbstractMessageListenerContainer와 Quartz통합은 모두 풀 쓰레드를 위해 TaskExecutor 추상화를 사용 Bean이 쓰레드 풀링이 필요하다면 자체적인 필요를 위해 추상화 사용 가능.

5. Sample Source(parallel) 병행처리
사용하는곳 ApplicationEventMulticaster와 같은 컴포넌트인 JMS의 AbstractMessageListenerContainer와 Quartz통합은 모두 풀 쓰레드를 위해 TaskExecutor 추상화를 사용 Bean이 쓰레드 풀링이 필요하다면 자체적인 필요를 위해 추상화 사용 가능. TaskExecutor Types SimpleAsyncTask Executor 어떤 쓰레드도 재사용하지 않는다. 각각의 호출에 새로운 쓰레드를 시작한다. 슬롯이 자유로워 질때까지 제한을 넘어선 호출은 블럭할 동시 제한을 지원 SyncTask 호출을 비동기적으로 수행하지 않는다. 대신, 각각의 호출은 호출 쓰레드로 대체된다. 간단한 테스트케이스와 같이 필요하지 않은 멀티쓰레드 상황에서 사용 ConcurrentTask Java 5 java.util.concurrent.Executor를 위한 래퍼(wrapper)이다. 대안으로 bean프라퍼티로 Executor 설정 파라미터를 나타내는 ThreadPoolTaskExecutor가 있다. ConcurrentTaskExecutor를 사용할 필요는 드물지만 ThreadPoolTaskExecutor가 필요한 것만큼 견고하지 않다면, ConcurrentTaskExecutor이 대안이 됨 SimpleThreadPoolTask 이 구현물은 실제로 Spring의 생명주기 콜백을 듣는 Quartz의 SimpleThreadPool의 하위클래스이다. 이것은 Quartz와 Quartz가 아닌 컴포넌트간에 공유될필요가 있는 쓰레드 풀을 가질때 사용 ThreadPoolTask Java 5 환경에서 사용 될 수 있지만 그 환경에서 가장 공통적으로 사용되는 것이다. java.util.concurrent.ThreadPoolExecutor를 설정하고 TaskExecutor에 그것을 포장하기 위한 bean프라퍼티를 나타낸다. ScheduledThreadPoolExecutor처럼 향상된 어떤것이 필요하다면, 대신 ConcurrentTaskExecutor를 사용하도록 추천 TimerTask 지원 구현물로 하나의 TimerTask를 사용한다. 이것은 비록 쓰레드에서 동기적이더라도 메소드 호출이 개별 쓰레드에서 수행되어 SyncTaskExecutor와 다르다 WorkManagerTask 지원 구현물로 CommonJ WorkManager을 사용하고 Spring 컨텍스트에서 CommonJ WorkManager참조를 셋팅하기 위한 중심적이고 편리한 클래스이다.

5. Sample Source(Trade) 목표 단계 프레임 워크의 실제 사용과 유사한 합리적인 시나리오를 보여준다.
DB로부터 Trade를 읽어오고 고객 계정의 크레딧(money)을 읽어온 값만큼 감소 시킨다. Customer가 감소된 크레딧에 대해 대해 파일로 기록한다.

5. Sample Source(Trade) Job(Trade) 흐름도. TABLE ( TRADE )
7. Step2(DB Writer) colum CREDIT decrease 4. Step1(DB Writer) TABLE ( CUSTOMER ) ValidationProcessor 5. Step1(종료) 6. Step2(DB Read) 8. Step2(결과 전송) Step 2 Step 3 3. Step1(유효성 검사) 9. Step3(DB Read) Data 10. Step3(Data Writer) 2. Step1(Data Read) Step 1 TABLE ( CUSTOMER ) 2. Step1(Data Read) Job Client 1. Job 실행 요청 11. Step3(결과 전송)

5. Sample Source(Trade) Project 구성 데이터의 입력 및 출력에 관한 소스 폴더
Trade Sample의 ROOT Source 폴더 Trade Sample의 Root의 하위폴더 DATA를 입력받을 File을 저장하는 폴더 Trade의 Job과 Step이 입력되는 File Trade Job을 Test 하기 위해 만든 File Configration을 하기위해 만든 File Job 실행전 스키마를 실행시키는 File Data를 주고받기 위해 필요한 모든 설정이 있는 File Job과 Step에 대한 세팅을 해주는 File Project에 필요한 라이브러리 폴더

5. Sample Source(Trade) Job 구조 (TradeJob)

5. Sample Source(Trade) Step 1

5. Sample Source(Trade) Data Source 구조 (전체)

5. Sample Source(Trade) Data Source 구조 Job의 시작전 필요 스크립트를 실행
${batch.schema.script}, ${batch.business.schema.script} 는 설정된 Properties 파일에서 load - transactionManager 트랜잭션의 설정을 해주는 bean incrementerParent 자동으로 값을 지정해 준다. DB의 시퀀스와 비슷 한 일을 하는 bean

5. Sample Source(Trade) Data Source 구조 - Environment
Helper class로 이것은 시스템 프로퍼티의 디폴트 값을 set up 한다. 시스템 프로퍼티는 지정된 키네임과 기본 값으로 만들어진다. 만약 프로퍼티가 이미 존재한다면 변경되지 않는다. - placeholderProperties location 에서 설정된 프로퍼티 파일을 읽어온다. - overrideProperties 기존의 설정된 프로퍼티 값에 location으로 설정된 파일이 override된다. 설정에 따라 기존의 값을 쓸지 오버라이드 된 값을 사용할지 설정할수 있다.

6 . Test Sample

6. Test Sample(Basic) 요약 목표
이 샘플은 아무 처리가 되지 않은 기본 데이터에 대한 Read 와 Write에 관하여 보여준다. 요약 각각의 데이터( addr, ne, expline, dong, wbras_bsid, ktipkookaddr )에 대한 Read와 데이터 처리후 Altibase Server에 Write가 된다. Exception, Skip, Retry, Log, Restart 등 아무런 설정이 없이 사용된다.

6. Test Sample(Basic) Neoss_test_1_basic Job 구조. Step Read Error
Write Error Option Addr X Ne O Expline 4. Wbras_bsid Dong Ktipkookaddr 실행순서 1 – 2 – (Exception)

6. Test Sample(Basic) Job(Basic) 흐름도. DB READ Job Client WRITE Log
Job Finish READ Job Exception ADDR Client NE EXPLINE WRITE Exception WBRAS_BSID DONG DB Error Data Data KTIPKOOKADDR

6. Test Sample(Skip) 요약 목표
이 샘플은 데이터의 Read 과정에 일어나는 Exception 에 대한 처리를 하는 Skip 에 관하여 보여준다. 요약 각각의 Step을 설정할때 Skip-limit를 설정 후 Skippable-exception-classes를 이용하여 Skip되어야 할 Exception을 설정하고 Fatal-exception-classes를 통해 Skip되지 않고 무조건 예외 처리되어야 할 Exception을 설정한다. Skip 설정은 Read중 예외상황에 대한 설정만 가능하며 Write중의 설정에는 영향을 미치지 못한다.

6. Test Sample(Skip) Neoss_test_2_ExceptionSkip Job 구조. Step
Read Error Write Error Option Addr X Skip count = 100 Ne O Expline 4. Wbras_bsid Dong Ktipkookaddr 실행순서 1 – 2 – 3 – 4 – 5 – 6

6. Test Sample(Skip) Job(Skip) 흐름도. DB READ Job Client Option WRITE
Log Job Finish READ Job [Over] Exception ADDR Client Count Exception NE [Not Yet] Skip Option EXPLINE Skip-limit=“1000” <Skippable- exception-classes> Java.lang.Exception </Skippable- WRITE Exception WBRAS_BSID DONG DB Error Data Data KTIPKOOKADDR

6. Test Sample(Retry) 요약 목표
이 샘플은 데이터의 Write 과정에 일어나는 Exception 에 대한 처리를 하는 Retry 에 관하여 보여준다. 요약 각각의 Step을 설정할때 retry-limit를 설정 후 retryable-exception-classes를 이용하여 재시도 되어야 할 Exception을 설정하고 Fatal-exception-classes를 통해 재시도되지 않고 무조건 예외 처리되어야 할 Exception을 설정한다. Retry 설정은 write중 예외상황에 대한 설정만 가능하며 Read중의 설정에는 영향을 미치지 못한다.

6. Test Sample(Retry) Neoss_test_4_loofJob 중 두번째 Job 구조. Step
Read Error Write Error Option Addr X on = ‘*’ to= ne Ne O on = ‘*’ to= expline Expline on = ‘*’ to= wbras_bsid 4. Wbras_bsid on = ‘*’ to=dong Dong on = ‘*’ to= ktipkookaddr, retry count= 10 , skip count = 100 Ktipkookaddr on = ‘*’ to= limitDecision 7. limitDecision count = 3 , to = addr 실행순서 1 – 2 – 3 – 4 – 5 – 6 – 7

6. Test Sample(Retry) Job(Retry) 흐름도. DB READ Job Client Option WRITE
Log Job Finish READ Job Exception ADDR [Over] Exception Client NE Exception Option Count Exception EXPLINE Retry-limit=“100” <retryable- exception-class> Java.lang.Exception </retryable- WRITE [Not Yet] Skip WBRAS_BSID DONG DB Error Data Data KTIPKOOKADDR

6. Test Sample(Restart) 기타 목표
이 샘플은 작업을 끝낸 Job을 Restart하여 JobInstance_ID를 통해 Job의 Key값을 받아와 Job의 이전 종료시점부터 재시작 한다. 기타 Joboperator에 의해 Job의 Restart를 진행한다. Job이 Error 없이 Complete로 작업이 끝났을 시 Restart를 하면 아래의 Exception Message를 보게 된다. “A job instance already exists and is complete for parameters={name=5}. If you want to run this job again, change the parameters.”

6. Test Sample(Restart) Neoss_test_3_Restart Job 구조. Step Read Error
Write Error Option Addr X Skip count = 100 Ne O Expline Restart Count = 3 실행순서 1 – 2 – Restart – 2 – Restart – 2 – Restart – 2 Step Read Error Write Error Option Dong O X Skip count = 100 Ktipkookaddr Restart Count = 3 실행순서 5 – 6 - Restart - Restart - Restart

6. Test Sample(Restart) Job(loofJob) 흐름도. DB READ Job Client WRITE
Log Job Finish READ Job Start Exception ADDR ReStart Client NE EXPLINE WRITE Exception Option WBRAS_BSID *Restart* Error position is “NE” DONG DB Error Data Data KTIPKOOKADDR

6. Test Sample(loofJob) 기타 목표
이 샘플은 Job과 Step의 흐름을 제어하는 모습을 보여주기 위해 설명되는 Sample 이다. 기타 Batch가 1.0에서 2.0으로 바뀌며 추가된 기능 으로 Step의 제어가 손쉽게 된다. limitDecider 빈을 통해 설정된 limit의 수만큼 Step의 반복 작업을 수행할수 있다.

6. Test Sample(loofJob) Neoss_test_4_loofJob 중 첫번째 Job 구조. Step
Read Error Write Error Option Addr X Skip count = 100 Ne O Skip count = 100,allow-start-if-complete=“true” Expline Skip count = 100,if(FAILED) to=ktipkookaddr 4. Wbras_bsid Dong Ktipkookaddr 7. limitDecision Count=3 , to=addr 실행순서 1 – 2 – 3 – 6 – 7 – 2 – 6 – – 6 – 7 – 2 – 6 - 7

6. Test Sample(loofJob) Job(loofJob) 흐름도. DB READ Job Client WRITE Log
Job Finish Start ADDR READ Job <next on="*" to=“NE"/> Exception NE Client <next on="*" to=“EXPLINE"/> EXPLINE [조건] Limit = 3, allow-start-if-complete = “ture” [실행순서] ADDR NE EXPLINE DONG LimitDecision Skip(NE) Skip(expline) Skip(dong) <next on="FAILED“ o="dong"/> <next on="*" to=“Wbras_bsid"/> WBRAS_BSID WRITE Exception <next on="*“ to=“dong"/> DONG <next on="FAILED“ o=“LimitDecision"/> <next on="*" to=“NE"/> KTIPKOOKADDR <next on="*" to=“LimitDecision"/> DB Error Data Data LimitDecision <next on="CONTINUE" to="addr" /> <end on="COMPLETED" />

7 . 향후 계획

7. 향후 계획 병행 배치처리 , 유효성 검사, 예외 처리 응용 남은 Sample Source 분석.
Batch version에 따른 호환 및 최적화. 단위테스트(Junit)을 통한 프로그램 무결성

Spring Batch 발표자 : 유 상 민.

Similar presentations

Presentation on theme: "Spring Batch 발표자 : 유 상 민."— Presentation transcript:

Similar presentations

About project

지원

로그인

Auth with social network:

Spring Batch 발표자 : 유 상 민.

Similar presentations

Presentation on theme: "Spring Batch 발표자 : 유 상 민."— Presentation transcript:

Similar presentations

About project

지원