로블록스, 일일 분석 이벤트 2조 건 달성까지의 여정

매일 평균 9,780만 명의 사용자*가 Roblox를 방문하여 소통하고, 창작하며, 함께 게임을 즐깁니다. 이러한 상호작용을 통해 총 2페타바이트의 분석 이벤트 데이터가 생성됩니다. 새로운 확장형 수집 시스템 덕분에 최근 중요한 이정표를 달성했습니다. 현재 우리 시스템은 하루에 2조 건 이상의 이벤트를 처리하고 있습니다. 이 시스템은 Roblox 플랫폼을 구동하는 개인화, 안전, 경제 알고리즘을 가능하게 합니다.

이전에는 클라우드 큐 서비스가 로블록스에서 생성된 분석 데이터를 events_hourly라는 단일 논리적 테이블로 수집했습니다. 이 테이블은 날짜, 시간, 그리고 웹, 모바일, friendService와 같이 임의로 정의된 태그별로 파티셔닝되었습니다. 당사의 데이터 과학자와 엔지니어들은 특정 이벤트를 전용 테이블로 추출하기 위해 예약된 배치 작업을 활용했습니다. 새로운 분석 이벤트를 생성하고 전송하는 데 사전 스키마가 필요하지 않았습니다. 엔지니어들은 추출, 변환, 로드(ETL) 파이프라인 단계에서 하류에 위치한 자체 테이블 스키마를 직접 제어했습니다.

이 구성은 유연하여 엔지니어들이 신속하게 대응할 수 있게 해주었지만, 몇 가지 문제점도 안고 있었습니다. 

• 이벤트 양이 증가함에 따라 날짜, 시간, 태그로만 분할된 2조 개의 행을 처리하는 것은 점점 비효율적이 되었습니다.
• events_hourly 테이블의 경우 하루가 끝날 때 6시간의 지연이 발생하고, events_daily의 경우 24시간의 지연이 발생하여 데이터 파이프라인이 차단되는 기간이 생겼습니다. 
• 데이터 세트 수준의 권한, 계층, 보존 기간 및 알림 관리가 더욱 복잡해졌습니다. 
• 이벤트 문서, 이력 및 소유권이 누락되어 데이터의 사용성과 추적성이 떨어졌습니다. 
• 클라우드 큐 서비스로 구축된 수집 인프라로 인해 23Gbps의 클라우드 수집 비용이 발생했습니다.

이전에는 데이터 분석이 수많은 배치 파이프라인을 통해 단일 논리 테이블에서 데이터를 추출하는 방식에 의존했습니다. 이는 대규모의 고성능 쿼리를 실행하기 위해 필요했지만, 동시에 처리 속도를 저하시키는 원인이기도 했습니다. 인제스트 백엔드 서비스를 사용하여 이러한 이벤트를 전용 테이블로 라우팅하면, 분석 이벤트에 스키마를 부여하고 대상 테이블을 사전에 정의함으로써 배치 추출 파이프라인을 제거할 수 있습니다. 

Roblox에서는 분석 이벤트의 스키마 언어로 Protobuf(proto)를 선택했습니다. proto와 gRPC가 우리가 선호하는 서비스 구축 프레임워크이기 때문에 이는 자연스러운 선택이었습니다. 또한 proto는 소유권, 보존 기간, 생산성 소프트웨어 채널, 이벤트 스키마와 같은 추가 메타데이터를 수집하는 데 활용하는 사용자 정의 옵션 정의에 대한 훌륭한 지원을 제공합니다. 

스키마 언어를 선택한 후, 스키마가 업데이트될 때 어떤 일이 발생하는지, 그리고 어떤 업데이트를 허용해야 하는지 검토했습니다. 게시된 스키마를 사용하는 최대한 많은 다운스트림 소비자를 지원하기 위해, 데이터 팀은 스키마 레지스트리(Schema Registry)에 설명된 역전이(backward transitive) 모드를 채택했습니다. 이 접근 방식을 통해 필드 추가 및 소프트 삭제(soft delete)가 허용됩니다. 이를 통해 다운스트림 소비자와의 사전 협의 없이도 스키마 변경이 가능해집니다. 

위의 예시에서 볼 수 있듯이, proto 파일을 업데이트하여 필드를 추가하거나 삭제할 수 있습니다.

스키마는 많은 이점을 제공하지만, 초기 단계에서 이를 의무화하면 작업에 걸림돌이 됩니다. 데이터 과학자와 엔지니어는 장애물 없이 신속하게 움직이고 반복 작업을 수행해야 합니다. 이를 지원하기 위해, 우리는 중앙 집중식 스키마 저장소를 도입하고 스키마 작성을 최대한 자동화하고 간소화할 수 있는 일련의 도구를 구축했습니다. 

예를 들어, 각 스키마가 필수 메타데이터를 갖추고 Roblox 규약을 준수하는지 검증하기 위해 맞춤형 proto 린터를 개발했습니다. 또한 이벤트 스키마를 Hive 데이터 정의 언어로 변환하는 Proto 플러그인을 구축하여, 스키마가 생성되거나 업데이트될 때마다 해당 Hive 테이블이 항상 동기화되도록 했습니다. 이러한 모든 도구는 CI/CD 파이프라인에 통합되어 있으며, 풀 리퀘스트가 생성될 때 자동으로 실행됩니다. 이를 통해 엔지니어들은 스키마가 병합되기 전에 스키마 문제를 조기에 포착하고 테스트용 Hive 테이블에서 이벤트를 검증할 수 있습니다. 그 결과, 스키마를 프로덕션에 배포하는 것은 병합하는 것만큼 간단해졌습니다. 

간소화된 개발자 환경이 구축된 후, 우리는 수집 파이프라인의 어느 단계에서 이벤트를 스키마화하고 Proto로 변환해야 할지 검토했습니다. 이벤트 생성자에게 직렬화된 Proto 바이트를 채택하여 전송하도록 요청하는 것은 여러 팀에 걸친 중대한 변화였습니다. 문제점을 해결하고 점진적으로 가치를 제공하기 위해, 우리는 수집 백엔드 서비스를 업데이트하여 들어오는 이벤트를 Proto로 변환함으로써 스키마화 작업을 이벤트 생성자와 분리했습니다. 이제 변환된 이벤트는 파케트(Parquet) 파일로 수집되어 분산 스토리지로 업로드되며, 개별 Hive 테이블로 등록됩니다.

다음으로, 분석 이벤트 제공에 드는 비용에 주목했습니다. 이전에는 수집 백엔드가 클라우드 인프라를 기반으로 구축되어 있었습니다. 분석 이벤트는 큐 서비스로 전송되어 버퍼링된 후, 후속 처리 및 분석을 위해 내구성 있는 클라우드 스토리지에 저장되었습니다. 클라우드 큐 서비스는 서비스를 단순화하고 투명한 확장성을 제공했지만, 다른 스트리밍 작업에서 사용하기 어렵고 비용도 더 많이 들었습니다. 이를 해결하기 위해, 우리는 수집 서비스를 Roblox의 데이터 센터로 이전하는 방안을 모색했습니다. 

내부 스토리지 팀은 오픈소스 분산 이벤트 스트리밍 플랫폼을 기반으로 큐-어즈-어-서비스(QaaS)를 구축했습니다. QaaS는 이벤트가 선입선출(FIFO) 순서로 처리되고 짧은 보존 기간 후 삭제되므로, 분석 이벤트 수집을 대체하기에 매우 적합합니다. Roblox에서는 스키마화된 각 이벤트마다 전용 토픽을 생성하고, 파티션 수를 활용해 대규모 이벤트 스트림에 대응합니다. 또한 데이터 팀은 QaaS에서 데이터를 수집하고, 파케트(Parquet) 파일을 생성하며, 이를 내구성 있는 클라우드 스토리지에 업로드하는 전용 서비스를 구축했습니다.

QaaS를 구축하고 파케트 파일을 생성 및 저장하는 전용 서비스를 마련한 후, 데이터 팀은 6개월 동안 섀도 라이팅을 수행하여 데이터 정확성과 확장성을 모두 검증했습니다. 마지막으로, 광범위한 데이터 완전성 및 무결성 검사를 거친 후, 기존 클라우드 큐 서비스에서 분석 이벤트 수집을 성공적으로 마이그레이션했습니다. 이는 중요한 이정표였습니다. 인제스트 경로에서 클라우드 리소스 비용을 제거하고, 이벤트 발생부터 데이터 레이크에 저장되기까지의 지연 시간을 대폭 단축했습니다. 이전에는 3시간이라는 서비스 수준 계약(SLA)을 준수하지 못하는 경우가 잦았으나, 현재는 평균 15분을 꾸준히 달성하고 있습니다. 

이를 통해 엔지니어들은 QaaS에서 데이터를 가져와 스키마화된 이벤트를 기반으로 실시간 이벤트 처리 파이프라인을 구축하여, 안전 및 실시간 추천 기능을 강화할 수 있습니다. 또한 동일한 스키마화 프레임워크와 QaaS 수집 기능을 활용한 변경 데이터 캡처(CDC)를 도입하여, 전체 데이터베이스 덤프 작업을 대폭 줄였습니다. 실시간 분석과 이벤트 스트리밍에서 새로운 사용 사례 발굴에 이르기까지, 우리는 대규모로 더 스마트하고 빠르며 비용 효율적인 데이터 시스템을 혁신하고 구축해 나가고 있습니다. 

이 작업에 귀중한 기여를 해주신 Paul Mou 님께 감사의 말씀을 전합니다.

^{* 2025년 3월 31일 종료된 3개월 기준.}