쿠팡은 라스트 마일 배송과 모바일 퍼스트 플랫폼에서 고객이 상품을 발견하는 새로운 방식을 선사함으로써 한국의 이커머스 시장을 혁신하고 있습니다. 쿠팡의 미션은 고객이 “쿠팡 없이 그동안 어떻게 살았을까?”라고 생각하는 세상을 만드는 것입니다.
쿠팡은 데이터 중심 회사입니다. 고객이 상품을 구매하는 모든 순간을 데이터에 기반해 설계합니다. 고객에게 최고의 경험을 제공하려는 이같은 노력은 물류센터 공간 최적화 알고리즘 등 쿠팡의 모든 영역 구석구석에 적용되고 있습니다. 쿠팡은 데이터를 이용해 각 프로세스 단계별 병목을 찾아내서 빠르게 처리합니다. 규모, 가용성, 레이턴시, 동시성, 빠른 데이터 성장이 항상 요구되는 다이내믹한 환경 속에서 탁월함을 일관성 있게 유지하기 위해 지속적으로 데이터 플랫폼을 발전시켜 왔습니다.
이제 쿠팡의 데이터 플랫폼이 지금까지 밟아온 여정과 앞으로의 로드맵을 설명하겠습니다.
Phase I — 초창기 (2010–2013)
쿠팡은 다른 스타트업 기업과 마찬가지로 관계형 데이터베이스에서 데이터를 처리했습니다. 쿠팡이 데이터 사이언스 플랫폼 팀에 투자하기로 결정하면서 초창기 발전이 이루어지기 시작했으며, 이 팀은 빠른 비즈니스 진행이 가능하도록 데이터 트렌드 파악과 데이터 사이언스 실험을 전담했습니다. 데이터 세트와 비즈니스 리포트 규모가 크지 않았을 때는 이 모델에 큰 문제가 없었습니다.
당시는 대형 기술 기업이 데이터에 적극적으로 투자하면서 ‘규범으로서의 데이터(data as a discipline)’가 각광받던 시기입니다. 더불어 데이터에 기반한 비즈니스 의사 결정과 애플리케이션 및 서비스가 주목받고 있었습니다.
하지만 고객과 BI 쿼리가 많아지자 속도와 규모가 문제가 되었고, 관계형 데이터베이스보다 높은 차원의 데이터베이스가 필요했습니다.
Phase II — 온프리미스 하둡, 하이브, MPP 시스템 시대 (2014–2016)
쿠팡은 빠르게 성장하던 과정에서 빅데이터 및 데이터 웨어하우스 분야에서 잘 알려진 데이터 인프라인 하둡(Hadoop)과 MPP(Massively Parallel Processing) 시스템에 투자를 결정했습니다. 이 시기에 쿠팡 내에 고도화된 팀들이 상당수 생기면서, 단순히 비즈니스 보고를 위한 데이터에 초점을 맞추고 있었던 과거와는 다르게, 각 팀에서 핵심 지표를 주별로 측정하고자 하는 수요가 생겨났습니다. 이렇게 조직 별로 주간 비즈니스 리뷰(WBR; Weekly Business Review)를 가지는 문화가 활성화되면서, 데이터 기반 애플리케이션이 함께 개발됐습니다. 이는 회사 전반적으로 데이터 생산과 수요가 늘어났다는 점에서 중요한 계기가 됐습니다. 쿠팡의 앱과 웹사이트에서 고객 행동을 로깅하고 수집해야 하는 수요가 생겼고, 동시에 빅데이터 인프라 역시 그렇게 수집된 데이터를 처리하여 이를 다양한 검색, 추천, 고객 분석의 시그널로 활용하게 해야 했습니다. 로그를 수집하는 팀이 생겨났고, 이들이 고객의 행동 데이터를 수집하면서, 로깅 프로세스가 크게 개선됐습니다.
그런데 일일 사용자수(DAU; daily active user) 수와 쿼리 수가 다시 10배 이상 늘어나자, 동시에 처리할 수 있는 쿼리가 제한된 MPP 같은 시스템이 병목으로 작용하기 시작했습니다. 하이브(Hive)와 MPP 시스템은 아침 8시부터 낮 12시까지만 버틸 수 있었습니다. 발목을 잡는 또 다른 근본적인 문제는 하나의 하드웨어가 운영 레포트, 비즈니스 인텔리전스, ETL, 데이터 사이언스 등 다양한 수요를 커버한 점입니다. 데이터를 필요로 하는 전사 직원이 찾는 데이터 창구가 사실상 단 하나만 존재하는 셈이었고, 많은 사람이 사용에 불편을 느끼면서 가장 중요한 쿼리는 아침 일찍 혹은 늦은 밤에 돌리는 방식으로 대처해야만 했습니다. 물론 이 과정에서 흥미로운 문제점들이 다수 발견되었고 데이터 팀으로서 개선할 수 있는 여지도 많았습니다.
그런데 온프레미스 환경에서는 클러스터에 노드를 추가하기가 쉽지 않았습니다. 많은 엔지니어링 작업과 프로세스 기반 기술이 적용되어 일시적인 해소가 가능하기도 했지만, 데이터 인프라는 항상 과부하를 겪고 있었습니다. 모든 것이 빠르게 움직이는 스타트업에서는 데이터 사이언스, 비즈니스 인텔리전스, 데이터 기반 애플리케이션 등 다양한 영역에서 새로운 용도가 지속적으로 발생하기 마련이었고, 이 모든 것들은 새로운 버전의 데이터 플랫폼을 필요로 했습니다.
Phase III — 재설계와 마이그레이션, 장기적 해결책 (2016–2017)
2016년 말부터 2017년까지, 팀에서는 데이터 플랫폼의 확장을 지원할 수 있도록 플랫폼을 재설계하였습니다. 클라우드 인프라를 사용해서 다양한 레이어를 재구축하였습니다. 모든 측면에서 10배, 아니 20배 성장을 지원할 수 있도록 클라우드로 마이그레이션을 하고, 기본 컴포넌트를 새롭게 구축하였습니다.
이 당시 사내에서 데이터 플랫폼에 제기된 주요 요구 사항 중 일부를 소개하고자 합니다. 새로운 요구사항은 장기적인 미래를 준비하는데 강력한 동력으로 작용하였습니다.
이커머스 플랫폼의 트래픽 대부분은 검색에서 시작되며, 이런 환경에서 고객 행동 데이터를 취합하면서 동시에 이를 트랜잭션, 카탈로그, 가격, 실험 데이터와 함께 처리 가능할 수 있도록 데이터 인프라가 견고하면서 안정적이어야 합니다.
수백 명의 비즈니스 담당자들이 매일 수천 개의 쿼리를 실행할 수 있어야 합니다.
A/B 테스트 및 프라이싱 플랫폼에서는 빅데이터를 필요로 합니다.
파이낸스와 글로벌 오퍼레이션 비즈니스 팀은 이기종 데이터(heterogenous data) 조인(join)이 필요합니다.
마케팅 팀은 소셜 미디어 데이터 통합이 필요합니다.
이러한 요구사항을 바탕으로 다음과 새로운 레이어를 구축했습니다.
▸ 로그 수집: 모바일 앱들과 웹사이트에서 고객의 상호작용 데이터를 수집하는 것은 근래 이미 일반화된 전략입니다. 여기서 더 나아가 사용자 행동 로그들을 수집하고 처리하여 다양한 고객 인사이트를 얻을 수 있도록 해주는 차세대 데이터 수집 프레임워크의 구축에 주목하였습니다.
▸ 빅데이터 플랫폼: 하둡 및 컨테이너 기반의 다른 빅데이터 툴과 컴포넌트를 이용하여, 고객이 대규모 데이터를 처리할 수 있게 하며, 또한 증가하는 컴퓨팅 수요에 발맞춰 플랫폼을 확장할 수 있도록 하였습니다.
▸ 엔터프라이스 데이터 웨어하우스 (EDW): 클라우드 기반의 MPP 시스템에서 스타 스키마가 사용되는 것과 같이, EDW는 올바른 데이터 모델링 패턴으로 클러스터를 재구축했습니다. 데이터 웨어하우스 클러스터는 다음과 같이 세 가지 종류로 구성됩니다.
데이터 수집 플랫폼: 원천 데이터셋을 필요로 하며 수시로 실행되는 쿼리, 운영 리포트, 그리고 시스템 애플리케이션들에 사용되는 트랜잭션 데이터들은 DAP(Data Acquisition Platform)라고 명명된 클라우드 데이터 웨어하우스에 저장합니다.
샌드박스: 수많은 팀이 자체적으로 테이블과 스테이징 데이터 셋을 생성하여 그때그때 필요한 분석을 하고자 합니다. 우리는 특정 팀이 요구하는 데이터 셋에 중점을 둔 샌드박스를 제공합니다.
리포팅: 사용자가 데이터를 조회하기 위해 사용하는 클러스터입니다. 모든 프로덕션 데이터는 이 클러스터를 통해 접근할 수 있습니다.
새로운 플랫폼은 확장 가능하고 쉽게 사용할 수 있었으며 고객의 불편도 거의 없었습니다. 하지만 사용자 쿼리의 동시성, 커넥션 개수, 데이터 카피, 맵리듀스와 DW의 확장, 스토리지와 연산의 디커플링, 로깅 데이터 품질에 대한 신뢰와 같은 격차가 존재했습니다.
▸ 빅데이터 도전과제: 많은 팀이 각자 자기만의 클러스터를 가지고 싶어해서, 하둡 클러스터가 과도하게 생성됐습니다. 비효율적으로 데이터 처리를 처리하는 잡 때문에 클러스터 운영이 어려웠고, 유휴 클러스터의 유틸라이제이션 효율성도 이슈가 됐습니다.
▸ 로깅 데이터 품질 신뢰: 비즈니스가 급성장하고 민첩하게 진행되는 앱과 웹 개발로 인해 레거시 데이터 수집 플랫폼 내에 명확한 세부 명세가 존재하지 않는 다수의 로그들이 앱과 웹페이지에서 만들어졌습니다. 미처 인지하지 못하고 진행되는 변경사항들과 감지되지 못한 버그들로 인해 고객 메트릭이 손상되는 일이 빈번했으며, 데이터 품질 자체에 대한 신뢰가 위협받았습니다. 새로운 데이터 수집 프레임워크는 그 결과물의 안정성과 메타데이터의 견고함에 대해 프로듀서와 컨슈머들로부터 신뢰를 얻을 수 있도록, 처음부터 새롭게 구축해야만 했습니다.
Phase IV — 서비스형 빅데이터, 클라우드 스토리지를 사용하는 EDW, 완전히 새로운 데이터 수집 프레임워크 (2018~2019)
2019년에 이르자 데이터 플랫폼에 대한 이해가 깊어지고 규모가 확대되어 다양한 비즈니스 사용 케이스 및 시나리오에 확장할 수 있게 진화됐습니다. 진화된 데이터 플랫폼이 지원하는 몇 가지 흥미로운 사례를 설명하겠습니다.
빅데이터 플랫폼 : 빅데이터팀은 그동안 여러 종류의 롱 러닝 하둡 클러스터를 운영해 왔지만, 폭발적인 사업 성장을 뒷받침하기 위해 클러스터 관리 정책 및 배포 전략을 대폭 수정해야만 했습니다. 고객을 위해서 더욱 안정적이고 확장 가능한 플랫폼을 제공할 수 있도록 머신 이미지를 미리 빌드했으며, 컴퓨팅 리소스 특성에 맞춘 다양한 최적화, 유연한 스케일링 정책, 클러스터 추상화 레이어 추가 등 다양한 분야를 개선했습니다.
클러스터 라이프사이클 : 고객의 워크로드를 기반으로 다양한 라이프 사이클을 지원하는 하둡 클러스터를 제공합니다. 각 클러스터의 라이프 사이클은 비용 효율 및 비즈니스 작업량에 따라 엄격히 관리됩니다. 이러한 클러스터는 공용 하이브 메타 스토어와 클라우드 저장소에 접근하기 때문에, 모든 고객은 동일한 하이브 테이블을 일관성 있게 사용할 수 있습니다.
스케일링 정책: 대부분의 클라우드 플랫폼에서는 시스템 지표에 따라 오토 스케일링 (Auto-scaling)을 처리합니다. 빅데이터팀도 처음에는 클라우드 서비스에서 제공하는 오토 스케일링을 사용했지만, 실제 고객의 필요를 충족시키기엔 부족했습니다. 그래서 트래픽이 집중되는 시간대를 분석한 후 해당 시간에 앞서 미리 확장할 수 있도록 해주는 스케줄 기반의 스케일링 기능을 적용했습니다. 스케줄 기반의 스케일링 기능과 오토 스케일링 기능을 조합하여 사용한 덕분에 고객의 플랫폼 경험이 크게 개선됐습니다.
머신 이미지 사전 빌드: 하둡 클러스터용 컴퓨팅 서버에는 OS를 포함한 다양한 소프트웨어와 하둡 에코시스템, 모니터링과 보안 에이전트가 설치됩니다. 빅데이터팀은 이러한 소프트웨어와 다양한 플러그인을 탑재한 서버 이미지를 미리 빌드합니다. 고객의 워크로드에 따라서 다양한 머신 이미지를 제공하며, 머신 이미지는 오픈소스Packer로 관리 합니다. 참고로 머신 이미지를 도입한 후, 하둡 클러스터 설치 시간이 60% 이상 단축됐습니다.
웹 로깅 플랫폼 : 쿠팡 초기 고객의 상호작용 데이터를 수집하는 플랫폼은 외부 솔루션을 기반으로 구축되었으나, 이 플랫폼에는 결함도 많고 기능도 부족했습니다. 그래서 많은 도메인 팀에서 메트릭을 집계하고 시각화하기 위해 또 다른 외부 서비스를 이용해야 했습니다. 이러한 문제를 근본부터 해결하기 위해 새로운 프레임워크를 구축했습니다. 장기간에 걸쳐 마이그레이션과 데이터 검증이 이뤄진 후, 신규 로깅 플랫폼이 레거시 로깅 플랫폼을 완전히 대체했습니다.
여기서 잠시, 로그의 여정에 대해 간략히 살펴보겠습니다. 시작하기에 앞서, 프로듀서가 메타데이터 서비스에 스키마를 등록합니다. 사람이 만들어내는 오류를 방지하기 위해 대개 스키마로부터 (정적 타이핑) 코드를 생성한 이후 해당 코드를 앱 또는 웹페이지에 넣어 줍니다. 앱이 릴리즈된 후, 클라이언트는 실제 로그를 생산하여 수집 파이프라인에 보냅니다. 수집 서버는 파이프라인 상에서 모든 로그를 받아 메시지를 생산한 후 메시지 큐로 보내고, 컨슈머가 작성한 다운스트림 잡을 위해 데이터 로더가 메시지들을 읽어들여 클라우드 저장소에 저장합니다. 이 데이터의 첫 컨슈머인 세션 배치 잡은 세션 구분 및 속성들이 추가된 세션 데이터 테이블을 생성하여 일반적인 배치 컨슈머들을 위한 표준 데이터를 제공합니다.
수집 파이프라인(수집 서버, 메시지 큐 및 데이터 로더): 쿠팡 플랫폼 서비스 팀에서 관리하는 메시지 큐 서비스를 이용, 실시간 컨슈머를 위한 실시간 데이터 스트림 및 배치 컨슈머를 위한 준 실시간 데이터를 손실, 중복 및 오염 없이 제공합니다. 컨슈머들은 또한 메시지 큐에 직접 접근하여 자체 SLA 및 ETL 로직을 구현한 로더를 직접 작성할 수도 있습니다. 배치 파이프라인은 실시간 파이프라인으로 적재된 로그 데이터를 이용하여 구현합니다.
메타데이터 서비스: 모든 로그 데이터에 스키마가 등록되어 있어야 하며 스키마 변경을 검토하고 알림을 받을 오너 및 컨슈머 정보가 있어야 합니다. 로그 데이터 구조에서 이 단일 데이터 소스(single source of truth)는 다른 서비스, 프로듀서의 UI 코드 및 컨슈머 쿼리의 근간이 됩니다.
로그 검증 서비스: 플랫폼상의 데이터 전송을 방해하지 않으면서 메타데이터 서비스에 있는 스키마를 토대로 파이프라인상의 모든 로그를 확인합니다. 모든 결과는 저장되고 해당 로그의 프로듀서 및 컨슈머에게 주기적으로 리포팅 되며 실시간으로 알림이 발송됩니다.
모니터링 및 테스팅 서비스 : QA 테스팅 및 프로덕션을 위해 실시간으로 모든 지정된 사용자나 디바이스의 로그를 추적 및 검증하기 위한 서비스가 제공되며, 사용자들은 구문 뿐만 아니라 의미까지 확인하기 위한 시나리오 기반 검증 기능을 사용할 수 있습니다.
엔터프라이즈 데이터웨어하우스(EDW): 데이터 플랫폼의 주요 데이터 웨어하우스 환경은 ORC 파일이며 하이브/휴(Hive/Hue), 프레스토/제플린(Presto/Zeppelin)을 통해 접속할 수 있습니다. 여전히 EDW 고객에게 MPP 기반의 샌드박스가 제공되지만 이는 EDW의 일부분에 불과합니다. 주요 기능은 고객이 프로덕션에 앞서 샌드박스 테이블을 빌드 하고 이를 통해 도메인 비즈니스를 관리할 수 있는 환경을 제공하는 것입니다. 더불어 고객의 샌드박스 테이블이 리포팅에 필요할 경우, 이 환경에서 단기적인 리포팅을 할 수 있다. 다만 장기간 리포팅을 하거나 공유해야 할 경우, 사용자가 관리하는 테이블을 클라우드 스토리지 기반의 테이블로 이관할 것을 권장합니다.
서브 컴포넌트
이번에는 쿠팡의 데이터 플랫폼에 포함된 다른 주요 기능에 대해서 소개하겠습니다.
데이터 품질
데이터 팀은 데이터 정확성 보장을 위해 열(row)의 HASH를 사용하여 전체 열 데이터와 열의 개수를 비교해주는 프레임워크를 구축했습니다. 기술적 테스팅의 일환으로, 프라이머리 키(primary key)와 빈 값(null value) 등의 DQ 체크도 실행합니다. 해당 프레임워크는 개발자의 비즈니스 관련 SQL 구문 플러그인을 지원할 뿐 아니라, 실제와 동일한 데이터 정확성도 제공합니다. 특히 빅데이터 테이블의 경우에는 제약사항 처리 및 임계치 기반의 데이터 확인을 위해 오픈소스 프레임워크도 활용하고 있습니다.
데이터 이상 알림 서비스
기술이 급변하는 추세에 발맞춰 우리도 빠르게 움직여야 했습니다. 데이터 알림 서비스 (Data Notifier)는 데이터 입력된 직후 가능한 최단 시간 내 이상 현상을 감지하여 알려 줍니다. 예를 들어, 지난달 신규 버전 안드로이드 앱이 출시되었는데 로그 기록에 버그가 발생하여 데이터가 유실되었다고 가정합니다. 과거에는 이러한 이상 현상을 감지하려면 고객이 앱을 설치할 때까지 기다려야 했기 때문에 데이터 유실을 알아채기까지 3일이 걸렸습니다. 하지만 데이터 이상 알림 서비스를 통해 앱 릴리즈로부터 2시간 내로 이상 감지가 가능하게 됐습니다.
SLA (Service Level Agreement)
신규 데이터 플랫폼에서는 매일 한국 시간 오전 9시에 데이터 마트 테이블의 준비 완료 여부가 고객에게 이메일로 공지합니다. 추가로 데이터 SLA 투명성 제고를 위해 데이터 플랫폼 사용자들이 SLA에 관한 정보를 쉽게 읽을 수 있도록, 가독성 높은 온라인 보고서도 개발 중에 있습니다.
데이터 디스커버리 툴
데이터 플랫폼의 테이블/칼럼에 관한 태그 및 설명을 등록할 수 있는 플랫폼으로, 다른 고객이 이를 검색 및 조회할 수 있으며 유기적 성장이 가능한 오픈 플랫폼입니다. 데이터 디스커버리는 쿠팡의 모든 데이터 고객이 자체적으로 데이터 발견(discovery)을 할 수 있도록 해주었고, 해당 기능을 통해 데이터를 찾는 수백 명의 사용자는 한층 편리해진 데이터 라이프와 향상된 생산성을 누릴 수 있게 됐습니다.
EDW 관리 시스템 (EMS)
데이터 파이프라인의 생성 및 관리, 데이터 수집 자동화 그리고 메타데이터를 사용한 자동화된 Airflow DAG 생성을 지원하는 프레임워크입니다. 이 프레임워크는 데이터 엔지니어가 필요한 모니터링, 재적재(backfill) , 다운스트림 디펜던시 기능을 지원합니다. 또한, EMS는 온콜 엔지니어를 위해 초기 SLA 감지 기능도 제공합니다.
향후 개선 과제
하둡 추상화 레이어
고객의 배치 잡 등록 및 하둡 클러스터 관리를 간소화해주는 하둡 추상화 레이어를 제공할 예정입니다. 이 서비스는 다양한 하둡 리소스에 대한 물리적인 세부 항목을 추상화해주기 때문에, 고객은 더 이상 복잡한 하둡 설정이나 디펜던시를 관리할 필요가 없습니다. 고객은 심플한 인터페이스를 통해서 필요한 버전과 컴퓨팅 리소스에서 하이브와 스파크 잡을 실행할 수 있습니다.
로그 품질 모니터링
여러 가지 이유로 인해 앱의 로깅 패턴은 릴리즈 이후에도 변화할 수 있습니다. 예를 들어, A/B 테스트로 인해 어떤 기능이 나중에 작동하기 시작할 수 있습니다. 도메인 API의 변경으로 클라이언트에 부작용이 발생할 수 있고, 웹으로 구현된 일부 뷰(View)에 언제든 새로운 배포가 진행될 수도 있습니다. 로그 데이터 품질을 보장하기 위해서는 릴리즈 단계의 QA 테스트만으로는 부족합니다. 이에 대한 해결책으로 완전한 기능의 로그 품질 모니터링 서비스를 제공할 예정입니다. 해당 서비스를 통해 릴리즈 이후에도 실제 디바이스에서 중요한 모든 로그 테스트를 완전 자동화 기반으로 실행할 수 있습니다. 더 나아가, 품질 모니터링 시스템은 클라이언트에서 생성하지 않고, 로그 파이프라인의 속성 품질을 확인해 데이터에 대한 신뢰성을 한층 높여줄 것입니다.
로그 스키마 디스커버리
메타데이터(Metadata) 서비스는 모든 로그 스키마에 대한 단일 데이터 소스(Single Source of Truth)입니다. 로그 스키마는 일종의 프로듀서와 컨슈머 간 계약으로, 이는 로그 데이터 신뢰성의 기반이 됩니다. 그러므로, 모든 컨슈머는 각 로그 스키마의 모든 변경사항에 대해 공지를 받아야 하고, 새로 등록된 스키마에 대해 프로덕션 배포 전 검토를 진행하고, 컨슈머 자신의 다운스트림 잡을 준비해야 합니다. 그러나 메타데이터 서비스에서는 검색 및 구독 작업이 수동으로 진행되고, 컨슈머가 프로덕션 전 검토해야 하는 신규 스키마 구독을 잊게 되는 경우가 일반적입니다. 이에 로깅 플랫폼 팀에서는 자동화 기반 스키마 디스커버리 툴을 제공할 예정입니다. 이 툴은 컨슈머 쿼리를 수집/분석하며, 이를 바탕으로 컨슈머가 필요로 하는 모든 스키마를 찾아, 사용자의 개입 없이 스키마 구독 업데이트를 자동화하게 됩니다. 이러한 정확한 등록 과정은 로그 품질 신뢰성의 핵심 기반이 될 것입이다.
저자:
Narendra Parihar, Matthew (정재화), Joong (김중훈)
별첨
쿠팡의 데이터 플랫폼 조직은 위와 같이 거대하고 복잡한 플랫폼이 전사적으로 동작할 수 있도록 여러 영역으로 구성되어 있습니다 : Big Data Platform, Enterprise Data Warehouse, Web Logging Platform, Technical Program Management
데이터 플랫폼의 비전은 신뢰할 수 있고 확장 가능하며 걱정 없이 사용할 수 있는 툴을 제공, 대규모로 데이터를 관리, 처리 및 시각화할 수 있도록 하는 것입니다. 내부 고객이 이와 같은 툴을 자발적으로, 믿음을 바탕으로 도입하게 되어야 하며 이를 통해 대규모 데이터 애플리케이션을 수월하게 구축하고 촉박한 시간 내 빠르게 이루어지는 결정을 포함하는, 데이터 중심 의사결정을 진행할 수 있어야 합니다.
데이터 플랫폼팀은 현재 다양한 포지션을 채용하고 있습니다. 자세한 공고는 이 사이트에서 확인하실 수 있습니다.
가입하기
