Balanceo de carga con HAProxy y Nginx para alta disponibilidad

La alta disponibilidad no es un lujo: es un requisito operativo básico para cualquier servicio empresarial que no pueda permitirse tiempos de inactividad. Pero alta disponibilidad sin balanceo de carga es una arquitectura incompleta. El balanceador de carga es el componente que distribuye las peticiones entrantes entre múltiples instancias de backend, detecta fallos y redirige el tráfico a instancias sanas, y proporciona una capa de abstracción que permite escalar horizontalmente los servicios sin cambiar la configuración de los clientes.

HAProxy y Nginx son las dos herramientas de balanceo de carga más utilizadas en entornos empresariales y de cloud nativo. HAProxy es un proxy TCP/HTTP de alto rendimiento especializado en balanceo de carga, con un modelo de configuración declarativo muy potente y métricas de operación excelentes. Nginx es un servidor web y proxy inverso que también ofrece capacidades de balanceo de carga, especialmente popular en arquitecturas de microservicios y como entrada de tráfico HTTP/HTTPS.

Este artículo compara ambas herramientas, explica sus algoritmos de balanceo, salud de backends, terminación SSL/TLS, sesiones persistentes y cómo construir una arquitectura de alta disponibilidad redundante con Keepalived.

HAProxy: arquitectura y casos de uso

HAProxy (High Availability Proxy) es un proyecto de código abierto creado por Willy Tarreau que ha evolucionado hasta convertirse en el estándar de facto del balanceo de carga en entornos de alta exigencia. Es usado por empresas como GitHub, Reddit, Stack Overflow y miles de instalaciones empresariales críticas. Su modelo es de proceso único con event loop, lo que le permite manejar cientos de miles de conexiones simultáneas con consumo de recursos muy eficiente.

HAProxy opera en capa 4 (TCP) y capa 7 (HTTP/HTTPS). En modo TCP balancea cualquier protocolo sobre TCP/UDP sin inspeccionar el contenido; es ideal para bases de datos, servicios SMTP, o cualquier protocolo binario. En modo HTTP realiza inspección del tráfico HTTP, permite enrutamiento basado en headers, URL, cookies, métodos HTTP y parámetros de query; es el modo usado para aplicaciones web y APIs REST.

Nginx como balanceador de carga

Nginx (pronunciado 'engine-x') nació como servidor web de alto rendimiento y ha evolucionado hasta convertirse en un proxy inverso completo con capacidades de balanceo de carga, caché, terminación SSL y streaming de vídeo. Su módulo upstream permite definir grupos de servidores backend y distribuir las peticiones entre ellos. En la versión comercial Nginx Plus se añaden características avanzadas como monitorización en tiempo real, DNS service discovery dinámico y persistencia de sesión por cookies.

Nginx es especialmente popular en arquitecturas Kubernetes como Ingress Controller (nginx-ingress-controller es uno de los más usados), en despliegues de microservicios donde actúa como API gateway y proxy inverso, y en entornos donde ya existe Nginx como servidor web y se quiere consolidar la funcionalidad de balanceo en el mismo componente.

Algoritmos de balanceo: comparativa y elección

Elegir el algoritmo de balanceo correcto impacta directamente en el rendimiento y la distribución de carga. Los más relevantes, disponibles en ambas herramientas aunque con nomenclatura diferente, son:

• Round Robin: distribuye las peticiones de forma circular entre los backends. Simple y efectivo cuando todos los backends tienen capacidad similar y las peticiones tienen duración homogénea.
• Weighted Round Robin: igual que Round Robin pero con peso asignado a cada backend. Útil cuando los servidores tienen capacidades diferentes (por ejemplo, un servidor con el doble de CPU recibe el doble de peticiones).
• Least Connections (leastconn en HAProxy, least_conn en Nginx): envía cada nueva petición al backend con menos conexiones activas. Ideal para peticiones de larga duración o con tiempos de respuesta variables (APIs, websockets, sesiones largas).
• Source IP Hash (iphash en Nginx, balance source en HAProxy): asigna cada cliente a un backend específico basándose en un hash de su IP. Garantiza persistencia de sesión sin cookies, pero puede generar distribución desigual si muchos clientes comparten IP (NAT corporativo).
• URI Hash: en HAProxy, balance uri dirige peticiones con la misma URI al mismo backend, útil para optimizar la caché.
• Random: útil para backends con latencias muy variables o en entornos con descubrimiento dinámico de servicios.

Health checks: la base de la alta disponibilidad

Un balanceador de carga sin health checks es una ilusión de alta disponibilidad. Si un backend falla y el balanceador sigue enviándole tráfico, los usuarios experimentan errores o timeouts. Los health checks permiten al balanceador detectar backends no disponibles y retirarlos del pool automáticamente.

Tipos de health checks en HAProxy

HAProxy ofrece health checks muy sofisticados. El check TCP básico verifica que el puerto está abierto. El check HTTP envía una petición HTTP específica (configurable: método, URL, headers esperados) y verifica que la respuesta tiene un código de estado dentro de un rango válido. El check de agente permite que el propio backend informe sobre su estado y peso a través de un protocolo simple. También soporta checks externos personalizados para validaciones más complejas.

Parámetros críticos de configuración: inter (intervalo entre checks), fall (número de checks fallidos consecutivos para marcar backend como down), rise (número de checks exitosos consecutivos para marcar backend como up de nuevo), timeout check (timeout del propio check). Una configuración típica podría ser: check inter 2s fall 3 rise 2, que marca un backend como down tras 6 segundos de fallos y lo recupera tras 4 segundos de éxitos.

Terminación SSL/TLS y offloading

En la mayoría de las arquitecturas empresariales, el balanceador de carga actúa como punto de terminación SSL/TLS. Esto significa que la comunicación entre el cliente y el balanceador va cifrada (HTTPS), pero la comunicación entre el balanceador y los backends puede ir en texto plano por una red interna confiable. Este modelo simplifica la gestión de certificados (centralizada en el balanceador) y reduce la carga de procesamiento criptográfico en los backends.

Configurar TLS correctamente en HAProxy requiere definir un certificado (en formato PEM concatenado: certificado + cadena + clave privada), los protocolos permitidos (solo TLS 1.2 y 1.3 en entornos modernos; TLS 1.0 y 1.1 deben deshabilitarse), los cipher suites (siguiendo las recomendaciones de Mozilla SSL Config Generator o similares) y el comportamiento de HSTS si aplica. En Nginx la configuración es análoga con las directivas ssl_certificate, ssl_protocols y ssl_ciphers.

SNI y certificados múltiples

En un balanceador que sirve múltiples dominios, SNI (Server Name Indication) permite usar un certificado diferente por nombre de dominio en el mismo listener. HAProxy soporta SNI desde hace años; basta con poner múltiples certificados en el directorio configurado en el frontend y HAProxy selecciona el correcto automáticamente. En Nginx se usan múltiples bloques server con sus respectivos ssl_certificate. Los certificados wildcard y los SAN (Subject Alternative Name) permiten cubrir múltiples subdominios con un solo certificado.

Persistencia de sesión (sticky sessions)

Muchas aplicaciones web tienen estado en sesión del servidor: el usuario se autentica, la sesión se almacena en el backend que le atendió, y las siguientes peticiones deben llegar al mismo backend para no perder el contexto. La persistencia de sesión (sticky sessions o session affinity) garantiza que las peticiones de un mismo cliente se envíen siempre al mismo backend.

HAProxy ofrece varios mecanismos de persistencia: mediante cookies (insert, prefix o rewrite), mediante source IP hash, mediante header personalizado o mediante stick tables que pueden compartirse entre múltiples instancias de HAProxy. Las stick tables son especialmente potentes: permiten almacenar estado por IP de origen o por cookie, incluyendo contadores de conexiones por segundo para rate limiting, y sincronizarlas entre instancias en HA.

En Nginx, la persistencia se logra mediante sticky cookie (Nginx Plus) o mediante ip_hash. La versión open source de Nginx tiene soporte limitado de persistencia; para entornos de producción exigentes, HAProxy tiene ventaja en esta área o es necesario Nginx Plus.

Alta disponibilidad del propio balanceador: Keepalived y VRRP

El balanceador de carga es un single point of failure si solo hay una instancia. Para hacer el propio balanceador altamente disponible, se usa Keepalived con el protocolo VRRP (Virtual Router Redundancy Protocol). El modelo consiste en dos (o más) instancias de HAProxy o Nginx en servidores diferentes, con Keepalived gestionando una IP virtual (VIP) que siempre apunta al balanceador activo.

En el modo activo-pasivo, solo una instancia sirve tráfico en cada momento. El servidor MASTER tiene la VIP asignada y anuncia su prioridad mediante mensajes VRRP. El BACKUP monitoriza al MASTER; si deja de recibir anuncios VRRP (por caída del servidor o del proceso HAProxy), asume la VIP en cuestión de segundos (el failover típico es de 1-3 segundos con configuración agresiva). En el modo activo-activo, ambas instancias sirven tráfico con VIPs diferentes y DNS o un balanceador de nivel superior distribuye entre ellas.

Configuración básica de Keepalived

La configuración de Keepalived se define en /etc/keepalived/keepalived.conf. Los parámetros más importantes son: state (MASTER o BACKUP), interface (interfaz de red donde operar VRRP), virtual_router_id (identificador único del grupo, igual en todos los nodos), priority (mayor prioridad = MASTER, por ejemplo 101 en el master y 100 en el backup), advert_int (intervalo de anuncios VRRP, 1 segundo por defecto) y virtual_ipaddress (la VIP a gestionar). Adicionalmente, se puede configurar un track_script que monitoriza el proceso de HAProxy y reduce la prioridad del nodo si el proceso falla, forzando el failover aunque el servidor esté vivo.

Rate limiting y protección DDoS básica en el balanceador

Los balanceadores de carga modernos son también el primer punto donde aplicar protección contra abuso y ataques de denegación de servicio. HAProxy puede limitar el número de peticiones por IP por segundo usando stick tables y ACLs: una tabla con tipo ip rate(100/s) registra el contador de peticiones por IP y una ACL puede denegar o redirigir a quien supere el umbral. Este mecanismo es efectivo contra ataques de baja intensidad o scraping agresivo.

Nginx ofrece las directivas limit_req_zone y limit_req para rate limiting a nivel de servidor o de location, con control de burst y nodelay. La combinación de ambas herramientas con soluciones de WAF (Web Application Firewall) como ModSecurity o con servicios cloud de CDN y DDoS protection (Cloudflare, Akamai, AWS Shield) cubre el espectro completo de protección en capas.

Logging, métricas y observabilidad

Un balanceador bien configurado es también una fuente de información valiosísima. HAProxy expone un socket de estadísticas en tiempo real (stats socket) que permite consultar el estado de todos los frontends, backends y servidores, y tiene una interfaz web de estadísticas integrada. Sus logs en formato estándar (accesibles vía syslog) incluyen por cada conexión: IP cliente, frontend, backend, servidor seleccionado, tiempos de conexión, tiempo de respuesta, código de respuesta y bytes transferidos.

Nginx genera access logs y error logs configurables. La integración con stacks de observabilidad como ELK (Elasticsearch, Logstash, Kibana), Loki+Grafana o Datadog se hace mediante exporters o agentes de log. Para métricas nativas, HAProxy Exporter (Prometheus) y Nginx Prometheus Exporter permiten integrar ambas herramientas en un stack de monitorización Prometheus/Grafana, exponiendo métricas como conexiones activas, tasa de peticiones, tiempos de respuesta por backend y tasa de errores.

Comparativa HAProxy vs Nginx: cuándo usar cada uno

• HAProxy: preferible para balanceo de carga TCP puro (bases de datos, servicios no-HTTP), cuando se necesitan health checks avanzados o stick tables, en entornos de muy alta exigencia de rendimiento por conexión, o cuando el equipo tiene mayor experiencia con su modelo de configuración.
• Nginx: preferible cuando también se necesita servidor web o caché de contenido estático en el mismo nodo, en arquitecturas Kubernetes como Ingress Controller, cuando se necesita streaming de vídeo (HLS, DASH) con caché, o en entornos donde Nginx ya está presente como servidor de aplicaciones.
• Combinación de ambos: un patrón frecuente es usar HAProxy como balanceador de nivel 4 (TCP) en el edge con VRRP para HA, y Nginx como proxy inverso HTTP en la capa de aplicación, cada uno haciendo lo que mejor sabe hacer.

La alta disponibilidad real no se consigue con un único servidor potente: se consigue diseñando para el fallo desde el principio. El balanceador de carga es el componente que hace posible esa resiliencia a nivel de capa de aplicación.

Conclusión

HAProxy y Nginx son herramientas maduras, fiables y extremadamente bien documentadas que cubren la gran mayoría de los casos de uso de balanceo de carga empresarial. No hay una respuesta única sobre cuál usar: depende del contexto, los requisitos específicos y las capacidades del equipo. Lo que sí es universal es la necesidad de diseñar la alta disponibilidad del propio balanceador desde el principio, no como un añadido posterior.

Si estás iniciando un nuevo proyecto o revisando una arquitectura existente, dedica tiempo a revisar los health checks (muchas veces mal configurados en sistemas heredados), la gestión del ciclo de vida de los certificados TLS y la observabilidad del balanceador. Estas tres áreas son las que generan más incidencias en producción y las que aportan mayor valor al mejorarlas.