How strategic database migration + data (re)modeling improved latencies and cut database costs 5X ZEE는 방송 TV, 영화, 스트리밍 미디어 및 음악을 다루는 인도의 최대 미디어 및 엔터테인먼트 비즈니스입니다. ZEE5는 190 개국 이상에서 사용할 수있는 주요 OTT 스트리밍 서비스입니다. ~ 150M 월간 활성 사용자. 시스템의 엔지니어들은 지속적인 비즈니스 성장이 인프라를 강조할 것이라는 것을 알았습니다 (그리고 데이터베이스 요금을 검토하는 사람들도 그렇습니다).그래서 팀은 심장마비를 일으키기 전에 시스템을 다시 생각하기로 결정했습니다. TL;DR, 그들은 내부적으로 그리고 사용자들에 의해 사랑받는 시스템을 설계했습니다.그리고 Jivesh Threja (Tech Lead)와 Srinivas Shanmugam (Chief Architect)는 작년 발렌타인 데이에 경험을 공유하기 위해 우리와 함께했습니다. 그들은 교체를위한 기술적 요구 사항 (클라우드 중립성, 다중 임대자 준비, 새로운 사용 사례의 삽입의 단순성, 최적의 비용으로 높은 전송량과 낮은 지연률)과 ScyllaDB를 어떻게 이끌었는지 설명했다. 포장, 그들은 ScyllaDB를 고려하거나 사용하는 모든 사람에게 유익 할 수있는 교훈을 공유했습니다. 5X cost savings (from $744K to $144K annually) and single-digit millisecond P99 read latency https://youtu.be/nArmqus9fbo?embedable=true 다음은 그 대화에서 나온 몇 가지 주목... Heartbeat 란 무엇입니까? "Heartbeat"는 ZEE5 OTT 플랫폼에서 비디오 재생 중에 정기적으로 발사되는 요청을 의미합니다.이 간단한 요청은 사용자가 시청하고있는 것을 추적하고 각 비디오에서 얼마나 발전했는지 의미합니다.이 요청은 ZEE5의 "Continue Watch" 기능에 필수적이며, 사용자가 하나의 장치에서 콘텐츠를 중단 한 다음 모든 장치에서 재생할 수 있습니다. 왜 변하는가 ZEE5의 원래 심장 박동 시스템은 각각 스트리밍 경험의 특정 부분을 처리하는 다른 데이터베이스의 웹이었지만 기술적으로 기능적이었지만이 접근 방식은 비싸고 특정 공급자 생태계에 잠겨있었습니다. 그들은 어떤 특정 클라우드 공급 업체에 잠겨 있지 않은 시스템을 원했고, 운영 비용이 저렴하고, 지속적으로 빠른 성능으로 대규모 규모를 처리 할 수 있었으며, 특히 단일 숫자 밀리초 응답을 원했습니다.또한 새로운 기능을 쉽게 추가하고 시스템을 다른 스트리밍 플랫폼에 쉽게 제공 할 수있는 유연성을 원했습니다. 시스템 아키텍처, 이전과 이후 다음은 여러 데이터베이스를 포함한 원래 시스템 아키텍처를 살펴보겠습니다: DynamoDB는 기본적인 심장 박동 데이터를 저장합니다. Amazon RDS: 다음 에피소드 및 이전 에피소드 정보를 저장 Apache Solr, Persistent Metadata 저장하기 메타데이터를 캐시하기 위한 One Redis instance to cache metadata 시청자 세부 사항을 저장하기 위한 또 다른 Redis 인스턴스 ZEE5 팀은이 프로젝트에 대한 네 가지 주요 데이터베이스 옵션을 고려했습니다 : Redis, Cassandra, Apache Ignite, ScyllaDB. 평가 및 벤치마킹 후, 그들은 ScyllaDB를 선택했습니다. 지속적인 데이터베이스 위에 추가적인 캐시 레이어가 필요하지 않습니다. ScyllaDB는 동일한 인프라 내에서 캐시 레이어와 지속적인 데이터베이스를 모두 관리하여 지역 간 낮은 지연, 복제 및 다중 클라우드 준비를 보장합니다.It works with any cloud vendor, including Azure, AWS, and GCP, and now offers managed support with a turnaround time of less than one hour. 지속적인 데이터베이스 위에 추가적인 캐시 레이어가 필요하지 않습니다. ScyllaDB는 동일한 인프라 내에서 캐시 레이어와 지속적인 데이터베이스를 모두 관리하여 지역 간 낮은 지연, 복제 및 다중 클라우드 준비를 보장합니다.It works with any cloud vendor, including Azure, AWS, and GCP, and now offers managed support with a turnaround time of less than one hour. 새로운 아키텍처는 이전의 시스템 아키텍처 구조를 단순화하고 부드럽게합니다. 이제 모든 심장 박동 이벤트가 심장 박동 주제로 밀려, 스트림 처리를 통해 처리되고 ScyllaDB 커넥터를 사용하여 ScyllaDB 클라우드에 흡수됩니다.When content is published, it is ingested into their metadata topic and then inserted into ScyllaDB Cloud via metadata connectors. Srinivas는 “이 새로운 아키텍처를 사용하여 DynamoDB, RDS, Redis 및 Solr에서 ScyllaDB로 워크로드를 성공적으로 마이그레이션했습니다. ” 5x cost reduction, bringing our monthly expenses down from $62,000 to around $12,000. 디자인에 깊이 들어가기 Jivesh는 낮은 수준의 디자인에 대해 더 많이 공유했습니다. 실시간 스트림 처리 파이프라인 실시간 스트림 처리 파이프라인에서 심장 박동은 정기적으로 ScyllaDB로 전송됩니다. 심장 박동 간격은 60초로 설정되며, 이는 모든 프론트 엔드 클라이언트가 사용자가 비디오를 시청하는 동안 60초마다 심장 박동을 보내는 것을 의미합니다.이 심장 박동은 재생 스트림 처리 시스템을 통과하고 비즈니스 논리 소비자는 해당 데이터를 필요한 형식으로 변환합니다 – 그런 다음 처리 된 데이터는 ScyllaDB에 저장됩니다. SCALABLE API 레이어 확장 가능한 API 계층의 첫 번째 구성 요소는 심장 박동 서비스이며, 이는 대량의 데이터 섭취를 처리하는 데 책임이 있습니다.Topics는 데이터를 처리한 다음 커넥터 서비스를 통과하여 ScyllaDB에 저장됩니다. 또 다른 주목할만한 API 레이어 서비스는 Concurrent Viewership Count 서비스입니다.이 서비스는 ScyllaDB를 사용하여 동시에 시청률 데이터를 검색합니다 – 사용자 당 또는 자산 당 (예를 들어, ID 당).예를 들어, 영화가 출시되면이 서비스는 영화를 어느 시점에서 얼마나 많은 사용자가 시청하고 있는지 알 수 있습니다. 메타데이터 관리 사용 사례 ZEE5가 직면한 첫 번째 주요 도전 중 하나는 대규모 OTT 플랫폼을위한 메타데이터를 관리하는 것이 었습니다. 처음에는 Solr, Redis 및 Postgres라는 세 가지 다른 데이터베이스의 조합을 사용하여 광범위한 메타데이터 요구를 처리했습니다.Optimizing and simplifying, they redesigned their data model to work with ScyllaDB instead – using ID as the partition key, along with materialized views. 여기 그들의 메타데이터 모델을 살펴보자: create keyspace.meta_data ( id text, title text, show_id text, …, …, PRIMARY KEY((id),show_id) ) with compaction = {‘class’: ‘LeveledCompactionStrategy’ }; 이 모델에서 ID는 파티션 키로 작동합니다.이 테이블은 비교적 적은 글쓰기를 경험하기 때문에 (새로운 자산이 출시될 때만 글쓰기가 발생하지만 훨씬 더 많은 글쓰기를 읽기 때문에, 그들은 Leveled Compaction Strategy를 사용하여 성능을 최적화했습니다.And, according to Jivesh, “choosing the right partition and clustering keys helped us get a single-digit millisecond latency.” Viewership Count Use 케이스 Viewership Count는 ScyllaDB로 이동한 또 다른 사용 사례입니다. Viewership count는 사용자 당 또는 자산 ID 당 추적 할 수 있습니다. ZEE5는 사용자 ID가 파티션 키로, 자산 ID가 정렬 키로 작용하는 테이블을 설계하기로 결정했습니다. 그들은 ScyllaDB의 TTL을 60초 심박수 간격과 일치하도록 설정하여 지정된 시간 이후에 데이터가 자동으로 만료되는 것을 보장합니다.또한, ScyllaDB의 Time-Window Compaction Strategy를 사용하여 메모리에서 데이터를 효율적으로 관리하여 구성된 TTL에 따라 만료된 레코드를 삭제했습니다. Jivesh는 "이 테이블은 모든 프론트 엔드와 모든 사용자의 심장 박동으로 지속적으로 업데이트됩니다. 심장 박동이 도착하면 시청자 수가 실시간으로 추적되고 TTL이 만료되면 자동으로 삭제됩니다. 여기에 그들의 시청자 계산 데이터 모델이 있습니다 : CREATE TABLE keyspace.USER_SESSION_STREAM ( USER_ID text, DEVICE_ID text, ASSET_ID text, TITLE text, …, PRIMARY KEY((USER_ID), ASSET_ID) ) WITH default_time_to_live = 60 and compaction = { 'class' : 'TimeWindowCompactionStrategy' }; ScyllaDB 결과 및 배운 교훈 다음 로드 테스트 보고서는 초당 41.7K 요청의 통과량을 보여줍니다.This benchmark was conducted during the database selection process to evaluate performance under high load. Jivesh는 "이렇게 높은 전송량에도, 우리는 microsecond 쓰기 지연과 평균 microsecond 읽기 지연을 달성 할 수있었습니다.이 실제로 ScyllaDB가 할 수있는 것에 대한 명확한 견해를주었습니다. 그는 다음과 같이 ZEE5의 ScyllaDB 배포의 규모에 대한 몇 가지 사실을 공유했습니다. "우리는 ScyllaDB에서 약 9TB를 가지고 있습니다.이 큰 양의 데이터에도 불구하고 마이크로 초 이내의 지연 시간과 단일 숫자 밀리초를 처리 할 수 있습니다. 우리는 매일 백만 명의 동시 시청자 수를 기록하고 있으며, 매초마다 ScyllaDB에 너무 많은 데이터를 삽입하고 그것에서 너무 많은 데이터를 얻고 있습니다. 우리는 하루에 100 억 번 이상의 심장 박동을 처리합니다.이것은 매우 거대합니다. " 토론은 다음과 같은 교훈으로 포장되었습니다 : 데이터 모델링은 단일 숫자 밀리초 지연을 달성하는 데 가장 중요한 요소입니다. 예를 들어, 각 노드가 읽을 수 있기 전에 심장 박동을 작성해야 하나요, 아니면 로컬 쿼럼이 충분합니까? 파티션 및 클러스터링 키를 현명하게 선택하십시오 - 나중에 수정하는 것은 쉽지 않습니다. Materialized Views를 사용하여 더 빠른 검색을 하 고 필터 쿼리를 피할 수 있습니다.Querying across partitions can degrade performance. 효율성을 향상시키기 위해 준비된 진술을 사용하십시오. 예를 들어 메타데이터 모델에서는 20개의 동기화된 쿼리를 동시에 실행했으며, ScyllaDB는 밀리초 이내에 그들을 처리했습니다. Zone-aware ScyllaDB 클라이언트는 cross-AZ(Availability Zone) 네트워크 비용을 줄이는 데 도움이 됩니다.Fetching data within the same AZ minimizes latency and significantly reduces network costs.
