Los equipos que llegan a Cloudflare Load Balancing desde un AWS ALB a menudo configuran todo correctamente y luego encuentran un comportamiento que su modelo mental no explica: un cliente sigue llegando al mismo origen durante minutos después de haber fallado, la distribución de carga parece desigual entre instancias y la conmutación por error tarda más de lo que sugieren las comprobaciones de estado. El producto funciona, pero de manera diferente a lo esperado, porque opera en el DNS, no en la capa de transporte o aplicación.
Cómo funciona realmente el equilibrio de carga de Cloudflare
Cloudflare Load Balancing es un servicio de distribución de tráfico que toma medidas en la resolución de nombres. Cuando un cliente realiza una consulta de DNS para el dominio equilibrado, Cloudflare Authoritative evalúa qué orígenes están en buen estado, aplica la regla de dirección configurada y devuelve la IP del origen seleccionado. Desde ese punto, el cliente se conecta directamente a la fuente (o al PoP de Cloudflare, si el registro es proxy) y todas las solicitudes de esa sesión van a ese destino hasta que el TTL caduque y el cliente necesite resolver el nombre nuevamente.
Esto significa que la distribución de la carga se realiza mediante resolución DNS, no mediante solicitud HTTP. A dos clientes concurrentes que resuelven el dominio en el mismo segundo se les pueden asignar orígenes diferentes. Un único cliente que resuelve el nombre una vez y mantiene la conexión abierta permanece en el mismo origen indefinidamente. Si hay diez instancias ejecutándose detrás de un ALB, el ALB distribuye las solicitudes entre ellas con cada nueva solicitud. Con Cloudflare LB, la granularidad es el cliente, no la solicitud.
El sistema de comprobaciones de estado corrige la ruta cuando falla una fuente. Cloudflare realiza comprobaciones de estado activas desde múltiples PoP (no desde un solo punto) contra cada origen registrado. Cuando el porcentaje de fallas excede el umbral configurado, la fuente se marca como degradada y se elimina del grupo de resolución. Los nuevos clientes que resuelven su nombre después de esta etiqueta ya no reciben la IP de la fuente problemática. Los clientes que ya han resuelto el nombre y tienen la IP en caché continúan intentando conectarse hasta que caduque el TTL. Por lo tanto, la conmutación por error tiene dos componentes de latencia: el tiempo para que la verificación de estado detecte y marque el error, y el TTL restante de los clientes que ya se han resuelto.
El modelo de precios y lo que cubre
El plan básico de Cloudflare Load Balancing cuesta $5 por mes e incluye dos grupos de origen, cinco orígenes por grupo y comprobaciones de estado configurables. El cargo adicional de $0,50 por cada 500.000 consultas de verificación de estado se aplica al volumen generado por las comprobaciones: con intervalos de 60 segundos y distribución en múltiples PoP, el volumen mensual aumenta rápidamente, pero todavía está en un rango razonable para configuraciones activas-pasivas con grupos pequeños.
Para una configuración activa-pasiva simple (un grupo principal con dos fuentes y un grupo alternativo), la factura mensual es inferior a $10 en la mayoría de los escenarios. Para arquitecturas más elaboradas con múltiples grupos regionales y controles de estado granulares por PoP, el costo aumenta, pero sigue siendo competitivo en comparación con la sobrecarga operativa de administrar la conmutación por error manual entre regiones.
Geo Steering: enrutamiento por origen geográfico del cliente
Geo Steering es la funcionalidad que convierte el Load Balancer en una verdadera capa de enrutamiento geográfico. La configuración asocia regiones (continentes o países específicos) con grupos de origen. Los clientes brasileños resuelven el dominio y reciben la IP del origen en São Paulo. Los clientes europeos reciben la IP del origen en Frankfurt. La autoridad de Cloudflare identifica la ubicación geográfica del solucionador que realizó la consulta y devuelve la respuesta del grupo correspondiente.
Cuando el grupo regional deja de estar disponible (todos los orígenes en él están marcados como degradados), Cloudflare pasa automáticamente al grupo de respaldo global configurado. El cliente europeo cuyo pool de Frankfurt está afuera recibe la IP de São Paulo o de cualquier otro pool que esté sano, sin intervención manual. Este mecanismo de respaldo automático es lo que hace que Geo Steering sea útil para la alta disponibilidad geográfica, no solo para la optimización de la latencia.
La afinidad de sesión de cookies complementa el enrutamiento geográfico para los casos en los que la misma instancia necesita atender al mismo cliente en múltiples resoluciones DNS. Cloudflare inyecta una cookie en la respuesta HTTP que identifica el origen seleccionado y Load Balancer usa esta cookie para devolver al cliente al mismo origen en resoluciones posteriores, incluso si el TTL ya ha caducado. Para aplicaciones sin estado esto es irrelevante; Para las sesiones que almacenan contexto en la memoria de la instancia, es el mecanismo que evita la interrupción de la experiencia durante las reresoluciones TTL normales.
La distinción que cambia el diseño de la arquitectura
Un ALB opera en la capa 7. Recibe conexiones TCP, inspecciona encabezados HTTP, aplica reglas de enrutamiento de encabezados y rutas y distribuye cada solicitud individual a una instancia del grupo de backend. Ve cada solicitud. Puede realizar enrutamiento basado en rutas: /api va a un grupo de instancias, /static va a otro. Puede inyectar o modificar encabezados. Tiene visibilidad sobre el cuerpo de la solicitud si el protocolo lo permite.
Cloudflare LB no ve solicitudes individuales. Responde consultas de DNS. No hay forma de inspeccionar la ruta /api porque la ruta ni siquiera existe en la capa DNS; solo aparece después de que el cliente haya establecido la conexión TCP con el origen y haya enviado el HTTP GET. Esta no es una limitación accidental; es la consecuencia natural de operar con el protocolo incorrecto para ese nivel de granularidad.
El patrón que combina los dos resuelve diferentes problemas en cada capa. Cloudflare LB se encarga del enrutamiento geográfico y la conmutación por error entre regiones: los clientes de Brasil llegan a São Paulo, los clientes de Europa llegan a Frankfurt y, si São Paulo falla, el tráfico migra automáticamente. Dentro de cada región, un ALB o nginx distribuye solicitudes entre las instancias del grupo, realiza enrutamiento basado en rutas y administra la carga a nivel de solicitud. Los dos coexisten sin conflicto porque resuelven problemas en diferentes capas de la pila.
Qué significan las comprobaciones de estado para el SLA de conmutación por error
La velocidad de la conmutación por error depende de tres variables: el intervalo de verificación de estado, la cantidad de fallas consecutivas necesarias para marcar una fuente como degradada y el TTL del registro DNS. Con comprobaciones de estado cada 60 segundos y dos fallos consecutivos como umbral, el peor caso de detección es 120 segundos. Al agregar el TTL, que para registros proxy es de 60 segundos, la ventana máxima de conmutación por error es de alrededor de 3 minutos.
Reducir el intervalo de verificación de estado acelera la detección, pero aumenta el volumen de consultas cobradas. El punto de equilibrio depende del SLA de disponibilidad del servicio. Para sistemas donde 3 minutos de falla parcial son aceptables (el origen inactivo no atiende a ningún cliente nuevo al ser detectado, pero los clientes con caché activo aún intentan alcanzar el TTL), la configuración predeterminada es adecuada. Para sistemas donde cualquier desvío de tráfico a una fuente degradada es inaceptable, la combinación de TTL bajo, verificación de estado de intervalos cortos y al menos dos comprobaciones de PoP en paralelo reduce la ventana a menos de 2 minutos en la práctica.
El punto que los equipos con experiencia en ALB subestiman es que Cloudflare LB no cancela las conexiones activas cuando un origen se marca como degradado. Deja de devolver esa IP en nuevas resoluciones DNS. Los clientes que ya tienen la IP en caché continúan intentándolo. El tiempo de espera de la conexión TCP o el error de la aplicación es lo que experimentará el cliente hasta que caduque el TTL y una nueva resolución devuelva una IP saludable. El impacto real depende de qué fracción de clientes activos tienen caché nueva versus caché caducada en el momento de la falla.
Lea también
- Cloudflare DNS: infraestructura de red que va mucho más allá de resolver nombres
- DNS proxy vs DNS solamente: qué cambia y cuándo tiene sentido cada modo
- DNSSEC con Cloudflare: qué protege, qué no protege y cómo activar sin problemas
- Enrutamiento de correo electrónico de Cloudflare: reciba correo electrónico en su dominio y lo que no está incluido
- KV vs R2 vs Cache API: cuándo usar cada nivel de almacenamiento de Cloudflare
- Cloudflare KV: ¿Qué significa distribuido globalmente cuando necesitas escribir?