대규모 배치시스템의 성공적인 구축 전략
성공시스템 구축을 위한
Enterprise Batch
대용량의 데이터, 끊임없이 이어지는 트랜잭션… 하루에도 수백만, 수천만 그리고 수억 건에 이르는 데이터 처리 작업이 금융과 통신으로 대표되는 서비스 산업에서 하루도 빠짐없이 이뤄지고 있다. 그만큼 우리의 IT 기술은 질적인 처리 능력뿐 아니라 양적인 면에서의 발전도 요구하며 하루가 다르게 변화하고 있다. 이런 흐름은 IT의 한 축인 SW 개발 영역에서도 예외는 아니다.
엔터프라이즈 환경에서 성공적인 차세대 배치시스템 구축을 고민하는 움직임이 점차 뚜렷해지면서 엔터프라이즈 배치(Enterprise Batch)의 필요성이 빠르게 대두되고 있다. 아직은 그 개념이 본격적으로 확산되진 않았지만 실무에서 혹은 컨설팅 차원에서 그 도입을 저울질하는 기업들이 늘어나는 만큼, 마소 10월호 커버스토리에서 먼저 그 실체를 점검해 본다.
이를 위해 엔터프라이즈 배치의 전체적인 이해를 돕는 배치시스템의 구축전략을 우선 설명하고 이어서 기업의 배치 처리에 활용되는 ETL 솔루션과 배치 프레임워크의 실질적인 예인 스프링 배치 2.0 등을 차례로 소개한다.
기획·정리 | 전도영 기자 mir@imaso.co.kr
1부 | 대규모 배치시스템의 성공적인 구축 전략 | 김진광
2부 | 더 견고한 PL/SQL 애플리케이션 만들기 | 조만희
3부 | 오픈소스 ETL 솔루션 활용 | 정상혁
4부 | 스프링 배치 2.0 | 최한수
엔터프라이즈 배치의 시작
대규모 배치시스템의 성공적인 구축 전략
배치시스템을 효과적으로 구축하기 위해서는 무엇보다 배치 애플리케이션이 가지고 있는 고유한 특징들을 정확히 파악하고 있어야 한다. 배치 애플리케이션의 처리 방식(Batch Processing)을 위키피디아(Wikipedia)의 표현을 빌려 정리하면, 사람의 상호 작용 없이 컴퓨터상에서 여러 프로그램을 실행시키는 것(execution of a series of programs on a computer without human interaction)이라고 할 수 있다. 이 글에서는 엔터프라이즈 배치 이해의 핵심인 배치시스템의 구축 전략에 대해 설명한다.
배치 애플리케이션은 많은 자원을 필요로 하는 대용량 작업을 정해진 시간 제약 내에 사용자와의 상호 작용을 최소화한 자동화된 형태로 수행해야 하는 처리 패턴을 갖고 있으며, 수많은 데이터 유형으로 인해 테스트가 어렵고 많은 수행 시간이 소요된다는 특징이 있다.
배치시스템의 이해
그럼 지금부터 배치 애플리케이션의 특징을 조금 더 자세히 살펴보자.
배치 애플리케이션의 네 가지 특징
● 사용자와의 상호 작용이 없다
온라인 애플리케이션과 배치 애플리케이션이 구별되는 가장 큰 특징은, 사용자에 의해 실행이 결정되지 않는다는 것이다. 배치 애플리케이션은 사용자와의 상호 작용이 없기 때문에 화면 개발로 인한 오버헤드가 없고, 사용자의 리뷰 과정에서 발생하는 요구사항 변경이 상대적으로 덜하다.
반면에 배치 애플리케이션은 사용자로부터 정확한 요구사항을 전달받기 어려우며, 불명확한 요건을 분석해 로직을 직접 설계해야 하므로 개발자/운영자의 비즈니스 이해도가 상대적으로 더 많이 요구된다.
● 정해진 시간 제약 내에 실행이 완료되어야 한다
정해진 시간 제약 내에 수행이 완료되어야 한다. 배치는 수행 결과가 필요한 시점에 의해 제약사항으로 결정된 특수한 시간 범위(Batch Window) 내에서 수행이 완료되어야 한다. 업무 로직의 개선과 프로그램 수행 성능 개선 등을 통해 Batch Window의 크기가 줄어들수록, 보다 빠른 정보 제공/마감이 가능해지기 때문에 동일 배치 애플리케이션이 제공하는 비즈니스적 가치가 높아진다.
● 많은 자원이 소모되는 대용량 작업이다
대용량 고 자원 소모의 작업을 수행한다. 온라인 실시간 처리가 힘든 대용량 처리를 수행함으로써 많은 자원을 사용하게 되므로, 한정된 자원(Connection, CPU 연산 능력, 메모리 등)을 효율적으로 관리할 수 있는 기술적인 지원 및 가이드가 필요하다. 한 번의 처리 실패로 인해 시간 제약을 지키지 못할 수 있으므로, 실패에 대한 정확한 모니터링 방법과 더불어 잘못 실행된 경우에도 효과적으로 처리할 수 있는 방안이 마련되어야 한다.
● 테스트가 어렵고 테스트에 많은 시간이 소요된다
다양한 파일과 복잡한 DB 연계가 포함되어 있어 테스트 데이터를 구성하는 것이 어렵다. 테스트 데이터를 확보하지 못한 상태에서 몇 백만 건 수준의 실제 데이터를 내려 받아 처리하므로 테스트에 많은 시간이 소요되고, 로직 오류로 인한 재 테스트 시 시간 낭비가 심할 수밖에 없다.
배치시스템에 대한 대표적인 오해(Pitfalls)
● 배치는 비교적 단순하고 덜 중요하다.
차세대 프로젝트에서 온라인/정보계 등에 비해 명확한 담당자를 찾기가 힘든 배치는 전사 아키텍처 관점에서 제대로 설계되지 못한 상태에서 프로젝트 막판에 비효율적으로 마무리되기 쉬우며, 성능에 대한 오해로 인해 균형 잡힌 최적화를 이루지 못하는 경우가 많다.
일반적으로 배치는 단순하고, 덜 중요하다고 여겨진다. 따라서 대부분 온라인/정보계 등에 집중하고 배치는 차세대 후반부에 고민하는 경향이 있다. 배치는 자동화된 대량 처리를 필요로 하는 온라인/정보계/대외계 모두와 밀접한 연관 관계를 갖고 있어, 전사 시스템이 유기적으로 업무를 처리하는 데 있어 촉매제와 같은 역할을 수행한다(직접 사용자를 만족시키는 건 적으나, 부지런히 정보가 제때 처리되도록 함).
전사 아키텍처를 설계하는 시점에서부터 배치의 역할 및 기술 구조, 연관 시스템 간의 유기적 연계 및 최적화 방안에 대한 고민이 이뤄져야 한다.
● 배치는 성능이 제일 중요하므로 C 같은 언어로 개발해야 한다
배치는 성능을 최우선으로 생각하는 경향이 있어 C나 COBOL 같은 성능이 뛰어난 언어로 개발해야 한다는 인식이 주를 이룬다. 하지만 성능에 대한 근본 요건은 주어진 Batch Window 내에서 처리할 수 있으면 된다는 것이다.
배치의 성능 최적화는 프로그래밍 언어나 프로그래밍 기법이 아닌 아키텍처 수준의 최적화를 통해 해결되어야 한다. 최적화 기법을 적용순서가 높은 순으로 나열해보면 배치 업무, 아키텍처, I/O 비용, 프로그램 수준에서 논의될 수 있다.
· 배치업무 최적화 : 유사 업무 통합, 불필요한 반복 작업 제거, 월 마감을 일 마감으로 전환, 배치 처리 요건 제거 등
· 관리 고도화 : 수작업 데이터 검증 최소화, 잘못된 결과로 인한 재작업 최소화, 중요도에 따른 자원 사용 고도화 등
· I/O 비용 최소화 : 배치 수행 시간의 80% 이상은 I/O 비용이며, I/O를 최소화해야 최적화된 성능 향상이 이뤄진다. 온라인 컴포넌트 사용 I/O 최소화, 대량 처리를 위한 DB I/O 최소화, 파일 I/O 최소화 등
· 프로그램 최적화 : 일정 사이즈로 처리 데이터를 균일하게 Fetch해서 적정 횟수만큼 묶어서 Commit하기, 프로그램 튜닝 팁 적용
배치시스템의 주요 이슈
배치 서비스 유형과 기술 유형이 정리되지 않고, 애플리케이션을 통한 유형 분석이 어려워 전사 배치 서비스에 대한 분석 및 현황 파악이 어렵다. 그리고 서비스에 대한 표준화가 이뤄지지 않고 있어서 서비스 통합 및 재활용이 되지 않아 유사 서비스가 양산되고 있다.
운영/관리 체계가 미흡해 전사 배치 서비스에 대한 현황 파악 및 효율적인 운영 및 관리가 이뤄지기 힘들며 기반 기술 구조가 취약해 적기에 고품질 서비스를 빠르고 저 비용으로 제공하지 못해 불필요한 인력 및 시스템 자원의 낭비가 존재한다.
이런 현실을 타계하기 위해 업무 애플리케이션, 애플리케이션과 기술이 연계된 표준화된 배치 모델이 필요하고 운영 및 관리 프로세스를 강화한 관리 시스템 구축 및 기반 기술 구조 설계가 필요하다.
모델 중심의 배치 서비스 표준화 미흡
배치 서비스 분류 및 유형이 비즈니스 관점, 업무 조직 관점, 업무 유형 관점에서 체계화되지 못하고 정보 항목(작업 주기/작업 유형/작업 시간 등)이 명확히 정의되지 않아 서비스에 대한 분석이 어려우며 관리 항목(서비스 대상 및 목표/상품 구분 등)이 명확히 정의되지 않아 현황 파악이 어렵다. 배치 기술 유형을 구분 짓는 기준이 불명확하고(입출력 리소스 유형, 사용 도구, 처리 흐름, 적용 기술), 각 기술 유형별로 구현 방법이 상이하며(경험한 유형이 아니면 구현 방법을 알기 어려움) 기술 유형의 확장성이 부족하다(새로운 기술 유형이 나왔을 때 유연하게 대처하기 어려움).
신규/변경 요구 발생 시 유사 서비스 파악을 통해 재활용을 극대화하는 장치가 부족하고, 업무 유형과 기술 유형을 쉽게 판단할 수 없어 배치 애플리케이션의 이해가 어려우며, 업무와 기술에 대한 이해 부족이 최적화되지 않은 배치 애플리케이션의 중복 개발로 이어진다.
관리 시스템 구축 및 기반 기술 구조 설계 필요
애플리케이션 관련 부서와 담당자 식별이 어렵고(현업 / 관리 / 개발) 장애 이력 관리 부족으로 체계적인 오류 원인 파악 및 대처가 이뤄지지 못하고 있으며, 데이터 정합성 확보를 위한 자동화된 사전 점검 기능이 부족해 담당자가 직접 검수하는 경우가 많다.
작업 신청 및 일정 관리, 수행 및 결과 모니터링, 현업 결과 제공 등 운영 업무가 효율적이지 못하고, 적절하지 못한 배치 수행 통제로 인해 전사 자원이 비효율적으로 사용되며, 보안성이 취약하다. 또한 배치 전산 자원에 대한 현황 파악이 어렵고, 지표를 활용한 자원 활용 및 관리가 어렵다. 전체 아키텍처 관점의 최적화가 미흡하다(온라인 로직 재사용, 정보계 ETL 도구의 배치 서비스 활용 등).
분할 처리 및 병렬 처리 미흡, I/O 최적화 부족 등으로 인해 적기 서비스가 지연된다. 효율적인 테스트를 위한 테스트 분류 및 각 분류에 따른 최적화된 테스트 방안이 미흡하다. 배치 개발/테스트/운영에 사용되는 데이터의 보안 요건에 대한 설계 및 빠른 반영이 어렵다.
어떤 문제들이 발생하는가?
[배치 애플리케이션 개발자 K 씨의 피곤한 일상]
현업이 변경을 요청하고 변경에 필요한 일정을 요청한다. 개발자 K 씨가 들어보니 아주 간단한 변경처럼 보인다. 하지만 자신이 없어 일단 일정을 어림잡아 일주일로 산정한다. 현업이 생각하기에도 일주일씩 걸릴 것 같지 않아 미심쩍지만, 배치 애플리케이션이므로 일단 받아들인다. 이제부터 K 씨의 돌고 도는 개발 프로세스가 진행된다.
개발자는 변경사항을 반영하기 위해 자신이 두 달 전에 개발한 배치 애플리케이션의 소스 코드를 분석해 변경 포인트를 찾는다. 본인이 개발한 코드이지만 너무 많은 중복된 코드와 반복적으로 나타나는 로깅, 트랜잭션, 예외 처리 코드 때문에 변경할 부분을 찾기가 쉽지 않다. 드디어 변경 포인트라 생각되는 부분을 찾아 현업의 요구사항을 반영한다. 이때 이미 하루를 변경 포인트를 찾는 데 허비했다.
테스트 과정에서 도출된 결과와 검증 데이터가 맞지 않는 사태가 발생한다. 도대체 어디가 잘못된 것인지 찾기가 쉽지 않다. 로깅 처리가 제대로 되어 있지 않아 이틀을 오류 찾는 데 허비하고 나서야 비로소 오류 부분을 찾았다. 오류를 수정하고 다시 테스트를 진행한다. 결과 데이터는 맞게 나왔지만 테스트 데이터의 양이 적어 테스트 결과를 확신할 수 없다. 운영서버에 적용한 후 보니, 또 다른 장애물이 나타난다. 배치 작업 중 성능이 나오지 않는 것이다. 원인을 찾아보니 오류를 찾으면서 추가한 로깅이 원인이다.
로깅을 제거한 후 다시 배치 작업을 시작한다. 이것이 끝이 아니다. 작업 중 어딘가에서 메모리 누수 현상이 발생해 배치가 중단되는 사태가 발생한다. 어느 누구도 배치가 비정상적으로 중단된 것을 알지 못했다. 다음날 K 씨가 로그를 확인한 후에야 배치가 실패했다는 것을 알게 되었고 다시 오류를 수정하고 밤새도록 K 씨가 모니터링해서 배치 작업을 완료한다.
배치 업무와 관련이 있는 곳에서는 이 사례와 같은 상황이 빈번하게 발생할 것이다. 또한 배치라는 이유로 이러한 상황을 당연하게 여겨왔을 것이다. 하지만 이러한 상황이 발생하는 원인이 무엇이고 어떻게 해결해야 할지 고민해본다면 분명히 답을 찾을 수 있을 것이다. 그럼 이 상황에서 몇 가지 핵심 질문을 유추해 보자
- 왜 간단한 요구사항을 반영하는 데 일주일이나 필요한가?
- 왜 배치는 수정하기 어려운가?
- 왜 배치는 개발자 스스로도 자신의 코드를 믿지 못하는가?
- 왜 배치의 시작과 끝을 모니터링할 수 있는 시스템이 존재하지 않는가?
- 왜 배치는 테스트하기 어려운가?
요구사항은 간단할지라도 코드 상에 CNP(Copy and Paste) 패턴으로 인한 중복된 로직들이 산재되어 있어 수정을 하기 어렵다. 배치는 대부분 대용량 데이터를 처리해야 하기 때문에 테스트 데이터를 만들기도 어렵고 테스트를 수행하는 데도 많은 시간이 소요된다. 따라서 수정한 후에 테스트를 통한 검증도 쉽지 않다. 배치는 지금까지 온라인 시스템에 비해 우선순위가 떨어진다고 생각되어 왔다. 따라서 배치시스템은 고도화되어 있지 않고 진정한 운영시스템도 존재하지 않는 경우가 많다. 이제부터 이러한 문제들을 해결하기 위한 구체적인 방법을 생각해 보자
배치시스템의 이해 및 성공 구축 전략
구축 전략을 이해하기 위해서는 배치시스템이 어떤 구조를 가지고 있는지 이해해야 할 필요가 있다.
배치시스템 구조 이해하기
<그림 1>을 보면 기업에서 사용하는 기술 구조상에서 배치는 극히 일부 요소에 불과함을 알 수 있다. 엑센츄어(Accenture) TRM 상에서 배치 서비스는 실행 환경의 인프라스트럭처 서비스에 위치하고 수많은 인프라스트럭처 서비스의 구성 요소 중 한 영역을 차지한다.
배치시스템의 구성요소를 자세히 살펴보면 배치관리 서비스, 배치 스케줄링 서비스, 대용량 배치 실행 서비스, 배치 애플리케이션 지원 서비스로 구성된다.
구성 요소별로 사용되는 도구들을 살펴보자.
● 배치 관리 서비스
일반적으로 In-House로 통합관리 시스템을 구축한다(배치 운영역량의 핵심).
● 배치 스케줄링 서비스
Control-M, TWS(Tivoli Workload Scheduler) 등 솔루션을 도입하거나 OPENSYMPHONY의 Quartz 같은 오픈소스 솔루션을 이용할 수 있다.
● 대용량 배치 실행 서비스
- 쉘 프로그래밍을 통해 유닉스 기능을 활용한다(처리 품질은 개발자 몫).
- 미들웨어를 이용해 실행 컨테이너를 구축한다(기본 처리 품질 보장 및 자동화).
- 서비스 프레임워크(온라인을 배치에서 사용) 또는 센터컷(배치에서 온라인을 사용)
● 배치 애플리케이션 지원 서비스
- 코어뱅킹 솔루션 등에 포함된 배치 지원 기능 또는 직접 배치 프레임워크를 구축
- 대용량 SAM 파일 처리도구(예 : Syncsort), DB 유틸리티(예 : SQL 로더) 배치 처리 결과 검증도구(예 : TeraStream) 등이 사용된다.
성공 구축 전략
배치시스템이 적시에 고품질 배치 서비스를 최소한의 비용으로 제공하기 위해서는 표준화된 배치 서비스 모델을 기반으로 배치 관리/운영 프로세스를 고도화하고, 최적화된 기술 기반 위에서 애플리케이션 프레임워크를 기반으로 이를 시스템화해야 한다.
체계적인 검증 기준의 수립과 검증을 자동화해 배치 작업의 오류를 최소화하고 데이터의 정합성을 확보한다. 하드웨어, 소프트웨어, 애플리케이션의 전체적인 최적화, 성능 향상, 안정화 등을 통해 서비스 제공시간을 단축함으로써 적시에 비즈니스 요구사항을 반영하며, 프로세스를 표준화하고 체계화해 비즈니스 변화에 일관되고 체계적인 관리를 수행함으로써 문제발생시 신속한 원인 파악 및 동일한 문제의 발생을 최소화한다. 통합된 기술표준을 확립하고, 모니터링을 통해 관리의 효율성을 높이며, 실시간으로 배치 작업을 통제해 문제 발생시 대처하는 역량을 증진시킴으로써 운영 및 관리의 효율성을 향상시킨다.
똑똑한 배치 처리를 돕는 다섯 가지 핵심 기법
배치 처리 유형을 표준화하고 이를 패턴화한 구현 방법을 제공하라
배치 기술 패턴은 반복 처리 패턴, 로직 처리 패턴, 유틸리티 패턴, 커스텀 패턴으로 크게 네 가지로 분류할 수 있다.
반복 처리 패턴은 건 단위로 반복적으로 입/출력이 이루어지고 입/출력 유형에 따라 구분된다. 반복 처리 패턴에서 입력 자원과 출력 자원은 다수가 존재할 수 있다. <표 1>에 입/출력 자원의 유형을 정리해 놓았다. 반복 처리 패턴은 ‘고정 길이 파일을 읽어서 구분자 파일로 쓴다’와 같이 표현할 수 있다.
로직 처리 패턴은 비즈니스 로직 상에서 다른 시스템의 자원을 사용하는 패턴을 뜻한다.
<표 2>에 로직 처리 패턴에서 사용되는 자원을 정리했다.
반복 처리 패턴과 로직 처리 패턴은 유기적으로 연결되어 있다. 입력 자원을 이용해 처리할 데이터를 읽고 데이터베이스, 온라인 서비스, 룰 엔진 등을 이용해 비즈니스 로직을 처리한 후, 결과를 출력 자원을 이용해 저장한다. 만일 입력 자원이 고정 길이 파일이고 출력 자원이 DB이면서 비즈니스 로직에서 Dao를 이용한다면 ‘Fixedlength File To DB Using DaoConnector’와 같이 표현할 수 있다. 유틸리티 패턴은 FTP, Print, Tool을 이용한 데이터 변환, 쉘 스크립트 등을 이용하기 위한 패턴을 뜻한다. 이러한 세 가지 패턴에 포함되지 않는 패턴은 커스텀 패턴으로 정의할 수 있다.
기본 빌딩 블럭을 통해 각각의 배치 처리 유형을 동일한 개념으로 구현하라
처리 패턴은 실제로 몇 백 개나 된다. 이걸 개발자들에게 다 알라고 하는 건 지나친 학습 부담을 초래한다. 따라서 패턴은 여러 개가 되더라도 각각의 패턴은 동일한 개념으로 구현될 수 있어야 한다. 이러한 개념들을 빌딩 블럭으로 표준화함으로써 처리 패턴이 다양해질지라도 동일한 구조로 개발하는 것이 가능하도록 한다. 기본적인 빌딩 블럭의 예로는 <그림 4>에서 보는 것과 같이 ResourceReader, Transfomer, Processor, Connector, ResourceWriter 등을 들 수 있다.
SoC 원칙을 최대한 적용해 개발자의 부담을 줄여라
관심사항 분리 전략을 적용해 반복적으로 처리되는 횡단 관심사인 보안, 로깅, 예외 처리, 트랜잭션 처리 등과 같은 작업은 프레임워크에서 담당하고 개발자는 비즈니스에 관련된 관심사만을 담당한다.
● 관심사항 분리
반복적이고 공통적으로 나타나는 코드를 프레임워크에서 담당함으로써 개발자는 핵심 관심사에만 집중할 수 있도록 한다.
로깅, 메시지, 예외 처리와 관련된 사례를 보고 생각해 보자.
[사례]
어느 날 배치 애플리케이션에서 에러가 발생했다. 로그 파일을 확인해 보니 알 수 없는 에러메시지만 남아 있었다. 에러를 확인하기 위해 에러를 재현해보는 수밖에 없었다. 확인 결과 프레임워크에서 발생한 에러였다. 이 에러를 찾는 데 하루가 소요되었고 프레임워크 팀에 수정을 요청하고 프레임워크 팀에서 에러를 수정하고 다시 배치 작업을 실행하느라 프레임워크 팀을 욕하면서 또 밤샘 근무를 해야 했다. 이 일이 있은 후부터 문제가 생기면 프레임워크를 먼저 의심하게 되었다.
배치 프레임워크에서는 로깅, 메시지, 예외 처리를 표준화해 꼭 필요한 경우가 아니라면 개발자가 임의로 로그를 남기는 것을 최소화해야 한다. 배치 작업의 특성상 개발자가 임의로 남긴 로깅 한 줄도 성능에 지대한 영향을 미칠 수 있기 때문이다. 프레임워크에서 로그를 남길 때는 프레임워크 메시지와 애플리케이션 메시지를 구별할 수 있도록 해서 위 [사례]와 같은 일이 발생하지 않도록 해야 한다.
예외 처리는 무시(skip)해야 하는 예외와 배치 작업을 종료(fatal)해야 하는 예외로 구분해 처리하고, skip 예외의 경우에는 로그를 남기지 않거나 최소한의 로그만을 남겨야 하며 배치 작업을 종료해야 하는 예외의 경우에는 에러 트레이스를 적절하게 남겨야 한다. 에러 트레이스를 분석해 배치 애플리케이션에서 발생한 예외일 경우에는 애플리케이션과 관련된 트레이스만을 남기는 방법을 고려해 볼 수 있다.
[사례]와 같은 일이 자주 발생한다면 개발자들은 아무도 프레임워크를 신뢰하지 않게 될 것이고, 결국 신뢰를 잃은 프레임워크는 사장되고 말 것이다. 따라서 로깅, 메시지, 예외 처리는 별로 중요하지 않은 듯 보이지만 배치 프레임워크에서 없어서는 안 될 아주 중요한 요소이다.
● 트랜잭션
배치 작업은 하나의 트랜잭션 내에서 처리되어야 한다. 업무로직 처리 중간에 Dao를 이용하거나 온라인 서비스를 이용하는 경우에도 역시 한 트랜잭션 내에서 커밋되고 롤백되어야 데이터의 무결성이 보장된다.
배치는 특성상 대부분 대용량의 데이터를 처리해야 하고 반복적으로 DB에 입력/수정/삭제처리를 하는 경우가 많다. 만약 천만 건의 데이터를 읽어서 천만 건의 데이터를 DB에 insert하는 작업이 있다면 천만 건의 데이터를 일일이 커밋할 경우 성능에 엄청난 영향을 미치게 된다.
따라서 프레임워크에서는 커밋 사이즈를 설정할 수 있어야 하고 그 사이즈만큼씩 트랜잭션 처리를 하도록 구현해야 한다. 하지만 에러가 발생했을 때는 1건 단위로 롤백되어야 한다. 배치 작업은 주로 일과 시간 이후에 실행되는 경우가 많지만 일과시간에 수행되는 배치 작업도 존재한다. 따라서 일과시간 이후에 실행되는 배치 작업과 일과시간에 실행되는 배치 작업의 커밋 사이즈를 적절히 조정해 시스템을 좀 더 효율적으로 이용할 수 있도록 하는 전략도 필요하다.
테스트를 최적화하라
배치 테스트를 수행하기 위해서는 기본적으로 모든 경우의 수를 고려할 수 있는 데이터가 필요하다. 하지만 실제로 배치는 고려해야 하는 경우의 수가 많아 모든 경우를 고려할 수 있는 데이터를 만드는 것이 현실적으로 불가능하다. 따라서 대량의 운영 데이터를 이관해 테스트를 수행한다. 이러한 테스트용 데이터가 존재하지 않거나 빈약할 경우 개발자들은 자신들이 개발한 배치 애플리케이션을 검증하기 위해 운영 DB에 접속하려 할 것이므로 테스트용 데이터는 기본적으로 마련되어 있어야 한다.
자동화된 단위테스트를 통해 쉽고 빠르게 배치 애플리케이션의 기능을 검증하고 애플리케이션의 변경이 있을 경우 단위테스트와 회귀테스트를 통해 애플리케이션을 검증해야 한다.
배치는 일반적으로 같은 작업의 중복 실행을 허용하지 않는다. 테스트 시에는 같은 작업을 반복해서 테스트하므로 같은 배치 작업을 반복해서 실행하기 위한 방안이 있어야 한다. 테스트를 수행하는 환경에 대해서는 독립적이어야 한다. 로컬에서 테스트를 진행하거나, 서버에서 테스트를 진행하더라도 배치 애플리케이션의 수정 없이 테스트를 수행할 수 있어야 한다.
운영 시스템을 고도화하라
운영시스템은 기본적으로 모니터링, 배치 작업 실행제어, 스케줄링, 통계, 배치 작업 등록, 경보 등의 기능을 갖추어야 한다.
● 모니터링
배치의 수행 상태, 수행 시간, 메모리 사용률, CPU 사용률 등을 모니터링해서 배치의 현재 상태를 모니터링할 수 있어야 한다.
● 배치 작업 실행제어
배치 작업은 엔드 유저의 상호작용 없이 실행되므로 운영시스템에서 스케줄에 따라 자동실행 또는 긴급 배치를 위한 수동 실행 기능을 제공해야 하며, 잘못된 실행의 경우 배치 작업을 취소할 수 있는 기능이 있어야 한다.
● 스케줄링
일별, 주별, 월별, 년별, 특정한 날의 배치 작업 등을 설정할 수 있어야 하며, 특정한 날에 배치 작업이 몰려 있을 경우 배치 작업 일정을 조정해 시스템에 과부하가 걸릴 만한 상황을 미연에 방지하기 위한 배치 작업일정 조회 뷰가 있어야 한다.
● 경보
모니터링을 통해 시스템적으로 한계상황에 도달하려 하거나, 배치 작업이 비정상적으로 종료되었을 경우 해당 배치 작업 담당자에게 경보를 울려 배치 작업을 안정적으로 수행할 수 있도록 해야 한다.
조직에 제대로 적용되기 위한 주의사항
배치의 유형은 무수히 많다. 프로젝트 기간 중 배치 유형에 대해 적어도 한 개는 대표 사례가 예제 형태로 구현되어야 하고, 프레임워크 등의 변경 시마다 회귀테스트가 이뤄져야 한다.
실 가동 상황에서 세심하게 테스트되어야 한다. 실 가동 상황이란 몇 백 만건의 데이터를 가지고 성능 프로파일링을 수행하며 진행하는 테스트를 의미한다(예 : 반각 문자가 포함되어 전문의 Layout이 깨지는 경우, 특수 처리 패턴에서 메모리 누수가 발생하는 경우 점차적으로 느려짐. 동일 DB에 대한 Access가 발생하는 상황 등).
엔터프라이즈란 말에는 복잡한 조직 구조를 포함하고 있다. 조직 내에는 매뉴얼을 정말 열심히 보는 사람과 전혀 보지 않는 사람 등 다양한 유형의 사람이 존재한다. 따라서 변경된 프레임워크에 적응하기 위한 다양한 교육방법과 교육시간이 확보되어야 한다. 예를 들면, 직접적으로 대면 교육을 하고, 동영상 교육 자료를 통해 지속적으로 찾아볼 수 있고, 실제 업무를 변환한 예제를 제공해 실무적응성을 높이는 등을 예로 들 수 있다.
이러한 상황을 종합하면, 실 가동 상황에서 철저한 테스트를 수행하고, 실제 실무자들이 프로젝트 팀에 참여해서 각 팀별로 대표 사례를 수집하고, 그 사례를 실제로 구현한 예제를 만들면서 프로젝트가 진행되어 프로젝트 종료 후 자연스럽게 그 사람들이 팀의 구현 리더로서 교육 담당자가 되는 구조가 되어야 한다.
배치시스템의 중요성
지금까지 대규모 배치시스템을 성공적으로 구축하기 위한 전략을 비즈니스, 애플리케이션, 운영의 관점으로 살펴봤다. 온라인 환경과는 다르게 배치시스템에 대한 관심이 적어 현재까지 대규모 배치시스템을 성공적으로 구축한 국내 사례는 거의 없다.
따라서 프로젝트를 수행하며 얻은 필자의 경험이 독자들이 현업에서 배치시스템을 구축하는 데 조금이나마 도움이 되기를 바란다. 배치시스템의 중요성을 인식하고 개선하기 위한 노력들이 조금씩 싹트기를 희망하며 이 글을 마친다.
필자소개
김진광 kwang23@gmail.com｜기업이 겪고 있는 다양한 기술적 문제들을 아키텍처 수준에서 해결 방법을 제시하고, 그것을 실제로 실현해 낼 수 있는 수준에 도달하기 위해 열심히 노력하고 있는 개발자이다. 현재 아이티와이즈컨설팅의 전문 엔지니어 그룹에서 근무하고 있으며, 대형 보험사의 전사 배치 프레임워크를 개발했던 경험을 기반으로 그룹 계열사 간의 연결재무시스템을 구축하는 IFRS 프로젝트에서 배치 프레임워크 개발을 담당하고 있다.
출처명 : 한국 마이크로 소프트웨어 [2009년 10월호]
Posted by 홍반장
