En CrowdHandler, a menudo nos encontramos con personas que se preparan por primera vez para afrontar un gran volumen de tráfico. A veces, lo único que realmente necesitan es una sala de espera.
Sin embargo, a menudo también incorporan servidores y sistemas de equilibrio de carga por primera vez, y están muy interesados en hablar de estos temas con nosotros.
Sin querer parecer demasiado desdeñosos, esta no es la principal preocupación de nuestro producto. En realidad, no nos importa, ya que nuestro producto es independiente de la arquitectura que haya detrás de la sala de espera. Nuestra principal preocupación es el volumen de transacciones que nuestros clientes pueden procesar.
De hecho, rara vez resulta práctico ampliar la capacidad lo suficiente como para gestionar un tráfico diez veces superior al habitual en caso de picos ocasionales. Dicho esto, cuanto más optimizada esté tu página web, más cortas serán las colas.
La mayoría de los desarrolladores web tienen carreras profesionales perfectamente respetables, sin haber trabajado nunca en nada que haya tenido una gran popularidad. Por eso, les sorprende descubrir que gran parte de los consejos sobre las supuestas «buenas prácticas» que circulan por ahí no resisten el contacto con el mundo real.
Nuestra experiencia se remonta a nuestros inicios, cuando creábamos sitios web de alta disponibilidad para grandes marcas del sector de los medios de comunicación y el entretenimiento. Por eso, contamos con ciertos conocimientos sobre cómo escalar sitios web. Sabemos lo que realmente funciona y lo que no.
Lo que no importa
Número de servidores de aplicaciones
Es posible que te estés pasando de un servidor compartido a uno dedicado. Quizás incluso te estés pasando de un servidor dedicado a varios servidores detrás de un equilibrador de carga (ya sea en un proveedor de alojamiento tradicional o en un servicio en la nube como AWS).
La verdad es que rara vez vemos servidores de aplicaciones al límite de su capacidad, por lo que esa cifra no es muy significativa.
La gestión de tareas en JavaScript, PHP o .NET para generar HTML o JSON no consume tantos recursos. Incluso un solo servidor puede hacer frente a un volumen considerable de tráfico.
Normalmente, los servidores de aplicaciones se amplían para garantizar la redundancia (con el fin de atender las solicitudes en caso de que falle uno de ellos). En situaciones de mucho tráfico, los servidores de aplicaciones suelen pasar la mayor parte del tiempo a la espera de algo, a menudo una base de datos o una API (que actúa como una base de datos remota).
Un servidor de aplicaciones suele bloquearse cuando se queda sin conexiones salientes mientras espera respuestas de los servidores superiores. Diez servidores de aplicaciones atascados esperando la misma consulta a la base de datos o la misma llamada a la API no servirán de mucho.
Añadir procesadores al servidor de la base de datos (BD)
Entonces, ¿eso significa que deberías revisar primero tu servidor de bases de datos?
La gente suele utilizar la palabra «clúster» a la ligera, pero, a menos que hayas incorporado el sharding a tu aplicación (échale un vistazo), no basta con añadir servidores de base de datos adicionales para ampliar el rendimiento.
Claro, podrías pasar a un servidor de base de datos más potente con más núcleos de CPU. Sin embargo, la mayoría de las aplicaciones modernas no suponen una gran carga de CPU para la base de datos. Las consultas que te ralentizan suelen estar limitadas por la velocidad del disco (E/S), sobre todo en entornos de nube sofisticados en los que el almacenamiento de la base de datos se encuentra quién sabe dónde, y puedes pasar por alto la limitación de E/S hasta que realmente tengas que abordarla. Entonces, descubres lo caro que puede resultar el rendimiento real de E/S.
Añadir E/S de disco
Si analizas los tiempos de ejecución de las consultas en tu servidor de base de datos, verás que aumentar la potencia de la CPU y la E/S de disco puede ayudar en cierta medida, pero no lo suficiente como para evitar que el sitio web se cuelgue bajo una carga elevada. Duplicar o incluso cuadruplicar las especificaciones de tu base de datos no salvará por arte de magia tu sitio web.
¿Por qué no? Normalmente, se debe a que tus consultas están mal optimizadas —a menudo generadas por algún marco de trabajo popular pero ineficiente— y no están indexadas correctamente. Si aplicas los índices adecuados, podrías conseguir que las consultas se ejecutaran 1.000 veces más rápido. Eso resulta mucho más rentable que gastar 1.000 veces más en tu servidor de base de datos.
Escalabilidad «infinita» en la nube
Parece fácil: basta con hacer clic en un botón para obtener más ejecuciones, procesos o hámsters.
Pero incluso si logras configurar todo a la perfección y no te importa el coste, si dependes de las transacciones (como ocurre con la mayoría de los sitios web), te encontrarás con un cuello de botella en la fase de transacción, ya sea en tu base de datos (las bases de datos transaccionales no pueden escalar infinitamente; búscalo) o en un servicio de terceros, como una API de pago (que también se basan en bases de datos transaccionales con límites de velocidad).
Lo que sí importa
Almacenar en caché la página de destino
¿Sabes esa página que todo el mundo va a compartir en Instagram y demás?
Almacénalo en la caché.
No malgastes los recursos del servidor regenerando esa misma página cientos de miles (o millones) de veces. Si se trata de una página dinámica, conviértela en estática —o, al menos, parcialmente estática—. Añade un botón que lleve a un paso de llamada a la acción independiente si los usuarios necesitan cargar el inventario u otros datos dinámicos.
¿No sabes con certeza a qué página acceden más los usuarios? Averígualo. Se trata de un dato fundamental. Configura los ajustes de caché y utiliza un proxy inverso (como Varnish) o una CDN (como Cloudflare), o incluso sirve un archivo completamente estático desde el servidor web. Puede que a los desarrolladores no les guste esta solución, pero para sitios web que esperan millones de visitas, el almacenamiento en caché supone el 80 % del trabajo.
Utiliza una CDN (red de distribución de contenidos)
Una CDN es una capa de almacenamiento en caché sofisticada y distribuida. Aunque optimizarla al máximo puede resultar complicado, dar los primeros pasos es muy sencillo. ¿Crees que las CDN solo sirven para distribuir archivos estáticos por todo el mundo?
No exactamente. Muchos de los sitios web con mayor tráfico actual están respaldados por una CDN, por muy «dinámicos» que parezcan. De hecho, este principio es la base de marcos de trabajo como Next.js/Vercel, que alcanzan unos niveles de rendimiento notables gracias a ello. Pero no es nada nuevo: las cadenas de televisión, el comercio electrónico y las páginas de venta de entradas llevan utilizando CDN desde antes de que tú nacieras. Los nuevos marcos de trabajo simplemente optimizan el enfoque. Algunas opciones de CDN son:
- Cloudflare: Asequible, popular y fácil de configurar.
- CloudFront: Se incluye con AWS, lo cual resulta muy práctico si alojas tu sitio web allí.
- Akamai: uno de los pioneros, utilizado por muchas grandes páginas web de comercio minorista.
Utiliza una sala de espera
La mayoría de los sitios web tienen límites transaccionales que no se pueden eliminar mediante el escalado. Incluso gigantes como Ticketmaster utilizan colas durante los picos de ventas, y eso que cuentan con un gran número de servidores. Empieza por almacenar en caché lo que se pueda almacenar y, a continuación, coloca una sala de espera delante de las partes verdaderamente dinámicas. Es un primer paso más acertado que escalar servidores al azar con la esperanza de satisfacer la demanda.
Configura una sala de espera, establece una tasa de transacciones que sepas que puedes gestionar y observa tu sitio web bajo una carga máxima para detectar cuellos de botella reales —que a menudo se encuentran en el registro de consultas lentas de tu base de datos o en los tiempos de respuesta de la API—. Es posible que puedas solucionar los problemas de escalabilidad simplemente añadiendo un índice a una tabla. Además, aprenderás del comportamiento real del tráfico, no de pruebas de carga teóricas ni de conjeturas.
CrowdHandler
En situaciones de gran afluencia, la estrategia más eficaz no es el escalado ilimitado, sino una gestión inteligente de los recursos. Las salas de espera son fundamentales para ello.
CrowdHandler se especializa en ofrecer salas de espera virtuales flexibles y fáciles de integrar para ayudarte a gestionar los periodos de mayor afluencia.
Regístrate hoy mismo para disfrutar de una prueba gratuita.