Balanceadores de carga y autoescalado
Un balanceador no reparte tráfico a máquinas: lo reparte a las que su chequeo de salud dice que están sanas. Y el autoescalado no agrega capacidad cuando hace falta sino unos minutos después. Las dos frases explican casi todos los incidentes de esta pareja.
Para este tema conviene tener claro:Máquinas virtuales, contenedores y funciones
Datos de proveedores verificados contra la documentación oficial el 19 de sept de 2026.
La receta se repite en todos los diagramas: un balanceador adelante, varias instancias atrás, un grupo de autoescalado que las sube y las baja. Se arma en veinte minutos y funciona.
Después llega el primer pico real y aparecen las dos preguntas que la receta no contesta: por qué el balanceador siguió mandando tráfico a una máquina rota, y por qué la capacidad nueva apareció cuando el pico ya había pasado.
Dos balanceadores distintos con el mismo nombre
Bajo la palabra “balanceador” conviven dos cosas: uno que entiende HTTP y uno que sólo mueve conexiones TCP o UDP. La diferencia no es de rendimiento, es de qué puede decidir.
| De aplicación (capa 7) | De red (capa 4) | |
|---|---|---|
| Qué ve | Ruta, encabezados, host, cookies | Direcciones y puertos |
| Qué puede hacer | Rutear /api a un destino y /admin a otro, reintentar, reescribir | Repartir conexiones y poco más |
| Dónde termina TLS | En el balanceador, normalmente | Puede pasar el tráfico cifrado sin tocarlo |
| Latencia y throughput | Mayor costo por request | Muy alto, con latencia mínima |
| Cuándo elegirlo | Aplicaciones web y APIs | Protocolos no HTTP, IP de origen preservada, escalas extremas |
El chequeo de salud es el componente crítico
Un balanceador no sabe si una instancia anda: sabe lo que le contesta el chequeo de salud. Por eso la calidad de ese endpoint decide la calidad de todo el conjunto.
Qué hace un chequeo de salud bien hecho
- Responde rápido y sin dependencias pesadas: si consulta la base en cada chequeo, una base lenta saca de servicio a todas las instancias a la vez.
- Verifica lo que la instancia necesita para atender, no sólo que el proceso esté vivo. Un endpoint que devuelve 200 siempre convierte al balanceador en un repartidor ciego.
- Distingue “arrancando” de “roto”: el período de gracia inicial existe para que una instancia que todavía está levantando no se declare fallida y se reemplace en loop.
- Tiene umbrales coherentes: dos fallos consecutivos para sacarla, dos éxitos para devolverla, con un intervalo que no tarde minutos en reaccionar.
Antes de seguir, predecí
El autoescalado siempre llega tarde
Entre que la carga sube y que hay capacidad nueva atendiendo pasan varios pasos, y cada uno suma minutos.
La cadena de demoras
- La métrica se publica cada uno o cinco minutos, según la resolución configurada.
- La alarma espera unos períodos consecutivos por encima del umbral para no reaccionar a un pico.
- Se lanza la instancia: arranque del sistema, de la aplicación y de sus dependencias.
- El chequeo de salud tiene que aprobarla, después del período de gracia.
- Recién ahí el balanceador le manda tráfico.
La conclusión práctica: el autoescalado sirve para cambios de carga de decenas de minutos, no para un pico de treinta segundos. Para el pico corto lo que sirve es tener margen de capacidad, una imagen que arranque rápido, o un modelo serverless donde el arranque es del proveedor.
99.9700 %
13 min por mes de caída esperada
A esta altura la fórmula deja de describir el sistema real: lo que manda ya no es la probabilidad de cada pieza sino lo que falla junto, como un despliegue o un cambio de configuración.
Lo que muestra el cálculo es la razón de fondo para tener más de una instancia, y también su límite: replicar el cómputo mejora mucho la disponibilidad, pero cada dependencia compartida —una base, una cola, un servicio externo— la empuja para abajo. El balanceador no protege de eso.
Antes de seguir, predecí
Elegir la métrica y evitar el vaivén
| Política | Cómo funciona | Cuándo conviene |
|---|---|---|
| Seguimiento de objetivo | Se fija un valor deseado y el proveedor ajusta la cantidad | El caso normal: es la más difícil de configurar mal |
| Por pasos | Umbrales que suman o restan una cantidad fija | Cuando la reacción tiene que ser distinta según cuán lejos está |
| Programada | Cambia el mínimo a una hora fija | Carga previsible: horario laboral, un lanzamiento, un cierre de mes |
| Predictiva | Anticipa según el historial | Patrones diarios estables y arranques lentos |
El vaivén —subir capacidad, bajarla, volver a subirla— se corta con tres cosas: un período de enfriamiento después de cada acción, un umbral de bajada más conservador que el de subida, y una cantidad mínima que no baje de lo que se necesita para tolerar la caída de una zona.
Más a fondo · nivel seniorEscalar contenedores: dos niveles, no uno
En Kubernetes el problema se parte en dos y hay que configurar los dos. El escalador de pods suma réplicas cuando la métrica sube; el escalador de nodos suma máquinas cuando los pods quedan sin lugar donde correr. Si sólo está el primero, los pods nuevos quedan pendientes y no atienden nada.
Dos detalles que cambian el comportamiento real: los requests de CPU y memoria de cada pod son los que deciden cuántos entran por nodo, así que pedir de más desperdicia máquinas enteras; y las métricas de negocio —largo de una cola, requests por segundo— se usan como objetivo a través de un adaptador de métricas, que es lo que convierte al escalador en algo que reacciona al trabajo pendiente y no a un promedio de CPU.
Cierre
Autoevaluación
¿Lo entendiste?
Práctica