Diagrama de balanceador de carga: capa 4 vs. capa 7, health checks y algoritmos

«Pon un balanceador de carga delante» es la frase más repetida en diseño de sistemas, y esconde un puñado de decisiones que importan en producción: en qué capa trabaja, cómo elige un backend, cómo sabe que un backend está sano y qué pasa con las peticiones en curso cuando se retira uno.

Este artículo repasa esas decisiones y dibuja el montaje de dos niveles al que acaban llegando la mayoría de los despliegues grandes: un balanceador de capa 4 delante de una flota de proxies de capa 7.

Capa 4 vs. capa 7

La diferencia que duele: un balanceador de capa 4 reparte conexiones, no peticiones. Con HTTP/2 o gRPC, un cliente abre una sola conexión de larga duración y envía miles de peticiones por ella, que acaban todas en el mismo backend. Balancear bien gRPC requiere un proxy de capa 7 o balanceo de carga en el cliente.

Por qué dos niveles

Los montajes grandes suelen apilar ambos. Un nivel de capa 4 tiene las direcciones IP públicas, absorbe avalanchas de conexiones y reparte las conexiones entre una flota de proxies de capa 7 haciendo hash de cada flujo. Los proxies terminan TLS, aplican las reglas de enrutamiento y reparten cada petición entre los pools de backends.

Cada nivel escala por su cuenta: el de capa 4 según paquetes y conexiones, la flota de proxies según peticiones y handshakes TLS. Separarlos también limita el radio de impacto, porque un mal cambio de configuración de los proxies afecta a los proxies de detrás de un nivel, no a las direcciones a las que se conectan los usuarios. Y como los proxies no tienen estado y comparten una única configuración, añadir uno es simplemente añadir capacidad.

Algoritmos de balanceo

Least request con dos opciones aleatorias es una buena opción por defecto para servicios HTTP. La documentación de balanceadores de Envoy lo describe así: elige dos hosts al azar (dos por defecto) y envía la petición al que tenga menos peticiones activas. Las investigaciones de Mitzenmacher y otros muestran que es casi tan bueno como revisar todos los backends, sin su coste. El hashing consistente, como ring hash o el algoritmo Maglev, mantiene la misma clave en el mismo backend y solo mueve una pequeña parte de las claves cuando cambian los backends, que es lo que quieren las cachés.

Health checks

Un balanceador debe dejar de enviar tráfico a los backends que no pueden atenderlo. Dos mecanismos trabajan juntos:

• Comprobaciones activas: el balanceador llama a un endpoint de salud, por ejemplo GET /healthz cada 5 segundos, y retira un backend tras varios fallos consecutivos.
• Comprobaciones pasivas (outlier detection): el balanceador observa las respuestas reales, expulsa un backend que devuelve errores o agota los timeouts y lo vuelve a admitir tras un periodo de enfriamiento.

Haz que el endpoint de salud sea honesto pero barato. Si comprueba todas las dependencias, una sola base de datos lenta vuelve insanos a todos los backends a la vez y el balanceador se queda sin sitio adonde mandar el tráfico. Comprueba lo que esta instancia necesita para atender peticiones y deja las dependencias compartidas al manejo de errores de la propia aplicación.

Draining y sesiones fijas

Cuando se retira un backend por un despliegue o una reducción de escala, debe dejar de recibir peticiones nuevas pero terminar las que tiene en curso. Configura un periodo de draining (los balanceadores en la nube lo llaman deregistration delay) más largo que tu petición normal más lenta, y haz que la aplicación deje de aceptar trabajo nuevo al apagarse.

Las sesiones fijas (sticky sessions) envían a un usuario al mismo backend cada vez, normalmente con una cookie. Ayudan cuando el estado vive en la memoria de un servidor y perjudican a todo lo demás: carga desigual, sesiones perdidas cuando muere un backend, despliegues más difíciles. Lleva el estado de sesión a un almacén compartido y desactiva la afinidad donde puedas.

Más allá de una región

Todo lo anterior ocurre dentro de un solo sitio. Repartir a los usuarios entre regiones es otra capa: el enrutamiento por DNS que responde con la región sana más cercana (enrutamiento por latencia o por geolocalización), o anycast, en el que muchos sitios anuncian la misma dirección IP y el enrutamiento de Internet lleva a cada usuario a uno cercano. El balanceo global elige la región; los dos niveles de este artículo eligen el servidor. Haz que las señales de salud fluyan hacia arriba, para que una región cuyos proxies no llegan a sus pools deje de recibir usuarios en lugar de devolverles errores.

El diagrama de arquitectura

Cómo leerlo:

• Izquierda: los clientes resuelven un nombre DNS y abren conexiones TCP en el puerto 443 hacia el balanceador de capa 4.
• Centro: el nivel de capa 4 reparte las conexiones entre la flota de proxies por hash de flujo. El marco indica que todos los proxies ejecutan la misma configuración.
• Derecha: los proxies terminan TLS y enrutan cada petición por ruta: /api/orders y /api/search a sus pools, /static a un bucket.
• El bloque Markdown contiene la tabla de enrutamiento, el algoritmo de cada pool y la configuración de los health checks, detalles que normalmente solo viven en un archivo de configuración.

Qué etiquetar en un diagrama de balanceador de carga

• La capa y el protocolo en cada salto: TCP 443, HTTP/2, gRPC.
• Dónde termina TLS. Decide qué puede ver cada nivel y dónde viven los certificados.
• El algoritmo de cada pool, y la clave de hash si usas hashing.
• Ruta, intervalo y umbral de los health checks.
• La configuración de draining y de afinidad, si la hay.

El diagrama de arquitectura de un API gateway trata las funciones de capa 7 que se suman al enrutamiento, el diagrama de ingress de Kubernetes muestra las mismas ideas dentro de un clúster y el diagrama de topología de red sitúa los balanceadores en la red más amplia.

Constrúyelo en Archboard

1. Inicia sesión con Google o GitHub y crea un diagrama.
2. Añade una Persona del pack Modelo C4 para los clientes, y un DNS y un Balanceador de carga del pack Red.
3. Añade un Marco del pack Básico para la flota de proxies con dos nodos Contenedor dentro.
4. Añade dos nodos Instancia de cómputo y un nodo Almacenamiento de objetos del pack Nube para los pools y el bucket.
5. Etiqueta las aristas con protocolos y rutas, y añade un bloque Markdown del pack Básico con la tabla de enrutamiento y los health checks.

El ejemplo usa 10 nodos de diagrama, dentro del plan Free.

Preguntas frecuentes

¿Qué diferencia hay entre un balanceador de capa 4 y uno de capa 7? Un balanceador de capa 4 distribuye conexiones TCP o UDP sin mirar dentro de ellas. Uno de capa 7 entiende HTTP, así que puede enrutar por ruta o por host y repartir cada petición por separado.

¿Qué algoritmo de balanceo debo usar? Least request con dos opciones aleatorias es una opción por defecto sólida para HTTP. Usa hashing consistente cuando la misma clave deba llegar al mismo backend, como en las cachés.

¿Por qué mi servicio gRPC envía todo el tráfico a un solo pod? Porque gRPC usa conexiones HTTP/2 de larga duración y un balanceador de capa 4 reparte conexiones, no peticiones. Pon un proxy de capa 7 en medio o usa balanceo de carga en el cliente.

¿Qué debe comprobar un endpoint de health check? Que esta instancia puede atender peticiones: el proceso está en marcha y sus propios recursos críticos están disponibles. Evita comprobar dependencias compartidas que harían fallar a todos los backends a la vez.

¿Son buena idea las sesiones fijas? Solo cuando el estado no puede salir del servidor. Provocan carga desigual y sesiones perdidas cuando hay fallos; un almacén de sesiones compartido suele ser mejor.

Empieza gratis — un puesto, sin tarjeta de crédito.