ID de la causa in-autoscale · Responsable principal Infraestructura de servidores (Equipo de infraestructura) · También Desarrollo de servidor (Equipo de desarrollo)
Cuando se junta mucha gente, se añaden servidores automáticamente, pero prepararlos lleva unos minutos y mientras tanto los servidores existentes van sobrecargados.
Por qué Empieza un evento y las conexiones se disparan → Efecto Un servidor nuevo tarda varios minutos en arrancar y estar listo → En pantalla Cámara lenta y el juego no conecta durante los primeros minutos del evento
Cuando se junta mucha gente, Al conectar o tras un mantenimiento
Responsable
Responsable principal Infraestructura de servidores (Equipo de infraestructura) · También Desarrollo de servidor (Equipo de desarrollo)
Tareas (Equipo de desarrollo)
Repartir a los jugadores entre canales (los que ya están en un canal lleno no se pueden mover a un servidor nuevo), reducir el tiempo de arranque y de carga de datos de los servidores nuevos.
Tareas (Equipo de infraestructura)
Escalar por adelantado antes de los eventos, tener servidores de reserva ya calentados, y al reducir apagar cada servidor solo cuando hayan salido los jugadores que quedan.
Cifras de referencia
Detectar la carga lleva de 1 a unos pocos minutos (porque las métricas se miran como promedio de varios minutos), y arrancar el servidor nuevo, leer los datos del juego y llenar la caché lleva otros varios minutos.
En el gráfico
Avalancha tras la apertura · Número de instancias, uso de CPU, conexiones en espera
Dónde mirar
Superponer el registro de actividad del autoescalado (hora en que se decidió escalar y hora en que la instancia nueva entró en servicio) sobre los gráficos de uso de CPU y conexiones. En AWS, las métricas del grupo de Auto Scaling (solo se ven si se activan) GroupDesiredCapacity (número objetivo), GroupPendingInstances (en preparación) y GroupInServiceInstances (en servicio)
Se confirma si
Tras el pico de conexiones, durante unos minutos solo suben el número objetivo y las instancias en preparación mientras la CPU de los servidores existentes está pegada al límite, y todo se alivia en cuanto aumentan las instancias en servicio
Se descarta si
Si sigue lento después de entrar las instancias nuevas, la causa está fuera del número de servidores (un recurso compartido como la BD, “Fallo en cascada”)
Se verifica con
Con herramientas de infraestructura (no hace falta código del juego)
Para saber más
El autoescalado se usa sobre todo donde basta con recibir a los jugadores nuevos en servidores nuevos, como el login, los gateways o las mazmorras. Reducir también trae problemas: si de madrugada, cuando ya queda poca gente, se apagan servidores sin esperar a que salgan los jugadores que quedan, esos jugadores se desconectan.
Target tracking scaling policies for Amazon EC2 Auto ScalingAWS Las métricas básicas de EC2 van cada 5 minutos (cada minuto con el monitoreo detallado), así que para reaccionar rápido se recomiendan métricas con intervalos de 1 minuto o menos
Amazon CloudWatch metrics for Amazon EC2 Auto ScalingAWS Las métricas de grupo se publican cada minuto solo si se activan: GroupDesiredCapacity (número de instancias que se quiere mantener), GroupPendingInstances (instancias que aún no están en servicio) y GroupInServiceInstances (instancias en servicio)