03.스프링배치 프로젝트와 주요 기능들

스프링배치 프로젝트의 개요와 현황

  Spring batch는 널리 쓰이고 있는 Spring 프레임웍의 portfolio의 일부이다.  이 프로젝트는 Spring 개발을 주도하고 있는 SpringSource와 배치처리에 대한 현장경험을 가지고 있는 Accenture가 공동으로 개발하고 있다. 2008년 3월28일에 1.0 final version이 발표된, 아직 어린 프로젝트이기는 하지만, 그 동안의 예비 버전을 통해 그 기본 틀은 안정된 것으로 보인다. 그리고 다른 Spring 프로젝트들이 뛰어난 하위 호완성을 지켜주고 있는 것을 볼 때, 실무 적용이 충분히 가능한 단계라고 생각된다.

  스프링 배치는 당연히 Spring core 모듈에 대한 의존관계를 가지고 있으며 그에 따라 POJO 기반의 개발, 유연한 설정법, AOP 적용 등 기존 스프링의 장점을 그대로 이어 받고 있다.  핵심 영역은 Spring 2.0 버전으로 사용할 수 있고, 일부 샘플 코드에서 annotation을 이용할 설정 같은 Spring 2.5의 기능을 쓰는 것이 보이기는 하지만, 어렵지 않게 2.0 방식으로 바꿔서 돌릴 수 있다.

스프링 배치의 기능들

  앞에서 배치처리의 특징과 유의점을 설명했지만, 여기에 스프링배치를 적용하면 어떤 좋은 점이 있는지 궁금해 하는 사람이 많을 것이다. 다음에 설명한 스프링배치의 기능들을 보면 그것을 이해하는데 도움이 될 것이다.

• 각종 읽기와 쓰기 기능의 구성요소를 같은 인터페이스들로 추상화 시키고 있고, 그에 맞는 기본 구현 클래스를 제공한다. DB, 플랫 파일,  XML 파일, JMS(Java Message Service) 등의 여러 가지 출처와 형태로 연결되는 데이터들을 ItemReader와 ItemWriter라는 인터페이스를 통해 동일한 방식으로 접근할 수 있다. 이것은 각각의 요소들의 역할 구분을 분명히 하고, 데이터 형태의 변화에 대응하는 유연성을 높일 수 있다. 그리고 부분적인 모듈의 테스트도 더욱 쉽게 한다. 기본 구현클래스 중에 적합한 것이 없을 경우 최종 개발자가 직접 작성할 수 있는 것은 당연한 일이다.
• 대용량 조회 처리를 위해서 커서기반이나 Driving query기반의 조회방식을 지원한다. 전자가 JdbcCursorItemReader나 HibernateCursorItemReader 클래스로 제공되고, 후자가 DrivingQueryItemReader, IbatisDrivingQueryItemReader 클래스를 통해 지원이 된다. 두 가지 방식 중에 하나의 선택이 쉽지 않을 때도 스프링배치를 쓰고 있다면 부담 없이 하나의 방식을 택할 수 있다. 향후에 그 방식을 변경이 할 지라도 스프링배치의 구조에서는 그 변경 영역이 지역화되므로 전체 모듈에 큰 영향을 미치지 않는다.
• Stream방식의 파일 처리를 더욱 편리하게 할 수 있는 API를 제공한다. 열고 닫는 것이 필요한 자원에는 공통적으로 ItemStream이라는 인터페이스를 통해 이를 지원한다. 그리고 StAX(Streaming API for XML) 기반의 API로 대용량 XML파일 처리를 쉽게 한다.  Spring WS(Web Service) 프레임웍의 일부인 Spring OXM (Object/XML Mapping framework)과 연결해서 특정 라이브러리에 종속적이지 않은 XML 파일 처리도 가능하다.  XStream, Caster, JiBX 등의 XML 처리 오픈 소스 라이브러리 중에 마음에 들거나 익숙한 것을 사용할 수 있는 것이다. 플랫파일에 대해서도 구분자 방식, 고정길이 방식의 구조를 읽을 수 있는 기본 클래스를 제공한다. 이를 이용하면 StringTokenizer와 같은 자바 기본 클래스로 복잡하게 코딩할 필요 없이 거의 설정만으로 파싱 모듈의 작성이 가능하다.
• 배치에 적합한 트랜잭션 처리를 위해 주기적인 commit방식을 지원한다. SimpleStepFactoryBean 클래스를 통해 설정할 수 있는 commitInterval이라는 속성이 한번의 트랜잭션에서 처리될 건 수이다. 데이터 특성이나 업무규칙에 따라서 적절한 값을 트랜잭션 단위로 묶이는 건수를 Java코드를 수정하지 않고도 설정으로 지정할 수 있는 것이다.
• 배치작업의 재시도, 재시작, 건너뛰기 등의 정책을 설정으로 적용할 수 있다.  스프링 배치에서는 네트워크 이상 같은 일시적인 장애로 인한 처리 실패를 대비해서 배치작업을 재시도하는 횟수를 지정할 수 있다. 그리고 재시작 시에는 이미 성공한 단계에 대해서는 건너뛸 수 있는 기능이 있고, ExecutionContext 라는 저장 공간을 통해서 이전 처리 때 생성한 정보를 활용할 수 있다.
• 유연한 Exception 처리를 할 수 있다.  Skip 해야 할 Exception , 또는 그 Skip할 수 있는 횟수 등을 정의해서 업무 로직의 특성에 맞는 Exception 처리를 복잡한 try catch문 없이 설정만으로 할 수 있다.
• 각종 이벤트 처리가 가능하다. 배치잡과 그것을 구성하는 단계, 또는 트랜잭션의 단위 별로 그 시작과 끝, 에러 발생 시점에 호출되는 Listener 인터페이스가 정의되어 있다. 그 Listener들을 구현해서 코딩하고 설정으로 연결하면 공통적인 작업들을 배치처리코드와 섞이지 않게 넣어서 실행시킬 수 있다.
• Commit 개수, Rollback 개수, 재시도 횟수 등 배치실행 통계 정보를 제공한다. 최종개발자가 작성하는 코드에서 별도로 이를 위한 변수를 할당하고 로깅하는 코드를 집어 넣어줘야 할 필요가 없어졌다.
•  다양한 실행방법을 선택할 수 있다.  Spring의 Quartz 지원 클래스를 이용해서 스케쥴링 기능을 Spring의 설정방식으로 지정할 수 있다. 수동으로 command line이나 JMX(Java Management Extensions) 콘솔 등을 통한 실행도 가능하다. 최근에 Spring의 본부 SpringSource에서 발표한 SpringSource Application Platin(SSAP)을 통해 OSGi기반으로도 실행이 가능하다. 실행방식도  동기, 비동기-병렬 실행이 다 가능하다.
•  추가 코딩 없이 설정만으로 기존 모듈 활용의 가능하다. 기존 모듈 중에 배치에서 하는 것과 동일한 작업을 하는 코드가 있다면 따로 스프링배치의 인터페이스로 감싸서 코딩할 필요 없이 applicationContext에서 설정만으로 연결이 가능하다. 그렇게 된다면 기존 모듈을 활용하면서도 스프링배치가 제공하는 이벤트 처리, 실행정보 제공 등의 장점을 같이 누릴 수가 있는 것이다.
• iBatis나 Hibernate를 사용해서 DB접근모듈을 개발할 수 있다. 이들은 이미 많은 개발자 층을 확보하고 있는 Persistant layer의 프레임웍들이기 때문에 학습비용의 절감해 줄 것이다. 또, 같은 프레임웍을 쓴다면 시스템의 다른 부분과 일관성 구현이 이루어지고 코드 중복을 막는데 도움을 줄 것이다.
• Validation 기능을 SpringValidator와 apache commons validator 를 사용해서 구현할 수 있다.

정상혁, http://benelog.egloos.com