O Cloud Load Balancing oferece mecanismos para distribuir o tráfego do usuário para várias instâncias de um aplicativo. Eles fazem isso distribuindo a carga entre instâncias do aplicativo e fornecendo um desempenho de aplicativo ideal aos usuários finais. Nesta página, são descritas algumas práticas recomendadas para garantir que o balanceador de carga seja otimizado para o aplicativo. Para garantir um desempenho ideal, recomendamos comparar os padrões de tráfego do aplicativo.
Coloque back-ends perto dos clientes
Quanto mais próximos os usuários ou aplicativos clientes estiverem das suas cargas de trabalho (back-ends do balanceador de carga), menor será a latência da rede entre eles. Portanto, crie os back-ends do balanceador de carga na região mais próxima do local em que você prevê que o tráfego dos usuários chegue ao front-end do Google. Em muitos casos, é necessário executar seus back-ends em várias regiões para minimizar a latência para clientes em diferentes partes do mundo.
Para mais informações, consulte os tópicos a seguir:
- Distribuição de tráfego para balanceadores de carga de aplicativo externos
- Práticas recomendadas para a seleção da região do Compute Engine
Ative o armazenamento em cache com o Cloud CDN
Ative o Cloud CDN e o armazenamento em cache como parte da configuração global global externa do balanceador de carga de aplicativo. Para mais informações, consulte Cloud CDN.
Quando você ativa o Cloud CDN, pode levar alguns minutos até que as respostas comecem a ser armazenadas em cache. O Cloud CDN armazena em cache somente as respostas com conteúdo que pode ser armazenado em cache. Se as respostas para um URL não estiverem sendo armazenadas em cache, verifique quais cabeçalhos de resposta estão sendo retornados para esse URL e como o armazenamento em cache está configurado para seu back-end. Para mais detalhes, consulte Solução de problemas do Cloud CDN.
Seleção do protocolo de regra de encaminhamento
Para o balanceador de carga de aplicativo externo global e o balanceador de carga de aplicativo clássico, recomendamos o HTTP/3, que é um protocolo de Internet criado com base no IETF QUIC do Google Analytics. O HTTP/3 está ativado por padrão em todos os principais navegadores, Android Cronet e iOS. Para usar HTTP/3 nos seus aplicativos, verifique se o tráfego UDP não está bloqueado ou tem limitação de taxa na rede e se o HTTP/3 ainda não foi desativado nos seus balanceadores de carga de aplicativo externos globais. Os clientes que ainda não são compatíveis com HTTP/3, como navegadores ou bibliotecas de rede mais antigos, não serão afetados. Para saber mais, consulte QUIC HTTP/3.
Para o balanceador de carga regional externo do aplicativo, há suporte para HTTP/1.1, HTTPS e HTTP/2. Tanto o HTTPS quanto o HTTP/2 exigem sobrecarga inicial para configurar o TLS.
Seleção do protocolo de serviço de back-end
A escolha do protocolo de back-end (HTTP, HTTPS ou HTTP/2) afeta a latência do aplicativo e a largura de banda de rede disponível para ele. Por exemplo, o uso de HTTP/2 entre o balanceador de carga e a instância de back-end pode exigir significativamente mais conexões TCP com a instância do que o HTTP(S). O pool de conexões, uma otimização que reduz o número dessas conexões com HTTP(S), não está disponível com o HTTP/2. Como resultado, talvez você veja altas latências de back-end porque as conexões de back-end são feitas com mais frequência.
O protocolo do serviço de back-end também afeta a forma como o tráfego é criptografado em trânsito. Com os balanceadores de carga HTTP(S) externos, todo o tráfego direcionado a back-ends que residem nas redes VPC do Google Cloud é automaticamente criptografado. Isso é chamado de criptografia automática no nível da rede. No entanto, a criptografia automática no nível da rede está disponível apenas para comunicações com grupos de instâncias e back-ends NEG zonais. Para todos os outros tipos de back-end, recomendamos o uso de opções de protocolo seguros, como HTTPS e HTTP/2, para criptografar a comunicação com o serviço de back-end. Veja mais detalhes em Criptografia do balanceador de carga nos back-ends.
Duração recomendada da conexão
As condições da rede mudam, e o conjunto de back-ends pode mudar com base na carga. Para aplicativos que geram muito tráfego para um único serviço, uma conexão de longa duração nem sempre é a configuração ideal. Em vez de usar uma única conexão com o back-end indefinidamente, recomendamos escolher um ciclo de vida de conexão máximo (por exemplo, entre 10 e 20 minutos) e/ou um número máximo de solicitações (por exemplo, entre 1.000 e 2.000). Depois disso, uma nova conexão será usada para novas solicitações. A conexão antiga é encerrada quando todas as solicitações ativas que a utilizam são concluídas.
Isso permite que o aplicativo cliente se beneficie de alterações no conjunto de back-ends, que incluem os proxies do balanceador de carga e qualquer reotimização de rede necessária para atender aos clientes.
Critérios de seleção do modo de balanceamento
Para um melhor desempenho, escolha o grupo de back-end para cada nova
solicitação com base no back-end mais responsivo. Para isso,
use o modo de balanceamento RATE. Nesse caso, é escolhido o grupo de back-end com a
menor latência média em solicitações recentes ou, para HTTP/2 e HTTP/3, o
grupo de back-end com o menor número de solicitações pendentes.
O modo de balanceamento UTILIZATION se aplica apenas aos back-ends do grupo de instâncias e
distribui o tráfego com base na utilização de instâncias de VM em um grupo
de instâncias.
Configurar a afinidade da sessão
Em alguns casos, pode ser benéfico para o mesmo back-end processar solicitações dos mesmos usuários finais ou relacionadas ao mesmo usuário final, pelo menos por um curto período. Isso pode ser configurado usando a afinidade da sessão, uma configuração definida no serviço de back-end. A afinidade da sessão controla a distribuição de novas conexões dos clientes com os back-ends do balanceador de carga. É possível usar a afinidade da sessão para garantir que o mesmo back-end processe solicitações do mesmo recurso, por exemplo, relacionadas à mesma conta de usuário 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 URL pode indicar vários serviços de back-end. Portanto, não é necessário usar apenas um tipo de afinidade de sessão no balanceador de carga. Dependendo do aplicativo, é possível usar diferentes serviços de back-end com diferentes configurações de afinidade de sessão. Por exemplo, se uma parte do aplicativo estiver exibindo conteúdo estático para muitos usuários, será improvável que ela se beneficie da afinidade de sessão. Você precisa usar um serviço de back-end ativado para o Cloud CDN a fim de exibir respostas em cache.
Para mais informações, consulte afinidade de sessão.