Qué es un balanceador de carga y para qué sirve

Todo servidor tiene un límite: CPU, memoria y conexiones simultáneas. Cuando el tráfico supera ese límite, las respuestas se vuelven lentas y, en el peor caso, el servicio se cae. Hay dos caminos: cambiar el servidor por uno más grande (escalado vertical) o poner varios servidores que se reparten el trabajo (escalado horizontal). El balanceador de carga es la pieza que hace posible el segundo camino.

¿Qué es un balanceador de carga?#

Un balanceador de carga (load balancer) es un componente que recibe las solicitudes de los clientes y las reenvía a un grupo de servidores que ofrecen el mismo servicio. Para quien accede, hay una sola dirección, como api.ejemplo.com. Detrás hay varios servidores y el cliente no sabe cuál respondió.

Puede ser software (nginx, HAProxy, Envoy), un servicio del proveedor de nube o un equipo dedicado. La idea es la misma en los tres: un punto de entrada, varios destinos.

¿Cómo funciona un balanceador de carga?#

Cada solicitud sigue cuatro pasos:

1. El cliente resuelve el nombre del dominio mediante DNS y se conecta a la dirección del balanceador.
2. El balanceador consulta su lista de servidores sanos.
3. Elige uno según el algoritmo configurado.
4. Reenvía la solicitud, recibe la respuesta y se la devuelve al cliente.

El paso 2 es el que da resiliencia. El balanceador vigila la salud de los servidores y saca de la rotación a los que no responden. Hay dos formas de comprobarlo: la activa, en la que el balanceador hace pruebas periódicas (por ejemplo, una solicitud a /health), y la pasiva, en la que observa las respuestas reales y marca como fallido al servidor que devuelve errores. El nginx de código abierto hace solo la comprobación pasiva (la activa es una función de NGINX Plus): tras fallos dentro de una ventana de tiempo (max_fails y fail_timeout), evita ese servidor durante un periodo.

¿Qué algoritmos de balanceo existen?#

El algoritmo decide qué servidor recibe la siguiente solicitud. Los tres más usados:

Hay variantes con pesos, que envían más tráfico a los servidores más potentes. El IP hash es una forma de "sesión fija" (sticky session), pero tiene un límite: los clientes detrás del mismo NAT comparten IP y acaban todos en el mismo servidor.

¿Cuál es la diferencia entre capa 4 y capa 7?#

El balanceo de capa 4 trabaja a nivel de transporte (TCP/UDP). Solo mira IP y puerto, sin entender el contenido. Por eso es rápido y sirve para cualquier protocolo, de bases de datos a servidores de juegos.

El de capa 7 trabaja a nivel de aplicación (HTTP). Lee las cabeceras, la ruta y las cookies, y puede decidir con base en ellas: enviar /api a un grupo de servidores y /static a otro, por ejemplo. A cambio, hace más trabajo por solicitud. Este tipo también suele terminar el TLS, lo que lo acerca a un proxy inverso.

¿Cómo montar un balanceador con nginx?#

El bloque upstream lista los servidores y proxy_pass apunta al grupo. Este ejemplo balancea por menor número de conexiones, con comprobación pasiva:

http {
    upstream app {
        least_conn;
        server 10.0.0.11:3000 max_fails=3 fail_timeout=30s;
        server 10.0.0.12:3000 max_fails=3 fail_timeout=30s;
        server 10.0.0.13:3000 backup;
    }

    server {
        listen 80;

        location / {
            proxy_pass http://app;
            proxy_set_header Host $host;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        }
    }
}

Sin la línea least_conn;, nginx usa round-robin. El servidor marcado como backup solo recibe tráfico cuando los demás no están disponibles. Cambia las IP por las de tus servidores y recarga con nginx -s reload.

¿Qué problemas trae el balanceo?#

Repartir tráfico entre servidores exige que sean intercambiables. Lo que hay que cuidar:

• Estado en memoria. Si el servidor A guarda la sesión del usuario en su propia memoria y la siguiente solicitud llega a B, el usuario pierde la sesión autenticada. La solución es guardar la sesión fuera del proceso, en una base de datos o en Redis, o usar sesión fija.
• Archivos locales. Un archivo subido al disco del servidor A no existe en B. Usa almacenamiento compartido, como un object storage.
• Tareas programadas. Un cron que corre en todos los servidores se ejecuta N veces. Ejecútalo solo en uno.
• El balanceador también falla. Si hay una única instancia, es un punto único de fallo.

¿Cuándo no necesitas un balanceador de carga?#

Si un servidor atiende el tráfico con holgura y una caída corta es aceptable, el balanceador solo añade complejidad y costo. La mayoría de bots y sitios pequeños está en ese caso. Antes de balancear, conviene medir CPU, memoria y latencia y ver si aumentar la RAM del servidor lo resuelve. Una CDN delante del contenido estático también quita mucha carga al servidor de origen sin necesitar un segundo servidor.

Cómo hacerlo en Square Cloud#

En Square Cloud, el balanceo es una función del dominio, sin nginx que configurar ni balanceador que mantener. Sube el mismo código a dos o más aplicaciones, define un dominio personalizado en la primera (creando en tu registrador los registros DNS que muestra el panel) y agrega el mismo dominio en las demás. A partir de ahí, las solicitudes se turnan en round-robin entre ellas, y una aplicación que se cae sale de la rotación por failover pasivo, ya que no hay health check activo.

La cantidad de aplicaciones por dominio depende del plan: hasta 2 en Standard (desde R$44,99 al mes), hasta 5 en Pro y hasta 10 en Enterprise, sin cobro por solicitud. Solo un dominio personalizado entra en el balanceo, no el subdominio squareweb.app. Y quien decide cuántas aplicaciones quedan detrás del dominio eres tú: ese número no cambia solo con el tráfico.

Lo visto en la sección anterior aplica aquí. No hay sticky session y cada aplicación tiene su propio disco, así que guarda las sesiones en Redis o en otra base de datos, envía los archivos subidos a Blob y deja las tareas programadas en una sola aplicación. Si el cuello de botella es un único proceso, aumentar la RAM de la aplicación en su configuración puede bastar. Consulta los pasos en load balancing y los límites de cada plan en precios.