데이터 플랫폼 2022: 데이터를 비즈니스 인사이트로 전환하기

쿠팡 데이터 플랫폼의 분석 플랫폼에 대하여 — Part 2

By Youngwan Lim, Michael Sommers, Eddard (Hyo Kun) Park, Thimma Reddy Kalva, Ibrahim Durmus, Martin (Yuxiang) Hu, Enhua Tan

본 포스트는 영문으로도 제공됩니다.

“쿠팡 없이 그동안 어떻게 살았을까?”라는 미션 하에 저희는 모든 중대한 비즈니스 의사결정을 데이터와 통계에 기반해 내립니다. 사소한 앱 피처 변경이든 회사의 운영 전략 상 중요한 결정이든, 데이터를 통한 고객 이해를 바탕으로 합니다. 데이터를 인제스천(ingestion)하고, ML 모델 개발 및 A/B 테스트 수행에 데이터를 활용하는 방법은 이 시리즈의 part 1을 확인해 주시기 바랍니다.

이번 포스팅에서는 쿠팡 데이터 플랫폼의 분석 플랫폼에 대해 설명드리고 미가공 데이터를 비즈니스 인사이트로 전환하는 과정에서 분석 플랫폼이 얼마나 중요한 역할을 하는지에 대해 중점적으로 다뤄보도록 하겠습니다.

목차

· 분석 플랫폼
· Redshift 데이터 웨어하우스
· 하둡 인프라 및 빅데이터
· 고객 경험 분석 플랫폼
· 메타데이터 관리
· 맺음말

분석 플랫폼

그림 1. 분석 플랫폼은 현재 데이터 플랫폼 전체 아키텍처에 있어 핵심적인 구성 요소입니다.

각 팀은 분석 플랫폼으로 데이터를 모으고 발견하고 분석합니다. 데이터로부터 실행가능한 인사이트를 도출해 비즈니스 전략을 수립하고 의사결정을 내리는데 활용합니다. 실험 메트릭 연산, 머신 러닝 모델 개발, 운영 및 경영지표 대시보드, 리서치 및 애드혹 애널리틱스 툴 및 기반 인프라를 제공합니다.

그럼 데이터 웨어하우스, 하둡(Hadoop) 인프라, 고객 경험 분석 플랫폼, 메타데이터 운영 전략을 어떻게 개선했는지 설명드리겠습니다.

Redshift 데이터 웨어하우스

분석 플랫폼은 Amazon Redshift를 매출 및 재무 데이터 웨어하우스로 사용하고 있습니다. 매출 및 중요 비즈니스 지표를 보관하는 웨어하우스이기 때문에 복잡하면서도 정교한 엑세스 및 데이터 애널리틱스가 필요합니다. 또한 프로덕트 카탈로그와 마케팅과 같은 다른 핵심 도메인도 Redshift를 사용합니다.

도전 과제

Redshift의 장점으로는 유지 보수 비용을 최소화할 수 있다는 것과 온보딩을 빠르게 진행할 수 있다는 것이 있습니다. 플랫폼 초기에는 데이터 웨어하우스 솔루션으로서 훌륭한 역할을 해냈지만, 데이터 양과 사용자 질의(query)가 현저히 증가하면서 몇 가지 문제에 직면하게 되었습니다.

• 제한된 동시성 및 대기열(queue). Redshift는 대규모 병렬 처리(MPP) 플랫폼으로 여러 노드로 데이터와 처리 능력이 분산되어 있습니다. 신규 사용자와 유스 케이스를 Redshift 클러스터에 온보딩할 때 잠금 현상 및 퍼포먼스 저하와 같은 문제가 발생했습니다.
• 데이터 공유 불가능. MPP 내 클러스터 간에 데이터가 공유되지 않아, 여러 클러스터에 걸쳐 수많은 잡(job) 복제본을 유지해야 했습니다. 이는 각 클러스터에 많은 부하를 주는 프로세스입니다. 데이터를 처리하고 질의(query)하는데 필요한 리소스를 잡아먹고 딜레이를 발생시켰을 뿐만 아니라, 수많은 원본(source) 및 대상(destination) 클러스터들의 관리 및 운영도 어렵게 만들었습니다.
• 낮은 확장성. Redshift는 스케일 인 & 아웃 측면에서 하둡만큼 유연하지 못합니다. Redshift의 스케일 인 또는 아웃 시, 온콜(on-call) 엔지니어는 실제 엔지니어링보다 사용자와의 소통 및 상태 검사(health check)에 더 많은 시간을 들여야 했습니다.
• 비정형 데이터 관련 지원 부족. 일반적으로 사용되는 정형 또는 비정형 데이터를 Redshift에 연동하기 위해서는 추가적인 처리 작업이 필요했습니다.
• 높은 운영비용. 더 큰 클러스터를 운영해 증가하는 데이터 처리 및 저장 수요를 충족시킬 수도 있었지만 너무 많은 비용이 필요했습니다.

해결 방법

그림 2. Redshift 데이터 웨어하우스는 프로세싱 클러스터와 고객 질의 클러스터로 나누어져 있었습니다.

Redshift의 확장성을 확보하기 위해 프로세싱 클러스터를 세 개로 나누고, 고객 질의 클러스터를 다섯 개로 나누었습니다. 각 클러스터는 데이터 적재 및 사용 시 특정 패턴, 접근 제어(access control)에 맞춰 구성되어 있어클러스터별로 한 가지 질의 유형만 다루게 됩니다. 다양한 잡들이 리소스를 두고 경쟁하는 문제가 줄어듭니다.

세 개의 프로세싱 클러스터 중 하나는 핵심 프로세싱 클러스터이고, 두 개는 일반 프로세싱 클러스터입니다. 일반 프로세싱 클러스터 두 개는 인제스천 플랫폼의 미가공 데이터 추출 및 적재 그리고 경량의 데이터 변형 시 사용됩니다. 핵심 프로세싱 클러스터는 미가공 데이터에 대한 핵심적이고 작업 부하가 큰 변형을 진행하고 변형된 데이터를 데이터 마트에 추가합니다.

고객 질의 클러스터 다섯 대는 경량의 데이터 변형 및 분석 질의를 수행하는 각 도메인별 샌드박스입니다. 예를 들어, 이 질의들은 특정 도메인에 대한 애드혹 분석, 도메인 내에 필요한 추가 변형, 대시보드 작업을 지원하기 위한 반복(recurring) 질의 계산 등을 위해 사용될 수 있습니다.

덧붙여서 모든 클러스터는 Datashare의 활성화를 위해 Redshift RA3 클러스터로 시작됩니다. Datashare를 통해 데이터를 수동으로 복사하거나 이동할 필요 없이 클러스터 간에 즉각적인 데이터 공유가 가능합니다. Datashare 사용으로 인해 추가 비용은 들지만, 클러스터를 물리적으로 복사하는 수고를 들이고 사용자에게 지연시간(latency)이 늘어나는 것에 비하면 합리적인 투자라고 판단했습니다.

마지막으로 Redshift Spectrum에 대한 지원을 추가했습니다. Spectrum을 이용하면 Redshift 테이블에 데이터를 적재할 필요 없이 S3 내 파일에서 정형 데이터 및 비정형 데이터를 효율적으로 질의하고 추출할 수 있습니다.

다음 단계

다음 단계에서는 Redshift 태스크를 EMR 기반 질의로 마이그레이션(migration)해 EMR에서 제공하는 확장성 옵션들을 충분히 활용하고자 합니다. 현재 Redshift 아키텍처는 확장성과 효율성을 해결할 뿐만 아니라 새로운 데이터셋을 순조롭게 온보딩하고 Redshift 프로세스를 EMR에서 Spark 기반 오퍼레이션으로 마이그레이션할 수 있도록 디자인되었습니다.

원활한 마이그레이션을 위해 Redshift 사용자 대상 교육 및 온보딩 세션을 여러 차례에 걸쳐 제공하고 있습니다. EMR 기반 데이터 마트 작업을 진행 중에도 S3에 저장된 데이터로 모든 Redshift 유스 케이스를 여전히 지원하고 있으며, 기존의 모든 Hive 프로세스도 Spark로 이관해 Spark 생태계의 장점을 활용할 예정입니다.

하둡 인프라 및 빅데이터

하둡 생태계는 지난 몇 년간 빅데이터 분야에 있어 확실히 눈에 띄는 트렌드입니다. 쿠팡 데이터 플랫폼에서 하둡은 EMR을 사용하며, 검색 랭킹 및 추천, 머신러닝 피처 스토어, 실험 메트릭 등의 데이터를 지원합니다.

도전 과제

견고한 하둡 인프라를 구축하기 위해 다음과 같은 몇 가지 과제들을 해결해야 했습니다.

• 까다로운 SLA 요구사항. 비용 절감을 위해 EMR 스팟 노드를 사용하고 있습니다. 하지만 사용량 피크 시간대에는 스팟 인스턴스가 중단되는 EMR 스케일링 문제가 발생했습니다. 따라서 엔터프라이즈 데이터 웨어하우스는 99.9%의 SLA 데이터 도착시간(landing time)을 지키기 어려웠습니다. 유스 케이스에 심각한 영향을 미쳤으며, 대규모 백필을 진행하거나 적시에 업데이트되지 않은 데이터셋으로 의사결정을 내리는 일이 발생했습니다.
• 제한적인 병합(upsert) 및 삭제(deletion) 기능 지원. 데이터 병합 및 삭제는 많은 쿠팡의 사용자가 필요로 하는 중요한 기능입니다. 중복 데이터를 제거하고 고품질의 다차원 데이터 분석에 있어 필수입니다. 하지만 제네릭한 하둡 시스템은 upsert와 deletion을 지원하지 않아 저희 요구사항을 충족시키지 못했습니다.
• 비정형 데이터와의 부적합성. 초기에는 EMR에서 Hive를 주요 플랫폼으로 사용하였습니다. 그러나 Hive는 상기 유스 케이스의 비정형 데이터 처리에 이상적인 선택지가 아니었으며, Spark를 더 많이 쓰게 되었습니다.
• 낮은 확장성. 데이터 로깅의 평상시 수치가 전년 대비 3배 증가했습니다. 여러 스토리지로 저장되는 데이터셋과 처리되는 잡의 규모가 두 배로 불어났습니다. 플랫폼 내 여러 대규모 하둡 클러스터에 각기 다른 버전의 Spark가 구동되고 다른 기술이 적용되어 있다보니, 클러스터마다 상이한 문제가 발생했고, 단일한 스케일링 솔루션은 없었습니다. 또한 더 나은 확장성을 원했지만, 비용 증가는 피하고자 했습니다.

해결 방법

그림 3. 하둡 추상 계층을 통합해 최종 사용자의 데이터 분석을 용이하게 만들었습니다.

사용자 니즈와 여러 인사이트를 분석한 후, 하둡 추상화 계층에 오픈 소스 프로젝트를 적용해 보았습니다.

이 추상화 계층은 간단하게 EMR 잡을 제출할 수 있는 인터페이스를 제공하며, 중앙화된 모니터링 및 관리 시스템을 통해 잡 요구사항에 맞는 자동 스케일 아웃(scale-out)을 실행합니다. 덕분에 사용자들은 하둡 또는 EMR 유지 보수에 신경쓸 필요 없이 Airflow 오퍼레이터, Python, 또는 REST API를 통해 몇 분내로 대규모 Hive 및 Spark 잡을 수행할 수 있게 되었습니다.

하둡 추상화 계층은 작업방식을 3가지 측면에서 개선하였습니다. 빅데이터 EMR 잡 제출을 단순화하고, 사용자를 위한 데이터 클러스터의 물리적 세부사항을 추상화하고, 하둡 클러스터의 수를 늘리지 않고도 스케일링할 수 있게 되었습니다.

고객 경험 분석 플랫폼

매일 인제스천되는 데이터의 상당 부분은 임프레션, 전환율 등 사용자 행동 데이터입니다. 이 데이터로부터 비즈니스 관련 핵심 질문, 프로덕트에서 가장 많이 사용되는 부분은 무엇인지, 그리고 어떤 고객 유형이 유지율(retention rate)이 높은지 등에 대해 답할 수 있는 인사이트를 도출하기 위해, 데이터 플랫폼팀은 데이터 포인트를 인사이트로 전환하는 커스텀 파이프라인을 수동으로 구축하곤 했습니다.

도전 과제

그러나 유스 케이스와 데이터량이 지속적으로 증가하다보니, 팀별로 커스텀 파이프라인을 구축해주는 방법은 시간이 너무 많이 소요되었습니다. 셀프 서비스 모델로의 전환이 필요했습니다.

목표는 내부 고객의 생산성을 제고하고, 인사이트 도출 시간을 단축하며, 표면적 분석과 복잡한 분석을 위해 SQL문을 최소화하는 것이었습니다. 표면적 분석에는 노출 횟수와 클릭스루(clickthrough) 메트릭이 포함되고, 복잡한 분석에는 고객 여정 분석과 전환율 또는 클릭스루 퍼널이 포함됩니다.

해결 방법

그림 4. Intro 페이지에서 home_today_recommendation과 나머지 세 개 레벨까지의 사용자 여정을 보여주는 Sankey 다이어그램에 대한 CXAP 비주얼라이제이션.

이를 위해 저희는 고객 경험 분석 플랫폼(CXAP, Customer Experience Analytics Platform)을 구축하였습니다. CXAP는 내부 사용자가 이벤트 로그 데이터의 클라이언트 쪽에서 다양한 분석을 수행할 수 있도록 돕는 셀프 서비스 분석 포탈입니다. 사용자는 단순한 인터페이스와 여러 가지 시각화 옵션을 이용하여 간단하게 한두 번의 클릭만으로 고객의 여정, 퍼널 그리고 트렌드를 추적할 수 있습니다.

또한 데이터 분석까지 몇 시간이나 걸리던 대기 시간을 몇 분 수준으로 단축하기 위해 CXAP 질의 백엔드를 ClickHouse로 마이그레이션했습니다. 이전 시스템은 1–4 시간의 리프레시 스케줄 지연이 있었으나, ClickHouse로 아웃풋 데이터 준비 시 몇십 초 내에 데이터 인제스천을 할 수 있게 되었습니다. 데이터 시각화 개선을 위해 다양한 차트를 짧은 렌더링 지연시간(latency)으로 지원하는 Apache Superset를 연동하였습니다.

위와 같은 업그레이드 후 셀프 서비스 툴을 채택한 사용자 수가 40% 증가했고, 이는 CXAP의 고객 경험이 개선되었음을 입증했습니다.

메타데이터 관리

사업의 초고속 성장과 함께 다양한 시스템에 테이블이 무수히 많이 생성되었습니다. 그러다보니 데이터 분석가와 엔지니어들은 자신이 필요로 하는 메타데이터 정보를 찾기 위해 많은 수고를 들여야했습니다. 찾아낸 정보가 유효한 정보인지 확신하기도 어려웠습니다. 이는 쿠팡의 모든 테이블을 검색할 수 있는 시스템에 대한 수요로 이어졌습니다.

도전 과제

사용자가 메타데이터를 검색할 수 있는 시스템은 기존에도 있었으나, 사업 초기 단계에 개발된 것이었고, 여러 신규 시스템의 특성을 반영하지 않았습니다.

일반적인 RDBMS가 테이블의 스키마 정보 확인에 초점을 두는 반면, Hive는 Hive 메타스토어를 통해 테이블 스키마 정보를 관리하고 분산 파일 시스템에 데이터를 저장합니다. Hive의 효율적 사용을 위해 사용자들은 테이블 스키마 정보 외에도 데이터의 물리적 위치 또는 파일 포맷과 같은 추가 정보를 검색하고 조회할 수 있는 기능을 원했습니다.

해결 방법

그림 5. 메터데이터 관리와 검색을 용이하게 해주는 쿠팡 데이터 디스커버리 툴의 아키텍처입니다.

데이터 플랫폼팀은 위와 같은 사용자 요구사항을 반영한 새로운 데이터 디스커버리 툴을 재런칭하였습니다. 이 툴로 쿠팡의 데이터 분석가 및 엔지니어들은 메타데이터, 데이터 계보(lineage), 데이터 신선도(freshness), 데이터 도착시간(landing time) 등을 빠르게 찾아낼 수 있습니다. 또한 이 데이터 디스커버리 툴은 다양한 시스템의 메타데이터를 자동으로 수집합니다. 시스템 정보가 제대로 등록되어 있으면, 1시간 내로 메타데이터가 자동 수집되어 사용자에게 제공됩니다.

이 신규 툴은 매일 같이 천 개 이상의 테이블에서 정보를 검색하는 약 100여명의 사용자를 지원하게 되면서, 가장 인기 있는 피처들 중 하나가 되었습니다.

맺음말

분석 플랫폼에 대한 여러 개선 작업을 통해 더 많은 양의 데이터 분석을 그 어느 때보다 더 빠른 속도로 지원할 수 있게 되었습니다. 수백 명의 사용자가 분석 플랫폼에 접속해 가공되지 않은 데이터를 가치있는 인사이트로 변환해 초고속 사업 성장의 원동력으로 삼고 있습니다.

“쿠팡 데이터 플랫폼 2022” 시리즈의 첫번째 이야기를 읽어보시면, 저희 데이터 플랫폼이 어떻게 데이터를 인제스천하고 머신러닝 모델을 개발하고 A/B 테스트를 수행하고 있는지도 확인하실 수 있습니다.

쿠팡은 복잡한 빅데이터 이슈 해결에 도움 주실 창의적인 엔지니어를 항상 찾고 기다립니다, 저희 채용 페이지를 참고해 주세요.