Local blog for Spanish speaking developers in LATAM
Tras bambalinas del backend de GCP de Dragon Ball Legends
jueves, 28 de junio de 2018
Publicado por Samir Hammoudi, especialista técnico en Videojuegos, Google Cloud
Dragon Ball Legends
, un juego nuevo de Bandai Namco Entertainment (BNE) para dispositivo móviles, se basa en la popular franquicia de
Dragon Ball Z
y, en este momento, se está implementando entre jugadores de todo el mundo. Sin embargo, la planificación de la infraestructura de nube para optimizar el juego data de febrero de 2017, cuando BNE alcanzó Google Cloud para abordar los desafíos interesantes que enfrentaban y la manera en que podríamos ayudar.
Según la demanda prevista, BNE tenía tres requisitos ambiciosos para su juego:
Escalabilidad extrema
: el juego se lanzaría de manera global, por lo que necesitaba un backend que pudiera escalarse con millones de jugadores y funcionar bien.
Red global
: debido a que el juego permite batallas de jugadores contra jugadores en tiempo real, necesitaba una red de latencia baja y confiable en las regiones.
Análisis de datos en tiempo real
: el juego está diseñado para evolucionar con los jugadores en tiempo real, de modo que fue fundamental disponer de una canalización de análisis de datos para la transmisión de estos al almacén de datos. Con esto, el equipo de operaciones puede medir y evaluar el modo en que la gente juega y ajusta el juego en el momento.
Tenemos mucha experiencia en las tres áreas. Google tiene varios servicios globales con más de mil millones de usuarios y usamos los datos que esos servicios generan para mejorarlos con el tiempo. Debido a que
Google Cloud Platform
(GCP) se ejecuta en la misma infraestructura que estos servicios de Google, los clientes de GCP pueden sacar provecho de las mismas tecnologías beneficiosas.
Veamos la manera en que BNE trabajó con Google Cloud a fin de compilar la infraestructura para Dragon Ball Legends.
Desafío n.º 1: Escalabilidad extrema
MySQL se usa ampliamente en empresas de juegos de Japón. Los ingenieros de allí están acostumbrados a trabajar con bases de datos relacionales con esquemas, consultas de SQL y una coherencia sólida. Esto simplifica mucho la tarea del lado de la aplicación; no hay necesidad de lidiar con limitaciones de las base de datos, como la coherencia eventual o la aplicación de esquema. Incluso fuera del ámbito de los juegos, MySQL se usa mucho y la mayoría de los ingenieros de backend tienen mucha experiencia en él.
Si bien MySQL ofrece muchas ventajas, tiene una gran limitación: la escalabilidad. De hecho, como se trata de una base de datos de escalamiento ascendente, si deseas aumentar el rendimiento de MySQL tienes que agregar más CPU, memoria RAM o capacidad de almacenamiento en disco. Cuando una única instancia de MySQL no pueda manejar la carga, podrás dividirla mediante fragmentación, separando usuarios en grupos y asignándoles varias instancias independientes de MySQL. Sin embargo, la fragmentación supone varios inconvenientes. La mayoría de los desarrolladores de juegos calculan el número de fragmentos que necesitarán para la base de datos antes del lanzamiento del juego, ya que volver a aplicar fragmentación es un trabajo intensivo y sujeto a errores. Eso hace que las empresas de videojuegos proporcionen abastecimiento excedente a la base de datos para que, de ser necesario, se puedan manejar más jugadores de los que esperaban. Si el juego es tan popular como se esperaba, todo está bien. Pero ¿qué sucede si el juego es un éxito arrollador y excede la demanda prevista? Y ¿qué sucede ante una larga cola con la que se prevé una reducción gradual de los jugadores activos? ¿Y si es el resultado es un fracaso absoluto? La fragmentación de MySQL no puede escalarse de forma dinámica, y el ajuste de su tamaño requiere mantenimiento y riesgos.
Lo ideal sería que las bases de datos puedan aplicar escalamiento dentro y fuera sin tiempo de inactividad y, a la vez, ofrecer las ventajas de una base de datos relacional. Cuando escuchamos que BNE consideraba aplicar fragmentación de MySQL a fin de manejar el tráfico masivo previsto para Dragon Ball Legends, sugerimos que en lugar de ello tuviera en cuenta Cloud Spanner.
¿Por qué Cloud Spanner?
Cloud Spanner es una base de datos relacional completamente administrada que ofrece escalabilidad horizontal y alta disponibilidad, y al mismo tiempo mantiene una coherencia sólida con un esquema similar al de MySQL. Lo que es mejor aún: como servicio administrado,
Google SRE
se encarga de su supervisión y lo cual elimina el mantenimiento de la base de datos y minimiza el riesgo de tiempo de inactividad. Creímos que Cloud Spanner ayudaría a BNE a dar alcance global a su juego.
Evaluación para la implementación
Antes de adoptar una tecnología nueva, los ingenieros siempre deben probarla para confirmar su rendimiento esperado en la realidad. Antes de reemplazar MySQL, BNE creó una instancia nueva de Cloud Spanner en GCP, incluidas algunas tablas con un esquema similar al que usaban en MySQL. Debido a que sus desarrolladores de backend usaban Scala para escribir, eligieron la
biblioteca cliente Java para Cloud Spanner
y escribieron código de ejemplo para cargar y probar Cloud Spanner. De ese modo, verían si podría satisfacer la demanda de consultas por segundo (QPS) para las operaciones de escritura de alrededor de 30 000 QPS como máximo. Trabajando con nuestro ingeniero de Clientes y con los equipos de ingeniería de Cloud Spanner, alcanzaron el objetivo fácilmente. Desarrollaron, incluso, su propio contenedor de
DML (idioma de manipulación de datos)
para escribir los comandos SQL como INSERT, UPDATE y DELETE.
Lanzamiento del juego
Completada la prueba de concepto, pudieron iniciar la implementación. Según los usuarios diarios activos (DAU) que se esperaban, BNE calculó la cantidad de nodos de Cloud Spanner que necesitaba (suficiente para todos los jugadores previamente registrados que esperaban). Para preparar el lanzamiento, organizaron dos pruebas beta cerradas a fin de validar su backend. ¡No tuvieron ningún problema con la base de datos! Finalmente, más de tres millones de participantes en el mundo se registraron previamente para Dragon Ball Legends e incluso con este gran número el juego se lanzó de manera oficial sin errores.
Para resumir, BNE se puede concentrar en mejorar el juego en lugar de pasar tiempo haciendo funcionar sus bases de datos.
Desafío n.º 2: Red global
Ahora veamos el segundo desafío de BNE: compilar un juego global de jugadores contra jugadores (PvP) en tiempo real. El objetivo de BNE en el caso de Dragon Ball Legends fue permitir que todos los jugadores jugaran unos contra otros en cualquier lugar del mundo. Quien sabe algo sobre redes piensa de inmediato en los desafíos de latencia. El tiempo de ida y vuelta (RTT) entre Tokio y San Francisco, por ejemplo, promedia los 100 ms. Para abordar esto, decidieron dividir cada segundo de juego en intervalos de 250 ms. De esta manera, aunque parezca desarrollarse en tiempo real para los usuarios, el juego es en realidad de turnos rápidos en su esencia (puedes leer más sobre la arquitectura
aquí
). Si bien algunos pueden decir que 250 ms ofrecen mucho lugar para la latencia, es muy difícil predecir la latencia para la comunicación a través de Internet.
¿Por qué redes de nube?
A continuación, se muestra lo que ve un cliente de juegos para acceder al servidor de un juego en GCP a través de Internet. Debido a que el número de saltos puede variar en cada ocasión, esto significa que la experiencia de juego en la modalidad PvP a veces puede percibirse como rápida o lenta.
Uno de los principales aspectos por los cuales BNE decidió usar GCP para el backend de Dragon Ball Legends fue la
red dedicada de Google
. Como puedes ver en la siguiente imagen, cuando se usa GCP, una vez que el cliente accede a uno de los cientos de puntos de presencia (POP) de GCP en todo el mundo se encuentra en la red dedicada de Google. Eso significa que no hay saltos impredecibles, lo que garantiza predictibilidad y la menor latencia posible.
Aprovechar la Google Cloud Network
Por lo general, las empresas de videos juegos implementan PvP conectando dos jugadores directamente o a través de un servidor de juegos dedicado. Generalmente, para los juegos de lucha que requieren una baja latencia entre jugadores se prefiere la comunicación P2P. En general, cuando dos jugadores se encuentran en puntos geográficos cercanos, la comunicación P2P funciona muy bien, pero a menudo no es confiable cuando intentas comunicarte en varias regiones (algunos proveedores incluso bloquean los protocolos P2P). Para que dos jugadores de dos continentes diferentes se puedan comunicar a través de la red dedicada de Google, los jugadores primero intentan comunicarse mediante protocolos P2P y, si eso falla, realizan conmutaciones por error a una implementación de código abierto de servidor STUN o TURN llamada
coturn
, que actúa como una retransmisión entre los dos jugadores. De ese modo, para las batallas entre continentes se aprovechan la baja latencia y la red de Google confiable tanto como sea posible.
Desafío n.º 3: Análisis de datos en tiempo real
El último desafío de BNE tuvo que ver con el análisis de datos en tiempo real. BNE quiso ofrecer la mejor experiencia de usuario a sus fanáticos y una manera de hacerlo fue a través de las operaciones de juegos en vivo, o LiveOps, en las cuales los operadores aplican cambios constantes al juego para que parezca actualizado. Para entender las necesidades de los jugadores, necesitaban datos; por lo general, datos de registro de acciones de los usuarios. De poder obtener estos datos casi en tiempo real, podrían tomar decisiones sobre los cambios que aplicarían al juego para aumentar la satisfacción y el captación de los usuarios.
Para reunir estos datos, BNE usó una combinación de Cloud Pub/Sub y Cloud Dataflow para transformar los datos de los usuarios en tiempo real e insertarlos en BigQuery.
Cloud Pub/Sub ofrece un sistema de mensajería confiable a nivel mundial que carga en búfer los registros hasta que se puedan manejar a través de Cloud Dataflow.
Cloud Dataflow es un servicio de procesamiento paralelo completamente administrado que te permite ejecutar ETL en tiempo real y en paralelo.
BigQuery es el almacén de datos completamente administrado donde se almacenan todos los registros del juego. Debido a que BigQuery ofrece almacenamiento en petabytes, el escalamiento no fue una preocupación. Gracias al procesamiento pesado en paralelo para la consulta de los registros, BNE puede obtener una respuesta a una consulta al escanear terabytes de datos en unos segundos.
Este sistema permite que un productor de juegos pueda ver el comportamiento de un jugador casi en tiempo real y tomar decisiones sobre características nuevas que se incorporarán al juego o cambios que se le aplicarán para satisfacer a todos los seguidores.
Conclusiones
Mediante Cloud Spanner, BNE se concentró en desarrollar un juego sorprendente en lugar de pasar tiempo planeando y escalando la capacidad de la base de datos.
En cuanto a las operaciones, con el uso de una base de datos escalable completamente administrada, BNE redujo drásticamente los riesgos relacionados con errores humanos con una sobrecarga de operaciones.
Mediante Cloud Networking, BNE aprovechó la red dedicada de Google y ofreció la mejor experiencia de usuario para sus fanáticos, incluso en luchas en diferentes regiones.
Finalmente, el uso de la pila de análisis de Google (Cloud PubSub, Cloud Dataflow y BigQuery) permitió a BNE analizar los comportamientos de los jugadores casi en tiempo real y tomar decisiones sobre la forma de ajustar el juego para hacer que sus fanáticos estuvieran aun más satisfechos.
Si quieres más información sobre la manera en que BNE evaluó y adoptó Cloud Spanner para su juego, únete a ellos en su sesión de
Google Cloud NEXT 2018
, en San Francisco.
Labels
.app
.dev
.txt
#AMP
#CPU
#DeveloperStudentClubs
#DevFest
#DragonBall
#DSC
#Forsety
#ForsetySecurity
#freeandopen
#GCP
#Google
#GoogleCloud
#GoogleCloudPlatform
#GoogleLaunchpad
#iio2009
#Kubernetes
#MaterialDesign
#OneCommunity
#Security
#TensorFlow
#UPGlobal
#UpLatam
#WithGoogle
+page
10 YEARS
2013
2019
64 bits
A/B Testing
AA
Accelerator
Action on Goolge
actionbar
Actions
Actions Console
AdMob
Ads
adwords
adwords api
AI
AIY
ajax
alarmmanager
ALFA
almacenamiento
alojamiento de proyectos en google code
AMP
AMP Conf
AMP Project
amp-date-picker
amphtml
Analytics
Andorid
android
Android (operating System)
Android 3.1
android 3.3
android 4.2
android 9
Android 9 Pie
Android App Bundle
android design
Android Dev Summit
Android Developers
android Jetpack
Android P
Android SDK
Android Studio
Android Things
Android Wear
AndroidDevStory
androititlan
angelina jolie
Annotation
Announcements
anuncios
API
API Analytics YouTube
Apigee
APIs
Aplicaciones
aplicaciones chrome
app
app engine
App Indexing
app invites
App Server
applications
AppQuality
apps
Apps Script
AR
ARCore
arte
ATLAS
AWP
backend
Base64
batch
Bava
Betatesting
Better Ads Standars
bigdata
BigQuery
Biometrics
blink
bootcamp
BOT
BQ
Business
búsqueda ajax
by Google
byCases
byCommunity
byDevelopers
byGoogle
C++
CALENDAR
Cardboard
case
caso de éxito
Casos de éxito
casos destacados
CCOSS
Century Fox
chat
chrome
chrome web store
chromebook
chromecast
chromium
Cinéfilos
cloud
Cloud Anchors
CLOUD endpoints
Cloud Firestore
Cloud Functions
Cloud IoT Core
Cloud Next
Cloud Scheduler
Cloud services
cloud test lab
Cloud Text-to-Speech
Cloud Translation
CMD en vivo
coconut
code
code-in
code.org
CodeLabs
código
código abierto
Colab
colombia
Communities
Comunidades
concurso google
conference
contenedores
convocatoria
Coordinate
crashlytics
CRE
crear aplicaciones ajax
creatividad
Crowdsource
CSS
cws
daniela robles
dart
dart sdk
dartium
dartlang
Dataset
DCL
denis labelle
desarrolladores
Desarrolladores Google
desarrolladores LatAm
Desarrollar
Design
Design Sprint
Destacados
dev
Dev.f
DevArt
DevBus
DevBusLatAm
Developer Bus
Developer Summit
DeveloperConsole
developers
DevFest
devoxx
dialogflow
diseño UX
Distribuir
DNS
DOM
domain
DonkeyCar
doubleclick
Drive SDK
Drivers
ecommerce
ecosistema
elections
elizalde
Emoticons
emprendedores
empresas
engagement
english
Enhanced Campaigns
enterprise
eventos
Events
evolución de aplicaciones
Excel
ExpertosDicen
Faas
Family
FanBridge
FCM
FCP
Featured
fido
find people
Fintech
firebase
Firebase Cloud Messaging
firebase summit
flu trends
Flutter
Flutter 1.0
flutter 1.7
flutter developers
Flutter Live
FlutterLive
FoundersLab
Freebase
Fuction
Fuctions
Full-Stack
functional programming
G Suite Dev Show
G+
g+ goto gal
G+GotoGal
GAE
game
games
GCloud
gcm
GCP
GCS
GDA
GDE
GDG
GDH
GDL
GDLevent
GDS
Get Inspired
get.app
GitHub
GLP
gmail
golang
GOMO
Google
Google Accelerator
Google AdMob SDK
Google AdWords
Google Analytics
Google APIS
Google App Engine
Google Apps
Google Apps Script
Google Art Project
Google Assistant
google calendar
google cast
Google Charts
Google Chrome
Google Cloud
Google Cloud Console
Google Cloud Messaging
Google Cloud Next
Google Cloud Platform
Google Cloud Platform Newsletter
google cloud platforn
Google Cloud Storage
google code-in
Google Compute Engine
Google Dataset
Google Developer Groups
google developers
Google Developers Academy
google developers expert
Google Developers Hackademy
google dns
Google Drawings
Google Drive
Google Earth
Google for games
Google Forms
google geo
Google Home
google i/o
google i/o extended
google io
Google Keep
Google Kubernetes Engine
Google Launchapad
Google Launchpad
Google Maps
google maps coordinate
Google Maps Platform
Google Mexico
Google Nose
google now
Google Person Finder
google places api
Google Play
Google Play Books
Google Play Developer API
google play games
Google Play Movies
Google Play Protect
Google Play Services
Google Plus
Google Science Fair
google search
Google Sheets
google sign in
Google Top Geek
Google+
Google+ Communities
Google+ Hangouts
google+ sign-in
GoogleAPI
googlecloud storage
GoogleCloudPlatform
googledevs
GooglePlay
Googleplex
Goolge Lunchpad
GTG
Hackademy
hackers
Haiko
Haití
hangouts
Hangouts Remote Desktop
hardcode
Heello
honeycomb
HTML
HTML5
HTTPS
I/O
IA
IAM
IETF
IFAI
in app purchases
in-app
ingles
Ingress
instagram
integración de soluciones
interactive post
Interesante
International
International Women’s Day
IO
io15
io18
io19
iOS
IoT
istio
IU
IVR
J2EE
java
JavaScript
jelly bean
JS
JSON
Juegos
juegos html5
Kit ML
Knative
kotlin
kUBERNATES
Kubernetes
LATAM
latamRegionSur
Launchpad
Launchpad Studio
Lenovo Mirage Solo
lightbox
linux
lucero galindo
machine learning
Made with Code
Mapdata
Mapeo
maps
Maps Ad Unit
Maps API
Maps Engine
Market
Marketing
Marshmallow
MATERIAL DESIG
Material Design
mejores apps 2013
México
michelle marie
MIT
MIT Global Start-up Labs
MIT-AITI
ML
ML Kit
mobile
monetizar
mongoDB
MOOC
Motorola
Mountain View
móvil
MQTT
mr.white
mTLS
natalie villalobos
Navigation
NBA JAM
NES
Next Big Sound
Next Level
nfc
Niantic
Nik
NINTENDO
node.js
NoSQL
nube
OAuth2
Objective-C
OClock
open source
OPenApi
OS
OSS
Paas
PageSpeed
PagesSpeed
parallel18
patrones
patters
performance
permisos
Pipeline API
Pixability
pixel
Píxel
play
Play Console
Playtime
Podcast
pollito pio
Polymer
por lote
Posse
Prediction API
primer
Producto
programación
Propositos
Protocol Buffers
proyecto 20%
Push API
PYMES
python
Q
Q4
quickoffice
Rasberry Pi Zero WH
Raspberry Pi
Realtime
Reflectly
register
Release
Resources
robots.txt
Safe
SDK
Search
Security
seedbank
seguridad
SEO
servidores
Showyou
sign-in
SNES
SO
social media
Spain
SpLATAM
SQL
SQLite
Start
startup grind
Startup Launch
startup weekend
startup weekend for the planet
startupbus
startups
StayAtHome
story
Street View
subtitles
success
sw
SyScan
tablet
Tablet Optimization Tips
tabletas
takeaction
Tango
tendencias 2013
TensorFlow Developer Summit
testing
TextView
TF JAM
The Garage
The Venture City
tips G+
tips gmail
TLD
TLS
Top Experts
Top Geek
top level domain
TopExpert
topics
traducciones
Transparency Report
triggers
Tubular Labs
twilio
Tyka
TypeScript
UAC
udacity
ui
Umbrales
UNAM
unity
Unity3D
universal search
UX
Vector
VectorDrawable
video juegos
vidIQ
ViewPager
Visual Progress
Voicekit
VPC
VR
VSCode
web
Web hosting
Web móvil
WebAssembly
with google
Wizdeo
WizTracker
Women at Google
Women Techmakers
workmanager
WTM
XKCD
XML
Yifat Cohen
youtube
YouTube Analytics API
YouTube API
YouTube Data API
YouTube One Channel
YouTube Player API
Archive
2024
sept
2023
nov
oct
sept
ago
jun
may
abr
mar
ene
2022
dic
nov
oct
sept
ago
jul
jun
may
abr
mar
feb
ene
2021
dic
nov
oct
sept
ago
jul
jun
may
abr
mar
feb
2020
dic
nov
oct
sept
ago
jul
jun
may
abr
mar
feb
ene
2019
dic
nov
oct
sept
ago
jun
may
abr
mar
feb
ene
2018
dic
nov
oct
sept
ago
jul
jun
may
abr
mar
feb
2017
nov
sept
ago
jul
jun
may
abr
ene
2016
nov
oct
sept
ago
jul
jun
may
abr
mar
feb
ene
2015
dic
nov
oct
sept
ago
jul
jun
may
abr
mar
feb
ene
2014
dic
oct
sept
ago
jul
jun
may
abr
mar
feb
ene
2013
dic
nov
oct
ago
jul
jun
may
abr
mar
feb
ene
2012
dic
nov
oct
sept
ago
jul
2011
nov
oct
may
mar
2010
dic
nov
oct
sept
ago
jul
jun
may
abr
mar
feb
ene
2009
dic
nov
sept
ago
jul
jun
may
abr
mar
feb
ene
2008
oct
sept
ago
jul
jun
may
abr
mar
feb
ene
2007
dic
Feed
Desarrolladores
Eventos y Comunidad
Casos Destacados
Dicen los Expertos
Google Accelerator