How strategic database migration + data (re)modeling improved latencies and cut database costs 5X ZEE é o maior negócio de mídia e entretenimento da Índia, cobrindo transmissão de TV, filmes, mídia de streaming e música. ZEE5 é o seu principal serviço de streaming OTT, disponível em mais de 190 países com ~150M usuários ativos mensais. Os engenheiros por trás do sistema sabiam que o crescimento contínuo do negócio enfatizaria sua infraestrutura (assim como as pessoas que revisavam as faturas de banco de dados).Então, a equipe decidiu repensar o sistema antes de causar qualquer ataque cardíaco.Tl;DR, eles projetaram um sistema que é amado internamente e pelos usuários.E Jivesh Threja (Tech Lead) e Srinivas Shanmugam (Arquiteto Principal) se juntaram a nós no Dia dos Namorados no ano passado para compartilhar suas experiências. Eles descreveram os requisitos técnicos para a substituição (neutralidade na nuvem, prontidão de vários locatários, simplicidade de embarque de novos casos de uso, alta transmissão e baixa latência a custos ótimos) e como isso levou ao ScyllaDB. Embalando, eles compartilharam lições aprendidas que poderiam beneficiar qualquer um que considerasse ou usasse o ScyllaDB. 5X cost savings (from $744K to $144K annually) and single-digit millisecond P99 read latency https://youtu.be/nArmqus9fbo?embedable=true Aqui estão alguns destaques dessa conversa... O que é um Heartbeat? “Heartbeat” refere-se a um pedido que é lançado a intervalos regulares durante a reprodução de vídeo na plataforma OTT ZEE5. Esses pedidos simples rastreiam o que os usuários estão assistindo e até onde eles progrediram em cada vídeo. Eles são essenciais para a funcionalidade “continuar assistindo” da ZEE5, que permite aos usuários parar conteúdo em um dispositivo e depois retomá-lo em qualquer dispositivo. Por que mudar? O sistema cardíaco original da ZEE5 era uma rede de bancos de dados diferentes, cada um dos quais lidava com uma parte específica da experiência de streaming.Embora tecnicamente funcional, essa abordagem era cara e os bloqueava em um ecossistema de fornecedores específico. Eles queriam um sistema que não estivesse bloqueado em nenhum provedor de nuvem específico, custaria menos para operar e poderia lidar com sua escala maciça com desempenho consistentemente rápido – especificamente, respostas de milissegundos de um dígito. Além disso, eles queriam a flexibilidade para adicionar novos recursos facilmente e a capacidade de oferecer seu sistema a outras plataformas de streaming. Como Srinivas disse: “Precisava ser multi-tenente pronto para que pudesse ser reutilizado para qualquer provedor OTT. E precisava ser facilmente extensível a novos casos de uso sem grandes mudanças arquitetônicas.” Arquitetura do sistema, antes e depois Aqui está uma olhada em sua arquitetura de sistema original com vários bancos de dados: DynamoDB para armazenar os dados básicos de batimentos cardíacos Amazon RDS para armazenar informações sobre episódios anteriores e próximos Apache Solr para armazenar metadados persistentes Uma instância Redis para cache de metadados Outra instância do Redis para armazenar detalhes de visualização A equipe da ZEE5 considerou quatro opções principais de banco de dados para este projeto: Redis, Cassandra, Apache Ignite e ScyllaDB. Após avaliação e benchmarking, eles escolheram ScyllaDB. O ScyllaDB gerencia tanto a camada de cache quanto a base de dados persistente dentro da mesma infra-estrutura, garantindo uma baixa latência entre regiões, replicação e disponibilidade multi-nuvem. Ele funciona com qualquer fornecedor de nuvem, incluindo Azure, AWS e GCP, e agora oferece suporte gerenciado com um tempo de volta de menos de uma hora. O ScyllaDB gerencia tanto a camada de cache quanto a base de dados persistente dentro da mesma infra-estrutura, garantindo uma baixa latência entre regiões, replicação e disponibilidade multi-nuvem. Ele funciona com qualquer fornecedor de nuvem, incluindo Azure, AWS e GCP, e agora oferece suporte gerenciado com um tempo de volta de menos de uma hora. A nova arquitetura simplifica e suaviza a estrutura anterior da arquitetura do sistema. Agora, todos os eventos de batimento cardíaco são empurrados para o tema de batimento cardíaco, processados através do processamento de fluxo e injetados na nuvem ScyllaDB usando conectores ScyllaDB. Sempre que o conteúdo é publicado, ele é injetado no tema de metadados e, em seguida, inserido na nuvem ScyllaDB através de conectores de metadados. Srinivas conclui: “Com esta nova arquitetura, migramos com sucesso cargas de trabalho de DynamoDB, RDS, Redis e Solr para ScyllaDB. ” 5x cost reduction, bringing our monthly expenses down from $62,000 to around $12,000. Mais profundamente no design Jivesh compartilhou mais sobre seu design de baixo nível... Pipeline de processamento de fluxo em tempo real No processo de processamento de fluxo em tempo real, os batimentos cardíacos são enviados para o ScyllaDB em intervalos regulares. O intervalo de batimentos cardíacos é definido para 60 segundos, o que significa que cada cliente front-end envia um batimento cardíaco a cada 60 segundos enquanto um usuário está assistindo a um vídeo. Esses batimentos cardíacos passam pelo sistema de processamento de fluxo de reprodução, os consumidores de lógica de negócios transformam esses dados no formato necessário – então os dados processados são armazenados no ScyllaDB. Escalável API Layer O primeiro componente da camada de API escalável é o serviço de batimento do coração, que é responsável por lidar com grandes volumes de ingestão de dados.Tópicos processam os dados, depois passam por um serviço de conector e são armazenados no ScyllaDB. Outro serviço de camada de API notável é o serviço Concurrent Viewership Count. Este serviço usa o ScyllaDB para recuperar dados de visualização simultâneos – por usuário ou por ativo (por exemplo, por ID). Gestão de Metadados Caso de Utilização Um dos primeiros grandes desafios que a ZEE5 enfrentou foi gerenciar metadados para sua enorme plataforma OTT. Inicialmente, eles confiaram em uma combinação de três bancos de dados diferentes – Solr, Redis e Postgres – para lidar com suas necessidades extensivas de metadados. Procurando otimizar e simplificar, eles redesenharam seu modelo de dados para trabalhar com o ScyllaDB em vez disso – usando ID como a chave de partição, juntamente com vistas materializadas. Aqui está uma olhada no seu modelo de metadados: create keyspace.meta_data ( id text, title text, show_id text, …, …, PRIMARY KEY((id),show_id) ) with compaction = {‘class’: ‘LeveledCompactionStrategy’ }; Neste modelo, o ID serve como a chave de partição. Uma vez que esta tabela experimenta relativamente poucos escritos (uma escrita ocorre apenas quando um novo ativo é lançado), mas significativamente mais leituras, eles usaram a estratégia de compactação nivelada para otimizar o desempenho. e, de acordo com Jivesh, “Escolher a partição certa e chaves de agrupamento nos ajudou a obter uma latência de milissegundo de um dígito”. Contagem de Caso de Utilização Contagem de visualização é outro caso de uso que eles mudaram para ScyllaDB. Contagem de visualização pode ser rastreada por usuário ou por ID de ativo. ZEE5 decidiu projetar uma tabela onde o ID de usuário serviu como a chave de partição e o ID de ativo como a chave de classificação - permitindo que os dados de visualização sejam consultados de forma eficiente. Eles configuraram o TTL do ScyllaDB para corresponder ao intervalo de batimentos cardíacos de 60 segundos, garantindo que os dados expiram automaticamente após o tempo designado. Jivesh explicou: “Esta tabela é continuamente atualizada com batimentos cardíacos de cada front end e de cada usuário. À medida que os batimentos cardíacos chegam, as contagens de audiência são rastreadas em tempo real e automaticamente apagadas quando o TTL expira. Aqui está o seu modelo de dados de contagem de espectadores: 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 Resultados e Lições Aprendidas O seguinte relatório de teste de carga mostra um desempenho de 41.7K solicitações por segundo. Jivesh comentou: “Mesmo com uma taxa de transmissão tão alta, conseguimos atingir uma latência de escrita de microsegundo e uma latência média de leitura de microsegundo. Ele então continuou a compartilhar alguns fatos que lançaram luz sobre a escala da implantação do ScyllaDB da ZEE5: “Temos cerca de 9TB no ScyllaDB. Mesmo com um volume tão grande de dados, é capaz de lidar com latências dentro de microsegundos e um milissegundo de um único dígito, o que é bastante enorme. A cada segundo, estamos escrevendo tantos dados no ScyllaDB e obtendo tantos dados a partir dele Nós processamos mais de 100 bilhões de batimentos cardíacos em um dia. A conversa foi encerrada com as seguintes lições aprendidas: A modelagem de dados é o fator mais crítico na obtenção de latências de milissegundos de um único dígito. Escolha a configuração de quórum correta e a estratégia de compactação. Por exemplo, um batimento cardíaco precisa ser escrito para cada nó antes de ser lido, ou um quórum local é suficiente? Selecionar o quórum certo garante o melhor equilíbrio entre a latência e os requisitos de SLA. Escolha Partition e Clustering Keys sabiamente – não é fácil modificá-los mais tarde. Use Visualizações Materializadas para pesquisas mais rápidas e evite consultas de filtro. Use declarações preparadas para melhorar a eficiência. Por exemplo, no modelo de metadados, 20 consultas sincronizadas foram executadas em paralelo, e o ScyllaDB as processou dentro de milissegundos. Clientes ScyllaDB conscientes da zona ajudam a reduzir os custos de rede cross-AZ (Availability Zone).A recuperação de dados dentro da mesma AZ minimiza a latência e reduz significativamente os custos de rede.
