Crear una plataforma de análisis de juegos móviles: una arquitectura de referencia

Las aplicaciones de juegos móviles generan una gran cantidad de datos de telemetría de jugadores y eventos de juegos. Estos datos tienen el potencial de proporcionar información sobre el comportamiento de los jugadores y su compromiso con el juego. La naturaleza de los juegos móviles (gran cantidad de dispositivos cliente, conexiones a Internet lentas e irregulares, problemas de batería y administración de energía) significa que la telemetría de los jugadores y el análisis de eventos de juegos se enfrentan a desafíos únicos.

Esta arquitectura de referencia proporciona un enfoque de alto nivel para recopilar, almacenar y analizar grandes cantidades de datos de telemetría de jugadores en Google Cloud Platform.

Más concretamente, descubrirás dos patrones de arquitectura principales para analizar eventos de juegos móviles:

  • Procesamiento en tiempo real de eventos individuales mediante un patrón de procesamiento de transmisión
  • Procesamiento masivo de eventos agregados mediante un patrón de procesamiento por lotes

Arquitectura de referencia para la telemetría de juegos

Figura 1: Arquitectura de referencia de telemetría de juego

La figura 1 muestra los canales de procesamiento para ambos patrones, así como algunos componentes opcionales para explorar, visualizar y compartir los resultados. La arquitectura de referencia cuenta con una alta disponibilidad y permite escalar a medida que aumentan los volúmenes de datos. Asimismo, ten en cuenta que esta arquitectura está compuesta únicamente por servicios gestionados para sus canalizaciones de análisis de datos, eliminando la necesidad de ejecutar máquinas virtuales o administrar sistemas operativos. Esto es especialmente cierto si tu servidor de juegos gestiona la autenticación de usuario a través de App Engine. El resto de este artículo te guiará paso a paso a través de esta arquitectura.

Procesamiento de eventos en tiempo real mediante el patrón de transmisión

Esta sección explora un patrón de arquitectura de ejemplo que ingiere, procesa y analiza una gran cantidad de eventos al mismo tiempo desde muchas fuentes diferentes. El procesamiento se produce a medida que se desarrollan los eventos en tu juego, lo que te permite responder y tomar decisiones en tiempo real.

Muchos juegos móviles generan una gran cantidad de mensajes de eventos. Algunos los activa el jugador, otros la hora del día, etc. Como consecuencia, los conjuntos de datos no tienen límites y no sabes cuántos eventos procesar de antemano. Por lo tanto, el enfoque correcto es procesar los datos utilizando un motor de ejecución de transmisión.

Imagina que tu aplicación móvil es un juego de rol que permite a los jugadores luchar contra las fuerzas del mal embarcándose en misiones para vencer a poderosos monstruos. Para seguir el progreso del jugador, un típico mensaje de evento contiene un identificador único para el jugador, una marca de tiempo del evento, métricas que indican la misión, el estado actual del jugador, etc. Es posible que se vea algo similar a este ejemplo, mostrando un mensaje de evento de final de batalla con un identificador de evento de playerkillednpc.

{
"eventTime":"2015-10-27T20:34:12.675362426+08:00",
"userId":"gamer@example.com",
"sessionId":"b6ff8881-0c30-9add-374c-c32052cee256",
"eventId":"playerkillednpc",
…
"attackRoll":17,
"damageRoll":13
}

Este ejemplo presentaba un evento relacionado con la batalla, pero los mensajes de eventos pueden incluir cualquier tipo de información que sea relevante para tu negocio, por ejemplo, eventos de compra dentro del juego.

Como no puedes predecir qué preguntas querrás hacer sobre tus datos en el futuro, es una buena estrategia registrar todos los puntos de datos posibles. De este modo, cuentas con el contexto adicional necesario para tus futuras consultas de datos. Por ejemplo, ¿qué es más esclarecedor: el hecho de que un jugador hizo una compra en el juego que cuesta 50 centavos, que lanzó un poderoso hechizo mágico contra el jefe en la misión 15, o que fue asesinado por ese jefe cinco veces en un fila en los 30 minutos anteriores a la compra? La captura de datos de eventos enriquecidos te brinda información detallada sobre lo que sucede exactamente en el juego.

Origen del mensaje: ¿servidor móvil o servidor de juegos?

Independientemente de los campos de contenido de tus mensajes de eventos, debes decidir si enviar los mensajes de eventos directamente desde el dispositivo del usuario final que ejecuta la aplicación móvil a la capa de ingestión Cloud Pub/Sub o al servidor del juegos. La principal ventaja de pasar por el servidor de juegos es que tu aplicación gestiona la autenticación y la validación. Un inconveniente es que se requerirá una capacidad adicional de procesamiento del servidor para gestionar la carga de mensajes de eventos que llegan desde dispositivos móviles.

Procesamiento de eventos de servidor de juegos y clientes de juegos en tiempo real

Figura 2: Procesamiento en tiempo real de eventos de clientes y servidores de juegos

Independientemente de la fuente de los datos, la arquitectura de backend sigue siendo, en gran medida, la misma. Como se muestra en la figura 2, hay cinco partes principales:

  1. Los mensajes de eventos en tiempo real los envían numerosas fuentes, por ejemplo, millones de aplicaciones móviles.
  2. La autenticación la gestiona el servidor de juegos.
  3. Cloud Pub/Sub ingiere y almacena estos mensajes de forma temporal.
  4. Cloud Dataflow transforma el evento JSON en datos estructurados basados en esquema.
  5. Esos datos se cargan en el motor de análisis de BigQuery.

Cloud Pub/Sub: ingerir eventos a escala

Para gestionar esta carga, debes tener un servicio escalable capaz de recibir y almacenar estos mensajes de eventos de forma temporal. Como cada evento individual es bastante pequeño, la cantidad total de mensajes es más preocupante que el requisito general de almacenamiento.

Otro requisito para este servicio de ingestión es permitir múltiples métodos de salida. Esto significa que los eventos deben poder consumirlos múltiples destinos. Finalmente, debe haber una opción entre el servicio que actúa como una cola, donde cada destino busca nuevos mensajes, y un método de inserción, que envía eventos de forma proactiva en el momento en que se reciben.

Por suerte, el servicio Cloud Pub/Sub ofrece toda esta funcionalidad. La figura 3 muestra la capa de ingestión recomendada, capaz de procesar millones de mensajes por segundo y almacenarlos durante hasta 7 días en un almacenamiento persistente. Cloud Pub/Sub lleva un patrón de publicación o suscripción donde puedes tener uno o más editores que envían mensajes a uno o más temas. También puede haber múltiples suscriptores para cada tema.

Modelo de publicación y suscripción Cloud Pub/Sub publish con almacenamiento persistente

Figura 3: Modelo de publicación y suscripción de Cloud Pub/Sub con almacenamiento persistente

Puedes elegir la cantidad de temas y la agrupación de cada uno. Como existe una relación directa entre la cantidad de temas y la cantidad de canalizaciones de Cloud Dataflow que crea, lo mejor es agrupar eventos conectados de forma lógica. Por ejemplo, un editor puede ser un dispositivo móvil individual o un servidor de juegos, con múltiples editores para un solo tema. Todo lo que se requiere es la capacidad de autenticar y enviar un mensaje con formato correcto a través de HTTPS.

Una vez que el servicio Cloud Pub/Sub recibe un mensaje, en este caso un evento de telemetría del jugador, se almacena de manera duradera en el almacén de mensajes hasta que cada suscripción del tema haya recuperado ese mensaje.

Canal de transmisión de Cloud Dataflow

Cloud Dataflow proporciona un lenguaje de alto nivel para describir los canales de procesamiento de datos de una manera sencilla. Puedes ejecutar estos canales utilizando el servicio gestionado Cloud Dataflow. Los canales de Cloud Dataflow se ejecutan en modo de transmisión y reciben mensajes del tema Cloud Pub/Sub a medida que llegan a través de una suscripción. A continuación, Cloud Dataflow realiza cualquier procesamiento obligatorio antes de agregarlos a una tabla de BigQuery.

Este procesamiento puede tomar la forma de operaciones sencillas basadas en elementos, como poner todos los nombres de usuario en minúsculas o unir elementos con otras fuentes de datos; por ejemplo, unir una tabla de nombres de usuario a estadísticas de jugadores.

Transformar mensajes JSON en formato de tabla BigQuery

Figura 4: Transformar los mensajes JSON en formato de tabla BigQuery

Cloud Dataflow puede llevar a cabo cualquier cantidad de tareas de procesamiento de datos, incluida la validación en tiempo real de los datos de entrada. Un caso práctico es la detección de fraude, por ejemplo, destacando a un jugador con el máximo de puntos de golpes fuera del rango válido. Otro caso práctico es la limpieza de datos, como garantizar que el mensaje del evento esté generado correctamente y que coincida con el esquema de BigQuery.

El ejemplo de la figura 4 retira el mensaje JSON original del servidor del juego y lo convierte en un esquema de BigQuery. La clave es que no tienes que administrar ningún servidor o máquina virtual para realizar esta acción, pues Cloud Dataflow hace el trabajo de iniciar, ejecutar y detener los recursos informáticos para procesar la canalización en paralelo. Asimismo, puedes reutilizar el mismo código para la transmisión y el procesamiento por lotes.

El SDK de Cloud Dataflow de código abierto proporciona la ejecución de interconexiones separada de la ejecución del programa Cloud Dataflow. Dicho programa crea la canalización y, por su parte, el código que has escrito genera una serie de pasos que el ejecutor de canalizaciones acabará realizando. Dicho ejecutor puede ser el servicio gestionado Cloud Dataflow en GCP, un servicio ejecutor externo como Spark y Flink, o un ejecutor local de canalización que ejecuta los pasos directamente en el entorno local, que es especialmente útil para fines de desarrollo y pruebas.

Cloud Dataflow asegura que cada elemento se procesa exactamente una vez, y también puede aprovechar las funciones de ventanas de tiempo y activadores para agregar eventos en función de la hora real en que ocurrieron (hora del evento) en lugar del momento en que se enviaron a Cloud Dataflow (hora de procesamiento). Es posible que algunos mensajes se retrasen debido a problemas de conexión a Internet móvil o a que se agoten las pilas pero, aun así, te conviene agrupar eventos por sesión de usuario. La funcionalidad de ventanas de sesión integrada de Cloud Dataflow lo admite. Consulta The world beyond batch: Streaming 101 para ver una excelente introducción a las estrategias de ventanas de datos.

De forma alternativa, si tus eventos contienen un campo de sesión único, como un identificador único universal (UUID), también puedes usar esta clave para agrupar eventos relacionados. La elección más adecuada dependerá de tu escenario específico.

BigQuery: almacén de datos totalmente gestionado para análisis de datos a gran escala

BigQuery se compone de dos partes principales: un sistema de almacenamiento que proporciona persistencia de sus datos con redundancia geográfica y alta disponibilidad. Además de eso, es el motor de análisis que te permite ejecutar consultas de tipo SQL sobre conjuntos de datos masivos. BigQuery organiza los datos en conjuntos que pueden contener múltiples tablas. Para BigQuery se requiere la definición de un esquema para cada tabla, y el trabajo principal de Cloud Dataflow en la sección anterior era estructurar los datos de eventos sin procesar con formato JSON en una estructura de esquema de BigQuery mediante el conector de BigQuery incorporado.

Una vez que los datos se cargan en una tabla de BigQuery, puedes ejecutar consultas SQL interactivas para extraer información valiosa. BigQuery está diseñado para una escala muy grande y permite ejecutar consultas de agregación sobre conjuntos de datos a escala de petabyte con tiempos de respuesta rápidos. Esto es ideal para el análisis interactivo.

Herramientas de visualización de datos

BigQuery también se integra con varias herramientas populares de BI y visualización de terceros, como Tableau y QlikView. Si estás familiarizado con Jupyter Notebook (anteriormente IPython), el servicio Cloud Datalab también ofrece conectividad incorporada a BigQuery. Finalmente, puedes ejecutar consultas de BigQuery directamente desde Hojas de cálculo de Google y Microsoft Excel.

Procesamiento masivo mediante el patrón de lote

El otro patrón principal es el procesamiento regular de conjuntos de datos grandes y limitados que no tienen que procesarse en tiempo real. La canalización por lotes se usará a menudo para crear informes o se combinará con fuentes en tiempo real para lograr lo mejor de ambas opciones: datos históricos fiables que contienen la información más reciente que entra a través de los canales de transmisión en tiempo real.

Procesamiento por lotes de eventos y registros de servidores de juegos

Figura 5: Procesamiento por lotes de eventos y registros de servidores de juegos

Cloud Storage es el lugar recomendado para almacenar archivos grandes. Se trata de un servicio de almacenamiento de objetos duradero, rentable y de alta disponibilidad. Pero tal vez te hagas una pregunta: ¿En primer lugar, cómo se meten los datos en Cloud Storage? La respuesta depende de tus fuentes de datos y es el tema que se trata en las siguientes secciones. Verás tres escenarios de fuentes de datos diferentes: en las instalaciones, otros proveedores de la nube y GCP.

Escenario 1: transferencia de archivos desde servidores locales

Puedes transferir archivos de registro de forma segura desde tu centro de datos local utilizando una serie de métodos. La forma más común es usar la utilidad de línea de comandos de código abierto gsutil para configurar transferencias recurrentes de archivos. El comando gsutil ofrece varias funciones útiles, incluidas cargas paralelas de subprocesos múltiples cuando tienes muchos archivos, sincronización automática de un directorio local, cargas reanudables para archivos grandes y, para archivos muy grandes, puedes dividir el archivo en partes más pequeñas y cargarlo en paralelo. Estas características reducen el tiempo de carga y utilizan la mayor cantidad de conexión de red posible.

Si no tienes suficiente ancho de banda de Internet para lograr cargas puntuales, puedes conectarte directamente al GCP mediante Direct Peering o Carrier Interconnect. De forma alternativa, si prefieres enviar contenido físico, hay un servicio de terceros llamado importación y exportación de medios sin conexión que recibirá tu contenido y lo cargará en tu nombre.

Escenario 2: transferencia de archivos desde otros proveedores de la nube

Algunos archivos de registro se pueden almacenar con otros proveedores de la nube. Quizás ejecutas un servidor de juego allí y envías los registros a un servicio de almacenamiento a ese proveedor en la nube. O bien utilizas un servicio que tiene un destino de almacenamiento predeterminado. Amazon Cloudfront (un servicio de red de distribución de contenido), por ejemplo, almacena tus registros en un segmento de Amazon S3. Por suerte, mover datos de Amazon S3 a Cloud Storage es muy sencillo.

Si transfieres a diario grandes cantidades de archivos de Amazon S3 a Cloud Storage, puedes usar el servicio de transferencia de almacenamiento para transferir archivos de fuentes que incluyen los servicios de Amazon S3 y HTTP/HTTPS. Puedes configurar transferencias periódicas y el servicio de transferencia de Cloud Storage admite varias opciones avanzadas. Este servicio aprovecha el gran ancho de banda de la red entre los principales proveedores de la nube y utiliza técnicas avanzadas de optimización del ancho de banda para lograr velocidades de transferencia muy altas.

La norma es usar este servicio por 1TB-10TB o más por transferencia, ya que podría ahorrarte la sobrecarga operacional de ejecutar la herramienta gsutil mencionada en el escenario 1 en múltiples servidores. En el caso de transferencias más pequeñas, o donde necesitas mover datos varias veces al día, puedes ver que la herramienta gsutil mencionada en el escenario 1 es una buena opción.

Escenario 3: los datos ya están en GCP

En algunos casos, los datos que deseas se almacenan automáticamente en Cloud Storage de forma predeterminada. Por ejemplo, los datos de Google Play Store, incluidos los informes de revisiones, informes financieros, instalaciones, bloqueo y aplicación que no responde (ANR), se encuentran disponibles en un segmento de Cloud Storage en tu cuenta de desarrollador de Google Play. En estos casos, puedes mantener los datos en el segmento original en el que se exportaron, a menos que tengas motivos para moverlos a otro segmento.

Patrón de servicio de transferencia asíncrono

Un enfoque a largo plazo y escalable es implementar un patrón de servicio de transferencia asíncrono en el que utilices una o más colas y mensajes para iniciar transferencias basadas en eventos o activadores. Por ejemplo, cuando se escribe un nuevo archivo de registro en el disco o en el almacén de archivos de origen, se envía un mensaje a la cola y los trabajadores se encargan de transferirlo a Cloud Storage, eliminando el mensaje de la cola solo cuando se realiza correctamente.

Patrón de lote alternativo: carga directa de Cloud Storage a BigQuery

Es posible que te preguntes si es estrictamente necesario utilizar Cloud Dataflow entre Cloud Storage y BigQuery. Puedes cargar directamente los archivos JSON en Cloud Storage proporcionando un esquema y comenzando un trabajo de carga. O bien puedes consultar directamente los archivos de copia de seguridad CSV, JSON o Cloud Datastore en un segmento de Cloud Storage. Esta puede ser una solución aceptable para comenzar, pero ten en cuenta los beneficios de usar Cloud Dataflow:

  • Transformar los datos antes de comprometerse con el almacenamiento. Por ejemplo, puedes agregar datos antes de cargarlos en BigQuery, agrupando diferentes tipos de datos en tablas separadas. De esta forma, se pueden reducir los costes de BigQuery al minimizar la cantidad de filas que consultas. En un escenario en tiempo real, puedes usar Cloud Dataflow para calcular tablas de clasificación en sesiones individuales o cohortes como gremios y equipos.

  • Usar de forma intercambiable canales de datos de transmisión y por lotes escritos en Cloud Dataflow. Cambia la fuente y el receptor de datos, por ejemplo, desde Cloud Pub/Sub a Cloud Storage, y el mismo código funcionará en ambos escenarios.

  • Ser más flexible en términos de esquema de bases de datos. Por ejemplo, si con el tiempo has agregado campos adicionales a tus eventos, puedes añadir los datos JSON adicionales sin procesar a un campo catch-all en el esquema y usar la funcionalidad de consultas JSON de BigQuery para realizar consultas dentro de dicho campo. A continuación, puedes consultar en múltiples tablas de BigQuery, aunque el evento de origen requeriría estrictamente esquemas diferentes. Esto se muestra en la figura 6.

Columna adicional para capturar nuevos campos de eventos en JSON sin procesar

Figura 6: Columna adicional para capturar nuevos campos de eventos en formato JSON sin procesar

Consideraciones operativas para las arquitecturas de referencia

Una vez que hayas establecido y creado tus canalizaciones, es importante controlar el rendimiento y las excepciones que puedan ocurrir. La interfaz de usuario de supervisión de Cloud Dataflow proporciona una vista gráfica de tus trabajos de canalización de datos, así como de las métricas clave. La figura 7 te muestra esto en una captura de pantalla.

Consola de supervisión de Cloud Dataflow incorporada

Figura 7: Consola de supervisión de Cloud Dataflow incorporada

La consola de Cloud Dataflow proporciona información sobre el gráfico de ejecución de canalización, así como estadísticas de rendimiento actuales, como la cantidad de mensajes procesados en cada paso, el retraso estimado del sistema y la marca de agua de datos. Para obtener información más detallada, Cloud Dataflow está integrado con el servicio Stackdriver Logging; en la figura 8 puedes ver una captura de pantalla de ejemplo.

Stackdriver Logging está integrado con Cloud Dataflow

Figura 8: Stackdriver Logging está integrado con Cloud Dataflow

Lectura adicional y recursos adicionales

¿Te ha resultado útil esta página? Enviar comentarios:

Enviar comentarios sobre...