Search
Duplicate

[사례연구] Tapjoy, SingleStore기반으로실시간 광고 최적화를 통해 모바일 광고 플랫폼 강화

문서번호: 71-395147
Tapjoy는 SingleStore의 열성적인 초기 고객으로 이 게시글에서 그들이 왜 SingleStore DB로 기존 DB를 변경했는지, 이를 통해 무엇을 얻게 되었는지 몇 가지 주요 내용을 설명합니다.
광고와 앱 수익화의 선두주자인 Tapjoy는 비디오 광고, 제안, 보상을 통하여 앱 제공자가 사용자를 늘리고, 모바일 앱을 통해 수익을 창출할 수 있도록 지원을 하는 기업입니다. Tapjoy는 3만개 이상의 모바일 앱에 임베디드용 SDK를 탑재하였고, 홍보를 통해 앱의 실사용자를 한 달에 8억명 이상을 증가 시켰으며, 전세계에 12개 이상의 지역 사무소를 보유하고 있습니다.
Tapjoy의 엔지니어링 팀도 글로벌하게 배치되어 있으며, 이들은 하루에 수십억 개의 데이터를 처리를 위한 강력한 백엔드 인프라 아키텍처를 구축하여 운영하고 있습니다. 이 백엔드 인프라에는 데이터 스트리밍 처리를 위한 Kafka, Amazon RDS, MySQL, Postgre SQL, Google BigQuery 등의 다양한 데이터베이스 솔루션이 있습니다. 이들은 문제 해결, 변화관리, 공급업체 평가 등을 위한 엄격한 규정과 절차를 갖고 있습니다.
하지만 그럼에도 Tapjoy는 MySQL에서 실행되는 워크로드로 인해 성능 문제에 직면했고 다양한 대안 솔루션을 세심하게 평가하고 테스트한 후 SingleStore DB를 적용하였습니다.

Tapjoy의 요구사항

Tapjoy의 성장은 종종 더 잘 확장되는 새로운 구성 요소를 통해 스택을 개선하도록 유도합니다. 몇 년 전, Tapjoy는 MySQL에 재무 데이터를 포함한 주요 워크로드를 저장하고 있었습니다. 이 워크로드는 주요 TapJoy 규칙의 예외 영역이었습니다. 아래와 같이 널리 알려진 MySQL 문제들로 인해 일반적으로 사이즈와 규모가 큰 애플리케이션은 MySQL을 사용하지 않습니다.
MySQL은 Oracle 소유이고, MySQL 로드맵 불투명
주요 워크로드의 성능 저하는 모든 디지털 기반 기업에서 유사하게 발생하는 것과 같이 Tapjoy 비즈니스에도 위험을 초래합니다.
예를 들어,
비즈니스를 효율적으로 성장시킬 수 없거나
기술 인력에 대한 요구가 증가하거나
SLA를 준수하기 어렵거나
서비스 품질이 저하와 같은 문제들이 발생을 합니다.
Tapjoy 기술팀은 아래와 같은 엄격한 기준을 적용해서 단시간 내에 대안 솔루션을 평가했습니다.
ACID 준수 : 관계형 데이터베이스(기존 RDBMS 또는 NewSQL)여야 함. NoSQL은 고려 대상이 아님
확장성 : 확장성이 용이하게 설계되어야 함.(DevOps 팀에게 확장이 불가한 시스템을 지원하라고 요청하기 어려움)
10배 성능 : 기본 보다 최소 10배 이상의 수요를 충족하기 위해 확장이 되어야 함
Drop-in 교체 : MySQL을 원활하게 “스왑 인(Swap-in) 되어야 함(변경은 가능한 빠르고 쉬워야 하고 코드 호환이 가능해야 함)
MySQL에서 발생한 문제는 확장성이 필요한 곳은 이었습니다.
MySQL의 평가에선 확장성이 문제 됐습니다. 일반적으로 이런 확장성은 MySQL만의 문제가 아니었습니다 ; 대체로 타 RDBMS들도 Tapjoy가 필요로 하는 범위까지 확장할 수 있는 기능이 부족했습니다.

Tapjoy의 고려사항

이러한 모든 기준 속에서 Tapjoy는 진지하게 고려할 가치가 있는 몇 가지 대안 들을 찾아냈습니다.
Sharded MySQL : 많은 조직이 Sharding MySQL을 통해 확장성 요구를 충족합니다. 하지만 엔지니어링 팀과 운영팀 모두 이 도전적인 일을 맡기를 원하지 않았고, 이미 확장성을 제공하지 못하고 있는 MySQL 시스템을 계속해서 사용하려고도 하지 않았습니다.
AuroraDB : AWS RDS(Relational Data Service)의 AuroraDB 옵션은 MySQL과 와이어드 호환(Wire-compatible)이 가능한 큰 장점입니다. 하지만 테스트 결과 성능의 기대에 도달하지는 못했습니다. AuroraDB는 설계상 확장가능하지만 실제로는 확장성에 대한 Tapjoy의 요구를 충족시키지 못했습니다.
SingleStore : 이미 Tapjoy의 Data science 팀에서 SingleStore를 사용하고 있었습니다. 이 팀은 SingleStore를 ACID 호환이 되고 성능과 용량 수용을 위해 완벽히 확장이 가능하고 탁월한 성능을 제공한다고 보증했습니다. 그리고, AuroraDB와 마찬가지로 MySQL과 와이어드 호환(Wire-compatible)이 가능했습니다.
SingleStore는 처음부터 Tapjoy와 같은 까다로운 요구사항을 충족하도록 설계되어었습니다.

엄청난 성능을 제공하는 SingleStore

엔지니어링 팀은 대안 DB 솔루션들과 SingleStore를 비교했습니다. 기존 솔루션들은 SingleStore보다 휠씬 성능이 낮아서 SingleStore가 가장 돋보였습니다.
Tapjoy 엔지니어링 블로그에 SingleStore로의 전환한 것에 대해 Sean Kelly는 다음과 같이 포스팅했습니다.
"SingleStore는 우리가 원하는 모든 요소를 가지고 있었고, 초기 파일럿을 실시한 결과 명시된 요구 사항을 모두 충족할 것임을 확인했습니다. 하지만 그 증거만으로는 불충분해서 실 환경과 유사한 사이즈의 클러스터를 구축하고 운영 데이터를 복제해서 우리가 적용하고자 사례에 맞는지 확인을 위한 일련의 테스트과정을 모두 성공적으로 거쳤습니다.”
테스트에는 20배의 스트레스 테스트 부하 발생과 기존 데이터베이스 솔루션 대비 2배 많은 과거 데이타에 기존 클러스터의 부하 실행이 포함됐습니다.
단일 파트너의 재무 데이터 집계(계속 반복해야 하는 작업)하는데 기존 솔루션에서 68초가 소요되었으나 Single Store에서 1.23초가 소요되어 55배 더 빠른 성능을 보여주었습니다.
월별 보고는 특히 고객이 재무 보고서를 요구하거나 청구서를 지불할 때 매우 중요합니다. 기존 시스템에서는 한 달 동안 전체 플랫폼의 단일 재무 데이터 포인트를 합산하는데 28분이 소요되었으며, Singlestore에서는 1.1초가 소요되어 처리속도가 1500배 이상 증가했니다.
마케팅은 재무와 함께 모든 사내 데이터 시스템의 중요한 구성 요소로서, 다양한 목적으로 최근 활성 고객 목록을 정기적으로 수집해야 합니다. 이전 시스템에서는 수집하는데 24초가 소요되었고, SingleStore의 경우 3초가 소요되어 8배가 향상되었습니다.
부하 테스트 결과에서 나타난 바와 같이, SingleStore는 Tapjoy의 요구사항을 모두 충족했고, 부하 테스트에서 기존 데이터베이스보다 월등한 성능을 보여주었습니다.
또한 SingleStore는 Tapjoy의 다른 요구 사항인 AID 준수, SQL 호환성, 확장성 및 MySQ 대체할 수 있는 기능도 충족시켰습니다.

결론

금번 활용 사례에서 SingleStore를 채택한 후, Tapjoy는 다양한 사례에서 SingleStore를 사용하게 되었습니다. SingleStore와 Tapjoy 양사가 협업한 결과를 발표했습니다.
Tapjoy의 아키텍처에 대한 보다 최신 프레젠테이션인 '모바일 광고를 위한 실시간 데이터 사이언스 서비스 구축'에서 볼 수 있습니다. 또한 까다로운 데이터 문제를 해결하기 위해 SingleStore를 사용해 보고 싶다면 SingleStore를 무료로 사용해 보시거나 SingleStore Korea 팀에게 문의하시기 바랍니다.