How Blitz scaled their game coaching app with lower latency and leaner operations é uma startup em rápido crescimento que fornece treinamento personalizado para jogos como League of Legends, Valorant e Fortnite. Eles visam ajudar os jogadores a se tornarem lendas da League of Legends através de insights em tempo real e análise pós-match. Blitz Enquanto os jogadores jogam, o aplicativo faz muito trabalho. capta dados de jogos ao vivo, analisa-os rapidamente e usa-os para sobreposições de tela de jogos em tempo real, além de treinamento pós-jogo personalizado.O guia é baseado na atividade de jogo atual e histórica de cada jogador, bem como dados coletados em bilhões de jogos envolvendo centenas de milhões de usuários. Graças à crescente conscientização sobre as estatísticas populares da Blitz e o aplicativo de treinamento de jogos, sua base de usuários em constante crescimento empurrou sua arquitetura original baseada em Postgres e Elixir para seus limites. Para fornecer baixa latência, alta disponibilidade e escalabilidade horizontal à sua base de usuários em crescimento, eles, em última análise: TL;DR Serviços de backend migrados do Elixir para o Rust. Substituição do Postgres pela ScyllaDB Cloud. reduziu consideravelmente a sua pegada. Eliminou seu cluster Riak. Substituição de processamento de fila por processamento em tempo real. Infraestrutura consolidada de mais de cem núcleos de microsserviços para quatro nós n4‐standard‐4 do Google Cloud (mais uma pequena instância do Redis para cache de borda) Como um bônus adicional, essas mudanças acabaram cortando os custos de infraestrutura da Blitz e reduzindo a carga de banco de dados sobre seu pessoal de engenharia. Blitz de fundo Como Naveed Khan (Chefe de Engenharia da Blitz) explicou, “Recolhemos muitos dados de editores de jogos e durante o gameplay.Por exemplo, se você estiver jogando League of Legends, usamos a API da Riot para extrair dados de jogo, e se você instalar nosso aplicativo, também monitoramos o jogo em tempo real.Todos esses dados são armazenados em nosso banco de dados de transações para processamento inicial, e a maior parte termina em nosso lago de dados.” Escalando Passado Postgres Uma parte chave do sistema da Blitz é a API Playstyles, que analisa dados pré-jogo para colegas de equipe e adversários. Este processo intensivo avalia até 20 jogos por jogador e é executado nove vezes por jogo (uma vez para cada jogador no jogo). A equipe refinou e consolidou estrategicamente inúmeros microservices para melhorar o desempenho. Mas o volume de dados permaneceu intenso. De acordo com Brian Morin (Engenheiro de Backend Principal da Blitz), “Encontrar uma solução de banco de dados capaz de lidar com esse volume de consulta foi crucial.” No entanto, à medida que suas cargas de trabalho pesadas em escrever cresciam, a complexidade operacional e os custos na Google Cloud aumentaram significativamente. Além disso, a escalação da Postgres tornou-se bastante complexa. Naveed compartilhou: “Tentamos todos os tipos de coisas para escalar. Construímos vários serviços em torno da Postgres para obter a escala que precisávamos: um cluster Redis, um cluster Riak e filas de Elixir Oban que ocasionalmente inundavam. À medida que as startups crescem, muitas vezes mudam de “apenas usar o Postgres” para “apenas usar o NoSQL”. apropriadamente, a equipe do Blitz considerou mudar para o MongoDB, mas eventualmente o excluiu. “Tivemos muita experiência com o MongoDB na equipe e alguns de nós realmente gostaram. no entanto, nossa carga de trabalho é muito pesada, com milhares de jogadores simultâneos gerando um fluxo constante de dados. criaria uma barreira para sua carga de trabalho específica e crescimento esperado. Arquitetura primária e secundária do MongoDB Os testes mostraram que ele atenderia às suas necessidades de latência, então eles realizaram a (re)modelação de dados necessária e migraram alguns jogos menores do Postgres para o RocksDB. No entanto, eles finalmente decidiram contra o RocksDB devido a preocupações de escala e alta disponibilidade. “Com base nos dados disponíveis de nossos testes, ficou claro que o RocksDB não seria capaz de lidar com a carga de nossos jogos maiores – e não poderíamos arriscar escalar verticalmente uma única instância, e então ter essa uma instância cair”, explicou Naveed. Por que ScyllaDB Um de seus engenheiros de backend sugeriu ScyllaDB, então eles alcançaram e executaram uma prova de conceito. Eles o testaram em seu próprio hardware primeiro, depois mudaram-se para a ScyllaDB Cloud. Por Naveed, “O custo era bastante próximo de auto-hosting, e recebemos gestão completa gratuitamente, então foi um não-brainer. Agora temos um aglomerado Redis significativamente reduzido, além de nos livrarmos do aglomerado Riak e das dependências da fila Oban. Basta escrever para a ScyllaDB e tudo funciona. Em termos de desempenho, a mudança atingiu seu objetivo de nivelar a experiência do usuário ... e também simplificou a vida de suas equipes de engenharia. Brian acrescentou: “O ScyllaDB provou ser excepcional, fornecendo desempenho robusto com capacidade de poupar após a otimização. Nosso produto League atingiu os picos em cerca de 5k ops/sec com o cluster reportando abaixo de 20% de carga. Nossa maior restrição foi o uso de disco, que lançamos várias atualizações para mitigar. O novo sistema pode agora retornar resultados imediatamente em vez de depender de dados em cache, fornecendo informações mais atualizadas sobre outros jogadores e até mesmo identificando companheiros de equipe frequentes. Os resultados desta migração foram impressionantes: mais de uma centena de núcleos de micros High-Level Architecture of Blitz Server with Rust and ScyllaDB Reescrevendo serviços Elixir em Rust Como parte de uma grande revisão de backend, a equipe da Blitz começou a repensar toda a sua infraestrutura – além da mudança descrita anteriormente do Postgres para o ScyllaDB de alto desempenho e distribuído. Ao lado desta migração de banco de dados, eles também optaram por lançar seus serviços baseados no Elixir em favor de uma linguagem mais moderna. Depois de uma avaliação cuidadosa, Rust surgiu como a escolha clara. “O Elixir é ótimo e serviu bem ao seu propósito”, explicou Naveed. “Mas quisemos avançar para algo com uma adoção mais ampla e um ecossistema de nível de sistema mais forte. Agora que o primeiro lote de serviços reescritos do Rust está em produção, a Naveed e a equipe não olham para trás: “O Rust é fantástico. É rápido, e o compilador obriga você a escrever código seguro de memória antecipadamente em vez de depurar problemas de coleta de lixo mais tarde.
