O Server Load Balancer (SLB) distribui as requisições recebidas para os servidores de backend com base em um algoritmo de agendamento configurado em cada regra de encaminhamento. O SLB oferece suporte a round-robin, round-robin ponderado, menos conexões ponderadas e hash consistente. Cada algoritmo é adequado a diferentes padrões de tráfego e configurações de servidor.
ALB, NLB e CLB oferecem suporte a diferentes subconjuntos desses algoritmos:
O ALB suporta round-robin ponderado, menos conexões ponderadas e hash consistente com base em endereços IP de origem e URLs.
O NLB suporta round-robin, round-robin ponderado, menos conexões ponderadas e hash consistente com base em endereços IP de origem, na combinação de quatro elementos e em QUIC IDs.
O CLB suporta round-robin, round-robin ponderado e hash consistente com base em endereços IP de origem, na combinação de quatro elementos e em QUIC IDs.
Round-robin
Visualize geral
O algoritmo round-robin distribui as requisições para os servidores de backend sequencialmente, seguindo uma ordem fixa. Esse método funciona bem para conexões stateless e de curta duração, como HTTP, nas quais cada requisição é independente e o tempo de processamento é aproximadamente uniforme.
Por exemplo, em um grupo de servidores de backend com duas instâncias do Elastic Compute Service (ECS), cada instância recebe requisições alternadamente: a primeira vai para ECS01, a segunda para ECS02, a terceira volta para ECS01, e assim por diante.
Vantagens
Simplicidade operacional: não exige configuração individual por servidor, sendo fácil de implementar e manter.
Distribuição uniforme: divide as requisições igualmente entre todos os servidores de backend quando o tempo de processamento e a capacidade dos servidores são semelhantes.
Desvantagens
Falta de percepção de carga em tempo real: ignora o nível de ocupação atual de cada servidor. Se houver grande variação de desempenho, servidores mais rápidos podem ficar subutilizados enquanto os mais lentos ficam sobrecarregados.
Desequilíbrio causado por conexões persistentes: não considera a duração das conexões. Caso algumas permaneçam abertas por muito mais tempo que outras, esses servidores acumulam mais conexões ativas ao longo do tempo, aumentando o tempo de espera para requisições subsequentes.
Quando usar
Capacidade uniforme dos servidores: o round-robin apresenta melhor desempenho quando os servidores de backend possuem CPU e memória semelhantes. Com hardware equivalente, a distribuição equilibrada mantém todos os servidores com níveis de carga aproximadamente iguais.
Requisições curtas e stateless: ideal para cargas de trabalho em que cada requisição é concluída rapidamente e não exige afinidade com um servidor específico — como entrega de ativos estáticos ou chamadas simples de API.
Round-robin ponderado
Visualize geral
O round-robin ponderado estende o conceito do round-robin ao permitir a atribuição de um peso a cada servidor de backend. Servidores com pesos maiores recebem proporcionalmente mais requisições. Assim como o round-robin tradicional, esse algoritmo é adequado para conexões não persistentes, como HTTP.
Como exemplo, se duas instâncias ECS receberem pesos 60 e 40, a primeira processará 60% das requisições e a segunda, 40%.
Vantagens
Distribuição proporcional: aloca o tráfego conforme o peso de cada servidor, permitindo que máquinas com maior capacidade absorvam mais carga sem ficarem sobrecarregadas.
Controle explícito: possibilita definir exatamente quanto tráfego cada servidor deve receber, facilitando o ajuste para servidores com especificações de hardware distintas.
Desvantagens
Sobrecarga de configuração: cada servidor de backend precisa de um valor de peso. Em ambientes com muitos servidores ou capacidade frequentemente alterada, manter os pesos precisos exige esforço contínuo de operação e manutenção.
Risco de pesos mal configurados: valores incorretos resultam em distribuição desequilibrada da carga. Se o desempenho do servidor mudar devido a upgrades, degradação ou variações de tráfego, será necessário atualizar os pesos manualmente.
Quando usar
Servidores com capacidades mistas: quando os servidores de backend têm diferenças de CPU, memória ou rede, defina pesos proporcionais ao desempenho relativo de cada um para que os mais robustos absorvam mais tráfego.
Migração gradual de tráfego: para transferir tráfego entre gerações de servidores ou implantar progressivamente uma nova instância, ajuste os pesos incrementalmente em vez de redirecionar todo o tráfego de uma só vez.
Controle refinado de tráfego: quando for necessário gerenciar com precisão as proporções de tráfego — por exemplo, enviar 20% das requisições para um servidor canary — o round-robin ponderado permite expressar essa razão diretamente por meio dos valores de peso.
Menos conexões ponderadas
Visualize geral
O algoritmo de menos conexões ponderadas encaminha cada nova requisição ao servidor de backend com o menor número de conexões ativas em relação ao seu peso. Se dois servidores tiverem o mesmo peso, aquele com menos conexões atuais recebe a próxima requisição. Esse método é mais eficaz para conexões persistentes, como conexões de banco de dados, onde a quantidade de conexões representa adequadamente a carga do servidor.
Por exemplo, considere duas instâncias ECS com peso 100 cada: uma com 100 conexões ativas e outra com 50. As novas requisições serão direcionadas à instância com 50 conexões até que os valores se equilibrem.
Vantagens
Percepção de carga em tempo real: monitora continuamente as conexões ativas por servidor e afasta novas requisições dos servidores mais ocupados, mantendo o equilíbrio mesmo com flutuações no tráfego.
Justiça ajustada por peso: combina a contagem de conexões com o peso do servidor para evitar tanto a sobrecarga de servidores de alta capacidade quanto a subutilização daqueles com menor capacidade.
Desvantagens
Maior custo de agendamento: comparado ao round-robin e ao round-robin ponderado, este algoritmo precisa consultar e comparar a contagem de conexões ativas em todos os servidores de backend antes de selecionar um, o que aumenta o custo computacional em grande escala.
Visualize incompleta da carga do servidor: rastreia apenas as conexões entre o SLB e o servidor de backend. Se os dados de monitoramento estiverem imprecisos ou desatualizados, as requisições podem não ser distribuídas para o servidor com menos conexões. Além disso, caso o mesmo servidor pertença a múltiplas instâncias de SLB, a contagem de conexões de uma única instância subestima a carga real do servidor, podendo causar sobrecarga ou subutilização.
Picos de carga ao adicionar novos servidores: servidores recém-adicionados iniciam com zero conexões e atraem um fluxo repentino de requisições. Isso pode sobrecarregá-los antes do aquecimento adequado, desestabilizando potencialmente o cluster.
Quando usar
Servidores de capacidades mistas com conexões persistentes: combine pesos com rastreamento de conexões em tempo real para manter a carga proporcional à capacidade de cada servidor, mesmo quando a duração das conexões variar significativamente.
Padrões de tráfego dinâmicos: recomendado quando as conexões ativas flutuam bastante ao longo do tempo, pois o algoritmo reequilibra o tráfego continuamente sem necessidade de ajustes manuais de peso.
Cargas de trabalho sensíveis à estabilidade: para aplicações que exigem tempos de resposta consistentes — como bancos de dados ou pools de conexões — encaminhar novas requisições ao servidor menos carregado ajuda a evitar que servidores individuais se tornem gargalos.
Hash consistente
Visualize geral
O hash consistente mapeia cada requisição para um servidor de backend com base em um hash calculado a partir de um ou mais atributos da requisição (fatores de hash). Requisições que compartilham o mesmo valor de hash sempre vão para o mesmo servidor, mesmo que a quantidade de servidores de backend mude. Ao adicionar ou remover um servidor, apenas um subconjunto mínimo de requisições é redirecionado.
Os fatores de hash incluem:
Endereço IP de origem: requisições provenientes do mesmo IP de cliente sempre chegam ao mesmo servidor de backend.
Quatro elementos: o hash utiliza a combinação do endereço IP de origem, porta de origem, endereço IP de destino e porta de destino. Requisições que compartilham esses quatro valores são enviadas ao mesmo servidor.
QUIC ID: o hash usa o ID de conexão QUIC, que identifica exclusivamente cada conexão QUIC. O uso de QUIC IDs permite balancear a carga entre as conexões. Requisições com o mesmo QUIC ID são distribuídas para o mesmo servidor de backend.
String de consulta da URL: requisições com a mesma string de consulta na URL são roteadas para o mesmo servidor de backend.
Por exemplo, em um grupo de servidores com duas instâncias ECS, se a última requisição foi roteada para ECS01, qualquer requisição subsequente com o mesmo valor de hash também será enviada para ECS01.
Vantagens
Persistência de sessão: requisições da mesma origem são roteadas consistentemente para o mesmo servidor de backend, preservando o estado da sessão sem a necessidade de um armazenamento externo. Isso torna o hash consistente ideal para aplicações que dependem de dados de sessão no lado do servidor ou cache específico por usuário.
Interrupção mínima durante alterações nos servidores: ao adicionar ou remover servidores, apenas as requisições cujos valores de hash correspondem ao slot alterado são redirecionadas. As demais continuam chegando aos mesmos servidores de antes.
Desvantagens
Desequilíbrio temporário após mudanças nos servidores: a adição ou remoção de um servidor faz com que as requisições mapeadas para o slot de hash desse servidor sejam redistribuídas. Se o número de servidores aumentar, menos requisições são reagendadas; se diminuir, mais requisições são reagendadas. Até que o tráfego se reequilibre, alguns servidores podem suportar uma parcela desproporcional da carga.
Complexidade operacional aumentada durante o scale-out: cada alteração nos servidores dispara um novo cálculo parcial de hash. Em ambientes com eventos frequentes de dimensionamento, esse redirecionamento contínuo adiciona sobrecarga operacional e pode complicar o planejamento de capacidade.
Quando usar
Aplicações com persistência de sessão: utilize hash consistente quando sua aplicação armazenar dados de sessão ou estado do usuário em servidores de backend individuais e não puder tolerar que requisições do mesmo usuário alcancem servidores diferentes durante a sessão.
Backends com uso intensivo de cache: quando os servidores de backend mantêm caches locais, rotear as mesmas requisições para o mesmo servidor maximiza as taxas de acerto de cache e reduz a computação redundante em todo o cluster.
Requisitos de localidade de dados: em cargas de trabalho onde dados particionados por chave devem ser processados em um servidor específico — como bancos de dados fragmentados ou processamento de fluxo com estado — o hash consistente garante que as requisições de cada chave sempre cheguem à partição correta.
O hash baseado em QUIC IDs aplica-se apenas a aplicações QUIC. Como o protocolo QUIC está em rápida evolução, a compatibilidade com versões específicas não pode ser garantida. Teste suas aplicações minuciosamente antes de habilitar o QUIC em produção.
NLB e CLB suportam hash baseado em QUIC IDs. As versões Q10 e Q29 são suportadas.