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 atuais limitem o número de instâncias que você pode escalonar 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 superar esses desafios com balanceamento de carga global
Os balanceadores de carga de aplicativo externos e os balanceadores de carga de rede de proxy externos são produtos de balanceamento de carga global com proxy por servidores do Google Front End (GFE) sincronizados globalmente, facilitando a mitigação desses tipos de desafios 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 para balanceadores de carga de rede de passagem externa. 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 funcionam os balanceadores de carga de aplicativo externos
O balanceador de carga de aplicativo externo usa uma abordagem 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.
O balanceador de carga de aplicativo externo 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.
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 de aplicativo externo 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 balanceador de carga de aplicativo externo 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.
Transbordamento de tráfego para outras regiões
Se uma região inteira atingir a capacidade determinada pela capacidade de veiculaçã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.
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.
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.
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 Waterfall by Region, pode ocorrer transbordamento de parte do tráfego do balanceador de carga de aplicativo externo 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 você pode gerenciá-lo usando o balanceador de carga HTTP, consulte o tutorial Gerenciamento de capacidade com balanceamento de carga que acompanha este artigo.
Como usar um balanceador de carga de aplicativo externo para solucionar desafios de capacidade
Para ajudar a enfrentar os desafios discutidos anteriormente, balanceadores de carga de aplicativo externos e de proxy externos podem exceder 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 relembrar como um balanceador de carga de aplicativo externo pode ajudar a lidar com os cenários mencionados no início do artigo:
Latência ao iniciar novas instâncias. Se o escalonador automático não puder adicionar capacidade rapidamente durante bursts de tráfego local, o balanceador de carga de aplicativo externo 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 balanceador de carga de aplicativo externo 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 balanceador de carga de aplicativo externo 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 fornecem mais informações e conhecimentos sobre as opções de balanceamento de carga do Google:
- Tutorial de gerenciamento de capacidade com balanceamento de carga
- Como otimizar a latência do aplicativo com balanceamento de carga
- Codelab Networking 101
- Balanceador de carga de rede de passagem externo
- Balanceador de carga de aplicativo externo
- Balanceador de carga de rede de proxy externo