Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

GAMEOPS03-BP04 Adopta una estrategia de despliegue que minimice el impacto en los jugadores

Incorpore una estrategia de despliegue para el software y la infraestructura del juego que minimice el tiempo de inactividad que impide a los jugadores participar en el juego. Si bien algunos tipos de actualizaciones pueden requerir la instalación de nuevas actualizaciones en el cliente del juego, diseña el juego de forma que se minimice o evite la necesidad de que se produzcan tiempos de inactividad durante las implementaciones.

Nivel de riesgo expuesto si no se establece esta práctica recomendada: alto

Guía para la implementación

Uno de los pasos más importantes a tener en cuenta a la hora de desarrollar una estrategia de despliegue de juegos es determinar cómo se gestionará la infraestructura del juego. Gestiona la infraestructura de tu juego con una herramienta de infraestructura como código (IaC), como AWS CloudFormationTerraform, de Hashicorp, para reducir los errores humanos durante la preparación del entorno. Las plantillas de infraestructura se pueden implementar y probar en procesos automatizados, lo que crea coherencia en la configuración de los diferentes entornos de juego.

Existen varias estrategias de despliegue que se pueden utilizar en un juego:

Sustitución continua

El objetivo principal de una sustitución continua por el despliegue es realizar la versión sin cerrar el juego y sin afectar a los jugadores. Es importante que la actualización o los cambios que se vayan a realizar sean compatibles con versiones anteriores y funcionen de forma similar a las versiones anteriores del sistema.

En esta implementación, las instancias del servidor se sustituyen (sustituyen o implementan) de forma incremental por instancias que ejecutan la versión actualizada. Esta sustitución sucesiva se puede realizar de diferentes maneras. Por ejemplo, para implementar actualizaciones continuas en una flota de servidores de juegos dedicados, un enfoque típico consiste en crear un nuevo grupo de EC2 instancias de Auto Scaling que contenga la nueva versión de compilación del servidor de juegos implementada en ellos y, luego, dirigir gradualmente a los jugadores a las sesiones de juego alojadas en esta nueva flota de servidores. Si hay una actualización del cliente de juego asociada que es necesaria como requisito previo para usar la nueva versión del servidor de juegos, debes incluir una comprobación de validación para comprobar que solo los jugadores que tengan instalada esta nueva actualización del cliente de juego puedan acceder a estas sesiones de juego.

Las flotas de servidores (por ejemplo, los grupos de EC2 Auto Scaling) que contienen la versión anterior de compilación del servidor de juegos solo se eliminan del servicio una vez agotadas las sesiones activas de los jugadores de forma adecuada, normalmente mediante la configuración de métricas de servidor individualizadas que permiten a los equipos de operaciones del juego automatizar este proceso. Como alternativa, para reducir la cantidad de infraestructura y el tiempo necesarios para realizar un despliegue continuo, se puede aplicar un enfoque alternativo en el que las instancias de producción existentes se retiran del servicio, se actualizan con la nueva versión del servidor de juegos y, a continuación, se vuelven a colocar en la flota de producción. Este enfoque reduce la cantidad de infraestructura necesaria, pero también aumenta el riesgo, ya que la cantidad de servidores de juegos en vivo disponibles para los jugadores se reduce a medida que se van sustituyendo los servidores.

Este modelo también se puede utilizar para realizar despliegues sucesivos en servicios de backend, como bases de datos, cachés y servidores de aplicaciones, que no alojan juegos. Siempre y cuando estos servicios se desplieguen de una manera altamente disponible con varias instancias agrupadas en clústeres, la complejidad de las implementaciones de estos servicios debería ser menor que la de las implementaciones en servidores de juegos dedicados.

Despliegue azul/verde

El objetivo principal de una blue/green implementación en un juego es minimizar el tiempo de inactividad y, al mismo tiempo, permitir una reversión segura a la implementación anterior si se detectan problemas. Es adecuado para despliegues en los que dos versiones del backend del juego sean compatibles y puedan servir a los jugadores simultáneamente.

En la estrategia de blue/green despliegue, se configuran dos entornos idénticos (azul y verde). La versión del juego existente está marcada en azul, mientras que la nueva versión del juego, que es el objetivo del despliegue, está etiquetada en verde. Cuando el entorno verde esté listo para la migración, puede configurar su capa de enrutamiento para transferir el tráfico al entorno verde y, al mismo tiempo, mantener el entorno anterior (azul) disponible en caso de que sea necesaria una conmutación por recuperación. En este escenario, las actualizaciones de enrutamiento pueden requerir la actualización del servicio de emparejamiento para configurarlo de modo que comience a enviar sesiones de juego a la nueva flota o, en el caso de los servicios de backend de juegos, esto podría consistir en actualizar los registros de DNS en Amazon Route 53 para tu servicio o cambiar la ponderación del balanceador de carga de aplicaciones para enviar tráfico a tu nuevo grupo objetivo.

Uno de los inconvenientes de la estrategia de blue/green implementación es el coste inherente del entorno de espera, debido a la infraestructura adicional que se requiere al realizar la implementación. Una opción para mitigar este costo adicional de infraestructura es considerar la posibilidad de adoptar una variante de blue/green implementación en la que el nuevo software de juegos se implemente en los mismos servidores que ya están implementados en la fase de producción. En este escenario, se puede iniciar un nuevo proceso de servidor ecológico con el nuevo software junto con el proceso de servidor azul existente, con la transición entre los procesos de servidor y no entre infraestructuras físicas independientes. Este enfoque también puede acelerar las implementaciones de juegos en una gran cantidad de infraestructura, ya que elimina la necesidad de esperar a que se lancen nuevos servidores en la nube. Para conocer las mejores prácticas sobre este enfoque de despliegue, consulte Implementaciones azules/verdes en. AWS

Implementación de Canary

La implementación de Canary es útil para los desarrolladores de juegos, ya que la estrategia se puede aplicar para lanzar una versión temprana de un juego en fase alfa o beta, o una función del juego, como un nuevo modo de juego, mapa o desafío, para un grupo reducido o reducido de jugadores en fase de producción. Este despliegue se denomina canario. Es posible que esta versión incluya funciones adicionales de seguimiento e informes, por lo que cuando jugadores reales juegan a ese juego o función, se recopila la telemetría de su jugabilidad y se analiza para detectar anomalías y problemas.

En el caso de las nuevas funciones, los jugadores no reciben notificaciones sistemáticas al respecto, y la telemetría del juego es la fuente principal que se utiliza para determinar si los jugadores tienen problemas, por lo que la versión debería retrasarse. Al mismo tiempo, si no se detecta ningún problema importante, la función podrá ampliarse a más jugadores para obtener información adicional. Si se notifica a los jugadores, se les puede pedir que envíen comentarios periódicos sobre su experiencia. Lo ideal sería que esta actividad de prueba fuera coordinada por un equipo de operaciones en vivo.

Como estrategia, el uso de Canary Deployment también se puede utilizar en versiones estándar para que los jugadores dispongan gradualmente de una nueva función. Una ventaja potencial con respecto al blue/green entorno estándar es que no se requiere un segundo entorno a gran escala. La capacidad del nuevo entorno reducido determina el número de jugadores que se incorporarán a la nueva función. Antes de añadir más jugadores, la capacidad debe escalarse adecuadamente. Si bien se espera que esta blue/green técnica personalizada cueste comparativamente menos que la técnica azul/verde estándar, se estima que tendrá un costo que puede ser superior al de la técnica de sustitución rodante, que se utiliza para los despliegues canarios.

Ejecute solo un canario en un entorno de producción y concéntrelo en sus datos y comentarios. Si se implementan varios canarios, se complica la solución de problemas y se aíslan los problemas de producción, y se perjudica la calidad de los conjuntos de datos y los comentarios que se recopilan.

Una variante del método canario es cuando uno o más experimentos (normalmente pruebas de interfaz de usuario) se realizan mediante despliegues específicos, en los que un conjunto de servidores back-end del juego sirve para una versión de una función y otro conjunto del mismo tamaño sirve para otra versión de la misma función. No se crea ninguna infraestructura adicional o especial para ello, y solo los grupos de servidores back-end elegidos reciben estas actualizaciones. El resultado de los experimentos consiste en observar cómo reaccionan los jugadores ante cada una de las versiones de la misma función, determinar si existe un consenso general sobre si les gusta o no les gusta y observar si hay problemas relacionados con su usabilidad o funcionalidad. Estos experimentos estratégicos también se denominan A/B pruebas, y el proceso general se denomina pruebas A/B. Al finalizar estos experimentos, se recopilan los datos de prueba necesarios antes de volver a la versión actual del sistema de backend del juego en los servidores utilizados para las pruebas.

Implementaciones tradicionales heredadas

En el estilo de despliegue tradicional, durante un período de mantenimiento programado, el juego se cierra y los jugadores conectados se eliminan o se agotan antes de que las instancias del servidor del backend del juego se actualicen con las versiones de código más recientes. Esta implementación afecta a los jugadores cada vez que se lleva a cabo, y hay que avisarlos antes de lo previsto. Como resultado, este modelo es el que más impacto tiene en los jugadores y debe evitarse siempre que sea posible.

Una vez implementada la actualización del juego, se puede hacer una prueba de humo antes de que los jugadores puedan acceder a él, quienes estarán esperando a que se vuelva a abrir el juego. Esto puede provocar un aumento de tráfico cuando los jugadores intenten iniciar sesión y jugar en poco tiempo. Por lo tanto, si el juego no está diseñado para soportar esos picos de tráfico, puedes optar por permitir que los jugadores regresen gradualmente al juego por lotes.

También puedes optar por aprovisionar en exceso la infraestructura para soportar el pico de tráfico inicial y, una vez que el tráfico del juego se estabilice, podrás reducir los recursos. Si es necesario, realiza este tipo de despliegue durante las horas de menor actividad, cuando el número de jugadores es más bajo. El mantenimiento programado con frecuencia, así como el mantenimiento prolongado, conllevan un riesgo inherente de pérdida de jugadores y una posible pérdida de ingresos. Los jugadores también esperan cambios tras una nueva versión y pueden perder la confianza en el juego una vez que regresen tras un periodo de inactividad.

Pasos para la implementación