Algoritmos de balanceamento: round robin, least connections e mais

Ter vários servidores atrás de um load balancer resolve só metade do problema. A outra metade é decidir, a cada requisição, para qual deles ela vai. Essa decisão é o algoritmo de balanceamento, e ela muda a latência que o usuário sente, o quanto cada servidor trabalha e se uma sessão em memória sobrevive.

Cada algoritmo abaixo vem com a regra de escolha, o cenário em que ele falha e a configuração no nginx. No fim, um script Python curto simula a lógica para você testar.

Quais são os principais algoritmos de balanceamento?#

Como funciona o round robin?#

O round robin é o mais simples: o balanceador mantém um ponteiro na lista de servidores e avança um a cada requisição. Com três servidores, a ordem é 1, 2, 3, 1, 2, 3. Ele não guarda estado sobre os servidores, por isso é barato e não tem surpresas.

Funciona bem quando os servidores têm o mesmo tamanho e as requisições têm custo parecido. Falha quando uma requisição ocupa um servidor por muito tempo: o round robin continua mandando trabalho novo para ele, porque só conta turnos, não carga.

No nginx, é o padrão. A documentação do nginx descreve o comportamento como round robin com pesos, e cada servidor tem peso 1 se você não disser o contrário.

Como o weighted round robin trata servidores diferentes?#

Se um servidor tem o dobro de memória, ele deve receber mais tráfego. O parâmetro weight faz isso. Com pesos 3, 1 e 1, de cada 5 requisições novas, 3 vão ao primeiro servidor e 1 a cada um dos outros:

upstream app {
    server 10.0.0.11:3000 weight=3;
    server 10.0.0.12:3000;
    server 10.0.0.13:3000;
}

Servidores sem weight ficam com o peso padrão, 1. É o mesmo exemplo da documentação do nginx.

Como o least connections escolhe o servidor?#

O balanceador acompanha quantas conexões ativas cada servidor tem e manda a próxima ao que tem menos. Se houver empate, desempata em rodízio. No nginx, a diretiva leva em conta os pesos dos servidores.

É a melhor escolha quando a duração das requisições varia: uploads, relatórios pesados, WebSockets ou chamadas a APIs lentas. Um servidor preso numa requisição longa acumula conexões e deixa de receber novas, enquanto os outros absorvem a fila. Para requisições todas curtas e iguais, o ganho sobre o round robin costuma ser pequeno.

upstream app {
    least_conn;
    server 10.0.0.11:3000;
    server 10.0.0.12:3000;
    server 10.0.0.13:3000;
}

Quando usar IP hash ou hash consistente?#

Nesses algoritmos a escolha depende de uma chave, não da carga. O mesmo valor de chave leva ao mesmo servidor. Isso serve para sessão em memória, cache local ou conexões que precisam voltar ao mesmo lugar.

O ip_hash do nginx usa os três primeiros octetos do IPv4 do cliente (ou o IPv6 inteiro) como chave:

upstream app {
    ip_hash;
    server 10.0.0.11:3000;
    server 10.0.0.12:3000;
    server 10.0.0.13:3000 down;
}

Há dois limites. O primeiro: como só os três primeiros octetos entram no hash, clientes da mesma rede /24, e todos os que passam pelo mesmo NAT, caem no mesmo servidor, o que desequilibra a carga. O segundo: se você remove um servidor, o hash é recalculado e muitos clientes mudam de destino. Por isso a documentação manda marcar o servidor temporariamente fora com down, o que preserva o mapeamento atual.

Para escolher outra chave, como a URL ou um cookie, use hash com consistent. O hash consistente (ketama) garante que, ao adicionar ou remover um servidor, só uma pequena parte das chaves muda de destino. É a escolha usual para caches, onde remapear tudo esvaziaria o cache de uma vez:

upstream cache {
    hash $request_uri consistent;
    server 10.0.0.21:8080;
    server 10.0.0.22:8080;
    server 10.0.0.23:8080;
}

Existem outros algoritmos?#

Sim. O nginx também oferece random, que sorteia um servidor respeitando os pesos. A variante random two least_conn sorteia dois servidores e fica com o que tem menos conexões ativas. Ela evita que vários balanceadores independentes mandem todos para o mesmo servidor ocioso ao mesmo tempo.

Existe ainda least_time, que prefere o servidor com menor tempo médio de resposta e menos conexões. Segundo a documentação, antes da versão 1.31.0 ele era exclusivo da assinatura comercial (NGINX Plus). Confira a sua versão antes de depender dele.

Como simular os algoritmos em código?#

Este script em Python 3 implementa round robin, round robin com pesos, least connections e hash por IP. Salve como lb.py e rode com python lb.py:

import hashlib
import itertools

SERVERS = ["app-1", "app-2", "app-3"]


def round_robin():
    return itertools.cycle(SERVERS)


def weighted_round_robin(weights):
    # {"app-1": 3, "app-2": 1} vira app-1, app-1, app-1, app-2
    return itertools.cycle([s for s, w in weights.items() for _ in range(w)])


def least_connections(active):
    # active: conexões abertas por servidor; o empate fica com o primeiro da lista
    return min(SERVERS, key=lambda s: active[s])


def ip_hash(client_ip):
    digest = hashlib.sha256(client_ip.encode()).digest()
    return SERVERS[int.from_bytes(digest[:4], "big") % len(SERVERS)]


rr = round_robin()
print([next(rr) for _ in range(6)])
wrr = weighted_round_robin({"app-1": 3, "app-2": 1, "app-3": 1})
print([next(wrr) for _ in range(5)])
print(least_connections({"app-1": 12, "app-2": 3, "app-3": 7}))
print(ip_hash("203.0.113.7") == ip_hash("203.0.113.7"))

A saída é ['app-1', 'app-2', 'app-3', 'app-1', 'app-2', 'app-3'], depois ['app-1', 'app-1', 'app-1', 'app-2', 'app-3'], depois app-2 (o menos ocupado) e True (mesmo IP, mesmo servidor). Adicione um quarto servidor a SERVERS e rode de novo: o ip_hash com módulo remapeia boa parte dos clientes, e é exatamente isso que o hash consistente evita. O weighted round robin deste script manda os três pedidos seguidos ao primeiro servidor; um balanceador real pode intercalar as escolhas.

Como escolher o algoritmo certo?#

• Servidores iguais, requisições curtas e parecidas: round robin.
• Servidores de tamanhos diferentes: weighted round robin.
• Requisições longas ou de duração imprevisível: least connections.
• Estado na memória do servidor que você não pode mover: IP hash. A melhor solução, porém, é tirar o estado da memória e guardar a sessão em Redis ou em um banco, e voltar a um algoritmo que não depende de chave.
• Cache distribuído: hash consistente.

Em todos os casos, o balanceamento só funciona se os servidores forem intercambiáveis e o balanceador remover da rotação quem falha. O proxy reverso na frente deles é quem aplica a regra.

Como fazer isso na Square Cloud#

Na Square Cloud, o balanceamento é por domínio. Você sobe o mesmo código em várias aplicações e associa o mesmo domínio personalizado a todas; o subdomínio squareweb.app não entra no balanceamento. Você configura o domínio criando no seu registrador os registros DNS que o painel mostra (veja como usar um domínio personalizado).

O tráfego do domínio é distribuído em round robin entre as aplicações, com failover passivo (sem health check ativo) se uma delas ficar indisponível. Não há cobrança por requisição. O domínio personalizado começa no plano Standard, que permite até 2 aplicações por domínio. O Pro permite até 5 e o Enterprise, até 10.

Como o algoritmo é round robin e não há sticky session, cada requisição pode cair em uma aplicação diferente, e cada uma tem o próprio disco. Guarde sessões em um banco ou Redis, não na memória do processo. Veja o passo a passo em balanceamento de carga na Square Cloud.