How a team of just two engineers tackled real-time persisted events for hundreds of millions of players Com apenas dois engenheiros, a Supercell assumiu a difícil tarefa de expandir seu sistema de conta básica em uma plataforma social que conecta centenas de milhões de jogadores. gerenciamento de contas, solicitações de amigos, promoções de jogos cruzados, bate-papo, rastreamento de presença de jogadores e formação de equipes – tudo isso teve que funcionar em seus cinco jogos principais. O engenheiro de servidores da Supercell, Edvard Fagerholm, compartilhou recentemente como sua poderosa equipe de dois lidou com esta tarefa.Leia mais para saber como eles transformaram uma ferramenta de gerenciamento de conta simples em uma infraestrutura de rede social abrangente que priorizou a simplicidade operacional e alto desempenho. Nota: Se você gosta de ouvir sobre feitos de engenharia como este, junte-se a nós no Monster Scale Summit (gratuito + virtual). Engenheiros da Disney+/Hulu, Slack, Canva, Uber, Salesforce, Atlassian e mais compartilharão estratégias e estudos de caso. do s. Notas Se você gosta de ouvir sobre feitos de engenharia como este, junte-se a nós em Monstros da Escala Engenheiros da Disney+/Hulu, Slack, Canva, Uber, Salesforce, Atlassian e mais compartilharão estratégias e estudos de caso Notas Monstros da Escala Título: Quem é a Supercélula? A Supercell é a empresa com sede na Finlândia por trás dos jogos de sucesso Hay Day, Clash of Clans, Boom Beach, Clash Royale e Brawl Stars. Até recentemente, toda a funcionalidade de gerenciamento de contas para jogos que atendem centenas de milhões de usuários ativos mensais estava sendo construída e gerenciada por apenas dois engenheiros. A Gênese do Supercell ID O Supercell ID nasceu como um sistema básico de conta – algo para ajudar os usuários a recuperar contas e movê-las para novos dispositivos. Edvard explicou: “O cliente poderia executar consultas HTTP para a API da conta, que principalmente devolvia tokens assinados que o cliente poderia apresentar ao servidor do jogo para provar sua identidade. Algumas operações, como fazer pedidos de amigo, exigiram que a API da conta envie uma notificação para outro jogador. Por exemplo, ‘Você aprova este pedido de amigo?’ Para esse fim, havia uma fila de eventos para notificações. Nós postaríamos o evento lá, e o backend do jogo transmitiria a notificação ao cliente usando o socket do jogo.” Entre em comunicação de duas vias Depois que Edvard se juntou ao projeto Supercell ID no final de 2020, ele começou a trabalhar no backend de notificações – principalmente para promoção cruzada em seus cinco jogos. Clientes conectados a uma frota de servidores proxy, em seguida, um mecanismo de roteamento empurrou eventos diretamente para os clientes (sem passar pelo jogo). Isso foi suficiente para o objetivo imediato de lidar com solicitações de promoções cruzadas e amigos. Eles perceberam que poderiam usar a comunicação bidirecional para aumentar significativamente o alcance do sistema Supercell ID. Edvard explicou: “Basicamente, isso nos permitiu implementar recursos que antes eram parte do servidor de jogos. Nosso objetivo era tomar recursos que qualquer novo jogo em desenvolvimento poderia precisar e embalá-los em nosso sistema – acelerando assim seu desenvolvimento.” Com isso, a Supercell ID começou a se transformar em uma rede social cross-game que suportava recursos como gráficos de amigos, equipe, bate-papo e rastreamento de estado de amigos. A evolução da Supercell ID para uma rede social cross-game Neste ponto, o lado da Rede Social do backend ainda era um projeto de uma pessoa, então eles o projetaram com simplicidade em mente. Encontrar a abstração certa “Queríamos ter apenas uma abstração simples que suportasse todos os nossos usos e, portanto, poderia ser projetada e implementada por um único engenheiro”, explicou Edvard. “Em outras palavras, queríamos evitar construir um sistema de bate-papo, um sistema de presença, etc. Queríamos construir uma coisa, não muitas.” Encontrar a abstração certa foi a chave.E uma loja hierárquica de valores-chave com Change Data Capture se encaixa perfeitamente na fatura.Eis como eles a implementaram: As chaves de nível superior na loja de valores-chave são tópicos que podem ser subscritos. Há um mapa de duas camadas sob cada chave de nível superior – mapa(corrente, mapa(corrente, cadeia)).Qualquer mudança nos dados sob uma chave de nível superior é transmitida para todos os assinantes dessa chave. Os valores no mapa mais íntimo também são timestampados.Cada fonte de dados controla seus próprios timestamps e define a ordem correta.O cliente lança qualquer atualização com um timestamp mais antigo do que o que já armazenou. Cartão(string, string, string) Uma mudança típica nos dados seria algo como “nível igual a 10” mudando para “nível igual a 11”.À medida que os jogadores jogam, eles desencadeiam todos os tipos de atualizações como esta, o que significa que muitos pequenos escritos estão envolvidos na persistência de todos os eventos. Encontrar o banco de dados certo Eles precisavam de um banco de dados que suportasse seus requisitos técnicos e fosse gerenciável, dada a sua equipe minimalista. Gerencia muitas letras pequenas com baixa latência Suporte a um modelo de dados hierárquico Gerencia backups e operações de cluster como um serviço ScyllaDB Cloud é a versão totalmente gerenciada do ScyllaDB, um banco de dados conhecido por fornecer latência baixa previsível em escala. Como tudo se desenrola Para uma ideia de como isso se desenrola em jogos Supercell, vamos olhar para dois exemplos. Primeiro, considere mensagens de bate-papo. Uma simples mensagem de bate-papo pode ser representada em seu modelo de dados da seguinte forma: Edvard explicou: “A chave de nível superior que é assinada é a ID da sala de bate-papo. A chave de nível seguinte é um timestamp-UID, então temos uma ordem de cada mensagem e podemos consultar o histórico do bate-papo. O objetivo da presença, de acordo com Edvard: “Quando se unem para a batalha, você quer ver em tempo real o avatar e a construção atual de seus amigos – basicamente as armas e equipamentos de seus amigos, bem como o que eles estão fazendo. Players’ state data is encoded into Supercell’s hierarchical map as follows: Note that: O nível superior é o ID do jogador, o segundo nível é o tipo e o mapa interno contém os dados. O Supercell ID não precisa entender os dados; ele simplesmente os transmite aos clientes de jogos. Os clientes de jogos não precisam conhecer o gráfico do amigo, uma vez que o roteamento é gerenciado pelo Supercell ID. Aprofundar na arquitetura do sistema Vamos terminar com uma visita à arquitetura do sistema, conforme fornecido por Edvard. "O backend é dividido em APIs, proxies e servidores de roteamento de eventos / armazenamento. Tópicos vivem nos servidores de roteamento de eventos e são divididos entre eles. Um cliente se conecta a um proxy, que lida com a assinatura do tópico do cliente. O proxy encaminha essas assinaturas para os servidores de roteamento de eventos apropriados. Endpoints (por exemplo, para chat e presença) enviam seus dados para os servidores de roteamento de eventos, e todos os eventos persistem na nuvem ScyllaDB. Cada tópico tem um shard primário e de backup. Se o primário cair, o shard primário mantém os números de sequência de memória para cada mensagem para detectar mensagens perdidas. O secundário enviará mensagens sem números de sequência. Se o primário cair, o primário irá desencadear uma atualização de estado no cliente, bem como a redefinição dos números de sequência. A API para as camadas de roteamento é uma simples RPC pós-evento contendo um lote de tópicos, tipos, chaves, tuples de valor. O trabalho de cada API é apenas reescrever seus dados para a representação de tuple acima. Cada evento é escrito em ScyllaDB antes de ser transmitido aos assinantes. Nossas APIs são sincronizadas no sentido de que se uma chamada de API dá uma resposta bem-sucedida, a mensagem persistiu em ScyllaDB. Enviar o mesmo evento várias vezes não faz mal, já que aplicar a atualização no cliente é uma operação idempotente, com a exceção de possivelmente múltiplos números de sequência mapeando para a mesma mensagem. Quando você se conecta, o proxy descobrirá todos os seus amigos e se inscreverá em seus tópicos, o mesmo para os grupos de bate-papo a que pertence.Também se inscreve em tópicos para o cliente que se conecta.Esses são usados para enviar notificações ao cliente, como pedidos de amigos e promoções cruzadas. Um reboot do roteador desencadeia uma reabertura de tópicos do proxy. Usamos Protocol Buffers para economizar no custo da largura de banda. Todo o balanço de carga é no nível TCP para garantir que as solicitações sobre a mesma conexão HTTP/2 são processadas pelo mesmo socket TCP no proxy. Isso nos permite cachear certas informações na memória na audição inicial, para que não precisemos refetchar em outras solicitações. Temos clientes simultâneos suficientes que não precisamos de balançar separadamente as solicitações HTTP/2 individuais, já que o tráfego é distribuído uniformemente de qualquer maneira, e as solicitações são quase igualmente caras para lidar com diferentes usuários. Usamos sockets persistentes entre proxies e roteadores. Desta forma, podemos facilmente enviar dezenas de milhares de assinaturas por segundo para um único roteador sem um problema.” Mas não é Game Over Se você quiser assistir a conversa técnica completa, basta pressionar o jogo abaixo: E se você quiser ler mais sobre o papel do ScyllaDB no mundo dos jogos, você também pode querer ler: Epic Games: Como a Epic Games usa o ScyllaDB como um cache binário na frente da NVMe e do S3 para acelerar a distribuição global de grandes ativos de jogos usados pela Unreal Cloud DDC. Tencent Games: Como a Tencent Games construiu uma arquitetura de serviços baseada em CQRS e padrões de aquisição de eventos com o Pulsar e o ScyllaDB. Discord: Como a Discord usa o ScyllaDB para impulsionar seu crescimento maciço, passando de uma plataforma de nicho de jogos para uma das maiores plataformas de comunicação do mundo. Jogos da Epic: Jogos da Tencent: A discordância:
