Local blog for Brazilian speaking developers
Nos bastidores com o back-end do Dragon Ball Legends no GCP
26/07/2018
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á.
Nenhum comentário :
Postar um comentário
Labels
+page
1
A/B
1
Action
1
Actions
1
Actions Console
1
Actions on Google
1
Adaptive Battery
1
AddThis
1
ADK
1
ADL
1
Admin do Firebase
1
AdMob
6
Ads
2
AdWords
1
AdX
1
AI
4
algoritmo
1
AMP
4
AMP Project
1
Analytics API
1
Android
51
Android 8.0 Oreo
1
Android 8.1
1
Android ADK
2
Android API
2
Android App Bundle
1
Android Developers
23
Android Marshmallow
1
Android N
3
Android Nougat
2
Android P
3
Android P Beta 2
1
Android Preview
1
Android SDK
1
android studio
7
Android Studio 3.2
1
android wear
2
AndroidDev
6
Announcement
2
AoG
1
AoGDevs
1
api
12
APIs
4
Aplicativos
4
app
1
App Engine
1
Apps
9
AR
1
ARCore
2
artificial intelligence
1
AsyncTask
1
AUC
1
AutoAugment
1
Avro
1
Awareness API
1
Biblioteca do Google
1
BigQuery
1
BiometricPrompt
1
Bot
1
bytecode Dalvik
1
C++
1
CameraDevice
1
canary
1
Cast
1
Chrome
6
Chrome 68
1
Chrome DevTools
1
Chrome OS
1
Chromecast
1
Chromium
2
CI
1
Cloud
6
Cloud Computing
1
Cloud Console
1
Cloud Developers
2
Cloud Firestore
1
Cloud Messaging
1
Cloud Shell
1
Cloud Source Repositories
1
Cloud Spanner
2
CodeSchool
1
código aberto
2
Compute Engine
1
ConfigMap
1
Container Builder
1
CPU
2
Crash Reporting
2
Crashlytics
3
credential api
1
criptografia
1
CSS
3
CSS Grid Layout
1
CSV
1
CTA
1
Curitiba
1
Dart API
1
Data Validation
1
DBAs
1
DCGAN
1
Desenvolvedores Google
11
Desenvolvimento
3
DevBusBrasil
1
DevBytes
2
Developer Bus
1
Developer Preview
1
developer quiz
1
DevFest
3
DevFest16
1
DevFest18
1
DevFestW
1
DFP
2
Dialogflow
1
documentação
1
Dragon Ball Legends
1
E2E
1
eclipse
1
end-to-end-encryption
1
Estimator
1
Estimators API
1
estudantes
1
Eventos
15
Famílias multilíngue
1
FCM
2
Featured
1
Firebase
22
Firebase Analytics
6
Firebase App Indexing
2
Firebase Cloud Messaging
4
Firebase Crashlytics
2
Firebase Dynamic Links
3
Firebase In-App Messaging
1
Firebase Invites
2
Firebase Lab
1
Firebase Links Dinamicos
1
Firebase Notifications
3
Firebase Remote Config
1
Flutter
2
FRR
1
G+
1
game
1
game dev
3
Games
2
games services
1
GCloud
3
GCM
1
GCP
4
GDD
7
GDE
1
GDEs
1
GDG
12
GDG Curitiba
1
GDG Floripa
1
GDG OpenSampa
1
GDG Porto Alegre
1
GDG Recife
1
GDG SP
3
GDGs
1
GDL
1
Git
1
GitHub
1
Google
3
Google AI
1
Google Analytics
1
Google Assistant
1
Google Assistente
3
Google Brain
2
Google Cast SDK
1
google clou
1
Google Cloud
13
Google Cloud Certified
1
Google Cloud Platform
2
google code-in
1
Google Developer Advocate
1
Google Developer Expert
1
Google Developers
11
Google Fotos
1
Google I/O
5
Google Play
14
Google Play Games services
1
Google Play Protect
1
Google Play Services
4
Google Slides
1
Google Speech
1
google summer of code
1
Google+
2
Google+ sign-in
1
GPU
2
GSuites
1
Hackathon
1
Hangouts
1
Hangouts Chat
1
HDR
1
High Quality Apps
2
HTML5
6
HTTP
3
HTTPS
2
HttpURLConnection
2
I/O
1
IA
1
Illusive Images
1
In-App Messaging
1
Inglês
1
Instant Apps
1
inteligencia artificial
1
IntelliJ REPL
1
IntentService
1
Interoperabilidade
1
IO Extended
1
IO13
1
iOS
8
Java
1
Java 8
1
javascript
2
JSON
2
Keyboard Map API
1
Knowledge Connectors
1
Kotlin
4
Kotlin da Udacity
1
Kubernetes
4
LangID
1
Launchpad
1
launchpad accelerator
2
Learning Augmentation
1
LEGO
1
Listas
1
ListFragment
1
Machine Learning
2
Meetup
2
mensagens
1
Mentoria
1
Messaging
2
ML
1
Mobile
3
Mobile Ads SDK
1
Monetização
3
Monetize
3
MySQL
1
Native
1
NES
1
Neto Marin
2
Next Level Apps
2
Next Level Tips
2
NNLM
1
Node.js
2
Notificações
1
OAuth
2
OAuth2
1
open source
3
Options Menu
1
Options Menu virtual
1
Orkut
2
Payment Request
1
pesquisa
1
PHA
1
Phone Gateway
1
Play Services
1
Porto Alegre
1
Preact
1
program
1
progressive web apps
2
Push Notification
2
Python
1
RA
1
Raspberry Pi
1
RBDMS
1
React
1
recording apis
1
remarketing
1
Remote Config
2
research
4
ResultReceiver
1
reward
1
RNN
2
SDK
4
SDK Manager
3
Security
2
Server
1
service worker
1
sign-in
1
Sliding Tabs
1
social
6
Spark
1
SRE
1
Stack
1
Stack Overflow
1
Startups
2
Storage
2
story
1
Support Library
1
Svelte
1
switch
1
Tag Manager
1
Tag Manager 360
1
tensorflow
5
TensorFlow Hub
2
TensorFlow Lite
1
TensorFlow Transform
1
Test Lab
2
Testes
1
TF Hub
2
tf.keras
1
TFDV
1
TFX
1
toolkit
1
tradução
1
TTS
1
Udacity
1
Universal Apps
1
Universal Sentence Encoder
1
user experience
1
ux
1
Volley
1
vr
2
vulnerabilidades
1
vulnerabilidades do Google
1
vulnerability
1
web
2
web dev
2
WebKit
1
webservice
3
when
1
WorkerDOM
1
YouTube
4
YouTube API
1
Zomato
1
Archive
2018
out
set
ago
jul
jun
mai
abr
mar
fev
2017
ago
jul
jun
mai
abr
mar
jan
2016
dez
nov
out
set
ago
jul
mai
mar
2014
jul
jun
abr
mar
fev
2013
dez
nov
out
set
ago
jul
jun
mai
mar
fev
jan
2012
nov
jul
jun
mai
abr
mar
2011
nov
set
ago
jul
jun
Feed
Follow @googledevbr
Nenhum comentário :
Postar um comentário