Rethinking latency-sensitive DynamoDB apps for multicloud, multiregion deployment Todo o processo de entrega de um anúncio ocorre dentro de 200 a 300 milissegundos.Nossas pesquisas de banco de dados devem ser concluídas em milissegundos de um único dígito.Com bilhões de transações diárias, o banco de dados deve ser rápido, escalável e confiável. – Todd Coleman, co-fundador técnico e arquiteto-chefe da Yieldmo Todo o processo de entrega de um anúncio ocorre dentro de 200 a 300 milissegundos.Nossas pesquisas de banco de dados devem ser concluídas em milissegundos de um único dígito.Com bilhões de transações diárias, o banco de dados deve ser rápido, escalável e confiável. – Todd Coleman, co-fundador técnico e arquiteto-chefe da Yieldmo O negócio de publicidade on-line da Yieldmo depende do processamento de centenas de bilhões de pedidos de anúncios diários com respostas de latência subsecundária. Os serviços da empresa dependem inicialmente do DynamoDB, que a equipe valorizava pela simplicidade e estabilidade. No entanto, os custos do DynamoDB estavam se tornando insustentáveis em escala e a equipe precisava de flexibilidade multicloud à medida que a Yieldmo expandiu para novas regiões. Em um discurso recente em Todd Coleman, co-fundador técnico e arquiteto-chefe da Yieldmo, compartilhou os desafios técnicos enfrentados pela empresa e por que a equipe finalmente avançou com a API compatível com o DynamoDB da ScyllaDB. Monstros da Escala Você pode assistir a sua conversa completa abaixo ou continuar lendo para um resumo. https://youtu.be/sk0mIiaOwM8?embedable=true LAG = Negócios Perdidos O Yieldmo é uma plataforma de publicidade on-line que conecta editores e anunciantes em tempo real como um carregamento de página. Quase todos os pedidos de anúncios desencadeiam uma consulta de banco de dados que obtém insights de aprendizagem de máquina e informações de identidade de dispositivo. Leilões efetivos Ajudar os parceiros a decidir se oferecer Acompanhe quais anúncios já foram exibidos em um dispositivo para que os anunciantes possam gerenciar os limites de frequência e otimizar a entrega de anúncios Todo o pipeline de anúncios é concluído em apenas 200 a 300 milissegundos, com a maior parte desse tempo consumido por parceiros avaliando e colocando ofertas. Quando um usuário visita um site, um pedido de anúncio é enviado para a Yieldmo. A plataforma da Yieldmo analisa o pedido. Ele solicita anúncios potenciais de seus parceiros. Ele realiza um leilão para determinar a oferta vencedora. A pesquisa de banco de dados deve ocorrer antes de qualquer chamada para parceiros. E essas pesquisas devem ser concluídas com latências de milissegundos de um único dígito. Coleman explicou: “Com bilhões de transações diárias, a base de dados deve ser rápida, escalável e confiável. DynamoDB Dores de Crescimento A infraestrutura de produção da Yieldmo é executada na AWS, então o DynamoDB foi uma escolha lógica à medida que a equipe construiu seu aplicativo. Em primeiro lugar, o DynamoDB estava se tornando cada vez mais caro à medida que o negócio crescia.Em segundo lugar, a empresa queria a opção de executar servidores de anúncios em provedores de nuvem além da AWS. Coleman compartilhou: “Em algumas regiões, por exemplo, os centros de dados da Costa Leste dos EUA, AWS e GCP [Google Cloud Platform] estão suficientemente próximos para que a latência seja mínima. Lá, não há problema em atingir nosso banco de dados DynamoDB a partir de um servidor de anúncios executado em GCP. No entanto, quando tentamos lançar um aglomerado de serviço de anúncios baseado em GCP em Amsterdã enquanto acessávamos o DynamoDB em Dublin, a latência era muito alta. Alternativas ao DynamoDB A equipe da Yieldmo começou a explorar alternativas ao DynamoDB que se encaixariam em suas cargas de trabalho de banco de dados extremamente pesadas em leitura. Um fluxo contínuo de dados em tempo real de seus parceiros, essencial para combinar os dados da Yieldmo com os seus Atualizações de lote impulsionadas por insights de aprendizado de máquina derivados de seus dados históricos Dado esse equilíbrio de leituras de alta frequência e escrituras estruturadas, eles estavam procurando um banco de dados que pudesse lidar com acesso em grande escala, de baixa latência, enquanto gerenciava eficientemente atualizações simultâneas sem degradação no desempenho. A equipe primeiro considerou permanecer com o DynamoDB e adicionar uma camada de cache. no entanto, eles descobriram que o cache não poderia corrigir o problema de latência geográfica e as falhas de cache seriam ainda mais lentas com esta opção. Eles também exploraram o Aerospike, que ofereceu suporte de velocidade e cross-cloud. no entanto, eles aprenderam que a indexação na memória da Aerospike teria exigido um aglomerado proibitivamente grande e caro para lidar com o grande número de pequenos objetos de dados da Yieldmo. Então eles descobriram o ScyllaDB, que também forneceu suporte de velocidade e cross-cloud, mas com uma API compatível com o DynamoDB (Alternator) e custos mais baixos. Coleman compartilhou: “O ScyllaDB suportava implantações cross-cloud, exigia um número gerenciável de servidores e ofereceu custos competitivos.O melhor de tudo, sua API era compatível com o DynamoDB, o que significa que poderíamos migrar com alterações mínimas de código. Avaliação, migração e resultados do ScyllaDB Para começar a avaliar como o ScyllaDB funcionava em seu ambiente, a equipe migrou um subconjunto de servidores de anúncios em uma única região. Isso envolveu a migração de vários terabytes, mantendo atualizações em tempo real. Processalmente, eles tinham a ferramenta de migração baseada em Spark do ScyllaDB para copiar dados históricos, paralisaram os trabalhos de lote ML e aproveitaram sua arquitetura Kafka para reproduzir escritos recentes no ScyllaDB. O próximo passo foi migrar todos os dados em cinco regiões da AWS. Esta fase levou cerca de duas semanas.Depois de avaliar o desempenho, a Yieldmo promoveu o ScyllaDB para o status primário e, eventualmente, parou de escrever para o DynamoDB na maioria das regiões. Refletindo sobre a migração quase um ano depois, Coleman resumiu: “O maior benefício é a flexibilidade multicloud, mas mesmo sem isso, a migração valeu a pena. Os custos da base de dados foram reduzidos aproximadamente pela metade em comparação com o DynamoDB, mesmo com preços de capacidade reservada, e vimos melhorias modestas na latência. ScyllaDB provou ser confiável: sua equipe monitora nossos clusters, nos alerta sobre problemas e nos aconselha sobre a escalação. Como o ScyllaDB se compara ao DynamoDB
