데이터 플랫폼 2022: 페타바이트 규모의 글로벌 확장
쿠팡 데이터 플랫폼의 데이터 인제스천(Ingestion), 머신 러닝, A/B 테스트 플랫폼 — Part 1
By Youngwan Lim, Michael Sommers, Eddard (Hyo Kun) Park, Thimma Reddy Kalva, Ibrahim Durmus, Martin (Yuxiang) Hu, Enhua Tan
본 포스트는 영문으로도 제공됩니다.
쿠팡은 매년 수백만 개의 상품을 로켓 속도로 배송하고 있으며, 커져가는 고객 규모에 맞춰 계속 성장해나가고 있습니다. 익일 배송과 같이 비지니스의 판도를 바꾸고 있는 쿠팡의 놀라운 서비스들 뒤에는 전세계 각지의 쿠팡 최고 엔지니어들에 의해 꾸준히 진화하고 있는 복잡한 데이터 플랫폼이 자리하고 있습니다.
목차
· 데이터 플랫폼 2022
· 인제스천 플랫폼
· ML 플랫폼
· A/B 테스트 플랫폼
· 맺음말
데이터 플랫폼 2022
쿠팡 데이터 플랫폼의 비전은 대량의 로우(raw) 데이터를 빠른 속도로 변환해 중요한 의사 결정을 가속화할 수 있는, 견고하고 사용자 친화적인 분석 도구를 제공하는 것입니다. 데이터 플랫폼의 사용자는 엔지니어부터 비즈니스 분석가, C-레벨 임원 등 쿠팡 50여개 팀 내 다양한 직군의 직원들과 공급업체, 광고주와 같은 외부 사용자까지 그 범위가 매우 넓습니다.
이미 눈치채셨겠지만, 쿠팡 데이터 플랫폼은 수백 명의 사용자가 페타바이트 규모의 데이터를 처리할 수 있도록 만들어졌습니다. 플랫폼은 매일 5천 건 이상의 잡(job)을 처리하고, 70개 정도의 각기 다른 소스에서 2TB 이상의 데이터를 추출합니다. 쿠팡의 계속되는 성장과 확장에 따라 이러한 작업량은 앞으로 몇 배 더 증가할 것으로 예상됩니다.
이번 포스팅에서는 데이터 인제스천(ingestion)과 머신 러닝(ML), A/B 테스트 플랫폼을 중심으로 2019년 이후 쿠팡 데이터 플랫폼의 진화를 살펴보겠습니다. 다음 편에서는 분석 플랫폼을 자세히 다룰 예정이니 많은 관심 부탁드립니다.
인제스천 플랫폼
먼저 인제스천 플랫폼을 소개하겠습니다. 인제스천 플랫폼은 데이터 소스와 데이터 플랫폼 사이의 게이트웨이입니다. 다양한 데이터 소스의 각기 다른 스키마를 단일 데이터 레이크로 효율적으로 인제스천(ingest)합니다.
도전 과제
이전에는 데이터 인제스천을 위해 그때 그때 특정 소스에 필요한 파이프라인을 구축해왔습니다. 그러나 데이터 양과 분석에 필요한 연산량이 크게 증가하면서 신규 추출/적재(load) 파이프라인을 소스별로 구축하는 이런 방법은 느리고 관리하기 어려웠습니다. 점점 커져가는 여러 파이프라인을 그 규모에 맞게 운영하는 일은 점점 더 어려워졌고, 사업과 관련된 결정을 긴급히 내릴 때 필요한 온디맨드 분석(on-demand analytics)도 제때 진행하는 것이 쉽지 않아 제한적으로 쓰일 수 밖에 없었습니다.
게다가 이런 추출 파이프라인은 업스트림의 스키마 변경 시 유지 보수에 상당한 리소스를 투입해야 했습니다. 수동으로 유지 보수를 해야했기 때문에 데이터가 갑자기 증가하거나, 데이터에 갑자기 비대칭이 발생할 경우 실패할 확률이 높았습니다. 비즈니스의 초창기에는 문제 없는 시스템이었으나, 데이터의 규모가 증가하면서 점점 오류에 취약하고 비효율적인 시스템이 되었습니다.
범용 데이터 인제스천: 소스 애그노스틱(Source-agnostic) 및 자동화
이런 어려움을 해소하고 수동 작업이 많이 요구되는 서비스 모델에서 벗어나기 위해, 확장이 가능한 셀프서비스 데이터 인제스천 플랫폼을 도입했습니다.
인제스천에 대한 전문 지식이 없더라도 쉽게 사용할 수 있는, 사용자를 중심으로 완전 자동화된 UDI(Universal Data Ingestion) 프레임워크를 구축했습니다. 이 프레임워크의 목표는 70개 데이터 소스에 대한 인제스천 프로세스를 표준화하는 것입니다. UDI는 Velocity(속도), Variety(다양성), Volume(볼륨)으로 구성된 3V 원칙을 바탕으로 설계되었습니다.
속도
속도 증가를 위해 UDI는 기존에 수작업으로 오래 걸렸던 인제스천 프로세스를 자동화했습니다. UDI 덕분에 최소한의 엔지니어링 시간으로 데이터를 쉽고 간단하게 인제스천하게 되었습니다.
예를 들어, 데이터 일괄처리 작업(batch)은 인제스천 전에 광범위한 검증 과정을 거칩니다. 소스 데이터를 내부 보안 절차에 따라 안전하게 액세스할 수 있는지 확인합니다. 구조화된 데이터 유즈 케이스의 경우, 데이터 스키마를 확인해 필요한 섹션들만 가져옵니다. 상기 및 기타 전체적인 확인 및 필터링 프로세스는 UDI에서 자동으로 처리됩니다.
또한 UDI는 인제스천의 일괄처리량을 자동으로 예측합니다. 이는 핵심 사업 데이터를 보유한 RDBMS 기반 데이터 소스 같은 경우에는 매우 중요한 과정입니다. 과도한 부하를 방지하기 위해 UDI는 각 일괄처리 작업에서 가져올 수 있는 효율적이면서도 안전한 데이터량을 예측합니다.
다양성
초기 파이프라인은 저희 프로덕션(production)에서 가장 많이 사용되던 MySQL에서 Hive로의 연결 방식에 초점을 두고 있었습니다. 더 다양한 범위의 데이터 소스를 지원하기 위해 셀프서비스 인제스천을 하둡 에코시스템 위에 플러그인 프레임워크 형태로 구축하였습니다. 재사용 가능한 이 플러그인 프레임워크를 활용해 사용자는 최소한의 추가 비용과 개발 리소스 투입만으로도 신규 데이터 소스들을 지원할 수 있게 되었습니다.
볼륨
UDI는 초창기부터 고확장성을 위해 디자인되었으며 개방형 표준을 준수하였습니다. 대용량 데이터를 분석 자료로 효율적으로 변환시키기 위해 다음과 같은 시스템을 사용하고 있습니다.
- AWS S3를 활용하는 데이터 저장소: 데이터 레이크는 수평적으로 확장가능하며 비교적 비용이 합리적인 S3를 기반으로 합니다. S3는 증가하는 데이터량에 맞추어 초고속으로 확장할 수도 있습니다.
- Hive 데이터 컨섬션(Consumption): 주요 컨섬션 레이어는 충분히 검증되어 널리 사용되고 있는 데이터 웨어하우징 솔루션인 Hive에서 사용됩니다.
- Spark를 활용한 데이터 처리: 추출, 적재, 변환, 즉 ELT(Extract, Load, and Transform)에 사용되는 주요 데이터 처리 엔진은 Spark를 기반으로 합니다. Spark는 네이티브로 지원되는 인메모리 처리 시맨틱스로 인해 타 MapReduce 기반 모델보다 빠릅니다.
- Presto를 활용하는 애드혹(ad-hoc) 쿼리: 스피드가 핵심인 인터랙티브 및 애드혹 쿼리는 Presto를 이용해 더 빠르게 분석 인사이트를 제공합니다.
다음 단계
향후 저희는 견고한 이벤트 기반 인제스천(event-based ingestion) 및 제네릭 이벤트 컨슈머(generic event consumers)가 포함된 스트리밍 솔루션을 도입하고자 합니다. 또한 강타입 로그 기반 인제스천 프로세스를 도입하기 위해, 디렉트 변경 데이터 캡처(Change Data Capture) 동기화 프로세스는 점진적으로 종료할 예정입니다. 마지막으로 인제스천 플랫폼의 셀프서비스 기능을 개선해 엔드투엔드 고객 경험을 강화하는 방안을 계속해서 모색할 예정입니다.
ML 플랫폼
이제 데이터가 어떻게 ML 모델을 통해 가치 있는 인사이트로 전환되는지 알아보겠습니다. 쿠팡의 데이터 사이언티스트와 ML 엔지니어가 ML 모델을 손쉽게 구축, 훈련 및 배포하기 위해 사용 중인 내부 ML 플랫폼에 대해 알아보겠습니다.
도전 과제
이전에는 각 팀의 데이터 사이언티스트와 ML 엔지니어가 각자의 ML 인프라를 관리했습니다. 이 방식은 두 가지 면에서 저희 엔지니어링 효율성에 부정적인 영향을 주었습니다. 첫째, 각 팀은 동일한 패키지와 툴을 사용해 유사한 데이터 사이언스 환경을 구축하는데 많은 시간을 쏟았습니다. 둘째, 각 팀은 표준화된 프로세스 없이 각자 데이터를 준비하고 피처(feature) 파이프라인을 구축하며 모델을 트레이닝하고 배포했습니다. 표준화 작업 및 일원화된 리소스 관리의 부재로 인해 각 팀이 GPU에 충분히 접근하기가 어려웠습니다. 이러한 엔지니어링 측면의 중복 작업은 비효율적인 리소스 활용과 저조한 ML 스루풋(throughput)으로 이어졌습니다.
단순하고 사용자 친화적인 플랫폼 내 모델 구축과 GPU 활용 프로세스의 표준화가 요구되는 상황이었습니다.
통일된 모델 트레이닝 플랫폼
저희의 ML 플랫폼은 피처 파이프라인과 오프라인 트레이닝의 구축을 지원하는 확장 가능한 트레이닝 플랫폼입니다. 텐서플로우(TensorFlow)와 파이토치(PyTorch) 같은 인기있는 ML 프레임워크와 툴을 지원합니다. 본 플랫폼에서는 데이터 전처리 기능, 인터랙티브 노트북 환경, 고성능 GPU를 활용한 분산 트레이닝, 하이퍼 파라미터 튜닝, 모델 서빙을 제공합니다.
동기화된 대규모 데이터 전처리
모델 학습에 필요한 피처 및 라벨 데이터셋은 Airflow 기반의 데이터 파이프라인 오케스트레이터를 활용해 생성했습니다. 이 오케스트레이터는 쿠팡에서 자체 개발했으며 이미 데이터 스토어 및 Spark, Hive, Presto 등의 대규모 데이터 처리 엔진과 완전히 연동되어 있습니다. 또한 트레이닝 플랫폼 전반에서 간편하게 데이터를 연동할 수 있도록 SDK도 개발했습니다. 엔지니어는 이러한 오케스트레이터와 데이터 스토어 SDK를 이용해 대규모 학습 데이터셋을 생성하고 관리하며 공유할 수 있게 되었습니다.
빠른 모델 학습 설정 및 추적
모델 학습 및 개발 플랫폼은 오픈 소스 툴을 활용해 구축되었습니다. 목표는 쿠팡 내 모든 엔지니어에게 표준화된 트레이닝 환경을 제공하는 것을 목표입니다. 주요 피처는 다음과 같습니다.
- 컨테이너 이미지: 컨테이너 이미지를 인기있는 ML/DL 프레임워크(TensorFlow, PyTorch, XGBoost, Scikit-Learn 등) 및 데이터 사이언스 라이브러리(Pandas, Numpy 등)와 함께 사전에 패키징해 정기적으로 퍼블리싱하고 있습니다. 엔지니어는 이 플랫폼에서 Jupyter 컨테이너를 런칭하면 간편하게 모델 개발을 시작할 수 있습니다.
- GPU 활용을 위한 CLI 및 API 엔드포인트: 효율을 높이기 위해 쿠팡의 ML 플랫폼에서는 명령어 인터페이스(CLI)와 API 엔드포인트를 제공하며, 이를 통해 사용자는 분산 트레이닝 및 GPU 전산 처리에 간편하게 접근할 수 있습니다.
- 하이퍼 파라미터 튜닝: 플랫폼은 사용자가 현재 진행 중인 여러 실험에 대한 최적의 하이퍼 파라미터를 파악할 수 있도록 다양한 하이퍼 파라미터 튜닝 알고리즘도 지원합니다.
- 모델 시각화: 사용자는 실험 추적 및 시각화 툴을 이용하여 담당 모델의 트레이닝 상황을 빠르게 평가하고 모니터링할 수 있습니다.
효율적 모델 서빙을 위한 예측 컨테이너
모델 트레이닝과 추론 사이의 시간을 더욱 단축하기 위해 모델 배포 툴과 모델 서빙 인프라를 구축했습니다. 모델 서빙을 지원하기 위해 Kubernetes용 인하우스 컨테이너 플랫폼과 커스터마이즈된 오픈 소스 툴을 활용했습니다. 엔지니어는 자신의 모델을 서빙하도록 오토 스케일링이 가능한 Jsonnet 스펙을 작성하고 REST 및 GRPC 추론 엔드포인트를 노출시키면 됩니다.
다음 단계
현재 검색랭킹팀에서는 검색어 이해, 검색 결과 및 구매율 개선을 위해 ML 플랫폼을 이용해 BERT 모델 및 DNN 모델을 트레이닝하고 있습니다. 광고팀에서는 클릭률과 전환율 개선을 위해 DIN(Deep Interest Networks)를 트레이닝하고 있습니다. 마케팅팀은 고객 참여와 유료 멤버십 전환률을 개선하기 위하여 ML 플랫폼을 이용해 개별 고객을 위한 맞춤 추천 및 이벤트를 기획하고 있습니다.
다음 목표는 엔지니어가 각자 다양한 버전의 ML 모델을 저장하고 관리하는 저희의 자체 모델 스토어를 개선하는 것입니다. 또한 피처 스토어를 접목하고 예측 스토어와 서빙 레이어의 연동을 강화하기 위해 내부의 여러 팀들과 협업하고 있습니다.
A/B 테스트 플랫폼
마지막으로 쿠팡의 A/B 테스트 플랫폼을 소개하겠습니다. A/B 테스트 플랫폼은 고객들이 더욱 “와우”한 경험을 제공 받을 수 있도록 데이터 기반의 의사결정 과정을 지원합니다.
앱에 신규 피처를 추가하는 것은 간단한 작업이 아닙니다. 새로운 피처의 임팩트를 측정하기가 어려울 수 있기 때문입니다. 쿠팡은 피처 런칭을 과학적이고 고객 중심적으로 접근하기 위해 A/B 테스트를 활용합니다. 배송 방법을 선택하는 페이지부터 상품 추천 광고까지 쿠팡 앱의 모든 피처는 철저한 A/B 테스트를 거쳐 탄생합니다.
도전 과제
A/B 테스트가 실제 고객을 대상으로 이루어지다 보니 도움이 되지 않는 피처의 경우 고객의 구매 퍼널을 막아 매출에 악영향을 줄 수 있습니다. 첫 번째 도전과제는 비지니스에 피해를 끼칠 수 있는 테스트를 빠르게 찾아내 자동으로 중단하는 것이었습니다.
두 번째 도전과제는 A/B 테스트 모니터링 공식(monitoring formulas)을 런칭하는 과정에서 엔지니어링 측면에서의 효율을 개선하는 것이었습니다. 복잡한 모니터링 공식을 구현하려면 최소 2주 동안 상당한 엔지니어링 리소스를 투입해야 했습니다. 각 A/B 테스트에서 배정이 잘못된 그룹, 가드레일 레이턴시, 평평한 노출 로그, 트래픽 미발생 등을 모니터링하기 위해서였습니다. 또한 테스트 쿼리가 실험 중에 수정될 경우 모니터링 잡을 엔지니어가 다시 시작해야 했습니다.
마지막으로 실험 플랫폼은 하루에 30억 건의 이벤트와 1천 건의 실시간 실험들을 처리합니다. 쿠팡의 글로벌 확장에 따라 다수의 지역에, 앱 버전 별로, 앱끼리 중복없이 순서대로 서비스하기 위해 플랫폼도 확장해야 했습니다. 이와 같이 서비스 대상이 증가하면서 모든 A/B 테스트의 메트릭을 효율적으로 계산해야했고 엔지니어링 복잡도는 크게 증가했습니다.
부정적인 실험 감지 및 중단
예전에는 구매자 전환율이 의미 있는 수준으로 (p 밸류 ≤0.001) 감소할 경우, 테스트 담당자에게 알림을 보냈습니다. 그리고 담당자가 12시간 내에 조치를 취하지 않으면, 해당 A/B 테스트를 자동으로 중단했습니다. 이 시스템 자체에 문제는 없었지만, 더욱 더 빠르게 핵심 도메인에서 문제 있는 A/B 테스트를 발견해 자동으로 중단하고 싶었습니다.
먼저 문제가 되는 테스트를 중단하기 위해 4시간마다 배치로 돌아가는 강제 중단 시스템을 만들었습니다. 하지만 4시간도 너무 길었습니다. 또한 시스템은 여전히 테스트 오너의 수동 개입에 의존하고 있었습니다.
이에 저희는 서킷 브레이커를 도입해 문제 있는 A/B 테스트를 실시간으로 전보다 더 빠르게 감지해 자동으로 중단했습니다. 쿠팡 주요 도메인 전환율에 주는 부정적인 영향을 최소화할 수 있었습니다.
서킷 브레이커 아키텍처에서 각 Spark 잡은 2분마다 메트릭을 계산해 S3 또는 MySQL에 저장합니다. 2분이라는 간격은 스트리밍 잡을 초기화하는 시간을 고려해 결정했습니다. 연산량을 줄이기 위해 서킷 브레이커는 설정에 기반해 데이터를 필터링하고 중복을 제거합니다. 서킷 브레이커 메트릭이 5회 연속으로 의미 있는 수준(p-value ≤ 0.001)으로 감소할 경우, A/B 테스트는 자동으로 중단되며 테스트 담당자는 알림을 받게 됩니다. 서킷 브레이커 덕분에 문제 있는 A/B 테스트는 그 어떤 수동 개입 없이도 약 10분 이내에 종료됩니다.
그림 5는 서킷 브레이커가 A/B 테스트를 몇 분 내에 중단해 유의미한 매출 감소를 방지한 예시입니다. 서킷 브레이커가 없었다면 해당 구매 퍼널의 전환율이 최소 4시간 동안 장바구니 페이지에서 20% 하락했을 수도 있습니다.
실험 모니터링 잡을 효율적으로 연동하기
다음 과제는 대규모 엔지니어링 리소스를 사용하지 않고 신규 모니터링 잡을 추가하는 것이었습니다. 효율성과 유연성의 극대화를 위해 MySQL에서 가져온 모든 메트릭 데이터를 별도의 모니터링 솔루션에 노출하는 쿼리 기반 모니터링 시스템을 설계했습니다. 이 신규 모니터링 시스템을 이용하여 복잡한 공식이 포함된 모니터링 잡을 단순한 쿼리로 전환할 수 있었습니다.
모니터링 시스템의 세부 아키텍처는 그림 6과 같습니다. 우선 모니터링 솔루션이 A/B 테스트 메트릭 데이터가 들어 있는 메트릭 노출자(Metric Exposer)에서 주기적으로 데이터를 인제스천합니다. 그러면 규칙 기반(rule-based) 모니터링 시스템이 특정 기준을 충족하는 A/B 테스트를 탐지하기 위해 1분마다 쿼리를 수행합니다. 규칙 기반 모니터링 시스템은 A/B 테스트를 찾아내 사용자가 설정한대로 작동하는 메시지 생성자(Message-generator)로 전달하고, 메시지 생성자는 테스트 담당자에게 알림을 보내거나 A/B 테스트를 중단하는 것과 같은 일들을 수행합니다.
이 신규 모니터링 시스템을 이용해 엔지니어는 단순한 쿼리를 작성해 모니터링 알림을 받을 수 있습니다. 다음은 장시간 수행되는 테스트의 모니터링이 가능한 쿼리의 예시입니다.
AVG(test_running_time{status=’RUNNING’}) by (experiment_id, result_date) > 1000000
A/B 테스트의 글로벌 확장
쿠팡의 글로벌 성장과 확장을 지원하기 위해 마지막으로 Apache ZooKeeper를 도입했습니다. 다양한 니즈를 안정적으로 충족시키기 위해 저희는 다음과 같이 ZooKeeper를 사용하였습니다.
- 설정 데이터 저장: ZooKeeper에는 플랫폼 및 앱 버전, 국가 정보, A/B 그룹 비율 등 A/B 테스트에 필요한 모든 설정 데이터가 있습니다. 테스트 담당자가 실험 플랫폼에서 설정을 변경할 경우, 해당 변경은 ZooKeeper를 통해 1만 개의 서버로 즉시 확산됩니다. 덕분에 저희는 A/B 테스트의 로컬 무작위화(randomization) 성능 및 네트워크 레이턴시를 개선할 수 있었습니다.
- 리더 선정의 안정화: 사용자 커넥션을 처리하기 위해 각 리전에 ZooKeeper 옵저버 노드를 추가했습니다. 안정적인 리더 선정은 ZooKeeper 클러스터를 안정적으로 운영하는데 매우 중요하므로 상기 작업은 ZooKeeper 리더와 팔로워가 유저 커넥션 없이 리더 선정에 집중할 수 있도록 여유 공간을 만들어 줍니다.
- 네트워크 대역폭 보장: ZooKeeper 노드 간 네트워크 대역폭은 데이터 처리량에 있어 핵심 요소입니다. 부팅 중에 100GB 이상의 데이터가 전송되는데, 이때 네트워크 대역폭이 보장되지 않을 경우 장애가 발생할 수 있습니다. 대량의 데이터로 인한 장애를 방지하기 위해 네트워크 대역폭이 보장된 인스턴스 유형을 사용했습니다.
- 확장성을 위한 설정: 비즈니스의 성장과 함께 커넥션 수가 급증하면서 ZooKeeper 노드를 시의적절하게 확장해야 했습니다. 미리 ZooKeeper 클러스터의 용량을 확인한 결과, 기존 사용 패턴의 경우 각 사용자가 약 3MB의 커넥션을 사용한다는 것을 알게 되었습니다. 이 커넥션별 메모리 사용량과 커넥션 수를 바탕으로 JVM 옵션을 설정했고, 클러스터의 견고한 확장성을 확보할 수 있었습니다.
- 네트워크 응답시간 개선: 네트워크 응답시간(latency)를 개선하고자 가상 데이터 센터(VDC) 설정을 토대로 SDK가 동일 리전 내 가장 가까운 옵저버 노드를 찾도록 설정했습니다.
다음 단계
실험 설계 및 세부 설정 부분을 개선해 글로벌 고객과 비즈니스에 대비하려고 합니다. 다음 목표는 피처 플래그, 동적 설정 오버라이드(override), 동적 타겟팅을 개발해 실험 설계의 복잡도를 줄이는 것입니다.
맺음말
이번 포스팅에서는 끊임없이 증가하는 고객들과 데이터를 처리하기 위해 지난 수년간 진행했던 데이터 플랫폼 개선 작업에 대해 이야기해보았습니다. 본 시리즈의 2편에서는 쿠팡의 분석 플랫폼에 대해 보다 상세하게 다뤄보도록 하겠습니다.
대규모 데이터를 기반으로 움직이는 쿠팡에서 데이터 플랫폼을 구축해보고 싶으신 분은 현재 채용 중인 포지션을 확인해보세요!
