Esta publicación es la primera parte de una serie de dos sobre el modo en que las organizaciones usan Azure Cosmos DB para satisfacer las necesidades del mundo real y la diferencia que marca para ellas. En la parte 1, se exploran los desafíos que han llevado a los desarrolladores de servicios de Minecraft Earth a elegir Azure Cosmos DB y cómo lo usan para capturar prácticamente cada acción de todos los jugadores del mundo, con una latencia muy baja. En la parte 2, se examina la carga de trabajo de la solución y cómo los desarrolladores de servicios de Minecraft Earth se han beneficiado de su compilación en Azure Cosmos DB.

Llevar el mundo de Minecraft a la vida real

Probablemente habrá oído hablar del juego Minecraft, aunque no haya jugado. Se trata del videojuego más vendido de todos los tiempos, con más de 176 millones de copias vendidas desde 2011. Actualmente, Minecraft cuenta con más de 112 millones de jugadores al mes, que pueden descubrir y recopilar materiales y herramientas de construcción para construir estructuras o terraplenes en el mundo tridimensional generado de forma inmersiva y por procedimientos del juego. En función del modo de juego, los jugadores también pueden competir con rivales controlados por el equipo y cooperar con otros jugadores o competir con ellos.

En mayo de 2019, Microsoft anunció la próxima versión de Minecraft Earth, cuyo lanzamiento mundial se realizó en diciembre de 2019. A diferencia de los juegos anteriores de la franquicia de Minecraft, Minecraft Earth eleva todo a un nivel completamente nuevo, ya que permite a los jugadores experimentar el mundo de Minecraft en nuestra vida real gracias al potencial de la realidad aumentada (AR).

Para los jugadores de Minecraft Earth, la experiencia resulta inmediatamente familiar, si bien se integra profundamente en el mundo que les rodea. Sin embargo, para los desarrolladores del equipo de Microsoft dedicado a Minecraft, la entrega de Minecraft Earth, en particular los servicios back-end autoritativos necesarios para respaldar el juego, requeriría crear algo completamente nuevo.

Nathan Sosnovske, ingeniero de software sénior del equipo de desarrollo de servicios de Minecraft Earth, explica:

"Con Vanilla Minecraft , aunque se podía hospedar un servidor propio, no había ninguna entidad de servicio centralizada. Minecraft Earth se basa en un servicio centralizado y autoritativo, el primer servicio "pesado" que creamos en primicia para la franquicia de Minecraft".

En este caso práctico, veremos algunos de los desafíos que los desarrolladores de servicios de Minecraft Earth abordaron para ofrecer lo que se necesitaba y cómo usaron Azure Cosmos DB para satisfacer dichas necesidades.

El desafío técnico: Evitar retardos en el juego

En el cliente de Minecraft Earth, que se ejecuta en dispositivos compatibles con AR basados en iOS y Android, casi todas las acciones que realiza un jugador generan una escritura en el servicio principal de Minecraft Earth. Cada escritura es una solicitud POST de REST que debe aceptarse y confirmarse inmediatamente para evitar cualquier retardo notorio en el juego.

"Desde la perspectiva de los servicios, Minecraft Earth requiere escrituras de baja latencia y lecturas de latencia media", explica Sosnovske. "Las escrituras deben ser rápidas porque el cliente requiere confirmación en cada una, como podría ser necesario para que el cliente realice la representación (por ejemplo, cuando un jugador hace clic en un recurso para ver lo que hay en él); no queremos que los objetos visuales se bloqueen mientras se procesa la solicitud de REST correspondiente. Las lecturas de latencia media son aceptables porque podemos usar la simulación del lado cliente hasta que el modelo de respaldo detrás del servicio pueda actualizarse para la lectura".

Para complicar el desafío, los desarrolladores de servicios de Minecraft Earth necesitaban garantizar escrituras de baja latencia independientemente de la ubicación de un jugador. Esto requiere que se ejecuten copias del servicio en varias ubicaciones dentro de cada geografía donde se ofrezca Minecraft Earth, junto con inteligencia integrada para enrutar el cliente de Minecraft Earth a la ubicación más cercana en la que se implementa el servicio.

"La latencia de red típica entre las costas este y oeste de EE. UU. es de 70 a 80  milisegundos", indica Sosnovske. "Si un jugador de Nueva York tuviera que confiar en un servicio que se ejecuta en San Francisco, o viceversa, el retardo en el juego sería inaceptable. Al mismo tiempo, el juego se denomina Minecraft Earth, lo que significa que necesitamos permitir que los jugadores de San Francisco y Nueva York compartan la misma experiencia en el juego. Para ofrecer todo esto, es necesario replicar el servicio y sus datos en varios centros de datos distribuidos geográficamente en cada geografía".

La solución: Patrón de aprovisionamiento de eventos basado en Azure Cosmos DB

Para satisfacer sus requisitos técnicos, los desarrolladores de servicios de Minecraft Earth implementaron un patrón de aprovisionamiento de eventos basado en Azure Cosmos DB.

"En principio, pensamos en usar el almacenamiento de tablas de Azure para almacenar nuestro registro de eventos de solo anexar, pero no resultaba factible por carecer de un SLA para las latencias de lectura y escritura", comenta Sosnovske. "En última instancia, elegimos Azure Cosmos DB porque proporciona un SLA de 10 milisegundos para lecturas y escrituras, junto con la distribución global y las funcionalidades de arquitectura multimaestro necesarias para replicar el servicio en varias ubicaciones dentro de cada geografía".

Con un patrón de aprovisionamiento de eventos, en lugar de simplemente almacenar el estado actual de los datos, el servicio de Minecraft Earth usa un almacén de datos de solo anexar basado en Azure Cosmos DB para registrar la serie completa de acciones realizadas en los datos (en este caso, la asignación a cada acción del juego realizada por el jugador). Una vez que se devuelve al cliente una confirmación inmediata de una escritura correcta, las colas que se suscriben al almacén de eventos de solo anexar controlan el posprocesamiento y aplican asincrónicamente los eventos recopilados a un estado de dominio que se mantiene en Azure Blob Storage. Para optimizar aún más las cosas, los desarrolladores de Minecraft Earth combinaban el patrón de aprovisionamiento de eventos con el diseño controlado por dominios, en el que cada dominio de aplicación (como elementos de inventario, perfiles de personajes o logros) tiene su propia secuencia de eventos.

"Modelamos nuestros datos como secuencias de eventos que se almacenan en un registro de solo anexar y mutan un estado del modelo en memoria, que se usa para controlar varias vistas de clientes", indica Sosnovske. "El estado almacenado en caché se mantiene en Azure Blob Storage, que es lo suficientemente rápido para lecturas y ayuda a reducir al mínimo los costos de la unidad de solicitud para Azure Cosmos DB. En muchos sentidos, lo que hemos hecho con Azure Cosmos DB es como crear una memoria caché de escritura realmente resistente".

En el diagrama siguiente se muestra cómo funciona el patrón de aprovisionamiento de eventos basado en Azure Cosmos DB:

Implementación de Azure Cosmos DB

Para poder usar Azure Cosmos DB, los desarrolladores tenían que tomar algunas decisiones de diseño:

API de Azure Cosmos DB. Los desarrolladores optaron por usar la API Core (SQL) de Azure Cosmos DB porque ofrecía el mejor rendimiento y la mayor facilidad de uso, junto con otras funcionalidades necesarias.

"Estábamos creando un sistema desde cero, por lo que no necesitábamos una capa de compatibilidad que nos ayudara a migrar el código existente", explica Sosnovske. "Además, algunas características de Azure Cosmos DB de las que dependemos, como TransactionalBatch, solo son compatibles con la API Core (SQL). Como ventaja adicional, la API Core (SQL) era realmente intuitiva, ya que nuestro equipo ya estaba familiarizado con SQL en general".

Lea Introducción a TransactionalBatch en el SDK de .NET para obtener más información.

Clave de partición. En última instancia, los desarrolladores decidieron crear particiones lógicas de los datos dentro de Azure Cosmos DB en función de los usuarios.

"En principio, realizamos particiones de los datos por usuarios y dominios, como por ejemplo los logros o elementos de inventario, pero descubrimos que este desglose era demasiado granular y nos impedía aprovechar el máximo potencial de las transacciones de bases de datos en Azure Cosmos DB", indica Sosnovske.

Nivel de coherencia. De los cinco niveles de coherencia admitidos por Azure Cosmos DB, los desarrolladores eligieron la coherencia de la sesión, que combinaron con comprobaciones de ETag precisas para garantizar la escritura correcta de los datos.

"Esto es muy útil debido a cómo almacenamos los datos, que se modelan como un registro de solo anexar con un documento principal que actúa como un puntero a la cola del registro", explica Sosnovske. "Escribir en la base de datos implica leer el documento principal y su ETag, derivar el identificador de registro N+1 y, a continuación, construir una operación por lotes transaccional que sobrescriba el puntero principal mediante el ETag leído anteriormente y crea un nuevo documento para la entrada de registro. En el improbable caso de que el registro ya se haya escrito, la comprobación de ETag y el intento de crear un documento que ya existía generará un error en la transacción. Esto sucedió con independencia de si otra solicitud "se nos adelantó" a escribir o si nuestra solicitud lee un poco los datos desactualizados".

En la parte 2 de esta serie, se examina la carga de trabajo actual de la solución y cómo los desarrolladores de servicios de Minecraft Earth se han beneficiado de su compilación en Azure Cosmos DB.

Introducción a Azure Cosmos DB

• Visite Azure Cosmos DB.
• Más información sobre Azure para juegos