Balanceo de carga: repartir tráfico y tolerar fallos
Un servidor tiene límites de CPU, memoria y conexiones. Cuando la demanda supera su capacidad, crecen las colas y la latencia. El escalado horizontal añade instancias; el balanceador ofrece un punto de entrada y distribuye conexiones o solicitudes.
El algoritmo importa
Round robin recorre destinos por turnos y resulta útil con capacidades y trabajos comparables. Una variante ponderada asigna más tráfico a servidores con mayor capacidad. Least connections prefiere el destino con menos conexiones activas, lo que puede ayudar si su duración varía mucho.
Contar conexiones no equivale a medir CPU: una conexión puede estar inactiva o transportar numerosos streams. El criterio debe evaluarse con tráfico real. Una solicitud pesada puede causar desequilibrio; no necesariamente bloquea todas las demás solicitudes del servidor.
Salud y retirada de instancias
Los health checks activos consultan un endpoint periódicamente; los pasivos detectan fallos del tráfico observado. Umbrales adecuados evitan retirar y reintroducir servidores por fluctuaciones aisladas. El chequeo debe reflejar si la instancia puede atender trabajo y no solo si existe un proceso.
Un destino no saludable deja de recibir nuevas solicitudes según la política configurada. Las que ya estaban en curso pueden fallar. Durante un despliegue, drenar conexiones permite retirar gradualmente una instancia. Los timeouts y reintentos deben impedir que un fallo se convierta en tráfico duplicado masivo.
Sesiones compartidas
Si el login vive solo en la memoria del servidor A, una petición al B puede perder ese contexto. La afinidad o sticky session intenta conservar el mismo destino, pero complica el reparto y no recupera esa memoria si A falla. Un almacén compartido de sesiones o un diseño de autenticación adecuado permite usar distintas réplicas.
Capas 4 y 7
La capa 4 utiliza información de transporte, como direcciones y puertos. La capa 7 interpreta HTTP y permite seleccionar por host, ruta o cabeceras. La elección depende de protocolos, volumen y necesidades de inspección. NGINX documenta métodos de reparto y persistencia para el caso HTTP.
La capacidad agregada no es una multiplicación garantizada. Si tres servidores sostienen 200 solicitudes por segundo cada uno, 600 es una referencia ideal antes de considerar desequilibrio y margen de fallo. Una base de datos saturada o el propio balanceador pueden seguir limitando el sistema.