Balanceador de carga: qué es y cuándo lo necesitas

Un balanceador de carga recibe conexiones o solicitudes y las reparte entre varios servidores disponibles. Lo necesita cuando una sola instancia ya no basta, cuando una caída no puede detener el servicio o cuando quiere desplegar cambios sin enviar todo el tráfico a un único punto.

Qué hace y qué no hace

El balanceador se coloca delante de un grupo de servidores. Publica una entrada estable, decide qué backend atenderá cada conexión o solicitud y evita enviar trabajo a nodos que considera no disponibles. El resultado puede ser más capacidad y una recuperación más limpia, pero solo si hay varios backends realmente independientes.

No crea alta disponibilidad por arte de magia. Si el propio balanceador es una única máquina, si todos los backends comparten la misma zona o si la base de datos sigue siendo un punto único de fallo, el dibujo parece redundante y la operación no lo es. La continuidad se diseña por dominios de fallo, no por cantidad de cajas.

Tampoco reemplaza el escalado. Puede distribuir el tráfico existente, pero no añade CPU, memoria ni conexiones disponibles. Para absorber crecimiento hace falta sumar capacidad, retirar nodos con cuidado y comprobar que el resto del sistema —base de datos, caché, colas y almacenamiento— acompaña.

L4 y L7: la decisión que cambia lo que puede ver

Un balanceador de capa de transporte trabaja principalmente con conexiones, direcciones IP y puertos. Puede repartir TCP sin interpretar cada ruta HTTP. Es útil para protocolos distintos de HTTP, para conexiones largas o cuando se busca una ruta más simple con menor conocimiento de la aplicación.

Uno de capa de aplicación entiende HTTP o HTTPS. Puede decidir según host, ruta, cabeceras o cookies: por ejemplo, enviar la ruta de API a un servicio y el resto a otro. Esa visibilidad permite reglas finas, redirecciones y observabilidad de solicitudes, a cambio de más configuración y de una dependencia mayor de la semántica HTTP.

La pregunta correcta no es cuál es mejor. Es qué información necesita la decisión de reparto. Si basta IP y puerto, L4 puede ser suficiente. Si necesita distinguir dominios, rutas o sesiones web, L7 encaja mejor.

La siguiente vista resume el recorrido. DNS encuentra la entrada del servicio; el balanceador aplica una decisión L4 o L7 y solo elige entre backends que han pasado sus comprobaciones. El mismo significado debe sostenerse en la configuración y en las pruebas, no solo en el diagrama.

Health checks: comprobar la aplicación, no solo el puerto

Una comprobación TCP responde a una pregunta limitada: ¿se puede abrir la conexión? Para una base de datos o un servicio sencillo puede ser una señal útil. En una aplicación web, un endpoint HTTP dedicado puede verificar además que el proceso responde y que sus dependencias mínimas están listas.

Una comprobación útil separa tres señales:

• conexión al puerto esperado;
• respuesta válida del proceso;
• preparación mínima de la aplicación para recibir tráfico.

El endpoint no debería ejecutar una auditoría pesada en cada consulta. Si exige una cadena larga de servicios externos, una incidencia menor puede expulsar todos los backends a la vez. Separe disponibilidad básica de diagnóstico profundo, use umbrales para evitar cambios de estado nerviosos y revise qué hace el producto cuando todos los nodos fallan.

También importa el retorno a servicio. Un proceso que acaba de arrancar puede aceptar conexiones antes de calentar cachés o completar migraciones. Darlo por sano después de una única respuesta feliz puede provocar una oscilación entre dentro y fuera de rotación.

Algoritmos sin promesas falsas

Los nombres ayudan a razonar, pero no garantizan un reparto perfecto:

Pruebe con el patrón real: duración de conexiones, tamaño de respuestas, picos y proporción de endpoints caros. El algoritmo es una hipótesis operativa, no un contrato de equidad.

TLS y persistencia de sesión

Terminar TLS en el balanceador centraliza certificados y permite que la capa de aplicación lea la solicitud. Simplifica renovaciones y reglas, pero convierte la frontera TLS en una decisión de seguridad. Si la red interna no es confiable o atraviesa dominios distintos, cifre también hacia los backends y valide sus certificados.

La persistencia —también llamada afinidad o sticky session— intenta mantener a un cliente en el mismo backend, mediante cookie, IP u otro identificador. Puede ser necesaria para una aplicación heredada que guarda sesión en memoria. El coste aparece durante fallos, despliegues y cambios de capacidad: el estado queda pegado a un nodo que puede desaparecer.

Cuando sea viable, saque la sesión del proceso y use un almacenamiento compartido adecuado. No elimina todos los problemas, pero permite que cualquier backend atienda la siguiente solicitud. Si activa persistencia, mida la distribución y documente qué ocurrirá cuando el backend asignado quede fuera.

DNS, proxy inverso y balanceador no son sinónimos

DNS traduce un nombre a uno o varios destinos y puede participar en un reparto global. Sin embargo, las respuestas pueden quedar en caché hasta que venza su TTL y DNS no observa cada solicitud HTTP. Por eso es útil para elegir región o punto de entrada, pero no sustituye automáticamente la selección rápida entre backends dentro de una aplicación.

Un proxy inverso recibe tráfico en nombre de servidores internos. Puede terminar TLS, aplicar cabeceras, caché o rutas. Un balanceador añade la decisión de distribuir entre varios destinos. Muchos productos cumplen ambos papeles, pero describir la función evita comprar una etiqueta sin entender el comportamiento.

Alta disponibilidad sin mover el punto único de fallo

Coloque instancias del balanceador en más de un dominio de fallo o use un servicio gestionado cuya arquitectura cubra esa redundancia. Después distribuya los backends entre zonas independientes y compruebe que cada zona conserva capacidad suficiente cuando otra desaparece.

Revise también DNS, certificados, reglas de red, secretos, configuración y observabilidad. Dos balanceadores con el mismo archivo defectuoso fallan juntos. Tres servidores que dependen de una sola base de datos no ofrecen continuidad completa. La redundancia útil necesita fallos independientes y un procedimiento probado para operar con capacidad reducida.

Qué observar y cómo probarlo

Como mínimo, mida conexiones activas, solicitudes, latencia en el balanceador y en los backends, errores del cliente y del servidor separados por origen, fallos de conexión, timeouts, backends sanos y cambios de estado. La latencia se prueba: añada un identificador de solicitud para seguir una operación a través de la cadena.

La prueba debe incluir cuatro escenas: carga normal, pico sostenido, backend lento y backend caído. Después retire una instancia del balanceador o una zona completa. Verifique que no solo responde la página de inicio: pruebe login, escritura, lectura, subida de archivos y cualquier checkout o llamada que mantenga ventas.

Antes de decidir que ya necesita un balanceador, confirme el cuello de botella. Si la aplicación vive en una sola máquina por simplicidad y tolera una ventana de mantenimiento, quizá convenga primero mejorar copias, restauración y monitorización.

Si cada caída corta ingresos, los despliegues exigen interrupción o un servidor ya limita la capacidad, el balanceador deja de ser adorno y pasa a ser parte de la ruta crítica.