욱'S 노트

스프링 배치로 작업을 계속 수행하다보면 각 히스토리 데이터가 계속 생성된다. 이럴 경우 주기적으로 삭제를 해줄 필요가 있는데 FK가 많아서 생각보다 쉽지 않다. 이에 삭제 스크립트를 정리해보았다. 아래는 8월 21일 전에 히스토리를 삭제하는 스크립트예이다. DELETE FROM BATCH_STEP_EXECUTION_CONTEXT WHERE STEP_EXECUTION_ID IN ( SELECT STEP_EXECUTION_ID FROM BATCH_STEP_EXECUTION WHERE START_TIME < '20150821'); DELETE FROM BATCH_STEP_EXECUTION WHERE START_TIME < '20150821'; DELETE FROM BATCH_JOB_EXECUTION_CONTE..

많은 배치 처리 문제는 single 스레드, single 프로세스 작업으로 해결할 수 있다. 그리고 복잡한 구현을 생각하기 전에 단순하게 처리할 수 있는지 체크하는 것은 좋은 생각이다. 실제작업이 성능을 측정하고 가장 단순한 방법으로 처리 할 수 있다는 그것이 베스트이다. 수백 메가바이트의 파일을 읽고 쓰는데도 1분이면 충분할 것이다. 우리는 이번에 작업을 병렬로 수행하는 방법에 대해 알아볼 것이다. 가장 크게 나누어 본다면 single process에서 멀티 스레드로 작업을 수행하는 것과 멀티 프로세스에서 처리하는 방법에 대해서 알아볼 것이다. Multi-threaded step 병렬처리를 시작하는 가장 단순한 방법은 Step 설정에 TaskExecutor를 추가하는 것이다. ... 이 예제에서 Tas..

스프링 배치 매뉴얼을 60% 본 시점 즈음에 다음과 같은 배치 프로그램을 작성해달라는 요청이 생겼다. 요건 : 파일로 부터 IP 리스트를 읽어서 특정 IP 대역을 분류해주세요. 음 엄청 간단하다. 첫번쨰 방법은 멀티 스텝을 구성해서 파일에서 IP 리스트를 읽어서 특정 대역에 해당하는 내용을 한 파일에 쓴다. 그리고 난 다음 두번째 스텝에서 특정대역에 속하지 않는 파일을 쓰면 된다. 그러나 이러한 방법은 우아하지 못하다. 배치라고 하면 대용량일텐데 입력파일을 두번 읽는다면, 두배로 시간이 소요되기 떄문이다. 그래서 구글링을 해봤더니 역시나 방법이 있었다. 이번 예제는 한번 읽어서 분류해서 두개의 파일로 출력하는 방법을 구현해보겠다. 먼저 입력 파일을 살펴보자. 아래와 같이 아이피를 가진 입력 파일이다.21..

모든 배치처리는 대량의 데이터를 읽고 계산하거나 변경하고 결과를 쓰는것으로 묘사될 수 있다. 스프링 배치는 bulk 처리를 위한 세가지 주요한 ItemReader, ItemProcessor 및 ItemWriter를 제공한다. ItemReader 비록 단순한 컨셉이지만 ItemReader는 다양한 타입의 입력 데이터를 제공하기 위한 것이다. 가장 일반적인 예는 다음과 같다. - Flat File, XML, Database public interface ItemReader { T read() throws Exception, UnexpectedInputException, ParseException, NonTransientResourceException; } Read 메소드는 ItemReader가 가장 주요한 ..

배치 도메인 중에서 step은 실제적인 배치 작업에서 필요한 모든 정보들이 정의된 도메인 오브젝트라고 했었다. Step은 배치 순서 중 독립적인 부분이다. 이것은 약간 작업을 작성하는 개발자의 재량에 따라 애매모호한 정의가 될 수 있다. Step은 개발자 원하는 것에 따라 단순하거나 복잡할 수가 있다. 파일로부터 데이터를 데이터베이스의 적재하는 것은 거의 코드가 필요없다. 더 복잡한 step은 어려운 비즈니스 룰을 포함할 수 있다. Chunk-Oriented Processing 스프링 배치에서는 대부분의 공통적인 구현이 Chunk 기반 처리를 수행한다. Chunk 기반 처리는 데이터를 한번에 하나씩 읽어서 트랜잭션 경게내에서 출력을 위한 chunks들을 생성한다, 하나의 아이템은 ItemReader로부터..

JobLauncher는 새로운 JobExecution을 생성하기 위해 JobRepository를 이용한다. 작업 수행중에 같은 실행을 업데이트하기 위해 같은 JobRepository를 이용한다. 단순한 시나리오는 위와 같지만, 수백 개의 배치 작업과 스케쥴링 요구 사항을 충족하기 위해선 다음과 같이 요구된다. JobExplorer와 JobOperator는 메타데이터에 대한 쿼리와 컨트롤을 추가한 인터페이스이다. JobExplorer 기존의 실행을 리파지토리로부터 쿼리를 하는 것이 가장 기본적인 기능일 것이다. 이러한 기능은 JobExplorer 인터페이스에 의해 제공된다. JobExplorer는 JobRepository의 read-only 버젼이다. 팩토리빈에 의해 쉽게 정의할 수 있다.` JobRegi..

JobLauncher 정의하기 JobLauncher의 가장 기본적인 구현체는 SimpleJobLauncher이다. 실행을 획득하기 위해 JobRepository에만 의존성을 가진다. JobExecution을 획득하면 Job의 execute 메소드로 전달된다. 이러한 과정은 스케쥴러로부터 구동되어 잘 수행되었을 경우이다. 하지만 Http 요청으로부터 작업이 구동될 경우에는 SimpleJobLauncher는 비동기로 작업을 수행하고 결과는 요청 즉시 클라이언트로 전달할 필요가 있다. 배치와 같은 많은 시간 수행되는 처리동안 HTTP 요청을 유지하는 것은 좋은 방식이 아니기 때문이다. 이러한 경우에 JobLauncher의 정의는 다음과 같이 표현된다. Running a Job 최소한 배치 작업을 구동하기 위해..

JobRepository 구성하기 JobRepository는 spring batch의 jobExecution과 stepExecution과 같은 domain 오브젝트를 저장하기 위한 CRUD 기능을 위해 사용된다고 언급했다.JobRepository는 JobLauncher, Job, Step과 같이 프레임워크는 주요한 특징이다. Transaction Configuration for the JobRepository 네임스페이스를 이용하면, transaction 어드바이스는 repository에 자동적으로 적용된다. 실패후 재시작되었을 때 상태를 포함한 메타데이터를 정확하게 하기 위함이다.작업이 구동되었을 때 create 작업을 수행하는 메소드에 대한 isolation level은 기본적으로 SERIALIZAB..

Job은 step의 단순한 컨테이너처럼 보이는 반면에 개발자들이 반드시 알아야 할 많은 옵션들이 있다.또한 작업을 어떻게 실행되는지 실행시 메타데이터가 어떻게 저장되는지에 대한 고려도 필요하다.이번에는 job에 관련된 다양한 옵션과 실행시 고려사항에 대해서 설명한다. 작업 정의하기 Job 인터페이스에는 다양한 구현체들이 존재한다. 그러나 네임스페이스 추상화를 통해 정의의 차이점을 없애준다.작업을 정의하기 위해서 단 세가지의 필수 요소(이름, jobRepository, step들)만이 필요하다.다음 예제는 parent 정의를 사용하여 step들을 생성하기 위한 예제이다.job-repository는 필수요소이지만, 암묵적으로 명시하지 않으면 jobReposity라는 id를 가진 빈을 참조한다. Restart..

아래 그림은 배치의 도메인을 가장 중요한 개념들만 나열한 것이다.Job은 다양한 Step으로 구성되며, 하나의 ItemReader, ItemProcessor 및 ItemWriter를 가진다.Job에 대한 수행 및 메타데이터를 관리하기 위해 JobLauncher와 JobRepository과 필요하다. Job 스프링 배치에서 job이란 step을 위한 컨테이너이다. job는 플로우에 논리적으로 함께 위치한 다수의 step으로 구성된다.재시작과 같은 모든 step에 공통적인 프로퍼티 설정을 적용할 수 있다. job 정의는 다음을 포함한다. - 작업의 이름- 스텝의 정의 및 순서- 작업의 재시작 가능 여부 스프링에서 제공하는 job 인터페이스의 가장 단순한 구현체로서 가장 표준적인 기능으로 SimpleJob 클..