Práticas recomendadas de desempenho do balanceador de carga de aplicações externo

O Cloud Load Balancing oferece mecanismos para distribuir o tráfego de utilizadores por várias instâncias de uma aplicação. Isto é feito através da distribuição da carga pelas instâncias da aplicação e da disponibilização de um desempenho ideal da aplicação aos utilizadores finais. Esta página descreve algumas práticas recomendadas para garantir que o equilibrador de carga está otimizado para a sua aplicação. Para garantir um desempenho ideal, recomendamos que faça testes de referência dos padrões de tráfego da sua aplicação.

Coloque os back-ends perto dos clientes

Quanto mais próximos os seus utilizadores ou aplicações cliente estiverem das suas cargas de trabalho (servidores de processamento do balanceador de carga), menor será a latência de rede entre eles. Por conseguinte, crie os back-ends do balanceador de carga na região mais próxima do local onde prevê que o tráfego dos seus utilizadores chegue ao front-end da Google. Em muitos casos, a execução dos seus backends em várias regiões é necessária para minimizar a latência para os clientes em diferentes partes do mundo.

Para mais informações, consulte os seguintes tópicos:

Ative a colocação em cache com o Cloud CDN

Ative a RFC do Google Cloud e o armazenamento em cache como parte da configuração predefinida do Application Load Balancer externo global. Para mais informações, consulte o artigo Cloud CDN.

Quando ativa o CDN na nuvem, pode demorar alguns minutos até que as respostas comecem a ser colocadas em cache. A RFC na nuvem coloca em cache apenas respostas com conteúdo colocável em cache. Se as respostas de um URL não estiverem a ser armazenadas em cache, verifique que cabeçalhos de resposta estão a ser devolvidos para esse URL e como a capacidade de armazenamento em cache está configurada para o seu back-end. Para mais detalhes, consulte a resolução de problemas do Cloud CDN.

Seleção do protocolo da regra de encaminhamento

Seleção do protocolo do serviço de back-end

A sua escolha do protocolo de back-end (HTTP, HTTPS ou HTTP/2) afeta a latência da aplicação e a largura de banda da rede disponível para a sua aplicação. Por exemplo, a utilização do HTTP/2 entre o balanceador de carga e a instância de back-end pode exigir significativamente mais ligações TCP à instância do que o HTTP(S). A partilha de ligações, uma otimização que reduz o número destas ligações com HTTP(S), não está disponível com HTTP/2. Como resultado, pode observar latências elevadas no back-end porque as ligações ao back-end são feitas com maior frequência.

O protocolo de serviço de back-end também afeta a forma como o tráfego é encriptado em trânsito. Com os balanceadores de carga HTTP(S) externos, todo o tráfego que se destina a back-ends que residem em redes VPC é encriptado automaticamente. Google Cloud A isto chama-se encriptação automática ao nível da rede. No entanto, a encriptação automática ao nível da rede só está disponível para comunicações com grupos de instâncias e back-ends de NEG zonais. Para todos os outros tipos de back-end, recomendamos que use opções de protocolos seguros, como HTTPS e HTTP/2, para encriptar a comunicação com o serviço de back-end. Para obter detalhes, consulte o artigo Encriptação do equilibrador de carga para os servidores de back-end.

As condições da rede mudam e o conjunto de back-ends pode mudar com base na carga. Para aplicações que geram muito tráfego para um único serviço, uma ligação de longa duração nem sempre é uma configuração ideal. Em vez de usar uma única ligação ao back-end indefinidamente, recomendamos que escolha um tempo de vida máximo da ligação (por exemplo, entre 10 e 20 minutos) e/ou um número máximo de pedidos (por exemplo, entre 1000 e 2000 pedidos), após o qual é usada uma nova ligação para novos pedidos. A ligação antiga é fechada quando todos os pedidos ativos que a usam são concluídos.

Isto permite que a aplicação cliente beneficie das alterações no conjunto de back-ends, que incluem os proxies do equilibrador de carga e qualquer reotimização da rede necessária para publicar os clientes.

Critérios de seleção do modo de equilíbrio

Para um melhor desempenho, considere escolher o grupo de back-end para cada novo pedido com base no back-end mais reativo. Isto pode ser conseguido através do modo de equilíbrio RATE. Neste caso, é escolhido o grupo de back-end com a latência média mais baixa em pedidos recentes ou, para HTTP/2 e HTTP/3, o grupo de back-end com o menor número de pedidos pendentes.

O modo de balanceamento UTILIZATION aplica-se apenas aos back-ends do grupo de instâncias e distribui o tráfego com base na utilização das instâncias de VM num grupo de instâncias.

Configure a afinidade de sessão

Em alguns casos, pode ser vantajoso que o mesmo back-end processe pedidos provenientes dos mesmos utilizadores finais ou relacionados com o mesmo utilizador final, pelo menos, durante um curto período. Isto pode ser configurado através da afinidade de sessão, uma definição configurada no serviço de back-end. A afinidade de sessão controla a distribuição de novas ligações de clientes aos back-ends do equilibrador de carga. Pode usar a afinidade de sessão para garantir que o mesmo back-end processa pedidos do mesmo recurso, por exemplo, relacionados com a mesma conta de utilizador ou do mesmo documento.

A afinidade de sessão é especificada para todo o recurso de serviço de back-end e não por back-end. No entanto, um mapa de URLs pode apontar para vários serviços de back-end. Por conseguinte, não tem de usar apenas um tipo de afinidade de sessão para o equilibrador de carga. Consoante a sua aplicação, pode usar diferentes serviços de back-end com diferentes definições de afinidade de sessão. Por exemplo, se uma parte da sua aplicação estiver a publicar conteúdo estático para muitos utilizadores, é pouco provável que beneficie da afinidade de sessão. Em alternativa, usaria um serviço de back-end ativado para o Cloud CDN para publicar respostas em cache.

Para mais informações, consulte afinidade de sessão.