Escalado de infraestructura: horizontal versus vertical, equilibrio de carga y escalado automático

Netflix presta servicios a 260 millones de suscriptores en 190 países escalando dinámicamente miles de instancias en función de la demanda en tiempo real. Si bien la mayoría de las empresas no operan a la escala de Netflix, los principios de escalamiento son los mismos: hacer coincidir la capacidad de la infraestructura con la demanda de tráfico automáticamente, sin intervención manual y sin pagar por recursos inactivos. Las elecciones que haga entre el escalado horizontal y vertical, los balanceadores de carga L4 y L7 y el escalado automático reactivo y predictivo determinan si su plataforma crece con gracia o choca contra una pared.

Conclusiones clave

• Inicie vertical (máquinas más grandes) para simplificar, luego cambie a horizontal (más máquinas) cuando necesite alta disponibilidad o exceda los límites de una sola máquina
• Los balanceadores de carga L7 brindan enrutamiento basado en contenido esencial para aplicaciones modernas, mientras que los balanceadores L4 ofrecen rendimiento sin procesar para una distribución TCP simple.
• Las políticas de escalado automático deben combinar activadores basados en métricas (CPU, memoria) con escalamiento predictivo para patrones de tráfico conocidos.
• El escalado de la base de datos sigue reglas diferentes a las del escalado de aplicaciones: réplicas de lectura para cargas con mucha lectura, partición para cargas con mucha escritura

---

Escala horizontal versus vertical

La decisión de escala fundamental es si agrandar las máquinas existentes (verticales) o agregar más máquinas (horizontales). Cada enfoque tiene distintas compensaciones.

Cuándo escalar verticalmente

El escalado vertical es la primera opción correcta por varias razones. No requiere cambios en la aplicación, ni configuración del balanceador de carga ni administración de estado distribuido. Especialmente para las bases de datos, el escalado vertical evita la complejidad de la fragmentación, el retraso en la replicación y las transacciones distribuidas.

Escalar verticalmente cuando:

• Su aplicación aún no tiene estado (sesiones almacenadas en la memoria, escrituras en el sistema de archivos)
• Estás ejecutando una única base de datos y no has alcanzado los límites de conexión o CPU.
• El siguiente tamaño de instancia es más barato que el tiempo de ingeniería para volverse horizontal
• Necesita escalar inmediatamente sin cambios arquitectónicos

Deje de escalar verticalmente cuando:

• Necesita alta disponibilidad (instancia única = punto único de falla)
• La instancia más grande disponible no es suficiente
• Estás pagando por la capacidad máxima que permanece inactiva el 90 % del tiempo.
• Necesita distribución geográfica para la latencia.

Cuándo escalar horizontalmente

El escalado horizontal requiere que su aplicación no tenga estado: cualquier solicitud puede ser manejada por cualquier instancia. Esto significa:

• Sesiones almacenadas en Redis o base de datos, no en memoria
• Cargas de archivos almacenadas en el almacenamiento de objetos (S3), no en el disco local
• Sin configuración específica de instancia ni almacenamiento en caché local sin replicación
• Manejo elegante de la terminación de instancias (verificaciones de estado, drenaje de conexiones)

Escalar horizontalmente cuando:

• La alta disponibilidad es un requisito (su empresa no puede tolerar minutos de inactividad)
• El tráfico es variable y el escalado automático puede ahorrar costos al reducirlo durante los períodos de tranquilidad.
• Debe realizar la implementación sin tiempo de inactividad (implementaciones continuas entre instancias)
• Los requisitos de rendimiento superan la capacidad de una sola máquina

---

Análisis profundo del equilibrio de carga

Un equilibrador de carga distribuye el tráfico entrante entre varios servidores backend. El tipo de equilibrador de carga determina qué decisiones de enrutamiento son posibles.

Equilibrio de carga L4 (capa de transporte)

Los balanceadores de carga L4 operan a nivel TCP/UDP. Enrutan conexiones según la dirección IP y el puerto sin inspeccionar el contenido de los paquetes. Son rápidos, simples y manejan cualquier protocolo basado en TCP.

Mejor para: Distribución TCP sin formato, proxy de conexión de base de datos (PgBouncer), protocolos no HTTP, requisitos de rendimiento extremadamente altos

Limitaciones: No se pueden tomar decisiones de enrutamiento basadas en la ruta URL, los encabezados o las cookies. No se puede finalizar SSL (debe hacerse en los servidores).

Equilibrio de carga L7 (capa de aplicación)

Los balanceadores de carga L7 operan a nivel HTTP. Inspeccionan los encabezados de las solicitudes, las URL, las cookies e incluso los cuerpos de las solicitudes para tomar decisiones de enrutamiento. Manejan la terminación y compresión de SSL y pueden modificar solicitudes y respuestas.

Ideal para: aplicaciones web, puertas de enlace API, enrutamiento basado en contenido, terminación SSL, pruebas A/B, implementaciones canary

Algoritmos de equilibrio de carga

Controles de salud y degradación elegante

Las comprobaciones de estado determinan si un servidor backend debe recibir tráfico. Configúrelos cuidadosamente:

• Comprobación de estado superficial: una simple comprobación de conexión TCP o HTTP 200 en un punto final dedicado. Detecta fallas del servidor pero no fallas a nivel de aplicación.
• Verificación de estado profunda: verifica la conectividad de la base de datos, la disponibilidad de Redis y la accesibilidad de los servicios externos. Detecta más problemas, pero corre el riesgo de obtener falsos negativos si una dependencia no crítica no funciona.
• Período de gracia: las instancias nuevas necesitan tiempo para prepararse (compilación JIT, llenado de caché). Establezca un período de gracia de inicio antes de que el equilibrador de carga envíe todo el tráfico.
• Drenaje: al eliminar una instancia, deje de enviar nuevas solicitudes pero permita que se completen las solicitudes existentes (agotamiento de conexión). Normalmente entre 30 y 60 segundos.

---

Políticas de escalado automático

El escalado automático ajusta la cantidad de instancias según la demanda, haciendo coincidir la capacidad con el tráfico sin intervención manual.

Escalado basado en métricas

El enfoque más común desencadena acciones de escalamiento cuando una métrica cruza un umbral.

Escala predictiva

Si su tráfico sigue patrones predecibles (picos diarios, ciclos semanales, eventos estacionales), el escalamiento predictivo proporciona capacidad antes de que llegue el tráfico. AWS Auto Scaling admite el escalado predictivo que aprende de patrones históricos y escala de manera proactiva.

Combine predictivo y reactivo: Utilice escalamiento predictivo para patrones conocidos (rampa de tráfico matutino, aprovisionamiento previo del Viernes Negro) y escalamiento reactivo para picos inesperados.

Mejores prácticas de escalamiento

1. Ampliación rápida, ampliación lenta: agregue instancias de manera agresiva (tiempo de reutilización de 1 a 2 minutos) pero elimínelas gradualmente (tiempo de reutilización de 10 a 15 minutos) para evitar fluctuaciones.
2. Utilice varias métricas: escale en CPU O memoria O recuento de solicitudes, utilizando la primera métrica que active
3. Establezca límites mínimos y máximos: evite escalar a cero (sin disponibilidad) o escalar indefinidamente (explosión de costos)
4. Pruebe el escalado durante las pruebas de carga: verifique que el escalado automático se active correctamente y que las nuevas instancias atiendan el tráfico dentro del plazo previsto.
5. Monitorear eventos de escalamiento: alerta sobre escalamientos frecuentes para detectar problemas de configuración o problemas de rendimiento subyacentes.

---

Estrategias de escalamiento de bases de datos

Las bases de datos no escalan horizontalmente de la misma manera que lo hacen los servidores de aplicaciones. Las operaciones de escritura requieren consenso y una fuerte coherencia limita las opciones de distribución.

Leer réplicas

Las réplicas de lectura copian datos de la base de datos principal y atienden consultas de lectura. Escalan el rendimiento de lectura linealmente pero no ayudan con el rendimiento de escritura.

Consideraciones de implementación:

• Retraso en la replicación: las réplicas eventualmente son consistentes. Es posible que las consultas inmediatamente después de una escritura no vean el cambio. Utilice el primario para lecturas después de escrituras.
• Enrutamiento de conexión: su aplicación necesita lógica para enrutar lecturas a réplicas y escrituras a la principal. Los ORM y los servidores proxy de conexión (ProxySQL, PgBouncer) pueden automatizar esto.
• Conmutación por error: si el principal falla, se puede promover una réplica. La conmutación por error automatizada (AWS RDS Multi-AZ, AWS Aurora) reduce el tiempo de inactividad a segundos.

Partición de tablas

Para cargas de trabajo con mucha escritura en tablas grandes, la partición divide una tabla en partes físicas más pequeñas mientras se mantiene una única interfaz lógica. Para conocer estrategias de partición detalladas, consulte nuestra guía de optimización de bases de datos.

Agrupación de conexiones

Las conexiones a bases de datos son costosas de crear y limitadas en número. Los agrupadores de conexiones, como PgBouncer, agrupan conexiones de muchas instancias de aplicaciones en un número menor de conexiones de bases de datos.

Sin agrupación: 20 instancias de aplicación x 20 conexiones cada una = 400 conexiones de base de datos (probablemente superando los límites de PostgreSQL)

Con PgBouncer: 20 instancias de aplicaciones se conectan a PgBouncer, que mantiene entre 50 y 100 conexiones a PostgreSQL, multiplexando solicitudes de manera eficiente.

---

Descomposición de microservicios

Cuando un monolito se vuelve demasiado grande para que un solo equipo pueda desarrollarlo e implementarlo de manera eficiente, la descomposición de microservicios permite el escalado independiente de diferentes componentes.

Cuándo descomponerse

No empieces con microservicios. Comience con un monolito bien estructurado y descompóngase cuando:

• Los diferentes componentes tienen requisitos de escala muy diferentes (la búsqueda necesita 20 instancias, el pago necesita 5)
• Diferentes equipos deben implementarse de forma independiente sin coordinar cronogramas de lanzamiento.
• Un componente específico necesita una pila de tecnología diferente (aprendizaje automático en Python, API en Node.js)
• El tiempo de implementación del monolito supera los 30 minutos debido al tamaño del código base.

Qué extraer primero

---

Preguntas frecuentes

¿Cómo sé cuándo necesito escalar?

Supervise cuatro métricas clave: utilización de la CPU (consistentemente por encima del 70%), uso de memoria (por encima del 80%), tiempo de respuesta P95 (por encima de su SLO) y tasa de error (por encima del 0,1%). Cuando una métrica supera constantemente su umbral, es necesario escalar. El monitoreo proactivo con alertas detecta estas tendencias antes de que los usuarios se den cuenta. Consulte nuestra guía de seguimiento.

¿Es más rentable el escalado automático o el aprovisionamiento previo?

El escalado automático es más rentable para el tráfico impredecible porque solo paga por la capacidad cuando la necesita. El aprovisionamiento previo es mejor para picos predecibles (viernes negro, picos diarios) porque el escalado automático tarda entre 3 y 10 minutos en agregar capacidad. El enfoque más rentable combina ambos: aprovisionamiento previo para picos esperados, escalado automático para picos inesperados y uso de instancias reservadas para su capacidad de referencia. Consulte nuestra guía de optimización de costos de la nube.

¿Debería utilizar contenedores (Docker/Kubernetes) o máquinas virtuales tradicionales?

Los contenedores se inician más rápido (segundos frente a minutos), utilizan los recursos de manera más eficiente (mayor densidad por host) y proporcionan entornos consistentes en todo el desarrollo y la producción. Kubernetes agrega orquestación (escalamiento automático, autorreparación, implementaciones continuas) pero una complejidad operativa significativa. Comience con servicios de contenedores administrados (AWS ECS, Google Cloud Run) antes de considerar Kubernetes.

¿Cómo manejo la conmutación por error de la base de datos sin pérdida de datos?

Utilice la replicación sincrónica para una conmutación por error sin pérdida de datos: el principal no reconoce una escritura hasta que la réplica la confirma. Esto agrega latencia de escritura (normalmente de 1 a 5 ms dentro de la misma región) pero garantiza que no se pierdan datos durante la conmutación por error. AWS RDS Multi-AZ y Aurora proporcionan replicación síncrona administrada con conmutación por error automática.

---

¿Qué sigue?

Evalúe su infraestructura actual frente a sus proyecciones de crecimiento. Si está ejecutando un único servidor, asegúrese de que su aplicación no tenga estado y esté lista para el escalamiento horizontal. Si ya ejecuta varias instancias, optimice la configuración de su balanceador de carga e implemente políticas de escalado automático.

Para obtener una perspectiva completa de la ingeniería de rendimiento, consulte nuestra guía fundamental sobre ampliar su plataforma empresarial. Para optimizar los costos a medida que escala, lea nuestra guía sobre optimización de costos de la nube.

ECOSIRE diseña e implementa infraestructura escalable para plataformas empresariales en AWS y entornos de múltiples nubes. Comuníquese con nuestro equipo de DevOps para una evaluación de escalamiento de infraestructura.

---

Publicado por ECOSIRE: ayuda a las empresas a escalar con soluciones impulsadas por IA en Odoo ERP, Shopify eCommerce y OpenClaw AI.