El objetivo de Cloudflare es hacer que las propiedades de Internet en todo el mundo sean más rápidas, seguras y confiables. El equilibrio de carga, que contribuye con la velocidad y la confiabilidad, ha evolucionado en los últimos tres años.
Veamos un caso que resalta un poco más lo que es un Load Balancer y el valor que ofrece. Un load balancer estándar consta de una serie de grupos, cada uno de los cuales tiene servidores de origen que son nombres de host o direcciones IP. Se asigna una directiva de enrutamiento a cada load balancer, que determina el proceso de selección del grupo de origen.
Supongamos que creas una API que usa servicios web ACME del proveedor de servicio en la nube. Lamentablemente, ACME tuvo una semana difícil y su servicio sufrió una interrupción regional en la zona del este de Estados Unidos. Como consecuencia, su sitio web no pudo atender el tráfico durante este período, lo que redujo la confianza de los usuarios en la marca y dio lugar a la pérdida de ingresos. Para evitar que esto vuelva a suceder, debes seguir dos pasos: utilizar un proveedor secundario de servicio en la nube (para evitar tener a ACME como un único punto de error) y utilizar el equilibrio de carga de Cloudflare para aprovechar la arquitectura de nubes múltiples. El equilibrio de carga de Cloudflare te ayuda a maximizar la disponibilidad de tu API para tu nueva arquitectura. Por ejemplo, puedes asignar comprobaciones de estado a cada uno de los grupos de origen. Estas comprobaciones de estado pueden supervisar el estado de los servidores de origen mediante el control de los códigos de estado HTTP, los cuerpos de respuesta y más. Si la respuesta de un grupo de origen no coincide con lo esperado, el tráfico dejará de dirigirse allí. Esto reducirá el tiempo de inactividad de la API cuando ACME tenga una interrupción regional, porque el tráfico de esa región se redirigirá sin inconvenientes a los grupos de origen alternativos. En este escenario, puedes establecer el grupo alternativo como servidores de origen en tu proveedor de nube secundario. Además de las comprobaciones de estado, puedes utilizar la directiva de enrutamiento “aleatorio” para distribuir las solicitudes de API de tus clientes de manera uniforme en todo el backend. Si deseas optimizar su tiempo de respuesta, puedes utilizar la “dirección dinámica”, que enviará el tráfico al servidor de origen que se determina que está más cerca de tu cliente.
Nuestros clientes realmente aprecian el equilibrio de carga de Cloudflare, y siempre estamos buscando maneras de mejorar y facilitar la vida de nuestros clientes. Desde que se lanzó por primera vez el equilibrio de carga de Cloudflare, la solicitud del cliente más popular era un servicio de análisis que proporcionaría información sobre las decisiones de direccionamiento del tráfico.
Hoy, estamos implementando el análisis de equilibrio de carga en la pestaña Tráfico del panel de control de Cloudflare. Los tres principales componentes del servicio de análisis son los siguientes:
Información general sobre el flujo de tráfico que se puede filtrar por load balancer, grupo, origen y región.
Un mapa de latencia que indica el estado del origen y las métricas de latencia de la red global de Cloudflare que abarca 194 ciudades ¡y sigue creciendo!
Registros de eventos que indican cambios en el estado de origen. Esta característica se lanzó en 2018 y hace un seguimiento de las transiciones de grupo y de origen entre estados en buenas y malas condiciones. Hemos trasladado estos registros a la nueva subpestaña de análisis de equilibrio de carga. Consulta la documentación para obtener más detalles.
En este artículo del blog, analizaremos la distribución del flujo de tráfico y el mapa de latencia.
Información general del flujo de tráfico
Nuestros usuarios quieren una visión detallada de la dirección de su tráfico, la razón por la que se dirige hacia allí e información sobre los cambios que pueden optimizar su infraestructura. Con el análisis de equilibrio de carga, los usuarios pueden ver de manera gráfica las demandas de tráfico en load balancers, grupos y orígenes en rangos de tiempo variables.
La comprensión de la manera en que se distribuye el flujo de tráfico informa al proceso la creación de nuevos grupos de origen, la adaptación a las demandas de tráfico pico y la observación de la conmutación por error durante las fallas del grupo de origen.
Figura 1
En la Figura 1, podemos tener una visión general del tráfico para un dominio determinado. El martes 24 se creó el grupo rojo y se agregó al load balancer. Durante las siguientes 36 horas, a medida que el grupo rojo administraba más tráfico, los grupos azul y verde tuvieron un volumen de trabajo reducido. En este escenario, el gráfico de distribución de tráfico brindó nueva información al cliente. En primer lugar, demostró que el tráfico se estaba dirigiendo al nuevo grupo rojo. También permitió que el cliente comprendiera el nuevo nivel de distribución de tráfico en toda su red. Por último, permitió que el cliente confirmara si el tráfico disminuyó en los grupos esperados. Con el tiempo, estos gráficos se pueden usar para administrar mejor la capacidad y planificar las futuras necesidades de infraestructura.
Mapa de latencia
La información general de la distribución del tráfico es solo una parte del rompecabezas. Otro componente esencial es entender el rendimiento de las solicitudes en todo el mundo. Esto resulta útil, ya que los clientes pueden asegurarse de que las solicitudes de los usuarios se gestionan con la mayor rapidez posible, independientemente del lugar del mundo donde se origina la solicitud.
La configuración estándar del equilibrio de carga contiene monitores que sondean el estado de los servidores de origen del cliente. Estos monitores se pueden configurar para que se ejecuten desde una región o regiones determinadas o, para clientes empresariales, desde todas las ubicaciones de Cloudflare. Estos recopilan información útil, como por ejemplo tiempo del trayecto de ida y vuelta, que se puede agregar para crear el mapa de latencia.
El mapa ofrece un resumen de la receptividad de los servidores de origen de todo el mundo, por lo tanto, los clientes pueden ver las regiones donde las solicitudes tienen un rendimiento inferior y necesitan que se haga una mayor investigación. Una métrica común que se usa para identificar el rendimiento es la latencia de solicitudes. Detectamos que la latencia p90 para todos los servidores de origen del equilibrio de carga que se supervisan es de 300 milisegundos, lo que significa que el 90 % de todas las comprobaciones de estado de los monitores tenían un tiempo de trayecto de ida y vuelta más rápido que 300 milisegundos. Utilizamos este valor para identificar ubicaciones donde la latencia era más lenta que la latencia p90 vista por otros clientes del equilibrio de carga.
Figura 2
En la Figura 2, podemos ver la capacidad de respuesta del grupo del noreste de Asia. El grupo del noreste de Asia es especialmente lento para los monitores en América del Sur, Oriente Medio y el sur de África, pero es rápido para los monitores que están sondeando más cerca del grupo de origen. Lamentablemente, esto significa que los usuarios del grupo en países como Paraguay ven una latencia de solicitudes alta. Los tiempos de carga de página altos tienen varias consecuencias negativas: una mayor tasa de rebote de visitantes, menor tasa de satisfacción del visitante y una clasificación más baja del motor de búsqueda. Para evitar estos impactos negativos, el administrador del sitio podría considerar la posibilidad de agregar un nuevo grupo de origen en una región más cercana a las áreas que se encuentran en desventaja. En la Figura 3, podemos ver el resultado que se logra al agregar un nuevo grupo de origen en el este de América del Norte. Vemos que la cantidad de ubicaciones con un dominio en malas condiciones desciende a cero y la cantidad de ubicaciones lentas se reduce en más del 50 %.
Figura 3
El mapa de latencia, vinculado con las métricas de flujo de tráfico de la página Información general, brinda a los usuarios información para optimizar sus sistemas internos, reducir sus costos y optimizar la disponibilidad de sus aplicaciones.
API de GraphQL Analytics
En segundo plano, el análisis del equilibrio de carga funciona con la API de GraphQL Analytics. Como verás a fines de esta semana, GraphQL ofrece muchos beneficios en Cloudflare. Los clientes ahora solo necesitan aprender un único formato de API que les permita extraer solo los datos que necesitan. Para el desarrollo interno, GraphQL elimina la necesidad de la API de análisis personalizada para cada servicio, reduce el costo de las consultas al aumentar los aciertos de caché, y reduce el agotamiento de los desarrolladores mediante el uso de un lenguaje de consulta sencillo, con formatos de entrada y salida estandarizados. Muy pronto, todos los clientes de equilibrio de carga de planes pagos podrán extraer información de la API de GraphQL. Analicemos algunos ejemplos para ver cómo puedes utilizar la API de GraphQL para comprender los registros de equilibrio de carga.
Supongamos que deseas comprender la cantidad de solicitudes que los grupos de un Load Balancer están viendo desde las diferentes ubicaciones de la red global de Cloudflare. La consulta de la Figura 4 cuenta la cantidad de combinaciones únicas (ubicación, identificador de grupo) cada quince minutos en el transcurso de una semana.
Figura 4
Para el contexto, nuestro Load Balancer de ejemplo, lb.example.com, utiliza la dirección dinámica. La dirección dinámica dirige las solicitudes al grupo de origen más receptivo que se encuentra disponible, que suele ser el más cercano. Lo hace utilizando una medición ponderada del tiempo del trayecto de ida y vuelta. Tratemos de entender por qué todo el tráfico de Singapur (SIN) está siendo dirigido a nuestro grupo en el noreste de Asia (asia-ne). Podemos ejecutar la consulta en la Figura 5. Esta consulta nos muestra que el grupo asia-ne tiene un valor avgRttMs de 67 ms, mientras que los otros dos grupos tienen valores avgRttMs que superan los 150 ms. El valor más bajo de avgRttMs explica por qué el tráfico en Singapur se está redirigiendo al grupo de asia-ne.
Figura 5
Observa cómo la consulta de la Figura 4 usa el esquema loadBalancingRequestsGroups, mientras que la consulta de la Figura 5 usa el esquema loadBalancingRequests. Las consultas loadBalancingRequestsGroups agregan datos durante el intervalo de la consulta solicitada, mientras que loadBalancingRequests brinda información detallada de solicitudes individuales. Para los que están listos para comenzar, Cloudflare ha elaborado una guía útil. El sitio web de GraphQL también es un excelente recurso. Recomendamos el uso de un IDE como GraphiQL para hacer consultas. GraphiQL integra la documentación del esquema en el IDE, se completa de manera automática, guarda tus consultas y administra tus encabezados personalizados, lo que facilita en gran medida la experiencia del desarrollador.
Conclusión
Ahora que la solución de análisis de equilibrio de carga se encuentra disponible para todos los clientes Pro, Business y Enterprise, ¡nos complace que empieces a usarla! Hemos adjuntado una encuesta a la página de información general de Tráfico y nos interesaría conocer tus comentarios.