Otimizações de capacidade de aplicativo com balanceamento de carga global

A maioria dos balanceadores de carga usa uma abordagem de hash round-robin ou baseada em fluxo para distribuir o tráfego. No entanto, os balanceadores de carga que usam essa abordagem podem ter dificuldade de adaptação quando a demanda excede a capacidade de veiculação disponível. Neste artigo, explicamos como o uso do Cloud Load Balancing pode solucionar esses problemas e otimizar a capacidade global de aplicativos. Isso geralmente proporciona uma melhor experiência do usuário e custos mais baixos em comparação com as implementações tradicionais de balanceamento de carga.

Este artigo faz parte de uma série de práticas recomendadas com foco nos produtos de Cloud Load Balancing do Google. Para um tutorial que acompanha este artigo, consulte Gerenciamento de capacidade com balanceamento de carga. Para mais detalhes sobre latência, consulte Como otimizar a latência do aplicativo com balanceamento de carga.

Desafios de capacidade em aplicativos globais

O escalonamento de aplicativos globais pode ser desafiador, especialmente se você tiver orçamentos de TI limitados e cargas de trabalho imprevisíveis e intermitentes. Em ambientes de nuvem pública, como o Google Cloud, a flexibilidade oferecida por recursos como escalonamento automático e balanceamento de carga pode ajudar. No entanto, os escalonadores automáticos têm algumas limitações, conforme explicado nesta seção.

Latência ao iniciar novas instâncias

O problema mais comum com o escalonamento automático é o aplicativo solicitado não estar pronto para veicular o tráfego com rapidez suficiente. Dependendo das imagens de instância da VM, geralmente é preciso executar os scripts e carregar as informações antes que as instâncias da VM estejam prontas. O balanceamento de carga costuma levar alguns minutos para direcionar os usuários para novas instâncias de VM. Durante esse tempo, o tráfego é distribuído para instâncias de VM existentes, que pode já estar acima da capacidade.

Aplicativos limitados pela capacidade de back-end

Alguns aplicativos não podem ser escalonados automaticamente. Por exemplo, os bancos de dados geralmente têm capacidade de back-end limitada. Apenas um número específico de front-ends pode acessar um banco de dados que não é escalonado horizontalmente. Se o aplicativo depender de APIs externas que só aceitam um número limitado de solicitações por segundo, o aplicativo também não poderá ser escalonado automaticamente.

Licenças não elásticas

Quando você usa software licenciado, a licença geralmente o limita a uma capacidade máxima predefinida. Isso pode restringir a capacidade de escalonamento automático, porque não é possível adicionar licenças imediatamente.

Espaço pequeno demais para instância de VM

Para dar conta de bursts de tráfego repentinos, um autoescalador precisa ter bastante espaço. Por exemplo, o autoescalador é acionado quando se atinge 70% da capacidade da CPU. Para economizar custos, pode ser tentador elevar essa meta, por exemplo, para 90% da capacidade da CPU. No entanto, valores de acionamento mais altos podem gerar gargalos de escalonamento quando confrontados com bursts de tráfego, como uma campanha publicitária que aumenta a demanda repentinamente. Você precisa equilibrar o espaço com base na suscetibilidade do tráfego e no tempo que as novas instâncias de VM levam para ficar prontas.

Cotas regionais

Se você tiver bursts inesperados em uma região, é possível que as cotas de recursos existentes limitem o número de instâncias que pode ser escalonado abaixo do nível necessário para dar conta do burst atual. O processamento de um aumento na cota de recursos pode levar algumas horas ou dias.

Como solucionar esses desafios com balanceamento de carga global

O balanceamento de carga HTTP(S), o balanceamento de carga de proxy SSL e o balanceamento de carga de proxy TCP são produtos de balanceamento de carga global. Intermediados por servidores do Google Front End (GFE) sincronizados globalmente, eles facilitam a mitigação dos desafios desses tipos de balanceamento de carga. Esses produtos oferecem uma solução para os desafios, porque o tráfego é distribuído para os back-ends de maneira diferente da maioria das soluções de balanceamento de carga regionais.

Essas diferenças são descritas nas seções a seguir.

Algoritmos usados por outros balanceadores de carga

A maioria dos balanceadores de carga usa os mesmos algoritmos para distribuir o tráfego entre os back-ends:

  • Round-robin. Os pacotes são distribuídos igualmente entre todos os back-ends, seja qual for a origem e o destino deles.
  • Hash. Os fluxos de pacotes são identificados com base em hashes de informações de tráfego, incluindo IP de origem, IP de destino, porta e protocolo. Todo o tráfego que produz o mesmo valor de hash flui para o mesmo back-end.

O balanceamento de carga de hash é o algoritmo atualmente disponível no balanceador de carga de rede do Google. Esse balanceador de carga aceita hash de duas tuplas (com base nos IPs de origem e destino), três tuplas (com base em IP de origem, IP de destino e protocolo) e cinco tuplas (com base em IP de origem, IP de destino, porta de origem, porta de destino e protocolo).

Com esses dois algoritmos, as instâncias não íntegras são retiradas da distribuição. No entanto, a carga atual nos back-ends raramente é um fator na distribuição de carga.

Alguns balanceadores de carga de hardware ou software usam algoritmos que encaminham tráfego com base em outras métricas, como ponderação de round-robin, carga mais baixa, menor tempo de resposta ou número de conexões ativas. No entanto, se a carga aumentar acima do nível esperado devido a bursts de tráfego repentinos, o tráfego ainda será distribuído para instâncias de back-end que estão acima da capacidade, acarretando aumentos drásticos na latência.

Alguns balanceadores de carga permitem regras avançadas, em que o tráfego que excede a capacidade do back-end é encaminhado para outro pool ou redirecionado para um site estático. Isso permite que você rejeite efetivamente esse tráfego e envie uma mensagem “serviço indisponível, tente novamente mais tarde”. Alguns balanceadores de carga oferecem a opção de colocar solicitações em uma fila.

As soluções de balanceamento de carga global geralmente são implementadas com um algoritmo baseado em DNS, veiculando diferentes IPs de balanceamento de carga regional com base no local do usuário e na carga do back-end. Essas soluções oferecem failover para outra região de todo ou parte do tráfego de uma implantação regional. No entanto, em qualquer solução baseada em DNS, o failover geralmente leva alguns minutos, dependendo dos valores de time to live (TTL) das entradas DNS. Em geral, uma pequena quantidade de tráfego continuará a ser direcionada para os servidores antigos por um bom tempo após a expiração do TTL em todos os lugares. Portanto, o balanceamento de carga global baseado em DNS não é a solução ideal para lidar com o tráfego em cenários de burst.

Como funciona o balanceamento de carga HTTP(S)

A abordagem usada no balanceamento de carga HTTP(S) é diferente. O tráfego é enviado por proxy por meio de servidores do GFE implantados em grande parte dos locais de extremidade da rede global do Google. Atualmente, isso representa mais de 80 locais em todo o mundo. O algoritmo de balanceamento de carga é aplicado aos servidores do GFE.

Mapa com cerca de 80 pontos de presença em todo o mundo

O balanceamento de carga HTTP(S) está disponível por meio de um único endereço IP estável, anunciado globalmente nos nós de borda e as conexões são finalizadas por qualquer um dos GFEs.

Os GFEs estão interconectados por meio da rede global do Google. Os dados que descrevem os back-ends disponíveis e a capacidade de exibição disponível de cada recurso com balanceamento de carga são distribuídos continuamente a todos os GFEs que usam um plano de controle global.

Diagrama sobre como as solicitações passam pelo GFE antes de chegar nos data centers do Google

O tráfego para endereços IP com balanceamento de carga é intermediado para instâncias de back-end definidas na configuração do balanceador de carga HTTP(S) por meio de um algoritmo especial de balanceamento de carga denominado cachoeira por região. Ele determina o back-end ideal para veicular a solicitação, considerando a proximidade das instâncias aos usuários, a carga de entrada e a capacidade disponível dos back-ends em cada zona e região. Por fim, a carga e a capacidade mundiais também são consideradas.

O balanceamento de carga HTTP(S) distribui o tráfego com base nas instâncias disponíveis. Para adicionar novas instâncias com base na carga, o algoritmo funciona em conjunto com os grupos de instâncias de escalonamento automático.

Fluxo de tráfego dentro de uma região

Em circunstâncias normais, todo o tráfego é enviado para a região mais próxima ao usuário. O balanceamento de carga é realizado de acordo com estas diretrizes:

  • Dentro de cada região, o tráfego é distribuído entre os grupos de instâncias, que podem estar em várias zonas de acordo com a capacidade de cada grupo.

  • Se a capacidade for desigual entre as zonas, as zonas serão carregadas de modo proporcional às respectivas capacidades de veiculação disponíveis.

  • Dentro das zonas, as solicitações são distribuídas uniformemente para as instâncias em cada grupo de instâncias.

  • As sessões são mantidas com base no endereço IP do cliente ou em um valor de cookie, dependendo da configuração de afinidade da sessão.

  • A menos que o back-end fique indisponível, as conexões TCP existentes nunca são movidas para outro back-end.

No diagrama a seguir, veja a distribuição de carga nesse caso, em que cada região está abaixo da capacidade e pode processar a carga dos usuários mais próximos a essa região.

Diagrama mostrando 50 RPS indo para três regiões diferentes que podem processar essa carga

Transbordamento de tráfego para outras regiões

Se uma região inteira atingir a capacidade determinada pela capacidade de exibição definida nos serviços de back-end, o algoritmo de cachoeira por região será acionado e o tráfego transbordará para a região mais próxima que tiver capacidade disponível. À medida que cada região atinge a capacidade, o tráfego é direcionado para a região mais próxima e assim por diante. A proximidade de uma região ao usuário é definida pelo tempo de retorno da rede do GFE até os back-ends de instância.

No diagrama a seguir, veja o transbordamento para a região mais próxima quando uma região recebe mais tráfego do que pode processar regionalmente.

Diagrama com uma sobrecarga de 150 RPS em uma região, causando transbordamento para a região mais próxima

Transbordamento entre regiões devido a back-ends não íntegros

Se as verificações de integridade descobrirem que mais da metade dos back-ends de uma região não são íntegros, os GFEs transbordarão preemptivamente parte do tráfego para a região mais próxima. Isso acontece para evitar que o tráfego falhe completamente, à medida que a região perde a integridade. Esse transbordamento ocorre mesmo que a capacidade restante da região com os back-ends não íntegros seja suficiente.

No diagrama a seguir, veja como funciona o mecanismo de transbordamento quando a maioria dos back-ends de uma zona não está íntegra.

Diagrama com falhas de back-end parciais em uma região, causando transbordamento para a região mais próxima

Todas as regiões acima da capacidade

Quando o tráfego para todas as regiões é igual ou superior à capacidade, o tráfego é balanceado de modo que todas as regiões fiquem no mesmo nível de transbordamento relativo à respectiva capacidade. Por exemplo, se a demanda global exceder a capacidade global em 20%, o tráfego será distribuído de forma que todas as regiões recebam 20% mais solicitações do que a capacidade regional, mantendo o tráfego o mais local possível.

No diagrama a seguir, veja como funciona essa regra de transbordamento global. Nesse caso, uma única região recebe tanto tráfego que não pode ser distribuído com a capacidade de exibição disponível globalmente.

Diagrama com todas as regiões acima da capacidade e solicitações distribuídas globalmente

Transbordamento temporário durante o escalonamento automático

O escalonamento automático baseia-se nos limites de capacidade configurados em cada serviço de back-end e apresenta novas instâncias quando o tráfego se aproxima dos limites de capacidade configurados. Dependendo da rapidez com que os níveis de solicitação estão aumentando e da rapidez com que novas instâncias ficam on-line, o transbordamento para outras regiões pode ser desnecessário. Em outros casos, o transbordamento pode agir como buffer temporário até que novas instâncias locais fiquem on-line e prontas para veicular o tráfego ativo. Quando a capacidade expandida por escalonamento automático é suficiente, todas as novas sessões são distribuídas para a região mais próxima.

Efeitos de latência do transbordamento

De acordo com o algoritmo cachoeira por região, pode ocorrer transbordamento de parte do tráfego por balanceamento de carga HTTP(S) para outras regiões. No entanto, as sessões TCP e o tráfego SSL ainda são terminados pelo GFE mais próximo ao usuário. Isso é benéfico para a latência de aplicativo. Para detalhes, consulte Como otimizar a latência do aplicativo com balanceamento de carga.

Na prática: como medir os efeitos do gerenciamento de capacidade

Para entender como o transbordamento ocorre e como é possível gerenciá-lo usando o balanceador de carga HTTP, consulte o Tutorial de gerenciamento de capacidade com balanceamento de carga que acompanha este artigo.

Como usar o balanceamento de carga HTTP(S) para solucionar os desafios de capacidade

Para ajudar a solucionar os desafios discutidos anteriormente, o balanceamento de carga HTTP(S), o balanceamento de carga de proxy TCP e o balanceamento de carga de proxy SSL podem transbordar a capacidade para outras regiões. Para aplicativos globais, responder a usuários com latência geral um pouco maior gera uma experiência melhor do que usar um back-end regional. Aplicativos que usam back-end regional têm latência nominalmente menor, mas podem ficar sobrecarregados.

Vamos rever como o balanceamento de carga HTTP(S) pode ajudar a solucionar os cenários mencionados no início do artigo:

  • Latência ao iniciar novas instâncias. Se o autoescalador não adicionar capacidade com rapidez suficiente durante bursts de tráfego local, o Balanceamento de carga HTTP(S) transbordará temporariamente as conexões para a região mais próxima. Isso garante que as sessões de usuário atuais na região original sejam gerenciadas na velocidade ideal, já que permanecem nos back-ends em uso, enquanto as novas sessões de usuário têm apenas um pequeno aumento de latência. Assim que as outras instâncias de back-end são ampliadas na região original, o novo tráfego é encaminhado outra vez para a região mais próxima dos usuários.

  • Aplicativos limitados pela capacidade de back-end. Os aplicativos que não podem ser escalonados automaticamente, mas que estão disponíveis em várias regiões, ainda podem transbordar para a região mais próxima quando a demanda em uma região está além da capacidade implantada para as necessidades normais de tráfego.

  • Licenças não elásticas. Se o número de licenças de software for limitado e se o pool de licenças na região atual estiver esgotado, o balanceamento de carga HTTP(S) poderá mover o tráfego para uma região em que as licenças estejam disponíveis. Para que isso funcione, o número máximo de instâncias é definido como o número máximo de licenças no autoescalador.

  • Espaço pequeno demais para VM. A possibilidade de transbordamento regional ajuda a economizar dinheiro, porque você pode configurar o escalonamento automático com um acionador por alto uso da CPU. Você também pode configurar a capacidade de back-end disponível abaixo de cada pico regional, porque o transbordamento para outras regiões garante que a capacidade global sempre seja suficiente.

  • Cotas regionais. Se as cotas de recursos do Compute Engine não corresponderem à demanda, o transbordamento do balanceamento de carga HTTP(S) redirecionará automaticamente parte do tráfego para uma região que ainda possa ser escalonada dentro da respectiva cota regional.

A seguir

As páginas a seguir contêm mais informações e conhecimentos sobre as opções de balanceamento de carga do Google:

Teste outros recursos do Google Cloud. Veja nossos tutoriais.