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.
