A maioria dos equilibradores de carga usa uma abordagem de hash baseada em fluxo ou round-robin para distribuir o tráfego. No entanto, os balanceadores de carga que usam esta abordagem podem ter dificuldade em adaptar-se quando a procura aumenta para além da capacidade de publicação disponível. Este artigo explica como a utilização do Cloud Load Balancing pode resolver estes problemas e otimizar a capacidade da sua aplicação global. Isto resulta frequentemente numa melhor experiência do utilizador e em custos mais baixos em comparação com as implementações de equilíbrio de carga tradicionais.
Este artigo faz parte de uma série de práticas recomendadas focadas nos produtos de balanceamento de carga do Google Cloud. Para ver um tutorial que acompanha este artigo, consulte Gestão da capacidade com o equilíbrio de carga. Para uma análise detalhada da latência, consulte o artigo Otimizar a latência da aplicação com o equilíbrio de carga.
Desafios de capacidade nas aplicações globais
A expansão de aplicações globais pode ser desafiante, especialmente se 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 funcionalidades como odimensionamento automático e o equilíbrio de carga pode ajudar. No entanto, os escaladores automáticos têm algumas limitações, conforme explicado nesta secção.
Latência no início de novas instâncias
O problema mais comum com o dimensionamento automático é que a aplicação pedida não está pronta para publicar o seu tráfego com rapidez suficiente. Consoante as imagens da instância de VM, os scripts têm normalmente de ser executados e as informações carregadas antes de as instâncias de VM estarem prontas. Normalmente, o equilíbrio de carga demora alguns minutos a conseguir direcionar os utilizadores para novas instâncias de VMs. Durante esse período, o tráfego é distribuído às instâncias de VM existentes, que podem já estar acima da capacidade.
Aplicações limitadas pela capacidade de back-end
Não é possível ajustar automaticamente a escala de algumas aplicações. Por exemplo, as bases de dados têm frequentemente uma capacidade de back-end limitada. Apenas um número específico de front-ends pode aceder a uma base de dados que não seja dimensionada horizontalmente. Se a sua aplicação depender de APIs externas que suportam apenas um número limitado de pedidos por segundo, também não é possível ajustar automaticamente a escala da aplicação.
Licenças não elásticas
Quando usa software licenciado, a sua licença limita-o frequentemente a uma capacidade máxima predefinida. Por conseguinte, a sua capacidade de dimensionamento automático pode estar restrita porque não pode adicionar licenças rapidamente.
Margem de segurança da instância de VM demasiado pequena
Para ter em conta os picos repentinos de tráfego, um escalador automático deve incluir uma margem suficiente (por exemplo, o escalador automático é acionado a 70% da capacidade da CPU). Para poupar custos, pode ser tentador definir este objetivo como mais elevado, como 90% da capacidade da CPU. No entanto, os valores de acionamento mais elevados podem resultar em gargalos de escalabilidade quando confrontados com picos de tráfego, como uma campanha publicitária que aumenta subitamente a procura. Tem de equilibrar o tamanho da margem de segurança com base na variabilidade do tráfego e no tempo que as novas instâncias de VM demoram a ficar prontas.
Quotas regionais
Se tiver picos inesperados numa região, as suas quotas de recursos existentes podem limitar o número de instâncias que pode dimensionar abaixo do nível necessário para suportar o pico atual. O processamento de um aumento da quota de recursos pode demorar algumas horas ou dias.
Abordar estes desafios com o balanceamento de carga global
Os balanceadores de carga de aplicações externos e os balanceadores de carga de rede de proxy externos são produtos de balanceamento de carga globais encaminhados através de servidores Google Front End (GFE) sincronizados globalmente, o que facilita a mitigação destes tipos de desafios de balanceamento de carga. Estes produtos oferecem uma solução para os desafios porque o tráfego é distribuído para os back-ends de forma diferente da maioria das soluções de equilíbrio de carga regionais.
Estas diferenças são descritas nas secções seguintes.
Algoritmos usados por outros equilibradores 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 backends, independentemente da origem e do destino dos pacotes.
- Hash. Os fluxos de pacotes são identificados com base nos hashes das informações de tráfego, incluindo o IP de origem, o IP de destino, a porta e o protocolo. Todo o tráfego que produz o mesmo valor 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 encaminhamento externo. Este equilibrador de carga suporta a aplicação de hash de 2 tuplos (com base no IP de origem e destino), a aplicação de hash de 3 tuplos (com base no IP de origem, no IP de destino e no protocolo) e a aplicação de hash de 5 tuplos (com base no IP de origem, no IP de destino, na porta de origem, na porta de destino e no protocolo).
Com ambos os algoritmos, as instâncias não íntegras são retiradas da distribuição. No entanto, a carga atual nos backends raramente é um fator na distribuição de carga.
Alguns equilibradores de carga de hardware ou software usam algoritmos que encaminham o tráfego com base noutras métricas, como o round-robin ponderado, a carga mais baixa, o tempo de resposta mais rápido ou o número de ligações ativas. No entanto, se o carregamento aumentar acima do nível esperado devido a picos de tráfego súbitos, o tráfego continua a ser distribuído para instâncias de back-end com capacidade excessiva, o que leva a aumentos drásticos na latência.
Alguns equilibradores de carga permitem regras avançadas em que o tráfego que excede a capacidade do back-end é encaminhado para outro conjunto ou redirecionado para um Website estático. Isto permite-lhe rejeitar eficazmente este tráfego e enviar uma mensagem "serviço indisponível. Tente mais tarde". Alguns balanceadores de carga dão-lhe a opção de colocar pedidos numa fila.
As soluções de balanceamento de carga global são frequentemente implementadas com um algoritmo baseado em DNS, que publica diferentes IPs de balanceamento de carga regional com base na localização do utilizador e na carga do back-end. Estas soluções oferecem uma alternativa noutra região para todo ou parte do tráfego de uma implementação regional. No entanto, em qualquer solução baseada em DNS, a comutação por falha demora normalmente minutos, consoante o valor de tempo de vida (TTL) das entradas DNS. Em geral, uma pequena quantidade de tráfego continua a ser direcionada para os servidores antigos muito depois de o TTL ter expirado em todos os locais. Por conseguinte, o equilíbrio de carga global baseado em DNS não é a solução ideal para lidar com o tráfego em cenários de picos.
Como funcionam os balanceadores de carga de aplicações externos
O Application Load Balancer externo usa uma abordagem diferente. O tráfego é encaminhado através de servidores GFE implementados na maioria das localizações periféricas da rede global da Google. Atualmente, isto representa mais de 80 localizações em todo o mundo. O algoritmo de balanceamento de carga é aplicado nos servidores GFE.
O Application Load Balancer externo está disponível através de um único endereço IP estável que é anunciado globalmente nos nós periféricos, e as ligações são terminadas por qualquer um dos GFEs.
Os GFEs estão interligados através da rede global da Google. Os dados que descrevem os back-ends disponíveis e a capacidade de publicação disponível para cada recurso com balanceamento de carga são distribuídos continuamente a todos os GFEs através de um plano de controlo global.
O tráfego para endereços IP com balanceamento de carga é encaminhado por proxy para instâncias de back-end definidas na configuração do Application Load Balancer externo através de um algoritmo de balanceamento de carga especial denominado Waterfall por região. Este algoritmo determina o back-end ideal para processar o pedido tendo em conta a proximidade das instâncias aos utilizadores, a carga recebida, bem como a capacidade disponível dos back-ends em cada zona e região. Por fim, também é tida em conta a carga e a capacidade mundiais.
O balanceador de carga de aplicações 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 escalamento automático.
Fluxo de trânsito numa região
Em circunstâncias normais, todo o tráfego é enviado para a região mais próxima do utilizador. O balanceamento de carga é realizado de acordo com estas diretrizes:
Em cada região, o tráfego é distribuído por 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 são carregadas proporcionalmente à respetiva capacidade de publicação disponível.
Dentro das zonas, os pedidos são distribuídos uniformemente pelas instâncias em cada grupo de instâncias.
As sessões são mantidas com base no endereço IP do cliente ou num valor de cookie, consoante a definição de afinidade de sessão.
A menos que o back-end fique indisponível, as ligações TCP existentes nunca são movidas para um back-end diferente.
O diagrama seguinte mostra a distribuição do carregamento neste caso, em que cada região está abaixo da capacidade e pode processar o carregamento dos utilizadores mais próximos dessa região.
Transbordo de tráfego para outras regiões
Se uma região inteira atingir a capacidade, conforme determinado pela capacidade de publicação definida nos serviços de back-end, o algoritmo de hierarquia por região é acionado e o tráfego transborda para a região mais próxima com capacidade disponível. À medida que cada região atinge a capacidade máxima, o tráfego é encaminhado para a região mais próxima seguinte e assim sucessivamente. A proximidade de uma região ao utilizador é definida pelo tempo de ida e volta da rede do GFE para os back-ends das instâncias.
O diagrama seguinte mostra o excesso para a região mais próxima seguinte quando uma região recebe mais tráfego do que consegue processar regionalmente.
Transbordo entre regiões devido a back-ends em mau estado de funcionamento
Se as verificações de estado detetarem que mais de metade dos back-ends numa região não está em bom estado, os GFEs encaminham preventivamente algum tráfego para a região mais próxima seguinte. Isto acontece para evitar que o tráfego falhe completamente à medida que a região se torna instável. Este excesso ocorre mesmo que a capacidade restante na região com os back-ends não íntegros seja suficiente.
O diagrama seguinte mostra o mecanismo de overflow em vigor, porque a maioria dos back-ends numa zona não está em bom estado.
Todas as regiões acima da capacidade
Quando o tráfego para todas as regiões está na capacidade ou acima desta, o tráfego é equilibrado para que todas as regiões estejam no mesmo nível relativo de excesso em comparação com a respetiva capacidade. Por exemplo, se a procura global exceder a capacidade global em 20%, o tráfego é distribuído de forma que todas as regiões recebam pedidos 20% acima da respetiva capacidade regional, mantendo o tráfego o mais local possível.
O diagrama seguinte mostra esta regra de excesso global em vigor. Neste caso, uma única região recebe tanto tráfego que não pode ser distribuído de todo com a capacidade de publicação disponível a nível global.
Excesso temporário durante o ajuste de escala automático
O dimensionamento automático baseia-se nos limites de capacidade configurados em cada serviço de back-end e inicia novas instâncias quando o tráfego se aproxima dos limites de capacidade configurados. Consoante a rapidez com que os níveis de pedidos estão a aumentar e a rapidez com que as novas instâncias ficam online, o transbordo para outras regiões pode ser desnecessário. Noutros casos, o excesso pode funcionar como um buffer temporário até que as novas instâncias locais estejam online e prontas para publicar tráfego em direto. Quando a capacidade expandida pelo ajuste de escala automático é suficiente, todas as novas sessões são distribuídas para a região mais próxima.
Efeitos da latência do overflow
De acordo com o algoritmo de cascata por região, pode ocorrer um excesso de algum tráfego do Application Load Balancer externo para outras regiões. No entanto, as sessões TCP e o tráfego SSL continuam a ser terminados pelo GFE mais próximo do utilizador. Isto é benéfico para a latência da aplicação. Para obter detalhes, consulte Otimizar a latência da aplicação com o equilíbrio de carga.
Prático: medir os efeitos da gestão da capacidade
Para compreender como ocorre o overflow e como o pode gerir através do balanceador de carga HTTP, consulte o tutorial de gestão de capacidade com balanceamento de carga que acompanha este artigo.
Usar um balanceador de carga de aplicações externo para resolver desafios de capacidade
Para ajudar a resolver os desafios abordados anteriormente, os balanceadores de carga de aplicações externos e os balanceadores de carga de rede de proxy externos podem transbordar a capacidade para outras regiões. Para aplicações globais, responder aos utilizadores com uma latência geral ligeiramente superior resulta numa melhor experiência do que usar um back-end regional. As aplicações que usam um back-end regional têm uma latência nominalmente inferior, mas podem ficar sobrecarregadas.
Vamos rever como um Application Load Balancer externo pode ajudar a resolver os cenários mencionados no início do artigo:
Latência no início de novas instâncias. Se o escalador automático não conseguir adicionar capacidade com rapidez suficiente durante picos de tráfego local, o balanceador de carga da aplicação externo transborda temporariamente as ligações para a região mais próxima seguinte. Isto garante que as sessões de utilizadores existentes na região original são processadas à velocidade ideal, uma vez que permanecem nos backends existentes, enquanto as novas sessões de utilizadores apenas experimentam um ligeiro aumento da latência. Assim que forem aumentadas as instâncias de back-end adicionais na região original, o novo tráfego é novamente encaminhado para a região mais próxima dos utilizadores.
Aplicações limitadas pela capacidade de back-end. As aplicações que não podem ser dimensionadas automaticamente, mas que estão disponíveis em várias regiões, podem continuar a transbordar para a região mais próxima seguinte quando a procura numa região excede a capacidade implementada para as necessidades de tráfego habituais.
Licenças não elásticas. Se o número de licenças de software for limitado e o conjunto de licenças na região atual tiver sido esgotado, o Application Load Balancer externo pode mover o tráfego para uma região onde as licenças estão disponíveis. Para que isto funcione, o número máximo de instâncias é definido como o número máximo de licenças no escalador automático.
Margem para otimização da VM insuficiente. A possibilidade de overflow regional ajuda a poupar dinheiro, porque pode configurar o dimensionamento automático com um acionador de utilização elevada da CPU. Também pode configurar a capacidade de back-end disponível abaixo de cada pico regional, porque o overflow para outras regiões garante que a capacidade global é sempre suficiente.
Quotas regionais. Se as quotas de recursos do Compute Engine não corresponderem à procura, o excesso do Application Load Balancer externo redireciona automaticamente parte do tráfego para uma região que ainda pode ser dimensionada dentro da respetiva quota regional.
O que se segue?
As páginas seguintes fornecem mais informações e contexto sobre as opções de equilíbrio de carga da Google:
- Tutorial de gestão da capacidade com balanceamento de carga
- Otimizar a latência da aplicação com o equilíbrio de carga
- Codelab Networking 101
- Balanceador de carga de rede de passagem externo
- Balanceador de carga de aplicações externo
- Balanceador de carga de rede de proxy externo