De Samir Hammoudi, especialista técnico em jogos do Google Cloud
Dragon Ball Legends , um novo jogo para dispositivos móveis da Bandai Namco Entertainment (BNE) é inspirado na famosa franquia Dragon Ball Z e está sendo lançado aos gamers do mundo todo enquanto neste exato instante. Mas o planejamento da infraestrutura de nuvem para suportar o jogo já vem de fevereiro de 2017, quando a BNE entrou em contato com o Google Cloud para falar das dificuldades interessantes que estavam enfrentando e sobre como poderíamos ajudar.
De acordo com nas necessidades antevistas deles, a BNE tinha três requisitos pretensiosos para o jogo:
Escalonabilidade extrema . O jogo seria lançado no mundo todo, e por isso precisava de um back-end que pudesse se escalonar a milhões de jogadores e continuar funcionando bem.
Rede global . Como o jogo tem batalhas entre jogadores em tempo real, precisava de uma rede sólida e de baixa latência em todas as regiões.
Análise de dados em tempo real . O jogo foi criado para evoluir junto com os jogadores, em tempo real, então era fundamental ter um canal de análise de dados para direcioná-los a um data warehouse. Depois, a equipe operacional poderia medir e analisar como as pessoas estão jogando e ajustar o jogo na hora.
E, por sorte, temos muita experiência em todas essas três áreas. O Google tem vários serviços globais com mais de um bilhão de usuários, e usamos os dados que esses serviços geram para melhorá-los com o tempo. Como o Google Cloud Platform (GCP) roda na mesma infraestrutura que esses serviços do Google, os clientes do GCP podem usar as mesmas tecnologias.
Vamos ver como a BNE trabalhou com o Google Cloud para criar a infraestrutura para o Dragon Ball Legends.
Desafio 1: escalonabilidade extrema
O MySQL é amplamente usado por empresas de jogos no Japão. Os engenheiros locais costumam trabalhar com bancos de dados relacionais com esquema, consultas de SQL e consistência forte. Isso simplifica muito as coisas no lado do aplicativo, pois não é preciso lidar com limitações do banco de dados, como consistência eventual ou aplicação de esquema. Mesmo fora do mundo dos jogos, o MySQL é muito usado, e a maioria dos engenheiros de back-end têm bastante experiência com ele.
Apesar de o MYSQL oferecer muitas vantagens, ele tem uma limitação muito importante: escalonabilidade. Na verdade, considerando um banco de dados para escalonamento, se você quiser melhorar o desempenho do MySQL, precisa adicionar mais CPU, RAM ou disco. E quando uma única instância do MySQL não consegue mais tratar da carga, é possível dividi-la através da fragmentação (dividir usuários em grupos e direcioná-los a diversas instâncias independentes do MySQL). Porém, a fragmentação tem várias desvantagens. A maioria dos desenvolvedores de jogos calcula o número de fragmentos de que precisam para o banco de dados antes do lançamento do jogo, já que a fragmentação é algo propenso a erros e que exige bastante trabalho. Isso faz com que as empresas de jogos provisionem muito banco de dados para eventualmente lidar com mais jogadores do que esperam. Se o jogo fizer o sucesso que se espera, está tudo certo. Mas e se o jogo viralizar loucamente e exceder a demanda prevista? E a cauda longa que representa uma queda gradual no número de jogadores ativos? E se for um fracasso total? A fragmentação do MySQL não é escalonável dinamicamente, então o ajuste de dimensionamento exige manutenção e envolve risco.
Em um mundo ideal, os bancos de dados poderiam se escalonar sem tempo de inatividade e ainda teriam as vantagens de um banco de dados relacional. Quando ficamos sabendo que a BNE estava pensando em usar fragmentação MySQL para lidar com o enorme tráfego previsto para o Dragon Ball Legends, sugerimos usar o Cloud Spanner.
Mas por que o Cloud Spanner?
O Cloud Spanner é um banco de dados relacional totalmente gerenciado que oferece escalonabilidade horizontal e alta disponibilidade, além de uma consistência forte com um esquema parecido com o do MySQL. E a cereja do bolo: como um serviço gerenciado, é administrado pelas Google SREs , removendo a manutenção de banco de dados e minimizando o risco de tempo de inatividade. Achamos que o Cloud Spanner seria a solução perfeita para ajudar a BNE a tornar o jogo global.
Da avaliação à implementação
Antes de adotar uma nova tecnologia, o ideal é que os engenheiros sempre a testem em um cenário real para confirmar o desempenho que se espera dela. Antes de trocar o MySQL, a BNE criou uma nova instância do Cloud Spanner no GCP, incluindo algumas tabelas com esquema similar ao usado no MySQL. Como os desenvolvedores de back-end da empresa programaram em Scala, eles escolheram a biblioteca do cliente Java para o Cloud Spanner e escreveram alguns exemplos de código para testar o Cloud Spanner com carga. Assim, eles veriam se o recurso conseguiria satisfazer os requisitos de consulta por segundo (QPS) para gravações. Eram cerca de 30.000 QPS, em momentos de pico. Trabalhando com nosso engenheiro de clientes e as equipes de engenharia do Cloud Spanner, foi fácil atingir essa meta. Eles ainda desenvolveram o próprio encapsulador DML (linguagem de manipulação de dados) para programar comandos SQL como INSERT, UPDATE e DELETE.
Versão do jogo
Com a validação do conceito fundamentando as ações, eles puderam começar a implementação. A partir da estimativa de usuários ativos diariamente (DAU), a BNE calculou quantos nós seriam necessários no Cloud Spanner para dar conta de todos os jogadores pré-registrados que estavam imaginando. Para preparar a versão, a empresa organizou dois testes beta fechados para validar o back-end e não tiveram problema nenhum com o banco de dados. Nenhum mesmo! No fim das contas, mais de três milhões de participantes do mundo todo se pré-registraram no Dragon Ball Legends, e mesmo com esse número enorme, a versão oficial do jogo funcionou tranquilamente.
Resumindo: a BNE pôde se concentrar em melhorar o jogo e não perder tempo operando os bancos de dados.
Desafio 2: rede global
Agora, vamos falar sobre o segundo desafio da BNE: criar um jogo global de jogador contra jogador (PvP) de tempo real. A meta da BNE para o Dragon Ball Legends era que todos os jogadores pudessem jogar uns contra os outros, em qualquer lugar do mundo. Se você entende bem de redes, já pensa logo sobre os possíveis problemas de latência. O tempo de retorno (RTT) entre Tóquio e São Francisco, por exemplo, é de cerca de 100 ms. Para resolver esse problema, eles decidiram dividir cada segundo do jogo em intervalos de 250 ms. Assim, apesar de o jogo parecer estar em tempo real para os usuários, ele é, na essência, um jogo de turnos extremamente rápidos (leia mais sobre a arquitetura aqui ). E embora se possa dizer que 250 ms criam muitas possibilidades de latência, é muito difícil (muito mesmo) prever a latência para a comunicação pela internet.
Por que uma estrutura de redes em nuvem?
Veja como um cliente do jogo acessa o servidor do jogo no GCP pela internet. Como o número de saltos pode variar a cada vez, a experiência em PvP pode ser às vezes rápida e às vezes lenta.
Um dos principais motivos que fizeram a BNE escolher o GCP como back-end do Dragon Ball Legends foi a rede dedicada do Google . Como mostrado na imagem abaixo, usando o GCP, quando o cliente do jogo acessa um dos inúmeros pontos de presença (POP) do GCP no mundo, ele está na rede dedicada do Google. Traduzindo: sem saltos imprevistos, previsibilidade e a menor latência possível.
Aproveitando os benefícios do Google Cloud Network
Normalmente, as empresas de jogos implementam o modo PvP conectando dois jogadores diretamente ou por meio de um servidor dedicado do jogo. É comum jogos de combate que precisam de baixa latência entre os jogadores prefiram comunicação P2P. Em geral, quando dois jogadores estão perto um do outro geograficamente, o P2P funciona muito bem. No entanto, na maioria das vezes, o P2P não é confiável quando se tenta estabelecer comunicação entre regiões diferentes (algumas operadoras inclusive bloqueiam protocolos P2P). Para dois jogadores de continentes diferentes se comunicarem pela rede dedicada do Google, primeiro eles tentam fazer isso por P2P, e se não funcionar, ela alterna para uma implementação de código aberto de servidor STUN/TURN chamada coturn , que atua como um relê entre os dois jogadores. Assim, as batalhas intercontinentais ficam com baixa latência e têm a confiabilidade da rede Google sempre que possível.
Desafio 3: análise de dados em tempo real
O último desafio da BNE envolvia a análise de dados em tempo real. A BNE queria oferecer a melhor experiência de usuário aos fãs, e uma forma de fazer isso era por meio de operações ao vivo no jogo, ou LiveOps, em que os operadores fazem mudanças constantes ao jogo para deixá-lo sempre com um ar renovado. Mas, para entender as necessidades dos jogadores, é preciso ter dados: especialmente os dados dos registros de ação do usuário. Se eles pudessem ter esses dados em tempo quase real, seria possível tomar decisões sobre as mudanças a serem aplicadas ao jogo para aumentar a satisfação e o envolvimento dos usuários.
Para coletar esses dados, a BNE usou uma combinação de Cloud Pub/Sub e Cloud Dataflow com o objetivo de transformar os dados do usuário em tempo real e inseri-los no BigQuery.
O Cloud Pub/Sub oferece um sistema de troca de mensagens globalmente consistente que carrega os registros em buffer até que eles possam ser gerenciados pelo Cloud Dataflow.
O Cloud Dataflow é um serviço de processamento paralelo totalmente gerenciado que permite executar ETL em tempo real e em paralelo.
O BigQuery é o data warehouse totalmente gerenciado em que todos os registros do jogo são armazenados. Como o BigQuery oferece armazenamento em nível de petabyte, escalonamento não era um problema. Graças ao processamento paralelo pesado na hora de consultar os registros, a BNE consegue receber uma resposta para uma consulta, analisando terabytes de dados em poucos segundos.
Esse sistema dá ao produtor de jogos a chance de visualizar o comportamento de um jogador praticamente em tempo real e tomar decisões sobre quais novos recursos devem ser adicionados ao jogo ou o que pode ser alterado no jogo para satisfazer todos os fãs.
Conclusão
Usando o Cloud Spanner, a BNE se concentrou em desenvolver um jogo incrível, e não em planejamento de capacidade e escalonamento do banco de dados.
Quanto à parte operacional, usando um banco de dados escalonável totalmente gerenciado, a empresa reduziu drasticamente os riscos relacionados a erro humano e uma possível sobrecarga operacional.
Usando o Cloud Networking, a BNE ganhou acesso à rede dedicada do Google para oferecer a melhor experiência aos usuários, mesmo no caso de lutas intercontinentais.
E, por fim, usando a pilha de análise do Google (Cloud Pub/Sub, Cloud Dataflow e BigQuery), a BNE conseguiu analisar o comportamento dos jogadores em tempo quase real e tomar decisões sobre os ajustes do jogo para deixar os fãs ainda mais satisfeitos!
Se quiser ver mais detalhes sobre como a BNE avaliou e adotou o Cloud Spanner para o Dragon Ball Legends, é só aparecer na sessão do Google Cloud NEXT'18 , em São Francisco, porque o pessoal da empresa estará lá.
Um comentário :
PINGIN CEPAT KAYA ? Bingung mulai dari mana ? Baru..!! Game judi online 2019 wargapoker terpercaya. Dapatkan bonus-bonus untuk pemain baru, Ada begitu banyak jenis taruhan judi online dengan uang asli yang bisa anda mainkan di afapoker kapan saja dan dimana saja, cukup menggunakan satu user id saja. Anda dipastikan memainkan permainan judi online yang murni dominobet dimana Anda bermain 100% player vs player tanpa ada campur tangan bot link alternatif domino88 2019. Tidak perlu lagi bersusah payah mencari uang, Anda bebas menikmati waktu Anda. Situs link alternatif pokerace 2019 deposit murah yang menyediakan banyak permainan dengan pelayanan berkualitas. Jadi silahkan daftar dan segera mainkan permainan. Dijamin mudah dan cepat. Anda akan diberi pelayanan yang ramah dan cepat saat proses pendaftaran. Didukung dengan sistem terbaru dan tim profesional serta kemudahan bertransaksi. Kami menjamin kerahasiaan data member.
Postar um comentário