이번 회에서는 배치잡의 일반적인 특징 때문에 개발자들은 배치처리 프로그래밍을 할 때 더 깊이 고민해야 한다는 것을 이야기하고자 합니다.
배치처리의 특징
요즘은 대부분의 정보시스템에서 웹 기반의 실시간 처리 모듈이 주요기능들을 제공하고 있다. 이에 따라 당연히 개발자들의 주요 관심사가 웹 개발에 쏠리고 있고, 그에 대한 많은 패턴, 프레임웍들이 넘쳐나고 있다. 하지만 동시에 대부분의 시스템에서 배치처리 모듈도 여전히 중요한 역할을 담당하고 있다.
배치처리의 가장 큰 특징은 아래 두가지를 들 수 있다.
- 사용자와의 상호작용이 없다.1
- 주로 Time based event 에 의해 실행된다.
UI가 없으니 사용자의 변덕에 덜 휘둘리고, 처리 성공시의 실행 결과는 명확히 정의된다. 그리고 웹 개발처럼 많은 Layer들을 코딩해야 하는 것도 아니고, HTML이나 javascript를 몰라도 되기 때문에 어떤 이들은 더 쉬운 개발이라고 생각할 수도 있겠다. 그래서인지 실제로 프로젝트에서 신입 개발자들에게 배치처리의 프로그래밍이 맡겨 지는 경우도 볼 수 있다.
그런데 보통 배치잡은 온라인 실시간 처리가 힘든 대용량, 고자원 소모의 작업을 수행하는 경우가 많다. 이럴 때는 한번의 실행 실패가 전체 시스템에게 치명적이다. 잘 못 실행되어서 영향 받은 데이터가 한 두건이 아니라면 복구나 재처리도 쉽지 않다. 더욱이 사용자가 바로 에러를 눈으로 확인할 수 있는 것이 아니기 때문에, 그 처리 실패가 즉시 감지되지 못하는 때도 많다.
그리고 개발 도중의 테스트도 난관이 있다. 배치처리의 테스트에는 운영환경과 유사한 테스트 데이터를 만드는 일이 더 손이 많이 갈 수 밖에 없다. 다루는 데이터 형식이 DB뿐만이 아니라 다양한 형태의 파일도 있어서 UI테스트의 데이터처럼 간단히 입력할 수 있는 성질의 것이 아닐 때도 많다. 거기다 대용량 처리에 대한 안정성까지 미리 확인해 보려면 충분히 많은 건의 테스트 데이터를 만들어야 한다. 또, UI가 없으니 최종테스트도 개발자만이 할 수 있는 경우가 많다. UI단에서 1차적인 Validation도 없으므로 이상 값 처리에 대한 테스트도 충분히 해야지 운영환경에 대비할 수 있다. 이런 상황에 배치프로그램이 적절하게 모듈의 분리가 되어 있지 않다면 통째로 실행시키면서 테스트를 해 볼 수 밖에 없다. 이렇게 테스트를 하기 힘든 모듈은 개발하기 어렵고 개발 후에도 버그를 많이 양산해서 지속적으로 비용을 유발한다.
따라서 배치잡은 오히려 실시간 처리 모듈보다 더 정교한 설계와 품질 높은 구현이 필요하다고 볼 수 있다.
그러나 이 중요도에 비해서 그 동안 JAVA 세계에서는 배치 프로그래밍에 대한 노하우들은 잘 공유되지 못하고 있었다. JAVA에서 수많은 웹개발 프레임웍이 있는 것에 비해 배치 처리를 위한 프레임웍은 쉽게 접하기 힘들었다. 스케쥴링에 대해서는 quartz나 flux가 있다지만 배치처리에서 스케쥴링은 그 일부일 뿐이다. 그리고 IBM에서 내 놓은 WebSphere XD Compute Grid에서 배치처리를 위한 기반들을 제공하기는 하지만, 상용 제품이기 때문에 현실적인 여건상 적용할 수 있는 상황이 제한적이다.
그리고 ETL(Extract, Transform, Load) 프로그램들이 XML이나 플랫파일(Flat file) 파일의 파싱 기능과, HTTP, FTP, SOAP, LDAP 등 각종 프로토콜을 이용한 데이터통합(data-integration) 프로세스들을 지원하기는 한다. 오픈소스로도 Pentaho Data Integration(=Kettle), Talend Open Studio(=JasperETL), Clover ETL 등의 ETL 어플리케이션들이 있다. 하지만 이런 ETL프로그램들은 프레임웍이라기보다는 도구에 가깝다고 볼 수 있고, 그 초점이 배치에 꼭 맞춰진 것은 아니었다.2
이렇듯 배치 프레임웍에 대한 논의가 부족하다 보니 많은 배치처리 프로그램들은 특별한 틀이 없이 바닥부터 작성한 기본 Java application으로 만들어 지고 있다. 이제는 정해진 구조가 확고해서 크게 어긋날 구석이 없는 웹 개발과는 다른 것이다. 그래서 개발자의 역량에 따라 그 품질의 편차가 크다 보니 한 메소드가 수 백 라인으로 된 코드가 난무하고 유지보수할 때는 어디서부터 고쳐야 할 지가 난감한 상황이 자주 발생한다. 그리고 시스템의 안위를 위해서는 매일 아침 출근해서 서버에 접속해 로그를 확인해야 하는 부지런함이 강요되는 프로젝트 환경도 많다.
배치모듈을 잘 만든 성과는 혜택은 개발자들에게 바로 돌아간다. 그래서 배치 프로그램에는 사용자들이 관심을 가지는 단순 기능수행 이상의 것이 있어야 한다. 에러처리, 복구, 모니터링, 유지보수가 쉬워지는 구조의 배치잡을 만드는 일은 바로 개발자 자신을 위한 일이다. 이렇듯 지금이라도 개발자들이 배치처리에 대해 관심을 돌릴 이유는 충분하다.
정상혁, http://benelog.egloos.com
- 위키페디아의 정의(http://en.wikipedia.org/wiki/Batch_job)에 따르면 Batch processing is execution of a series of programs ("jobs") on a computer without human interaction. 라고 되어 있다. [본문으로]
- 더 많은 Java 오픈소스 ETL툴이나 프레임웍들은 http://www.manageability.org/blog/stuff/open-source-etl 에서 찾아볼 수 있다. [본문으로]

Prev



Rss Feed