Programación · Servidores · Redes
¿Qué es un balanceador de carga?
Un solo servidor tiene un límite. Cuando el tráfico supera lo que una sola máquina puede atender — o cuando, sencillamente, no puedes permitirte que el sitio se caiga si esa máquina falla — pones en marcha varias copias y colocas un balanceador de carga delante de ellas. Esta guía explica qué es un balanceador de carga, cómo decide adónde va cada petición y cómo se relaciona con el proxy inverso que quizá ya conozcas.
La idea central: repartir el trabajo
Un balanceador de carga es un componente que recibe las peticiones entrantes y las distribuye entre un pool de servidores backend — normalmente copias idénticas de la misma app. Para el visitante hay una sola dirección; detrás, el balanceador reparte el tráfico discretamente para que ningún servidor se sature. Resuelve dos problemas a la vez: escala (atender más tráfico del que podría una sola máquina) y disponibilidad (si un servidor muere, los demás siguen sirviendo).
Este segundo punto es el que se infravalora. Un balanceador de carga comprueba continuamente si cada backend está sano y deja de enviar tráfico a los que dejan de responder. Un único servidor en mal estado ya no tumba todo el sitio: su parte de peticiones se enruta sin más hacia los servidores sanos.
Cómo decide: los algoritmos de balanceo
El balanceador de carga necesita una regla para elegir qué servidor atiende la siguiente petición. Los más comunes son:
- Round-robin — entregar cada nueva petición al siguiente servidor por turnos. Simple y equitativo cuando los servidores son parecidos.
- Least connections (menos conexiones) — enviar la petición al servidor que tenga ahora mismo menos conexiones activas. Mejor cuando las peticiones varían en coste.
- IP hash — elegir el servidor según la IP del cliente, para que el mismo visitante caiga siempre en el mismo backend (útil para la persistencia de sesión).
- Ponderado (weighted) — dar a los servidores más potentes una mayor parte del tráfico.
Layer 4 vs Layer 7
Los balanceadores de carga trabajan en uno de dos niveles. Un balanceador de Layer 4 (transporte) enruta por dirección IP y puerto sin mirar dentro del tráfico — rápido e independiente del protocolo. Un balanceador de Layer 7 (aplicación) entiende HTTP, así que puede enrutar por ruta de URL, nombre de host o cabeceras, terminar TLS y tomar decisiones más inteligentes. El Layer 7 es la opción habitual para apps web; el Layer 4 gana cuando la velocidad bruta importa más que un enrutamiento consciente del contenido.
Balanceador de carga vs proxy inverso
Esta es la pregunta que confunde a la gente. La respuesta honesta: el balanceo de carga es una de las tareas que un proxy inverso puede hacer. Un proxy inverso es la idea más amplia — un servidor que se sitúa delante de tus backends y puede enrutar, cachear, terminar TLS y repartir la carga. Un «balanceador de carga» es esa misma puerta de entrada centrada en la tarea de reparto. En la práctica, las herramientas se solapan: Nginx, HAProxy y Caddy actúan todos como balanceadores de carga, y un balanceador de carga en la nube es una versión gestionada del mismo papel.
Dónde se ejecutan los balanceadores de carga
Te los encuentras en varias formas. Los balanceadores de carga de software — Nginx, HAProxy, Traefik — se ejecutan en un servidor que controlas tú. Los balanceadores de carga en la nube (AWS, Google Cloud, Azure) son servicios gestionados que configuras en lugar de alojar. Y en plataformas de contenedores como Kubernetes, el balanceo de carga viene integrado y reparte el tráfico entre los pods a medida que aparecen y desaparecen. Uses el que uses, querrás más de un backend — normalmente unos cuantos servidores ejecutando copias idénticas de la app.
En resumen
Un balanceador de carga reparte las peticiones entrantes entre varios servidores para que el sistema pueda atender más tráfico y sobrevivir a la caída de un servidor. Elige un backend mediante un algoritmo como round-robin o least connections, comprueba la salud de cada servidor y puede trabajar en la capa de transporte (L4) o de aplicación (L7). Piénsalo como la tarea de reparto de un proxy inverso — la pieza que convierte una app en una sola máquina en un servicio que escala y se mantiene en línea.