Singular 어떻게 놀랍도록 빠른 앱 ROI 분석을 제공하는가

모바일 앱 마케터는 앱 ROI를 정확하게 측정하기 위해 점점 더 세분화된 데이터에 접근해야 하는데, 이는 필연적으로 엄청난 양의 데이터를 실시간으로 처리해야 한다는 것을 의미합니다. 이로 인해 데이터베이스 쿼리 속도가 급격히 느려져 마케터의 업무에 병목 현상이 발생하고, 원하는 만큼 빠르고 빈번하게 최적화 작업을 진행하지 못하게 됩니다. 점점 더 빨라지는 속도에 대한 요구 속에서 끊임없이 쏟아지는 데이터의 홍수에 직면하는, 이것이 바로 현대 모바일 마케팅의 딜레마라고 할 수 있습니다.

Singular 에서는 인 퍼블리셔 ROI 출시를 앞두고 이 문제가 중요하게 대두되었습니다 . 퍼블리셔 ROI를 통해 마케터는 광고 네트워크의 인벤토리를 퍼블리셔별로 분석하고 최고의 성과를 내는 개별 사이트와 앱을 신속하게 파악할 수 있습니다.

이 기능에 대한 초기 테스트 결과, 게시자 수준 데이터에 대한 고객 쿼리에 엄청난 컴퓨팅 성능이 요구되는 것으로 나타났습니다 Singular 에서 일반적으로 쿼리를 위해 수집 및 처리되는 데이터 양의 50~100배 였습니다. 테스트 중에 쿼리 시간이 급증하는 것을 확인하면서, 우리는 중요한 스타트업 이정표에 도달했음을 깨달았습니다. 바로 기존 데이터베이스 기술의 한계를 넘어섰다는 것이었습니다.

최신 혁신 기술을 출시하고 모바일 앱 마케터에게 점점 더 세분화된 마케팅 데이터에 대한 빠르고 유연한 액세스를 지속적으로 제공하기 위해, 10억 행에 달하는 데이터에 대한 임시 쿼리를 1초 미만의 성능으로 처리할 수 있는 새로운 데이터 파이프라인과 데이터 저장소를 도입해야 했습니다.

이 게시물에서는 데이터베이스 기술의 특정 구성 요소를 재구축하여 고객 쿼리 속도를 획기적으로 향상시킨 방법을 설명합니다. 경우에 따라 최대 150배 .

하지만 고객 문의 처리 속도를 어떻게 향상시켰는지 자세히 알아보기 전에, 모바일 앱 마케터들의 변화하는 요구 사항과 Singular처럼 유연한 분석 플랫폼을 제공하는 데 있어 우리가 직면한 방대한 데이터 문제에 대해 간략히 설명하는 것이 좋겠습니다.

Singular개발 초기부터 저희는 고객들이 Singular에서 실행하는 쿼리 유형을 면밀히 관찰해 왔습니다. 마케터들이 쿼리에 사용할 만한 차원을 예측하는 시스템을 구축하기 위해 패턴을 파악하려고 노력했습니다. 하지만 곧 고객들이 실행하는 보고서와 쿼리가 매우 다양하고, 다양한 차원과 측정항목의 조합이 무수히 많다는 것을 알게 되었습니다.

테이블의 행이라고 생각해 보세요. 예를 들어 100개의 서로 다른 게시자를 통해 광고를 게재하는 광고 네트워크에서 광고한다고 가정해 보겠습니다. 네트워크 전체의 ROI를 확인하고 싶다면 Singular에서는 단 한 줄의 데이터만 있으면 됩니다. 하지만 실적이 좋은 게시자와 그렇지 않은 게시자를 구분하기 위해 각 게시자의 개별 실적을 분석하려면 100개의 행이 필요합니다. 이제 4개의 다국가 캠페인을 운영하고 특정 지역에서 특정 게시자의 실적이 특히 좋은지 확인하고 싶다면 400개의 행이 필요합니다. iOS와 Android별로 데이터를 분석하고 싶다면 800개의 행이 필요하죠.

이러한 복잡성 때문에 우리는 요구 사항을 충족할 수 있는 데이터베이스 아키텍처에 대한 첫 번째 결론을 내릴 수 있었습니다. Singular 이 매우 다양하고 쿼리 차원의 조합이 무수히 많기 때문에, 우리는 즉발 쿼리 최종 형태 로 데이터베이스에 입력해야 했습니다 .

Singular 에서의 데이터 수집

Singular 에서는 마케팅 데이터 수집 처리합니다 . 각 수집 작업은 특정 고객에 대해 제3자 마케팅 협력업체로부터 1~30일 이내의 데이터를 수집하는 역할을 합니다. 저희의 데이터 수집 파이프라인은 각 작업에서 수집하는 데이터의 양(30일간의 세부적인 Facebook 통계는 엄청난 양입니다)과 협력업체들이 정기적으로 데이터를 소급 업데이트하는 경향이 있다는 점에서 독특합니다. 따라서 Singular 오래된 통계를 최신 데이터로 지속적으로 교체해야 합니다.

이전에는 데이터 수집 파이프라인이 MySQL에 데이터를 로드하고 데이터를 쿼리하고 업데이트하는 방식으로 다양한 수집 로직을 실행했습니다. 데이터가 준비된 후에는 대시보드와 API에서 트리거되는 쿼리도 MySQL에 접근했습니다.

이 방식은 게시자 수준의 데이터 수집 및 쿼리 기능을 도입하기 전까지는 잘 작동했습니다. 하지만 데이터 양이 급증하면서 MySQL로의 로딩 속도가 느려져 파이프라인에 병목 현상이 발생했습니다. 게다가 이처럼 방대한 데이터에 대한 분석 쿼리를 실행하는 데에도 시간이 너무 오래 걸렸습니다.

새로운 공급망 설계

끊임없이 증가하는 데이터 양과 무한한 작업량을 지원하기 위해, 우리는 MySQL과는 달리 수평 확장이 가능한 파이프라인을 구축하고자 했습니다. 이러한 요구 사항을 충족하기 위해 Amazon Simple Storage Service(S3)를 선택하는 것은 당연한 결정이었습니다. 우리는 이미 MySQL에 데이터를 삽입하기 전에 S3를 사용하여 데이터를 백업하고 있었습니다. 게다가 S3는 수평 확장이 가능하고, 운영 관리가 전혀 필요 없으며, Amazon Web Services(AWS) 환경에서 빠른 다운로드/업로드 속도를 제공합니다.

따라서, 저희의 새로운 데이터 수집 아키텍처는 S3를 기반으로 하며, MySQL에는 메타데이터만 저장됩니다. MySQL을 직접 쿼리하고 업데이트하는 대신, 파이프라인의 각 구성 요소는 S3 파일을 입력으로 받아, 수신한 데이터와 구성 요소가 생성한 새로운 정보가 담긴 또 다른 S3 파일을 다음 구성 요소로 전달합니다.

저희 파이프라인의 최종 단계에서는 고객, 마케팅 소스 및 날짜별 최신 통계 데이터가 담긴 S3 버킷으로 데이터를 전송합니다. 이를 통해 데이터 수집 작업을 병렬로 실행할 수 있으며, 이 버킷이 시스템의 핵심 데이터 소스가 됩니다.

새로운 데이터 저장소를 향하여

최종 형태로 S3에 저장된 데이터를 바로 쿼리할 수 있었기 때문에, 데이터 저장소 선택에 있어 유연성이 매우 높았습니다. 이전에 API와 MySQL 사이에 작은 추상화 계층을 구축해 두었기에, 어떤 쿼리 언어나 스키마에도 맞춰 조정할 수 있었습니다. 따라서 새로운 데이터베이스를 평가할 때, 전환 비용이 매우 낮았기 때문에 최종 결정이 아니라는 것을 미리 알고 있었습니다. 결국, 마케팅 분석 데이터에 대한 집계 쿼리라는 특정 요구 사항에 맞춰 개발된 오픈 소스 데이터 저장소인 Druid를 선택했습니다.

구현 후 결과는 매우 만족스러웠습니다. Druid를 사용하니 이전에는 60초가 걸리던 1~2초 30초가 걸리던 쿼리는 1초도 채 걸리지 기존 시스템에 비해 데이터베이스 쿼리 시간이 최대 150배

이러한 모든 발전 과정을 거쳐 올해 초, 일부 고객을 대상으로 비공개 베타 테스트를 통해 퍼블리셔 수준 ROI 기능을 활성화하기 시작했습니다. 이 베타 테스트는 새로운 아키텍처에 대한 궁극적인 스트레스 테스트 역할을 했습니다.

세부적인 정보와 빠른 속도가 승리의 열쇠입니다

퍼블리셔 수준 ROI가 무엇인지, 그리고 왜 획기적인 개념인지 다시 한번 설명하기 위해 업계 배경을 간략히 살펴보겠습니다. 광고 네트워크는 일반적으로 수백, 때로는 수천 개의 웹사이트와 앱에 게재되는 광고 슬롯으로 구성된 인벤토리를 구매합니다. 이러한 웹사이트와 앱은 개별적으로 "퍼블리셔"라고 불리며, 마케터의 광고가 게재되는 곳입니다.

최근 몇 년 동안 모바일 앱 마케터들은 가장 가치 있는 트래픽을 파악하기 위해 퍼블리셔 수준의 성과에 대한 더 자세한 정보를 요구해 왔습니다. 이에 네트워크들은 마케터들에게 제공하는 성과 데이터에 퍼블리셔 ID를 포함시켜 대응해 왔습니다. 마케터들은 이러한 퍼블리셔 또는 사이트 ID를 활용하여 성과를 내는 퍼블리셔에 대한 투자 비중을 늘리고, 성과가 저조한 퍼블리셔에 대한 투자 비중을 줄이거나 '블랙리스트'에 추가하는 등 최적화를 진행합니다.

하지만 과거에는 여러 네트워크에 걸쳐 퍼블리셔를 최적화하는 것이 매우 힘들고 오류 발생 가능성이 높은 작업이었습니다. 마케터들은 여러 대시보드를 오가며 다루기 힘든 엑셀 파일을 수동으로 업데이트해야 했기 때문입니다. 특히 클릭률이나 설치 횟수뿐 아니라 ROI로 측정되는 사용자 품질을 기준으로 퍼블리셔의 성과를 분석하고자 하는 마케터들에게는 이러한 과정이 더욱 고통스러웠습니다.

Singular 모든 마케팅 데이터를 한 곳에 수집한 후, 추적 링크에서 가져온 수익 및 이벤트 데이터와 결합하여 앱 ROI 및 기타 전체 퍼널 비즈니스 지표를 파악할 수 있도록 자동화된 프로세스를 제공합니다.

하지만, 여기서 보여드린 것처럼, 일단 수집, 보강 및 결합된 퍼블리셔 수준의 데이터를 빠르고 유연하게 만드는 것은 완전히 다른 차원의 문제입니다. 바로 이러한 이유로 저희는 새로운 파이프라인과 데이터 저장소에 막대한 투자를 했습니다. 모바일 앱 마케터는 세부적인 정보와 빠른 속도 모두를 필요로 하며, 그 결과가 이를 증명한다고 자신 있게 말씀드릴 수 있습니다.

저희는 새로운 Druid 기반 시스템을 사용하는 베타 테스트 고객에게 퍼블리셔 수준의 ROI를 제공하기 시작했으며, 고객들은 데이터 양이 크게 증가했음에도 불구하고 매우 빠른 로딩 속도를 경험했다고 보고했습니다.

성능 향상은 게시자 수준 쿼리에만 국한되지 않습니다. Singular 사용자 수준 파악하는 것과 같이 데이터 집약적인 쿼리도 새로운 데이터베이스 기술의 발전 덕분에 그 어느 때보다 빨라졌습니다.