Escalado del sistema

Todos los sistemas comienzan de forma simple, a menudo ejecutándose en una sola máquina. A baja escala, esto funciona bien porque el servidor puede manejar las solicitudes entrantes, procesar la lógica y administrar los datos sin una carga significativa.

A medida que la aplicación crece, la demanda aumenta. Más usuarios significa más solicitudes simultáneas, lo que ejerce presión sobre los recursos de CPU, memoria y red.

El crecimiento de los datos añade otra capa de estrés. Los conjuntos de datos más grandes requieren más almacenamiento y hacen que las consultas sean más lentas, lo que incrementa aún más los tiempos de respuesta.

Con el tiempo, el sistema llega a un punto en el que una sola máquina ya no puede seguir el ritmo. Escalar se vuelve necesario para mantener el rendimiento, evitar ralentizaciones y garantizar que el sistema continúe funcionando de manera confiable bajo una carga creciente.

El escalado vertical, también conocido como scaling up, mejora la capacidad del sistema al actualizar un solo servidor. Esto normalmente implica añadir más núcleos de CPU, aumentar la RAM o ampliar el almacenamiento.

Este enfoque es sencillo. La arquitectura del sistema permanece sin cambios y no es necesario introducir la complejidad de un sistema distribuido, como la comunicación por red o la sincronización de datos.

Sin embargo, el escalado vertical tiene límites estrictos. Las máquinas físicas solo pueden actualizarse hasta cierto punto, y el hardware de gama alta se vuelve cada vez más caro.

Debido a estos límites, el escalado vertical funciona bien en las primeras etapas, pero con el tiempo resulta insuficiente para sistemas a gran escala.

El escalado horizontal, también conocido como scale out, mejora la capacidad del sistema añadiendo más servidores en lugar de actualizar uno solo. Cada servidor maneja una parte de la carga de trabajo total.

El tráfico entrante se distribuye entre estos servidores, lo que permite que el sistema procese muchas más solicitudes en paralelo en comparación con una configuración de una sola máquina.

Este enfoque también mejora la confiabilidad. Si un servidor falla, otros pueden seguir atendiendo solicitudes, reduciendo el impacto de las fallas.

Sin embargo, el escalado horizontal introduce complejidad de sistemas distribuidos, lo que requiere mecanismos de coordinación, balanceo de carga y consistencia de datos.

A medida que los sistemas escalan horizontalmente, el tráfico entrante debe distribuirse entre varios servidores. Un balanceador de carga se sitúa delante de estos servidores y actúa como punto de entrada para todas las solicitudes.

En lugar de enviar todo el tráfico a una sola máquina, el balanceador de carga usa algoritmos como round-robin o least connections para distribuir las solicitudes de manera uniforme. Esto evita que un solo servidor se convierta en un cuello de botella.

Los balanceadores de carga también comprueban continuamente el estado de los servidores. Si un servidor se vuelve lento, falla o no supera las comprobaciones de salud, se elimina automáticamente del grupo para que los usuarios no sean dirigidos a una instancia defectuosa.

Además, los balanceadores de carga pueden encargarse de tareas como la terminación SSL, el enrutamiento de solicitudes basado en rutas y la regulación del tráfico. Herramientas como Nginx, HAProxy y los balanceadores de carga administrados en la nube se usan ampliamente para implementar esta capa en los sistemas modernos.

Un load balancer no es solo un divisor de tráfico — importa cómo distribuye el tráfico.

La estrategia más simple es round-robin, donde cada solicitud va al siguiente servidor en secuencia. Esto funciona cuando los servidores son idénticos, pero falla cuando las cargas de trabajo varían.

Least connections mejora esto al enrutar el tráfico al servidor que maneja la menor cantidad de solicitudes activas, reduciendo la sobrecarga y mejorando los tiempos de respuesta.

Sticky sessions mantienen a un usuario vinculado al mismo servidor. Esto ayuda cuando los datos de sesión se almacenan localmente, pero reduce la flexibilidad y puede crear una carga desigual.

Los sistemas modernos combinan estrategias con health checks y weights. Los servidores más potentes pueden recibir más tráfico, mientras que los que fallan se eliminan automáticamente.

Elegir una mala estrategia provoca una carga desigual, mayor latencia y desperdicio de infraestructura, incluso si hay un load balancer presente.

En un sistema sin estado, cada solicitud es independiente. El servidor no almacena información sobre solicitudes anteriores o sesiones de usuario en su memoria local.

En su lugar, cualquier estado necesario, como sesiones de usuario o datos de autenticación, se almacena en sistemas externos como bases de datos, cachés o almacenes de sesión dedicados.

Este diseño facilita mucho el escalado horizontal. Como ningún servidor conserva datos únicos de sesión, las solicitudes pueden enrutar a cualquier servidor disponible sin preocuparse por dónde se atendieron las solicitudes anteriores.

La arquitectura sin estado también mejora la confiabilidad y la flexibilidad, ya que los servidores pueden agregarse, eliminarse o reemplazarse sin interrumpir las interacciones del usuario.

El tráfico en los sistemas reales no es constante. El uso puede dispararse durante las horas pico y bajar en los periodos de menor actividad, lo que hace ineficiente una infraestructura fija.

El autoescalado resuelve esto ajustando automáticamente la capacidad del sistema. Cuando aumenta el tráfico, se agregan nuevos servidores para manejar la carga. Cuando el tráfico disminuye, se eliminan los servidores no utilizados.

Este proceso normalmente está impulsado por métricas como la utilización de CPU, el uso de memoria o la tasa de solicitudes. Se definen umbrales para que el sistema pueda reaccionar rápidamente a los cambios en la demanda.

El autoescalado mejora tanto el rendimiento como la eficiencia de costos. Los sistemas pueden manejar picos repentinos sin intervención manual, al mismo tiempo que evitan costos innecesarios de infraestructura durante los periodos de bajo uso.

Cuando los usuarios acceden a una aplicación, los datos normalmente viajan desde un servidor central, que puede estar geográficamente muy lejos. Esta distancia introduce latencia y ralentiza los tiempos de respuesta.

Las CDNs resuelven esto almacenando en caché contenido estático —como imágenes, scripts y hojas de estilo— en servidores edge distribuidos por todo el mundo. Cuando un usuario realiza una solicitud, esta se atiende desde la ubicación edge más cercana.

Esto reduce significativamente la distancia que deben recorrer los datos, lo que se traduce en tiempos de carga más rápidos y una mejor experiencia de usuario.

Las CDNs también reducen la carga en los servidores de origen al gestionar una gran parte del tráfico. Servicios como Cloudflare, AWS CloudFront y Fastly se usan comúnmente para implementar esta capa en sistemas escalables.

Un sistema escalable no es un solo componente, sino una combinación de capas que trabajan juntas para manejar una demanda creciente. Cada capa es responsable de una función específica en el flujo de la solicitud.

Primero, los usuarios interactúan con una CDN, que sirve contenido en caché y reduce la latencia. Las solicitudes que requieren procesamiento dinámico se reenvían a un balanceador de carga.

El balanceador de carga distribuye el tráfico entre varios servidores de aplicaciones, lo que permite que el sistema procese muchas solicitudes en paralelo.

Los servidores de aplicaciones interactúan con una base de datos distribuida, donde los datos se particionan o replican para manejar grandes conjuntos de datos y altos volúmenes de consultas.

Este enfoque por capas permite que cada parte del sistema escale de forma independiente, haciendo posible manejar el crecimiento de usuarios, tráfico y datos sin rediseñar todo el sistema.