온라인 음식 주문 및 배달 서비스 시장은 경쟁이 매우 치열한 곳으로, 속도가 비즈니스의 생존 여부를 결정합니다. 이에 쿠팡이츠(이하 ‘이츠’) 데이터 플랫폼팀은 설정 기반의 데이터 처리 시스템을 구축했습니다. 이번 포스트에서는 데이터 플랫폼으로 어떻게 비즈니스 운영의 일부분을 자동화하고 비즈니스 성장을 가속화했는지를 공유드리고자 합니다.
목차
· 도입
· 이츠 데이터 플랫폼의 구조
· 데이터 처리 파이프라인
∘ 비실시간(Non-real-time)
∘ 근실시간(Near real-time, NRT)
∘ 완전 실시간(Pure real-time)
· 결론
도입
2019년 말에 론칭된 쿠팡의 신규 비즈니스인 이츠는 온라인 음식 주문 및 배달 서비스 시장에 후발주자로 진입했습니다. 초반에는 비즈니스 가동 및 운영에 필요한 기반을 마련하느라 바빴습니다. 그러나 지금은 애플리케이션의 안정성만을 확보하는 단계를 벗어나 더 효율적인 운영방식에 대해 고민하는 시점에 이르렀습니다.
이젠 데이터 자동화와 복잡한 머신러닝(ML) 모델을 활용해 더 적은 엔지니어링 비용으로 더 많은 고객들을 확보해 비즈니스를 성장시키고 있습니다. 예를 들어 현재 저희는, 배달예상시간을 ML 모델로 에측하고, 실시간 사용자 태그로 고객 프로모션을 자동화하고, 데이터 시각화 및 지표 계산을 돕기 위해 동적 데이터 서비스를 만들고 있습니다. 이츠에서 데이터 사이언스로 어떻게 음식 배달의 과제들을 극복하고 있는지에 대해 좀 더 알고 싶으시면 저희의 이전 포스트를 참고해 주세요.
견고하게 여러 영역을 커버하고 있는 이츠의 데이터 플랫폼은, 이런 스마트하고 자동화된 비즈니스 운영의 기반을 이루고 있습니다. 실시간 분석이든 오프라인 데이터 서빙이든 간에, 고객 성장을 견인하고 모든 비즈니스 니즈를 지원할 수 있게끔 확장 가능하도록 개발되었습니다.
비즈니스 초기 단계의 데이터 플랫폼은 중앙 집중식 시스템이 아니었습니다. 각 팀에서ML 모델을 훈련시키고 자료를 입력하는 일과 그 외의 데이터 사이언스 서비스를 진행했습니다. 비효율적인 피처 엔지니어링(feature engineering), 한발 느린 지표 모니터링 및 알림, 데이터 시각화의 부재 등과 같은 어려움이 있었습니다. 이런 비효율은 엔지니어링 자원을 낭비할 뿐 아니라, 비즈니스를 확장하는 데 있어 큰 병목으로 작용했습니다. 어떻게 이 어려움들을 해결했는지 더욱 자세히 알고 싶으시면, 저희 블로그 계정을 팔로우 하시고 다음 포스트를 읽어봐 주세요.
이츠 데이터 플랫폼 구조
데이터 플랫폼은 데이터 처리 과정의 생애주기(lifecycle)를 처음부터 끝까지 관리합니다. 데이터 처리의 생애주기는 일반적으로 다음의 단계들을 따릅니다.
- 데이터 인제스천(ingestion): 여러 데이터 소스로부터 데이터를 가져오는 첫 단계. 이후 단계의 원활한 데이터 처리와 이동을 위해 이 단계에서는 데이터의 우선순위를 정하고 분류.
- 데이터 전처리(pre-processing): 비어 있는 값 채우기, 포맷 표준화, 데이터 품질 확인, 데이터 필터링 등. 전처리의 목적은 데이터 사이언스와 ML 태스크를 위해 데이터를 준비하는 것임.
- 데이터 처리(processing): 미가공 데이터를 복잡한 데이터 분석에 필요한 출력 형태로 변환하는 과정. 데이터를 적절한 데이터 저장소로 수신(sink)될 수 있게 하는 것도 이 단계에 포함됨.
- 데이터 활용(utilization): 처리된 데이터를 분석하는 과정. 데이터 파이프라인의 최종 단계로, 각종 비즈니스 이슈를 지능적으로 해결하는 DaaS(Data-as-a-service)를 사용함.
이츠 데이터 플랫폼은 위의 4 단계를 따르며, 상세 구조는 그림 1과 같습니다. 이츠 데이터 플랫폼은 효율적인 방법으로 모든 데이터 처리 니즈를 지원할 수 있는 원스톱 시스템으로 개발되었습니다. 비즈니스 분석가(BA), 데이터 엔지니어, 데이터 사이언티스트 모두가 이 플랫폼을 활용해 다양한 데이터 니즈를 충족시킬 수 있습니다.
데이터 처리 파이프라인
음식 배달 서비스는 고객, 쿠팡이츠 배달 파트너(Eats Delivery Partners, EDP), 판매자라는 세 축 사이에서 다양한 계산이 실시간으로 이루어지는 굉장히 복잡한 비즈니스입니다. 일례로 고객에게 가장 빠른 속도로 음식을 배달하려면 주문이 수 초 이내에 배달 파트너에게 배정 완료되어야 합니다. 반면 타겟 광고 노출을 위한 고객 세분화(segmentation)와 같은 경우 시간에 크게 민감하지 않아, 관련된 계산이 실시간으로 이루어질 필요는 없습니다.
이츠 데이터 플랫폼은 이렇게 시간 요건이 극명하게 다른 여러 가지 과제들을 처리할 수 있도록 설계되었습니다. 이 섹션에는 더욱 세부적으로 이츠 데이터 플랫폼의 데이터 처리 파이프라인을 살펴보겠습니다. 연산 엔진은 비실시간, 근실시간, 그리고 완전 실시간으로 데이터를 처리하고 있습니다.
비실시간(Non-real-time)
- 시간 효율: 최소 1시간
비실시간 파이프라인은 작업 스케줄러에 따라 일괄 처리(batch) 단위로 돌아갑니다. 이 파이프라인은 ML 관련 피처 생성, 사용자 프로파일링 및 태그 생성, 그리고 데이터 시각화 등을 지원합니다.
이츠 데이터 플랫폼을 개발하기에 앞서 비실시간 파이프라인의 최대 문제점은 오프라인 피처 및 시그널을 온라인 저장소에 보내는 것이었습니다. 일괄 처리된 데이터 집합의 대용량 업로드는 시스템의 속도, 효율성, 비용 측면에서 매우 큰 부담이었습니다.
저희는 이러한 단계를 가속화하기 위해 설정 기반(configuration-driven)의 파이프라인을 개발했습니다. 설정 기반 파이프라인에서는 개발자들이 새로운 데이터 소스(source)를 추가해야 할 경우 단순히 설정만 새롭게 정의하면 되기 때문에, 파이프라인 생성 과정이 더 쉽고 편리해졌습니다. 사실상 아래의 간단한 세 단계만 수행하면 됩니다.
- 데이터 동기화 정보를 메타데이터 관리 시스템에서 정의하기. 전체 피처 그룹을 정의할 수도 있는데, 여기에 구체적인 비즈니스 시나리오를 위해 미리 정의된 피처, 그리고 피처 및 Hive 테이블 열(column) 간의 매핑 관계를 포함시킬 수 있음.
- 제네릭(generic) Spark SDK를 제공해 Hive 데이터를 읽고, 미리 정의된 메타데이터와 매핑 설정에 따라 피처를 온라인 피처 스토어(feature store)와 동기화.
- 작업 스케줄러에 Spark 잡(job)을 생성하고 SDK를 참조해 데이터를 온라인 저장소와 자동으로 동기화.
근실시간(Near real-time, NRT)
- 시간 효율: ≥ 30초
여러 애플리케이션이 실시간 데이터 스트리밍을 지원하지만, 이는 데이터 인프라에 큰 부담을 주고 고도의 기술적 전문성을 필요로 합니다. 실시간 데이터 스트리밍은 또한 유연성이 떨어져 변화하는 비즈니스 요건에 대응하기가 쉽지 않습니다.
이런 단점들에 대응하고자 저희는 고성능 OLAP 엔진의 장점을 취하는 근실시간(NRT) 파이프라인을 설계하였습니다. NRT 파이프라인은 스케줄링된 작업을 통해 거의 실시간에 가까운 SQL 스크립트 실행 시그널을 생성합니다. NRT 파이프라인은 ML 예측을 위한 피처 실시간 생성, 사용자 태그 실시간 생성, 비즈니스 지표의 실시간 대시보드 게시 및 알림을 지원합니다.
NRT 엔진은 제네릭(generic) 파이프라인으로, 비실시간 파이프라인과 마찬가지로 설정에 기반합니다. 데이터 엔지니어, 데이터 사이언티스트, 비즈니스 분석가(BA)에게 익숙한 언어인 SQL로 코드를 작성할 수 있게 되면서 여러 종류의 비즈니스를 지원할 수 있게 되었습니다. NRT 파이프라인이 반년 이상 서비스된 지금, 피처 프로덕션 효율성은 눈에 띄게 개선되었습니다.
다음은 회사 내부 사용자들의 NRT 파이프라인 활용 사례입니다.
- 업스트림 Kafka 메시지를 OLAP 엔진으로 인제스천하거나, 클라우드 저장소에 있는 Hive 테이블 데이터를 읽어들이기.
- 설정된 간격(30초에서 1시간 사이)에 따라 OLAP 엔진 SQL 실행하기. 이 단계에서 실시간 데이터가 저장되는 Kafka나 클라우드 저장소에서 인제스천되었던 여러 테이블 소스(source)를 조인(join)해 와이드 테이블(wide table) 만들기.
- 이전 단계에서 생성된 와이드 테이블들을 활용해, 데이터 사이언티스트는 근실시간 지표 및 시그널을 생성하는 OLAP 엔진 및 SQL 작업을 스케줄링
- 작업 스케줄러가 정의된 간격에 따라 SQL을 실행. 생성된 시그널을 Kafka 컨슈머에게 다운스트림으로 보내거나 데이터 스토리지에 쓰기.
완전 실시간(Pure real-time)
- 시간 효율: 1초 미만
NRT 파이프라인으로 프로덕션의 실시간 피처 유스 케이스(feature use case)의 80% 정도를 커버할 수 있었습니다. 그러나, 그것만으로 데이터 폭증 감지나 리스크 관리와 같은 고효율, 저지연(low latency) 작업이 필요한 상황은 지원하지 못합니다.
이렇게 긴급한 작업은 완전 실시간 데이터에 의존했습니다. 하지만 완전 실시간 파이프라인에는 Spark와 다른 분산 처리 엔진이 함께 사용됩니다. 대부분의 데이터 사용자가 Spark 스트리밍 코드에 익숙하지 않았기 때문에, 실시간 데이터 처리를 위해 사용자가 계속 코드를 직접 작성하는 일은 실용적이지 못했습니다.
그래서 저희는 이번에도 모든 사용자가 쉽게 활용할 수 있는 설정 기반의 실시간 데이터 처리용 파이프라인을 개발했습니다. 파이프라인은 다음과 같은 방식으로 작동합니다.
- 필요한 데이터를 Kafka 토픽에 인제스천.
- 실시간 피처 메타 설정을 바탕으로 이벤트 데이터를 브로드캐스트 시스템을 통해 각기 다른 다운스트림 운영자(downstream operator)에 동적으로 분할(dynamic partition)함.
- 피처 메타데이터의 정의에 따라 실시간 피처들의 값을 미리 구현된 각 집산자(aggregator)에 계산. 계산된 값을 즉시 또는 주기적으로 Kafka 또는 다운스트림 운영자으로 출력함.
이 완전 실시간 파이프라인은 SUM, COUNT, UNIQUE COUNT, TOPN 등 10여 개의 자주 사용되는 통계 함수를 지원합니다. 또한, 이 파이프라인은 다차원 통계 함수를 지원합니다. 저희는 완전 실시간 파이프라인을 통해 데이터 스트리밍을 코드 없이 정의해 실시간 피처 계산 비용을 극적으로 줄이고 효율성을 증대할 수 있었습니다.
결론
지금까지 이츠 데이터 플랫폼의 구조와 데이터 처리 파이프라인에 대해 살펴보았습니다. 비즈니스 요건에 따라 요구되는 시간 민감성이 다르기 때문에 저희는 비실시간, 근실시간, 그리고 완전 실시간 파이프라인 세 가지를 개발했습니다. 세 가지 데이터 파이프라인 모두 설정 기반(configuration-driven)으로 만들어졌으며, 사용자들은 최소한의 코딩으로 파이프라인들을 별다른 어려움 없이 사용할 수 있게 되었습니다.
저희 블로그 계정을 팔로우 해주시면 다음 포스트를 통해 DaaS(Data-as-a-service)로서의 이츠 플랫폼에 대한 좀 더 자세한 이야기를 확인해 보실 수 있습니다.
혹시 복잡한 비즈니스 문제를 데이터 엔지니어링을 통해 해결해보고 싶으시다면, 저희의 채용공고를 확인해보세요.
