Home Artigos técnicos Avaliando um Sistema Adaptativo de Balanceamento de Carga para nossa CDN
Applications

Avaliando um Sistema Adaptativo de Balanceamento de Carga para nossa CDN

About The Author

Outline

À medida que os volumes de tráfego entregues por nossa CDN continuam a aumentar, continuamos a expandir a pegada de nossa CDN tanto em termos de número quanto de tamanho de pontos de presença (pop). À medida que os tamanhos de pops crescem, é importante distribuir carga em seus servidores para manter sua saúde e estabilidade e garantir resiliência a picos de tráfego efêmeros.

Sistema de balanceamento de carga atual

As solicitações que chegam a um pop são balanceadas em carga para diferentes servidores com base no URI da solicitação.

Quando uma solicitação chega a um pop, um servidor front-end processa a solicitação e mapeia a solicitação para um servidor de cache com base no URI solicitado. Hashing consistente (ou, para ser preciso, o hashing Rendezvous obtido usando o protocolo de roteamento de matriz de cache CARP -Cache) garante que o mesmo recurso será sempre mapeado para o mesmo servidor de cache, desde que esse servidor esteja saudável. Este mapeamento consistente é crucial para o desempenho. Direcionar uma solicitação para um servidor que não tenha o recurso solicitado em seu cache exigirá a obtenção do recurso de outro servidor, aumentando a latência da resposta. É importante ressaltar que o hash consistente também consegue uma distribuição bastante uniforme de recursos em todos os servidores de cache no pop, ajudando a distribuir a carga de trabalho.

No entanto, diferentes recursos variam em popularidade, e um servidor que serve um recurso popular pode acabar servindo muito mais tráfego do que outros no pop. Por essa razão, um mecanismo chamado Hot Filing é iniciado quando um recurso rapidamente se torna muito popular e começa a usar uma fração considerável dos recursos de rede ou CPU de um servidor. O Hot Filing replica rapidamente esse recurso em um ou mais servidores adicionais. Ele notifica os front-ends sobre quais servidores as réplicas estão, resultando em uma distribuição mais ampla da carga gerada por recursos.

Espaço potencial para melhoria

A lógica que aciona o Hot Filing hoje é baseada em limites fixos que garantem que nenhum recurso único é responsável por mais de uma taxa predeterminada de solicitações ou bytes servidos por um servidor. Se uma carga de recurso exceder esse limite, ela será distribuída ainda mais. No entanto, um desafio com limites fixos é que, se uma fração considerável da carga de um servidor em um servidor for gerada por recursos logo abaixo desse limite, esses recursos não serão arquivados a Quente. Portanto, a respetiva carga de solicitação não será distribuída.

Devido a isso, observamos que, mesmo com a combinação de balanceamento de carga baseado em recursos e Hot Filing, a distribuição de carga entre servidores em um pop pode ser irregular, com alguns servidores entregando mais de 2-3x a carga mediana.

A distribuição desigual da carga da rede é comum em muitos pops a qualquer momento, com alguns servidores entregando até 2x mais tráfego do que a mediana.

Esse desnível nem sempre é um problema, porque os servidores podem permanecer eficientes, desde que não estejam atingindo sua capacidade. No entanto, em casos extremos, o impactos pode ser muito aparente. A figura a seguir ilustra um exemplo real desse efeito.

Dois servidores atingem ou excedem sua capacidade de rede, enquanto o resto do pop fornece volumes de tráfego mais baixos. Os servidores mais externos sofrem inflação óbvia nas verificações de saúde (tempos de resposta).

Neste instantâneo da distribuição de carga de rede em um pop específico, enquanto a maioria dos servidores está enviando baixos volumes de tráfego, dois servidores estão servindo mais de 2x a carga mediana, atingindo sua capacidade devido a um ou alguns recursos muito populares. Isso tem um impactos observável em sua métrica de verificação de integridade, um proxy de seu tempo mínimo de resposta. Os valores saudáveis para esta métrica são normalmente inferiores a 1 ms e os alertas são levantados quando excedem 10 ms. Neste exemplo, a verificação de integridade aumentou para valores acima de 100ms e persistiu por pelo menos uma hora, durante a qual os servidores sobrecarregados provavelmente tiveram um desempenho ruim.

Também observamos casos em que alguns servidores são persistentemente mais carregados do que o resto do pop por até vários dias. Durante esses períodos, esses servidores carregados geralmente são menos resilientes a picos de tráfego de entrada do que outros servidores no pop. Isso é exacerbado durante as horas de pico, pois sua carga pode atingir ou exceder sua capacidade, embora haja capacidade disponível no resto do pop.

Sistema de balanceamento de carga de pedido adaptável

Com base nessas observações, temos pesquisado a ideia de Hot Filing com limiares dinâmicos. Essa abordagem considera a distribuição de carga entre servidores a qualquer momento e onde cada servidor está nessa distribuição. Com base nessas condições, um limite específico do servidor é calculado como uma função do lugar do servidor na distribuição de carga: um servidor com uma carga superior à mediana recebe um limite inferior ao de um servidor com uma carga inferior, favorecendo mais descarregamento para servidores na cauda da distribuição.

Os limites do servidor são gerados com base no local atual de distribuição de carga de cada servidor. Um servidor com uma carga superior à mediana recebe um limite inferior a um servidor com uma carga inferior.

Mais especificamente, definimos dois parâmetros que controlam o nível de Hot Filing:

  • BaseThresh controla o valor de linha de base para cada limite de servidor. Um limite específico do servidor é derivado desse valor e ajustado para o servidor de acordo com sua carga atual.
  • α ∈ (0, 2) controla quão agressivamente o algoritmo ajusta os pesos para servidores que precisam ser descarregados.

Em seguida, para cada servidor no pop, geramos um peso W(s) ∈ (0, 2), que é inversamente proporcional à carga atual do servidor, usando a fórmula:

Onde: α ∈ (0, 1 ) BW(s) é a carga atual do servidor BWmin é a carga mais baixa do servidor de carga BWmin é a carga mais alta do servidor de carga então, o limite T(s) de cada servidor é calculado como:

Em nossa implementação, configuramos o BaseThresh para um valor adequado às nossas cargas de trabalho. Deixamos o algoritmo escolher dinamicamente o valor para α, de modo que o descarregamento mais agressivo é aplicado em servidores mais externos (mais carregados) se esses servidores estiverem muito longe da mediana em termos de carga.

Avaliação usando cargas de trabalho de produção CDN

Avaliamos nossa abordagem em simulação, usando snapshots de cargas de trabalho de produção. Para medir a (mudança de) assimetria na distribuição de carga entre os servidores em um pop, definimos o “fator de assimetria”:

Em outras palavras, S mede a distância do servidor mais carregado da mediana. Por exemplo, 2 significa que o servidor mais carregado oferece 2x a carga mediana. Idealmente, queremos que todos os servidores estejam próximos da mediana, portanto, valores mais baixos para S são melhores (com 1 sendo o ideal teórico). A figura abaixo mostra como S muda em várias iterações do processo de Hot Filing com base em limites dinâmicos, o número de novos Hot Files gerados em cada iteração e o valor de α escolhido em cada iteração.

Carregue a distribuição após várias iterações de back-to-back do algoritmo. A carga nos servidores mais carregados é reduzida de 2,73x o valor mediano 1.42x o valor mediano, e o tráfego dentro do pop se torna mais uniformemente distribuído.

A linha azul (“start”) mostra o estado inicial, representando um instantâneo real da distribuição de carga em um pop. Notamos que S é diminuído após cada iteração até que um ponto seja atingido onde não são gerados mais arquivos quentes (HF). À medida que a cauda é aparada em cada iteração, a distribuição se torna mais uniforme, com mais servidores mais próximos da carga mediana.

Em seguida, repetimos o mesmo experimento 10 vezes para 6 pops diferentes:

Alteração do Fator de Skewness (S) para 6 pops. O S converge em 5 iterações, diminuindo em média 92%.

Cada grupo de barras na figura representa um pop diferente, e cada barra dentro de um grupo representa uma iteração subsequente. A primeira barra em cada grupo representa o estado inicial, extraído de snapshots de carga de trabalho de produção. Cada barra representa os valores para 10 execuções. Observamos que, em todos os casos, a diminuição de S é muito mais dramática na primeira iteração do que em qualquer uma das seguintes iterações em que S está alcançando valores mais aceitáveis. É importante ressaltar que a disseminação da distribuição (ilustrada pelos bigodes), bem como os outliers (diamantes), são reduzidos de forma semelhante. Observamos que o mecanismo de balanceamento de carga converge após um pequeno número de iterações e só precisaria ser acionado quando S se torna alto devido ao novo tráfego desequilibrado.

Próximos passos

Distribuir a carga entre servidores em um pop é importante para o desempenho. Embora algum grau de desnível seja esperado devido a recursos rapidamente populares, os servidores persistentemente sobrecarregados, apesar da capacidade disponível no resto do pop, podem afetar seu desempenho e resiliência a mais picos de tráfego de entrada. Neste trabalho, exploramos uma melhoria ao nosso mecanismo de balanceamento de carga existente, o que pode ajudar a mitigar tal desigualdade de carga.

Os resultados da simulação têm sido promissores, por isso estamos a preparar esta mudança para o nosso mecanismo existente e a monitorizar os resultados na produção. Testar este método de produção nos permitirá obter resultados mais realistas e avaliar fatores adicionais que são mais difíceis de quantificar na simulação. Tais fatores incluem resiliência a cargas de trabalho altamente dinâmicas, efeitos de tempo do dia, alterações de replicação de recursos e a sobrecarga associada.

Explore nosso site para saber mais sobre como nossa rede de entrega de conteúdo oferece melhor desempenho, segurança e confiabilidade.