De vez en cuando, vemos comentarios de desarrolladores en las redes sociales en los que se preguntan por qué alguien utilizaría una solución para salas de espera. Para ellos, instalar CrowdHandler sería una admisión de derrota, en lugar de una incorporación inteligente a su conjunto de herramientas.
Al fin y al cabo, ¿para qué necesitarías una solución para salas de espera si puedes limitarte a utilizar una nube mágica y con capacidad de ampliación infinita?
He aquí un ejemplo:
«Una estrategia de equilibrio de carga decente con expansión ilimitada frente a una sala de espera que resulta molesta para los clientes... Mmm, qué difícil elección».
¿Expansión ilimitada? Eso no existe.
Por alguna razón, muchos desarrolladores parecen dar por sentado que sus soluciones en la nube —como los grupos de EC2 con escalado automático, AWS Lambda o sus equivalentes en Azure o Google— son capaces de escalar de forma ilimitada.
Quizás crean que están hechos de magia.
La verdad es que las soluciones en la nube solo pueden escalar dentro de ciertos parámetros y, por muchos servidores que puedas añadir como por arte de magia, al final llegarás a unos límites.
Tus parámetros incluirán aquellos que hayas tenido que configurar y pagar por tu cuenta; en otras palabras, los parámetros dentro de los cuales esa nube te permite operar en función de tu presupuesto. Pero probablemente también habrá un límite máximo determinado por la tecnología de tu base de datos. (Al fin y al cabo, ninguna capa de almacenamiento ACID puede escalar infinitamente, ya que, por su propia naturaleza, ninguna transacción ACID puede ser infinita.)
Por eso, cuando veo un comentario como el anterior, sé que esa persona no tiene mucha experiencia real en el escalado en condiciones reales.
Porque, una vez que hayas trabajado con una aplicación que intente adaptarse a niveles enormes de tráfico en un plazo muy breve, llegarás a esos límites y comprenderás que no existe tal cosa como la «expansión ilimitada».
El escalado automático funciona... hasta que deja de hacerlo
Claro, tienes una aplicación escalable realmente buena que puede escalar automáticamente a lo largo del día, o quizá a lo largo de un mes. Puedes ajustarla para adaptarse a los distintos niveles de tráfico sin ningún problema, incluso durante las épocas de mayor actividad. Tu arquitectura de escalado automático detectará que hay un poco más de actividad y añadirá servidores automáticamente para hacer frente a la demanda... y luego, cuando la actividad disminuya, los retirará del sistema. Funciona bien.
Todo esto está muy bien, el 99 % de las veces. Pero los patrones de tráfico que exigirían que tu arquitectura de autoescalado fuera infinitamente escalable no se parecen en nada a esto. Nos referimos a aquel escenario en el que tu aplicación se ve sometida de repente a una carga diez veces mayor, cien veces mayor… quizá incluso mil veces mayor… en menos de un minuto.
De repente, mil veces más ocupado
La puesta a la venta de entradas es el ejemplo más evidente de este tipo de picos repentinos de tráfico que observamos aquí en CrowdHandler. Cuando salen a la venta las entradas para la gira de la última megaestrella, por ejemplo, el sitio web de un vendedor puede pasar de cero a un millón justo a las 10 de la mañana en punto.
Pero no se trata solo de la venta de entradas para megaestrellas. A cualquiera le puede ocurrir un pico repentino de tráfico. Cualquier tipo de oferta con una dinámica de agotamiento; la escasez repentina de una línea popular; una mención de tu producto por parte de un influencer en redes sociales (¡ya sea previsible o no!). Todo ello puede provocar un aumento repentino del tráfico.
Lo que suele ocurrir en estos casos es que, efectivamente, el sistema de escalado automático detecta el aumento del tráfico —quizás observa que los tiempos de carga de las páginas se alargan o que el uso de la 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 iniciarse y las cachés tienen que calentarse.
En realidad, resulta irónico: cuando se activan los mecanismos de autoescalado, solemos observar una notable disminución del rendimiento. Este parón, hasta que los sistemas vuelven a estabilizarse, dura hasta cinco minutos.
Si se ha configurado una «sala de espera», es en este momento cuando entra en funcionamiento. Cuando el rendimiento se ralentiza hasta el punto de que, de no ser así, los usuarios finales correrían el riesgo de que la aplicación se colgara, la «sala de espera» se encarga de mantener a los usuarios a la espera durante esos pocos minutos mientras todo vuelve a ponerse en marcha.
Tiempo de actividad de Triple 9
Por cierto: ¿qué dice tu SLA sobre el tiempo de actividad total? Porque, a lo largo de un mes, esos cinco minutos que se tardó en recuperar la escalabilidad apenas se notarán, a pesar de que podrían causar un gran perjuicio. Haz las cuentas: ¡5/43 920 significa que sigues teniendo un tiempo de actividad del 99,99 %! Pero esos cinco minutos son probablemente los más críticos de todo el mes en cuanto a la experiencia del usuario y la reputación.
Entonces, ¿qué puedes hacer para evitar problemas?
Cómo mitigar la sobrecarga de tráfico - 1: Cuando es predecible
A menudo, sabes cuándo va a producirse un pico de tráfico. Quizás programes tus rebajas de productos de alto precio para los viernes por la mañana. Quizá estés planeando una oferta para el Black Friday. Así que nuestro consejo es: ¡no esperes a que el tráfico active el autoescalado! Programa tu «nube mágica» para que aumente su capacidad con antelación. (Esto es lo que hacen nuestros amigos de Made Media: saben que muchos de sus clientes van a lanzar ofertas, saben que esto suele ocurrir los viernes por la mañana, así que su infraestructura está programada para aumentar su capacidad cada viernes por la mañana).
Y… lo has adivinado: instala CrowdHandler. Porque, aunque conozcas a la perfección los parámetros de tu escalabilidad y estés totalmente seguro de que entiendes el nivel de tráfico que vas a recibir, sigue habiendo un margen de error enorme. Una sala de espera, sin embargo, aguantará casi cualquier cosa (y recuerda que, en realidad, no se activará si no es necesario).
También podemos afirmar con seguridad que a veces surgen sorpresas. A menudo, un cliente nos pregunta por qué se ha activado la sala de espera y nos comenta que su panel de control de CrowdHandler muestra un tráfico «erróneo» o «tráfico que no existe». Pero el tráfico sí que existe; simplemente es inesperado. Más tarde, descubren que un influencer les ha mencionado, lo que ha provocado que su página web reciba un gran número de visitas en un momento en el que no se lo esperaban. En el mundo de la venta de entradas, vemos cada vez más a artistas que se adelantan y comparten un enlace como parte del anuncio de una gira sin consultar el calendario de relaciones públicas cuidadosamente preparado.
Cómo mitigar la sobrecarga de tráfico - 2: Cuando es impredecible
Si no sabes cuándo se van a producir los picos de tráfico (¡o si estás coordinándote con influencers impredecibles!), entonces sin duda deberías instalar CrowdHandler como solución universal, para que esté siempre en funcionamiento.
Mejor aún, utilízalo con la función «Autotune» activada. En este caso:
- Aumento del tráfico
- La cola se activa y la función «Autotune» de CrowdHandler gestiona la frecuencia.
- La nube con escalado automático responde al aumento de la carga y comienza a escalar, lo que ralentiza el rendimiento
- La función Autotune de CrowdHandler detecta la ralentización, retiene a algunos usuarios en la cola y les ofrece una experiencia de usuario positiva con mensajes adecuados.
- Los niveles de rendimiento vuelven a la normalidad y Autotune aumenta la velocidad para vaciar rápidamente la cola.
Unas últimas palabras sobre la experiencia del usuario
He aquí algo curioso. Aunque tu nube con escalado automático «mágico» funcionara a la perfección y tu producto se agotara en menos de un segundo, tus usuarios tendrían una experiencia que distaría mucho de ser óptima (y es posible que expresaran su descontento). Esto se debe a que, cuando algo ocurre muy rápidamente —por ejemplo, si parece que no hay tiempo alguno entre el momento en que la transacción está disponible y el momento en que se agota—, puede resultar muy injusto para el usuario final. Hemos tenido clientes que nos han comentado que el proceso de CrowdHandler y los mensajes asociados mantienen a los usuarios de nuestro lado, ya que les dan tiempo para respirar y los mantienen informados.
Así que, cuando se active la sala de espera, confía en el proceso. No te asustes (pero utiliza 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 viendo una página web que se ha colgado o un mensaje inmediato de «agotado».