¿Será magia? Autoescalado con CrowdHandler
De vez en cuando, vemos comentarios de desarrolladores en las redes sociales preguntándose por qué alguien utilizaría una solución de sala de espera. Para ellos, instalar CrowdHandler sería admitir su derrota en lugar de una astuta adición a su conjunto de herramientas.
Al fin y al cabo, ¿para qué necesitas una solución de sala de espera si puedes utilizar una nube mágica de escala infinita?
He aquí un ejemplo:
"Decente estrategia de equilibrio de carga con expansión ilimitada vs cliente molesto sala de espera hmm difícil elección"
¿Expansión ilimitada? No existe
Por alguna razón, muchos desarrolladores parecen asumir que sus soluciones en la nube -como los grupos EC2 de autoescalado, AWS Lambda o los equivalentes de Azure o Google- son capaces de escalar infinitamente.
Tal vez crean que están hechos de magia.
Lo cierto es que las soluciones en la nube sólo pueden escalar dentro de ciertos parámetros e, independientemente de cuántos servidores pueda añadir por arte de magia, acabará por toparse con los límites.
Sus parámetros incluirán los que usted mismo habrá tenido que establecer y pagar, es decir, los parámetros dentro de los cuales esa nube le permite operar en función de su rango de precios. Pero probablemente también habrá un límite último basado en la tecnología de su base de datos. (Al fin y al cabo, ninguna capa de almacenamiento ACID puede escalar infinitamente, porque, por su propia naturaleza, ninguna transacción ACID puede ser infinita).
Por eso, cuando veo un comentario como el anterior, sé que la persona no ha escalado mucho en la naturaleza.
Porque, una vez que hayas trabajado con una aplicación que intente escalar a niveles enormes de tráfico en un espacio de tiempo muy corto, darás con esos parámetros y comprenderás que no existe la "expansión ilimitada".
El escalado automático funciona... hasta que deja de funcionar.
Claro, usted tiene una aplicación escalable realmente agradable que puede auto-escala en el transcurso de un día, o tal vez más de un mes. Puedes adaptarla a los distintos niveles de tráfico sin problemas, incluso durante las temporadas altas. Tu arquitectura de auto-escalado notará que estás un poco más ocupado y automáticamente añadirá servidores para lidiar con ello... luego notará cuando las cosas se calmen, y los sacará del bucle. Funciona bien.
Todo esto está muy bien, el 99% de las veces. Pero los patrones de tráfico que requerirían que tu arquitectura de autoescalado fuera infinitamente escalable no son así en absoluto. Estamos hablando del escenario en el que tu aplicación de repente está diez veces más ocupada, cien veces más ocupada - quizás incluso mil veces más ocupada . . en menos de un minuto.
De repente mil veces más ocupado
La venta de entradas es el ejemplo más obvio de este tipo de pico de tráfico repentino que observamos en CrowdHandler. Cuando se ponen a la venta entradas para la última gira de una megaestrella, por ejemplo, el sitio de un vendedor puede pasar de cero a un millón en punto de las 10 de la mañana.
Pero no se trata sólo de la venta de entradas de megaestrellas. Un pico de tráfico repentino puede ocurrirle a cualquiera. Cualquier tipo de venta con una dinámica de caída; la escasez repentina de una línea popular; una mención de su producto por un influenciador de los medios sociales (¡previsible o no!) Todo esto puede provocar una oleada de tráfico.
Lo que suele ocurrir en estos casos es que, sí, el autoescalador reconoce el aumento de tráfico -quizá nota que los tiempos de carga de las páginas se alargan, o que el uso de CPU en los servidores es mayor- y reacciona poniendo en marcha más servidores.
Sin embargo, este proceso no es instantáneo. Los contenedores tienen que arrancar y las cachés tienen que calentarse.
No deja de ser irónico: cuando se ponen en marcha los comportamientos de autoescalado, suele producirse una notable disminución del rendimiento. Esta calma, hasta que los sistemas se estabilizan de nuevo, dura hasta cinco minutos.
Si se ha creado una sala de espera, este es el momento en que entra en acción. Cuando el rendimiento se ralentiza hasta el punto de que los usuarios finales corren el riesgo de que la aplicación se bloquee, la sala de espera está ahí para mantener a raya a los usuarios durante esos minutos mientras todo se calienta de nuevo.
Triple 9 de tiempo de actividad
Por cierto: ¿qué dice su SLA sobre el tiempo de actividad general? Porque, a lo largo de un mes, esos cinco minutos que se tardó en volver a escalar apenas se registrarán, a pesar de que potencialmente pueden hacer mucho daño. Eche cuentas: 5/43920 significa que el tiempo de actividad sigue siendo del 99,99%. Pero esos cinco minutos son probablemente los más críticos de todo el mes en términos de experiencia de usuario y reputación.
¿Qué puede hacer para evitar problemas?
Mitigar la sobrecarga de tráfico - 1: Cuando es previsible
A menudo, usted sabe cuándo se va a producir un pico de tráfico. Puede que haga sus grandes rebajas los viernes por la mañana. Puede que esté planeando una venta de Black Friday. Así que nuestro consejo es: ¡no espere a que el tráfico se autoescala! Programe su nube mágica para escalar con antelación. (Esto es lo que hacen nuestros amigos de Made Media: saben que un montón de sus clientes van a salir de rebajas, saben que esto suele ocurrir los viernes por la mañana, así que su infraestructura está programada para escalar todos los viernes por la mañana).
Y ... lo has adivinado: instala CrowdHandler. Porque incluso si usted está muy bien versado en los parámetros de su escala, y muy seguro de que entiende el nivel de tráfico que va a recibir, todavía hay un enorme margen de error. Una sala de espera, sin embargo, resistirá casi cualquier cosa (y recuerde, no se activará si no es necesario).
También podemos decir con confianza que las sorpresas ocurren. A menudo, un cliente nos pregunta por qué se ha activado una sala de espera y nos dice que su panel CrowdHandler está informando del tráfico "incorrecto", o de "tráfico que no existe". Pero el tráfico está ahí, sólo que es inesperado. Más tarde, se enteran de que un influencer les ha avisado, lo que ha provocado una gran afluencia a su sitio web en un momento que no esperaban. En el mundo de la venta de entradas, cada vez más artistas se precipitan y comparten un enlace como parte de un anuncio de gira sin consultar el programa de relaciones públicas cuidadosamente preparado.
Mitigación de la sobrecarga de tráfico - 2: Cuando es imprevisible
Si no sabes cuándo se van a producir los picos de tráfico (¡o estás coordinando con influencers impredecibles!) entonces definitivamente deberías instalar CrowdHandler como un catch-all, funcionando todo el tiempo.
Mejor aún, úsalo con Autotune activado. En este escenario:
Aumento del tráfico
La cola se activa y el Autotune de CrowdHandler gestiona el ritmo
La nube de autoescalado responde al aumento de la carga y comienza a escalar, lo que ralentiza el rendimiento.
Autotune de CrowdHandler detecta la ralentización, retiene a algunos usuarios en la cola y les ofrece una experiencia de usuario positiva con los mensajes adecuados.
Los niveles de rendimiento vuelven a la normalidad y Autotune aumenta la velocidad para vaciar rápidamente la cola.
Unas palabras finales sobre la experiencia del usuario
Esto es curioso. Aunque tu nube mágica de autoescalado funcionara a la perfección y tu producto se agotara en menos de un segundo, tus usuarios no tendrían una experiencia óptima (y podrían compartir sus resentimientos). Esto se debe a que, cuando algo sucede muy rápidamente -por ejemplo, si aparentemente no pasa nada de tiempo entre que la transacción está disponible y se agota-, puede parecer muy injusto para el usuario final. Algunos clientes nos han dicho que el proceso de CrowdHandler y su mensajería asociada mantienen a los usuarios a raya, dándoles tiempo para respirar y manteniéndoles informados.
Así que, cuando empiece la sala de espera, confía en el proceso. Que no cunda el pánico (pero utilice los campos de mensaje con prudencia). Tus usuarios se sentirán mucho más cómodos esperando en la cola unos segundos o minutos que mirando un sitio colapsado o una página inmediata de "agotado".