On-premise 에 운영중인 서버들을 머리속에 떠올리면 무겁고 움직이지 않는 거대한 돌덩이 같다. 특히나 우리나라의 고도화된(?) 보안 정책에 둘러 쌓여 힘겹게 그 역할을 수행하고 있는 장비들이 아닐까 싶다.
얼마나 기다렸던가? 이제 이들에게 몰려있던 많은 데이터를 클라우드에 연계하고 클라우드에서 가볍게 분석할 수 있도록 데이터 이관을 하게 됐다. 당장 진행해 봐야 할 분석들이 산더미 이지만 데이터가 제대로 있어야 분석도 가능하니 데이터를 하나도 빠짐 없이 잘 올리는 것이 무엇 보다 중요하다.
그렇다고 데이터 올리는 일이 쉬운 일은 아니다. 오로지 올바른 툴을 잘 찾아내고 잘 어울리는 자동화 방법을 찾아낸 사람들만 마음 편히 데이터 마이그레이션을 온전히 즐길 수 있다.
급속히 변화 해 가는 영업 환경 속에서 재빠르게 분석 환경을 만들기 위해 분석가나 현업이 바라보는 Legacy 데이터의 모양(Schema)을 유지한 채로 최대한 빨리 Cloud에 연결하기 위해 무수한 테이블들을 Lift & Shift 방식으로 복제해야 한다.
이런 미션이 주어진 후 약 2주간 다음과 같은 고민들을 해결하기 위해 여러 프러덕들을 시험하고 조사해 보았다. 일손이 부족하니 상용 제품이라도 단시간에 목표를 달성해 줄 수 있다면 감사하겠다는 마음으로 이리저리 데스크 서치를 해보았지만 오늘에 이르러서는 embulk라는 오픈 소스 도구를 이용하게 되었고 내 문제를 해결하기위해 이 도구에서 벗어날 수 없을 것 같다는 결론에 이르렀다.
왜 상용제품을 사용하지 않고 오픈 소스를 선택 했는 지는 따로 정리하고 싶다. 왜냐하면 한국 뿐만 아니라 외산 SW 제품과 서비스를 판매 하는 당사자들도 이런 시장의 실정을 알아야 더 발전이 있지 않을까 하는 생각, 그리고 기업에서 SW제품을 선정하는 담당자들의 의사결정에 기준이 되어 적어도 누군가는 고민을 줄이는 데에 도움을 주고 싶은 바램이 있기 때문이다.
이러한 EL (또는 ETL, E:Extract, T: Transform, L:Load) 도구로 embulk를 선정하게 되었던 기준들을 아래에 나열한다.
- Datasource connectivity : on-premise 의 다양한 database 들과 연결하여 추출과 로드를 할 수 있어야 한다. 예를 들자면, SAP Hana DB, Teradata, Oracle, AWS Redshift, Google Bigquery 등등
- Technical security : 데이터 추출과 로드 속도 및 안정성이 보장되어야 한다.
- Transformability : 추출 된 데이터에 간단한 Transform이 가능해야 한다. 즉, ms949에서 utf-8 로의 캐릭터 인코딩 변경, Encryption, Hashing, regexp를 활용한 치환 등
- Automatability : 자동화가 용이해야한다. bash 나 python을 이용해 scripting이 빨리 될 수 있어야 한다.
- Agile Supportiveness : 오늘 당장 이용하여 테스트 및 파일럿이 가능해야 한다.
- Quality of Documentation : 문서화가 잘 되어 있어야 한다. 문서화가 안 되어 있다면 이해하기 쉽도록 직관적인 오픈소스 코드가 제공되어야 한다.
- Compatibility : 나와 잘 맞아야한다. 내가 이해하기 쉬워야 하고 내가 팀을 이해시키기 용이해야하며, 지금 운영중인 시스템에서 어떤 방법으로 적용을 하던 궁합이 잘 맞아야 한다.
각 조건에 어떻게 부합하는 지는 검증 과정에서 확인이 되었다. 오픈소스이지만 다행히도 안정적이었고 여러 RDBMS에 jdbc를통해 연결이 가능해 일단 검증을 시작해볼 수 있었다. 특히나 문서와 설명이 부족한 편이기는 하지만 코드들에 직접 접근해서 필요한 기능은 수정해 가며 사용할 수 있었고, 로그 분석만으로도 데이터 로딩중 발생하는 문제들을 해결할 수 있어 큰 걱정없이 자동화 작업으로 업무를 이어갈 수 있게 되었다.
어떻게 embulk를 잘 활용하게 되는 지는 다음편에 이어 소개하겠다.
