Compila una plataforma de estadísticas de videojuegos para dispositivos móviles: una arquitectura de referencia

Las aplicaciones de juegos para dispositivos móviles generan una gran cantidad de datos de telemetría de los jugadores y eventos de juego. Estos datos tienen el potencial de proporcionar estadísticas sobre el comportamiento de los jugadores y su participación en el juego. La naturaleza de los juegos para dispositivos móviles (gran cantidad de dispositivos cliente, conexiones a Internet irregulares y lentas, problemas de batería y administración de energía) hacen que la telemetría de los jugadores y las estadísticas de eventos de juego se enfrenten a desafíos únicos.

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

De manera más específica, aprenderás dos patrones principales de arquitectura a fin de analizar eventos de juegos para dispositivos 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 telemetría de juego

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

La Figura 1 ilustra las canalizaciones de procesamiento para ambos patrones y algunos componentes opcionales mediante los cuales se puede explorar, visualizar y compartir los resultados. La arquitectura de referencia posee alta disponibilidad y te permite escalar a medida que el volumen de tus datos aumenta. Además, ten en cuenta que esta arquitectura está compuesta solo por servicios administrados para las canalizaciones de tus estadísticas de datos. Esto elimina la necesidad de ejecutar máquinas virtuales o administrar sistemas operativos. Esto se aplica en especial si tu servidor de juego realiza la autenticación de usuarios mediante App Engine. En el resto de este artículo se te guiará por esta arquitectura paso a paso.

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

En esta sección se explora un ejemplo de patrón arquitectónico que transfiere, procesa y analiza una gran cantidad de eventos de distintas fuentes de manera simultánea. El procesamiento ocurre mientras se desarrollan los eventos en tu juego, lo que te permite responder y tomar decisiones en tiempo real.

Muchos juegos para dispositivos móviles generan una gran cantidad de mensajes de evento. La activación de algunos depende del jugador, otros, por ejemplo, se activan según el momento del día. Como consecuencia, los conjuntos de datos no tienen límites y no sabes cuántos eventos procesar con antelación. Por este motivo, el enfoque correcto es procesar los datos mediante un motor de ejecución de transmisión.

Imagina que tu app para dispositivos móviles es un juego de rol que les permite a los jugadores luchar contra fuerzas malvadas a través de misiones para derrotar a monstruos poderosos. A fin de seguir el progreso del jugador, un mensaje de evento típico incluye un identificador único para el jugador, una marca de tiempo del evento, métricas que indican la misión, la salud actual del jugador, y demás. Quizás sea similar a este ejemplo, que muestra un mensaje de final de batalla del evento 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 muestra un evento relacionado con la batalla, pero los mensajes de evento pueden incluir cualquier tipo de información relevante a tus asuntos como eventos de compras en el juego.

Como no puedes predecir qué preguntas querrás hacer sobre tus datos en el futuro, una buena estrategia es registrar tantos datos como puedas. Esto proporciona el contexto adicional necesario para tus futuras consultas sobre datos. Por ejemplo, ¿qué proporciona más información? ¿Que un jugador realizó una compra en el juego por 50 centavos o que compró un hechizo mágico potente contra el jefe en la misión 15 y que ese jefe mató al jugador cinco veces seguidas en los 30 minutos previos a la compra? Capturar datos de evento variados te proporciona información detallada de lo que ocurre en tu juego.

Fuente del mensaje: ¿dispositivo móvil o servidor del juego?

Sin importar los campos de contenido de tus mensajes de evento, debes decidir si los mensajes de evento se enviarán de forma directa desde el dispositivo de usuario final que ejecuta la app para dispositivos móviles a la capa de transferencia de Cloud Pub/Sub o a través del servidor del juego. El beneficio principal de hacerlo a través del servidor del juego es que tu aplicación se encarga de la autenticación y validación. Una desventaja es que se necesitará capacidad adicional de procesamiento de servidores para soportar la carga de mensajes de evento que provienen de dispositivos móviles.

Procesamiento de eventos de clientes de juego y servidores de juego en tiempo real

Figura 2: Procesamiento de eventos en tiempo real por parte de clientes y servidores de juego

Sin importar la fuente de los datos, la arquitectura de backend se mantiene casi igual. Como se muestra en la Figura 2, hay cinco partes principales:

  1. Un gran número de fuentes envían mensajes de evento en tiempo real, por ejemplo, a millones de apps para dispositivos móviles.
  2. El servidor del juego se encarga de la autenticación.
  3. Cloud Pub/Sub transfiere y almacena de forma temporal estos mensajes.
  4. Cloud Dataflow transforma el evento JSON en datos estructurados y con base en esquemas.
  5. Los datos se cargan en el motor de estadísticas de BigQuery.

Cloud Pub/Sub: transferencia de eventos a gran escala

Para manejar esta carga, necesitas un servicio escalable capaz de recibir y almacenar de manera temporal estos mensajes de evento. Debido a que cada evento individual es de tamaño pequeño, la cantidad total de mensajes es de mayor preocupación que el requisito de almacenamiento total.

Otro requisito para este servicio de transferencia es permitir múltiples métodos de resultado. Esto significa que los eventos deberían ser consumibles para múltiples destinos. Por último, debería haber una opción entre el servicio que actúa como una cola, en el que cada destino encuesta para recibir nuevos mensajes, y un método de envío, que envía eventos de manera proactiva en el momento en que los recibe.

Por suerte, el servicio de Cloud Pub/Sub proporciona todas estas funciones. La Figura 3, muestra la capa de transferencia recomendada, capaz de procesar millones de mensajes por segundo y guardarlos por hasta 7 días en almacenamiento continuo. Cloud Pub/Sub opera con un patrón de publicación y suscripción en el que uno o más publicadores pueden enviar mensajes a uno o más temas. Puede haber múltiples suscriptores a cada tema.

El modelo de publicación y suscripción de Cloud Pub/Sub con almacenamiento continuo

Figura 3: El modelo de publicación y suscripción con almacenamiento continuo de Cloud Pub/Sub

Puedes elegir la cantidad de temas y la forma en que se agrupan. Es mejor agrupar los eventos conectados de manera lógica, ya que hay una relación directa entre la cantidad de temas y la cantidad de canalizaciones de Cloud Dataflow que creas. Por ejemplo, un publicador puede ser un dispositivo móvil individual o un servidor del juego, con múltiples publicadores en un solo tema. Lo único que se requiere es la capacidad de autenticar y enviar un mensaje con el formato correcto mediante HTTPS.

Una vez que el servicio de Cloud Pub/Sub recibe el mensaje (en este caso, un evento de telemetría de un jugador), se almacena de manera duradera en el almacenamiento de mensajes hasta que todas las suscripciones al tema lo reciban.

Canalización de transmisión de Cloud Dataflow

Cloud Dataflow proporciona un lenguaje de nivel alto para describir de forma fácil las canalizaciones de procesamiento de datos. Puedes ejecutar estas canalizaciones mediante el servicio administrado de Cloud Dataflow. La canalización de Cloud Dataflow se ejecuta en modo de transmisión y recibe mensajes del tema Cloud Pub/Sub a medida que llegan a través de una suscripción. Luego, Cloud Dataflow realiza el procesamiento requerido antes de agregarlos a una tabla de BigQuery.

Este procesamiento puede ser en la forma de operaciones simples en términos de elementos, como hacer que todos los nombres de usuario estén en minúscula, o unir elementos con otras fuentes de datos, como unir una tabla de nombres de usuario con las estadísticas de los jugadores.

Transforma mensajes JSON en formato de tabla de BigQuery

Figura 4: Transforma mensajes JSON en el formato de tabla de BigQuery

Cloud Dataflow puede realizar muchas tareas de procesamiento de datos, incluida la validación en tiempo real de datos de entrada. Un caso práctico es la detección de fraude; por ejemplo, destacar a un jugador con puntos de salud que exceden el rango válido. Otro caso práctico es la limpieza de datos, como asegurarse de que el mensaje de evento tenga el formato correcto y coincida con el esquema de BigQuery.

El ejemplo en la Figura 4 desmarca el mensaje original JSON del servidor del juego y lo convierte al esquema de BigQuery. La clave es que no tienes que administrar ningún servidor o máquinas virtuales para realizar esta acción. Cloud Dataflow se encarga de iniciar, ejecutar y detener los recursos de procesamiento para procesar tu canalización de forma paralela. También puedes volver a usar el mismo código para los procesamientos por lotes y de transmisión.

El SDK de Cloud Dataflow de código abierto proporciona la posibilidad de ejecutar la canalización y tu programa de Cloud Dataflow por separado. Tu programa de Cloud Dataflow construye la canalización y el código que escribiste genera una serie de pasos que el ejecutor de canalizaciones debe realizar. El ejecutor de canalizaciones puede ser el servicio administrado de Cloud Dataflow en GCP, un servicio de ejecución de terceros como Spark y Flink, o un ejecutor de canalizaciones local que ejecute los pasos de forma directa en el entorno local, que es útil, en particular, para el desarrollo y las pruebas.

Cloud Dataflow se asegura de que cada elemento se procese exactamente una vez. También puedes aprovechar las funciones de sistema de ventanas de tiempo y activadores para agregar eventos con base en el tiempo real en que ocurrieron (tiempo del evento), a diferencia del tiempo en que se envían a Cloud Dataflow (tiempo de procesamiento). Puede que algunos mensajes se retrasen en la fuente debido a problemas con la conexión de Internet móvil o agotamiento de la batería, pero aun así deberías agrupar los eventos por sesión de usuario. La función integrada de sistema de ventanas de sesión de Cloud Dataflow es compatible con esto. Consulta El mundo más allá de los lotes: introducción a la transmisión para una introducción excelente a las estrategias de sistema de ventanas de datos.

De manera 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 decisión más apropiada dependerá de tu caso específico.

BigQuery: almacén de datos completamente administrado para estadísticas de datos a gran escala

BigQuery consiste de dos partes principales: un sistema de almacenamiento que proporciona la continuidad de tus datos con redundancia geográfica y alta disponibilidad. Además, es el motor de estadísticas que te permite ejecutar consultas similares a las de SQL sobre conjuntos de datos masivos. BigQuery organiza sus datos en conjuntos de datos que contienen múltiples tablas. BigQuery requiere que se defina un esquema para cada tabla. El trabajo principal de Cloud Dataflow en la sección anterior era estructurar los datos de evento sin procesar con formato JSON en una estructura de esquema de BigQuery mediante el conector incorporado de BigQuery.

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

Herramientas de visualización de datos

Google Data Studio te permite crear y compartir paneles interactivos que acceden a una amplia variedad de fuentes de datos, incluido BigQuery.

BigQuery también es compatible con muchas herramientas de inteligencia empresarial y visualización de terceros, como Tableau y QlikView. Si estás familiarizado con las notebooks de Jupyter (antes IPython), el servicio de Cloud Datalab ofrece conectividad incorporada a BigQuery. Por último, puedes ejecutar consultas de BigQuery de forma directa desde Hojas de cálculo de Google y Microsoft Excel.

Procesamiento masivo mediante el patrón por lotes

El otro patrón principal es el procesamiento normal de conjuntos de datos grandes y delimitados que no necesitan ser procesados en tiempo real. Las canalizaciones por lotes se usan, por lo general, para crear informes o se combinan con fuentes de tiempo real con el fin de obtener todos los beneficios: datos históricos confiables que incluyen la última información obtenida mediante la canalización de transmisión en tiempo real.

Procesamiento por lotes de eventos y registros de servidores de juego

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

Cloud Storage es el lugar recomendado para almacenar archivos grandes. Posee durabilidad, alta disponibilidad y servicio de almacenamiento de objetos rentable. Pero quizás te haces la siguiente pregunta: ¿cómo cargo mis datos a Cloud Storage en primer lugar? La respuesta a tu pregunta depende de tus fuentes de datos y es el tema de las próximas secciones. Obtendrás información sobre tres situaciones de fuentes de datos: local, otros proveedores de servicios en la nube y GCP.

Situación 1: transfiere archivos desde servidores locales

Puedes transferir archivos de registro de forma segura desde tu centro de datos local a través de varios métodos. La forma más común es con la utilidad de línea de comandos de código abierto gsutil para establecer transferencias de archivos recurrentes. El comando gsutil ofrece muchas características útiles, como cargas paralelas de varios hilos cuando tienes varios archivos, sincronización automática de un directorio local, cargas reanudables para archivos grandes, y, para archivos todavía más grandes, puedes dividir el archivo en partes más pequeñas y subirlas en paralelo. Estas características acortan el tiempo de carga y usan tu conexión de red tanto como es posible.

Si no tienes suficiente ancho de banda de Internet para completar las cargas, puedes conectarte de forma directa a GCP con el intercambio de tráfico directo o el intercambio de tráfico por proveedores. De forma alternativa, si prefieres enviar medios físicos, hay un servicio de terceros llamado Offline Media Import / Export que recibirá tus medios y los subirá por ti.

Situación 2: transfiere archivos desde otros proveedores de servicios en la nube

Algunos archivos de registro pueden estar almacenados con otros proveedores de servicios en la nube. Quizás ejecutas un servidor de juego allí y almacenas los registros en un servicio de almacenamiento de ese proveedor, o usas un servicio que tiene un objetivo de almacenamiento predeterminado. Amazon Cloudfront (un servicio de red de entrega de contenido), por ejemplo, almacena sus registros en un depósito de Amazon S3. Por suerte, transferir datos de Amazon S3 a Cloud Storage es simple.

Si transfieres una gran cantidad de datos a diario desde Amazon S3 a Cloud Storage, puedes usar el Servicio de transferencia de almacenamiento para transferir datos desde fuentes, incluidos Amazon S3 y servicios HTTP y HTTPS. Puedes establecer transferencias recurrentes con regularidad. Además, el Servicio de transferencia de almacenamiento brinda muchas opciones avanzadas. Este servicio aprovecha el gran ancho de banda de red entre los principales proveedores de servicios en la nube y usa técnicas de optimización de ancho de banda avanzadas para lograr velocidades de transferencia muy altas.

Se recomienda usar este servicio para transferencias desde 1 TB a 10 TB o más, ya que podría evitarte la sobrecarga operativa de ejecutar la herramienta gsutil mencionada en la Situación 1 en múltiples servidores. Para transferencias más pequeñas, o en las que necesitas transferir datos múltiples veces por día, quizás te resulte útil usar la herramienta gsutil mencionada en la Situación 1.

Situación 3: los datos ya están en GCP

En algunos casos, los datos que quieres se almacenan de forma automática en Cloud Storage de forma predeterminada. Por ejemplo, los datos de Google Play Store, incluidos informes financieros, reseñas, instalaciones, informes de aplicación no responde (ANR) y fallas están disponibles en un depósito de Cloud Storage en tu cuenta de desarrollador de Google Play. En estos casos, puedes conservar los datos en el depósito original al que se exportaron, a no ser que tengas motivos para moverlos a otro depósito.

Patrón de servicio de transferencia asíncrona

Un enfoque a largo plazo y escalable es implementar un patrón de servicio de transferencia asíncrona en el que usas una o más colas y mensajes para iniciar las 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 fuente, se envía un mensaje a la cola y a los trabajadores, luego se inicia el trabajo de transferir con éxito ese objeto a Cloud Storage y, solo cuando el trabajo se completa con éxito, se quita el mensaje de la cola.

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

Quizás te preguntes si es necesario usar Cloud Dataflow entre Cloud Storage y BigQuery. Puedes cargar los archivos de forma directa desde archivos JSON en Cloud Storage si proporcionas un esquema y comienzas un trabajo de carga. También puedes consultar de forma directa los archivos de copia de seguridad de CSV, JSON o Cloud Datastore en un depósito de Cloud Storage. Esta puede ser una solución aceptable para empezar, pero ten en cuenta los beneficios de usar Cloud Dataflow:

  • Transforma los datos antes de comprometerte con el almacenamiento. Por ejemplo, puedes agregar datos antes de cargarlos a BigQuery y agrupar diferentes tipos de datos en tablas separadas. Esto puede ayudarte a reducir tus costos de BigQuery mediante la minimización del número de filas que consultas. En una situación en tiempo real, puedes usar Cloud Dataflow para procesar tablas de clasificación dentro de sesiones individuales o cohortes como alianzas y equipos.

  • Usa canalizaciones de datos por lotes y de transmisión escritos en Cloud Dataflow de forma intercambiable. Cambia la fuente y el receptor de datos, por ejemplo, de Cloud Pub/Sub a Cloud Storage y el mismo código funcionará en ambas situaciones.

  • Sé más flexible en términos de esquemas de bases de datos. Por ejemplo, si agregaste campos adicionales a tus eventos con el tiempo, quizás desees agregar datos JSON sin procesar adicionales para un campo genérico en el esquema y usar la función de consulta JSON de BigQuery con el fin de consultar dentro del campo. Luego puedes consultar múltiples tablas de BigQuery a pesar de que el evento fuente requeriría diferentes esquemas. Esto se muestra en la Figura 6.

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

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

Consideraciones operacionales para las arquitecturas de referencia

Una vez que estableciste y creaste tus canalizaciones, es importante supervisar el rendimiento y cualquier excepción que pueda ocurrir. La interfaz de usuario de Cloud Dataflow Monitoring proporciona una vista gráfica de tus trabajos de canalización de datos y métricas clave. Puedes ver una captura de pantalla de muestra en la Figura 7.

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 en el grafo de ejecución de la canalización y estadísticas del rendimiento actual, como el número de mensajes que se procesan en cada paso, el retraso estimado del sistema y la marca de agua de datos. Para obtener información más detallada, Cloud Dataflow es compatible con el servicio de Stackdriver Logging. Puedes ver una captura de pantalla de ejemplo en la Figura 8.

Stackdriver Logging está integrado con Cloud Dataflow

Figura 8: Stackdriver Logging es compatible con Cloud Dataflow

Lecturas y recursos adicionales

¿Te sirvió esta página? Envíanos tu opinión:

Enviar comentarios sobre…