A medida que los volúmenes de tráfico entregados por nuestra CDN continúan aumentando, continuamos expandiendo la huella de nuestra CDN tanto en términos de número como de tamaño de Puntos de Presencia (POP). A medida que crecen los tamaños de los pops, es importante distribuir la carga a través de sus servidores para mantener su salud y estabilidad y para garantizar la resiliencia a picos de tráfico efímeros.
Sistema actual de equilibrio de carga
Las solicitudes que llegan a un pop se equilibran de carga a diferentes servidores basados en el URI de solicitud.
Cuando una solicitud llega a un pop, un servidor front-end procesa la solicitud y asigna la solicitud a un servidor de caché basado en el URI solicitado. El hashing consistente (o, para ser precisos, el hashing rendezvous logrado usando CARP -Cache Array Routing Protocol) garantiza que el mismo recurso siempre será asignado al mismo servidor de caché siempre y cuando ese servidor esté en buen estado. Este mapeo consistente es crucial para el rendimiento. Dirigir una solicitud a un servidor que no tiene el recurso solicitado en su caché requerirá obtener el recurso de otro servidor, lo que aumentará la latencia de respuesta. Es importante destacar que el hashing consistente también logra una distribución bastante uniforme de los recursos en todos los servidores de caché en el pop, lo que ayuda a distribuir la carga de trabajo.
Sin embargo, diferentes recursos varían en popularidad, y un servidor que sirve a un recurso popular puede terminar sirviendo mucho más tráfico que otros en el pop. Por esa razón, un mecanismo llamado Hot Filing se activa cuando un recurso rápidamente se vuelve muy popular y comienza a usar una fracción considerable de los recursos de la red o CPU de un servidor. Hot Filing replica rápidamente este recurso en uno o más servidores adicionales. Notifica a los front ends sobre qué servidores están las réplicas, lo que resulta en una distribución más amplia de la carga generada por recursos.
Potencial margen de mejora
La lógica que desencadena el Hot Filing hoy en día se basa en umbrales fijos que garantizan que ningún recurso único es responsable de más de una tasa predeterminada de solicitudes o bytes servidos por un servidor. Si una carga de recursos excede ese umbral, se distribuye más. Sin embargo, un desafío con umbrales fijos es que si una fracción considerable de la carga de un servidor en un servidor es generada por recursos justo por debajo de ese umbral, esos recursos no serán archivados en caliente. Por lo tanto, su respectiva carga de solicitud no será distribuida.
Debido a esto, hemos observado que incluso con la combinación de equilibrio de carga basado en recursos y Hot Filing, la distribución de carga entre servidores en un pop a menudo puede ser desigual, con algunos servidores entregando más de 2-3 veces la carga media.
La distribución desigual de la carga de la red es común en muchos pops en un momento dado, con algunos servidores entregando hasta 2 veces más tráfico que la mediana.
Esta desigualdad no siempre es un problema porque los servidores pueden seguir siendo eficientes mientras no alcancen su capacidad. Sin embargo, en casos extremos, el impacto puede ser muy evidente. La siguiente figura ilustra un ejemplo real de este efecto.
Dos servidores alcanzan o superan su capacidad de red, mientras que el resto del pop ofrece volúmenes de tráfico más bajos. Los servidores atípicos sufren una inflación obvia en los controles de salud (tiempos de respuesta).
En esta instantánea de distribución de carga de red en un pop en particular, mientras que la mayoría de los servidores están enviando volúmenes bajos de tráfico, dos servidores están sirviendo más de 2 veces la carga media, alcanzando su capacidad debido a uno o unos pocos recursos muy populares. Esto tiene un impacto observable en su métrica de verificación de estado, un indicador de su tiempo de respuesta mínimo. Los valores saludables para esta métrica suelen ser inferiores a 1 ms, y las alertas se elevan cuando exceden los 10 ms. En este ejemplo, la comprobación de estado aumentó a valores superiores a 100 ms y persistió durante al menos una hora, durante la cual los servidores sobrecargados probablemente tuvieron un desempeño deficiente.
También hemos observado casos en los que unos pocos servidores están persistentemente más cargados que el resto del pop por hasta varios días. Durante estos períodos, estos servidores cargados son generalmente menos resistentes a los picos de tráfico entrantes que otros servidores en el pop. Esto se agrava durante las horas pico, ya que su carga puede alcanzar o superar su capacidad, aunque hay capacidad disponible en el resto del pop.
Sistema de equilibrio de carga de solicitud adaptativa
Con base en estas observaciones, hemos estado investigando la idea de Hot Filing con umbrales dinámicos. Este enfoque considera la distribución de carga entre servidores en un momento dado y donde cada servidor se encuentra en esa distribución. En base a estas condiciones, se calcula un umbral específico del servidor en función del lugar del servidor en la distribución de carga: a un servidor con una carga superior a la mediana se le asigna un umbral inferior que a un servidor con una carga inferior, favoreciendo una mayor descarga para los servidores en la cola de la distribución.
Los umbrales de servidor se generan en función de la ubicación actual de distribución de carga de cada servidor. A un servidor con una carga superior a la mediana se le asigna un umbral inferior al de un servidor con una carga inferior.
Más específicamente, definimos dos parámetros que controlan el nivel de Hot Filing:
- BaseThresh controla el valor de base para el umbral de cada servidor. Un umbral específico del servidor se deriva de este valor y se ajusta para el servidor de acuerdo con su carga actual.
- α ∈ (0, 2) controla la agresividad con que el algoritmo ajusta los pesos para los servidores que necesitan descarga.
Luego, para cada servidor en el pop, generamos un peso W(s) ∈ (0, 2), que es inversamente proporcional a la carga actual del servidor, usando la fórmula:
Donde: α ∈ (0, 1) BW(s) es la carga actual del servidor BWmin es la carga más baja del servidor BWmin es la carga más alta del servidor de carga entonces, el umbral T(s) de cada servidor se calcula como:
En nuestra implementación, configuramos BaseThresh a un valor que se ajuste a nuestras cargas de trabajo. Dejamos que el algoritmo elija dinámicamente el valor para α, de modo que se aplique una descarga más agresiva en servidores atípicos (más cargados) si esos servidores están muy lejos de la mediana en términos de carga.
Evaluación utilizando cargas de trabajo de producción CDN
Evaluamos nuestro enfoque en simulación, utilizando instantáneas de cargas de trabajo de producción. Para medir el (cambio de) sesgo en la distribución de carga entre los servidores en un pop, definimos el “factor de sesgo”:
En otras palabras, S mide cuán lejos está el servidor más cargado de la mediana. Por ejemplo, S=2 significa que el servidor más cargado entrega 2 veces la carga media. Idealmente, queremos que todos los servidores estén cerca de la mediana, por lo que los valores más bajos para S son mejores (con S=1 siendo el óptimo teórico). La siguiente figura muestra cómo S cambia a lo largo de múltiples iteraciones del proceso de Hot Filing en función de umbrales dinámicos, el número de nuevos Hot Files generados en cada iteración y el valor de α seleccionado en cada iteración.
Distribución de carga después de varias iteraciones consecutivas del algoritmo. La carga en los servidores más cargados se reduce de 2.73x el valor medio 1.42x el valor medio, y el tráfico dentro del pop se distribuye de manera más uniforme.
La línea azul (“START”) muestra el estado inicial, representando una instantánea real de la distribución de carga en un pop. Observamos que S se reduce después de cada iteración hasta que se alcanza un punto en el que no se generan más archivos calientes (HF). A medida que la cola se recorta en cada iteración, la distribución se vuelve más uniforme, con más servidores más cerca de la carga media.
A continuación, repetimos el mismo experimento 10 veces para 6 diferentes estallidos:
Cambio del factor de inclinación (S) para 6 pops. S converge en 5 iteraciones, disminuyendo un 92% en promedio.
Cada grupo de barras en la figura representa un pop diferente, y cada barra dentro de un grupo representa una iteración posterior. La primera barra de cada grupo representa el estado de inicio, extraído de instantáneas de carga de trabajo de producción. Cada barra representa los valores para 10 carreras. Observamos que en todos los casos, la disminución de S es mucho más dramática en la primera iteración que en cualquiera de las siguientes iteraciones en las que S está alcanzando valores más aceptables. Es importante destacar que la difusión de la distribución (ilustrada por los bigotes), así como los valores atípicos (diamantes), se reducen de manera similar. Observamos que el mecanismo de equilibrio de carga converge después de un pequeño número de iteraciones y solo tendría que activarse cuando S se vuelve alto debido al nuevo tráfico desequilibrado.
Los próximos pasos
Distribuir la carga entre servidores en un pop es importante para el rendimiento. Si bien se espera cierto grado de desigualdad debido a los recursos rápidamente populares, los servidores sobrecargados persistentemente, a pesar de la capacidad disponible en el resto del pop, podrían afectar su rendimiento y resistencia a más picos de tráfico entrante. En este trabajo, exploramos una mejora de nuestro mecanismo de equilibrio de carga existente, que puede ayudar a mitigar este desequilibrio de carga.
Los resultados de la simulación han sido prometedores, por lo que estamos horneando este cambio en nuestro mecanismo existente y monitoreando los resultados en la producción. Probar este método de producción nos permitirá obtener resultados más realistas y evaluar factores adicionales que son más difíciles de cuantificar en la simulación. Estos factores incluyen la resiliencia a cargas de trabajo altamente dinámicas, efectos de hora del día, cambios en la replicación de recursos y los gastos generales asociados.
Explore nuestro sitio web para obtener más información sobre cómo nuestra red de distribución de contenido ofrece un mejor rendimiento, seguridad y confiabilidad.
