Offcanvas

CIO / 디지털 트랜스포메이션 / 빅데이터 | 애널리틱스 / 애플리케이션 / 클라우드

ETL 병목에 대한 이베이츠의 해법 '클라우드 데이터 레이크'

2018.08.31 Thor Olavsrud  |  CIO
기업이 데이터 레이크(Data Lake)를 데이터 웨어하우스(Warehouse)로 사용하려다가 문제에 부닥치는 경우가 종종 있다. 가트너의 리서치 부사장 머브 에이드리언은 '끔찍한 아이디어'라고 말할 정도다. 거대 전사상거래 업체 이베이츠(Ebates)의 분석 부사장 마크 스테인지-트리기어가 4년 전 이베이츠에 합류했을 때도 비슷한 상황이었다.



당시 이베이츠는 일부 엔지니어가 단일 SQL 서버와 주요 생산 데이터베이스의 복사본을 사용하는 것 외에는 이렇다 할 비즈니스 인텔리전스(Business Intelligence, BI) 인프라가 없었다. 가장 큰 문제는 ETL(Extract, Transform, and Load) 프로세스였다. 스테인지-트리기어는 "ETL 작업에 28시간이 걸렸다. 필요한 보고서 또는 정보를 제때 확보하기 어려웠다. 또한 동시 실행 성능도 한계에 부딪혀 시스템 전체가 불안정해지고 있었다"라고 말했다.

그래서 대안으로 도입한 것이 바로 하둡(Hadoop) 클러스터 기반의 데이터 레이크였다. 비용과 비전 측면에서 적절한 솔루션이라고 판단했다. 여러 사일로(Silo)를 거치지 않고도 모든 데이터를 한 곳에 통합해 활용할 수 있을 것으로 기대했다.

당시 스테인지-트리기어의 팀은 핵심 ETL 프로세스를 파이썬(Python)으로 작성했고 불과 몇 달 후에는 최고 임원을 위한 보고서용 데이터를 새로운 데이터 레이크에서 뽑아내기 시작했다. 스테인지-트리기어가 "그때부터 임원진이 데이터 레이크를 받아들였다. 훨씬 빠르고 효율적으로 데이터를 뽑아냈기 때문이다. 이후 모든 것이 바뀌었다. 많은 작업이 필요하긴 했지만, 결국 기존에 사용하던 모든 SQL 서버를 걷어낼 수 있었다"라고 말했다.

ETL 병목현상
이베이츠의 단일 하둡 클러스터에서 2가지 구별된 데이터 영역이 있다. 하나는 업체가 말하는 '데이터 레이크'로써, 실제 업무에 사용하는 데이터베이스의 원본 그대로의 사본이다. IT팀에 데이터를 변형 또는 정리하는 일이 거의 없는 데이터로, 데이터 레이크의 테이블은 생산 데이터베이스의 데이터와 거의 똑같다.

다른 영역은 이베이츠가 '데이터 웨어하우스'라고 부른다. 방대한 보고서용 작업을 위해 정리하고 통합한 데이터다. 스테인지-트리기어는 "데이터 레이크에서 데이터를 미리 수집해 데이터 웨어하우스에 넣어둔다. 데이터 레이크에서 직접 자료를 뽑지만 일부 작업을 통해 성능을 개선했다"라고 말했다.

이때까지만 해도 스테인지-트리기어는 이 BI 인프라는 문제의 해결책이라고 믿었다. 그러나 하둡 클러스터 사용이 증가하면서 새로운 문제가 발생하기 시작했다. 그는 "특정 시점에서 서로 다른 유형의 작업을 같은 기기에서 실행하면 각 작업이 리소스를 두고 경쟁하게 된다. 읽기와 쓰기가 많아지면서 디스크 수준에서 먼저 처리되는 것과 나중에 처리되는 것이 생겨나는 것이다"라고 말했다.

물론 하둡 클러스터의 이런 문제가 발생했을 때 기기를 추가해 처리 능력을 확장할 수 있는 장점이 있다. 그러나 이런 방식으로는 잠시 문제를 '가릴' 뿐 해결할 수는 없다. 스테인지-트리기어는 "가장 큰 문제는 통제와 예측이 불가능한 임시 작업 부하이었다. 누군가 엄청나게 많은 결합이 필요한 작업을 실행하면 ETL 작업 부하, 이메일 예약 전송, 일상 보고 등이 서로 간섭을 일으켜 결국 클러스터가 다운됐다. 오늘날의 하둡 기술이 안정적이다. 그러나 클러스터에 과도한 작업이 들어오면 다운된다. 우리는 하루에도 몇 번씩 이런 상황에 놓였다"라고 말했다.

해결책은 2가지였다. 하나는 작업 부하의 문제가 되는 유형을 찾아 이런 명령을 입력하지 못하도록 제한하는 것이다. 그러나 모두에게 비즈니스 인텔리전스를 제공하면서 이렇게 설정하기는 매우 어렵다. 스테인지-트리기어는 "통제해야 할 사람이 있고 아닌 사람이 있으므로, 이를 완전히 없애는 것은 불가능하다. 아마도 우리 분석팀 중에도 통제해야 할 사람이 있었을 것이다. 따라서 이런 식의 접근보다는 결국 이런 종류의 부하가 언제든 발생할 수 있다는 점을 염두에 두고 해법을 찾고자 했다"라고 말했다.

이 문제를 푸는 2번째 방법은 가트너의 에이드리언이 추천한 것이다. ETL 처리와 임시 쿼리 작업 부하를 일련의 다양한 하드웨어로 분산하는 것이다. 스테인지-트리기어는 "오리지널 버전과는 반대로 사일로화된 데이터 인프라로 회귀한다는 느낌이 들어서 쉽지 않은 결정이었다. 그러나 별도의 ETL 클러스터와 데이터 레이크 클러스터를 통해 과도한 ETL 비용을 들이지 않고도 데이터 작업을 할 수 있게 됐다"라고 말했다.


클라우드의 ETL
분산하는 쪽으로 결정했다고 해도 아직 중요한 의사결정이 남았다. 현재 이베이츠가 직면한 고민이기도 하다. 바로 새로운 온프레미스 하둡 클러스터를 구축할지 아니면 이를 클라우드에 배치할지 결정하는 것이다.

이와 관련해 가트너의 에이드리언은 "때에 따라서는 클라우드가 데이터 레이크보다 더 문제가 될 수 있지만 대부분은 클라우드에 적용하는 것이 더 유리하다. 비용이 카펙스(CapEx)가 아니라 오펙스(OpEx)로 잡히기 때문이다. 전문 업체가 대신 지원, 패치해주는 것도 장점이다 특히 데이터 과학 작업의 경우 연산과 저장을 분리할 수 있다는 것이 클라우드의 매력이다"라고 말했다. 반면 프로덕션 작업의 경우 클라우드의 이점이 그리 명확지 않다. 에이드리언은 "프로덕션 환경은 대부분 복잡하기 때문에 항상 과금 상태가 되고 결국 클라우드의 비용상 이점이 그리 크지 않다"라고 말했다.

실제로 HDFS를 사용하는 클라우드에서 하둡을 잘 쓰지 않는 이유도 바로 비용이다. 야후의 개발, 사용자 데이터, 분석 부사장 출신으로 앳스케일(AtScale)의 설립자 겸 기술 부사장직을 맡고 있는 데이비드 마리아니는 "데이터는 노드 자체에 저장된다. 연산과 저장은 연관돼 있으므로, 이런 노드는 계속 사용 상태이고 과금도 계속 이뤄진다"라고 말했다. 앳스케일이 이 문제를 해결한 방법은 데이터를 아마존 S3에 직접 저장하고 필요에 따라 앳스케일의 미들웨어가 데이터를 끌어오거나 타블로(Tableau) 같은 BI 툴에 연결하는 것이었다.

엣스케일의 이 해법은 이베이츠의 상황에서도 유용할 수 있다. 스테인지-트리기어는 "우리는 온프레미스 솔루션에 프로세서가 내장돼 있으므로, 일단 리포팅 솔루션을 클라우드로 옮기는 것을 검토하고 있다. 여기서 효과가 확인되면 모든 ETL 처리를 클라우드로 옮기는 것도 가능할 것으로 보고 있다"라고 말했다. ciokr@idg.co.kr 
CIO Korea 뉴스레터 및 IT 트랜드 보고서 무료 구독하기
추천 테크라이브러리

회사명:한국IDG 제호: CIO Korea 주소 : 서울시 중구 세종대로 23, 4층 우)04512
등록번호 : 서울 아01641 등록발행일자 : 2011년 05월 27일

발행인 : 박형미 편집인 : 천신응 청소년보호책임자 : 한정규
사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2024 International Data Group. All rights reserved.