Balanceamento de Carga

Uma réplica de inventory aguenta, digamos, 800 holds por segundo antes de a latência subir (um número ilustrativo — no hands-on 2 você mede o número real para catalog). A venda do estádio precisa de 5.000. A resposta é óbvia — rodar sete ou oito réplicas —, mas ela levanta na hora as perguntas que esta página responde: quem decide qual réplica recebe cada requisição? O que acontece quando uma réplica morre, fica lenta ou está sendo reimplantada? E se a requisição precisar cair numa réplica específica?

Um load balancer (LB) é o componente que distribui o trabalho por um pool de servidores intercambiáveis — os backends, targets ou upstreams —, de modo que o pool se comporte como um único servidor, maior e mais confiável¹. Ele é o componente lb da paleta e, no Kubernetes, o componente ingress faz o mesmo papel para o tráfego HTTP que entra no cluster.

Por que balancear carga?

Um load balancer dá três coisas de uma vez:

• Escalabilidade: adicionar réplicas para atender mais tráfego (escala horizontal, ou scale-out), em vez de comprar uma máquina maior (escala vertical, ou scale-up).
• Disponibilidade: quando uma réplica falha nos health checks, o LB para de mandar tráfego para ela; os usuários não percebem.
• Operabilidade: dá para drenar, substituir e atualizar réplicas uma de cada vez (rolling deploys), sem downtime.

Isso só funciona se as réplicas forem intercambiáveis — qualquer uma delas atende qualquer requisição. É por isso que os servidores de aplicação devem ser stateless: dados de sessão, carrinhos e holds de assentos ficam num store compartilhado (Redis, PostgreSQL), não na memória de uma réplica. Não ter estado é a pré-condição de tudo nesta página.

flowchart LR
    f([Fãs]) --> lb{{Load balancer}}
    lb --> a1[inventory-1]
    lb --> a2[inventory-2]
    lb --> a3[inventory-3]
    lb -.->|"health check falha: ignorada"| a4["inventory-4 ✗"]
    a1 --> db[(PostgreSQL)]
    a2 --> db
    a3 --> db

L4 versus L7

Load balancers diferem em quanto do tráfego eles entendem.

Um load balancer de camada 4 (L4) trabalha com conexões TCP ou datagramas UDP. Ele vê endereços IP e portas, escolhe um backend quando uma conexão abre e encaminha os bytes daquela conexão para ele. Ele não lê HTTP: não consegue rotear por path, não percebe que uma conexão carrega 1.000 requisições e não precisa decifrar TLS.

Um load balancer de camada 7 (L7) fala HTTP. Ele termina a conexão do cliente, lê cada requisição (método, path, headers, cookies), escolhe um backend por requisição e abre (ou reaproveita) a sua própria conexão com ele. É um reverse proxy completo.

Um layout comum em produção usa os dois: um load balancer L4 (ou anycast) na frente, pela capacidade bruta e pela resiliência a DDoS, distribuindo conexões por uma frota de proxies L7 (Envoy, Nginx) que fazem TLS, roteamento e balanceamento por requisição. É assim que os front ends do Google e da Cloudflare são construídos.

Algoritmos de balanceamento

Depois que o LB tem a lista de backends saudáveis, ele precisa de uma regra para escolher um. A regra importa mais quando as requisições têm custos diferentes ou os backends têm velocidades diferentes.

Dois deles merecem mais atenção.

Power of two choices

Escolher o backend menos carregado entre todos parece ideal, mas, com muitas instâncias de load balancer (cada uma com uma visão um pouco desatualizada), todas escolhem o mesmo servidor "menos carregado" ao mesmo tempo e o sobrecarregam — um rebanho (herd). Escolher um backend ao acaso evita o rebanho, mas deixa, por azar, alguns servidores bem mais ocupados que outros. Mitzenmacher mostrou que um pequeno meio-termo pega quase o melhor dos dois: sortear dois backends e escolher o menos carregado². A carga máxima cai exponencialmente em comparação com a escolha puramente aleatória, e não há rebanho, porque instâncias diferentes do LB sorteiam pares diferentes. Envoy, Nginx (random two least_conn), HAProxy e as bibliotecas gRPC implementam esse algoritmo; ele é a escolha padrão de muitos proxies modernos.

Hashing consistente

Às vezes você quer que a mesma chave vá para o mesmo backend: um servidor de cache que guarda os dados de um usuário, um servidor WebSocket que mantém uma sala de chat, um shard de um key-value store. O jeito ingênuo é server = hash(key) mod N. Funciona até N mudar: passar de 5 para 6 servidores muda o resultado do mod para a maioria das chaves, então quase toda chave se move — todo cache erra ao mesmo tempo.

O hashing consistente (Karger et al., 1997)³ coloca servidores e chaves num círculo de valores de hash (o anel). Uma chave pertence ao primeiro servidor encontrado andando no sentido horário a partir da sua posição.

flowchart LR
    A["nó A<br/>posição 10"] -->|horário| B["nó B<br/>posição 40"]
    B -->|horário| D["novo nó D<br/>posição 55"]
    D -->|horário| C["nó C<br/>posição 75"]
    C -->|"horário (volta ao 0)"| A
    k1(["hold:42 → 30"]) -.->|dono| B
    k2(["hold:77 → 50"]) -.->|"dono: era C, agora D"| D
    k3(["hold:91 → 90"]) -.->|"dono (dá a volta)"| A

No diagrama, as posições vão de 0 a 99: hold:42 tem hash 30 e pertence a B (o primeiro nó na posição 30 ou depois); hold:91 tem hash 90 e dá a volta até A. Quando o nó D entra na posição 55, só as chaves entre 40 e 55 — como hold:77 — passam de C para D; nada mais muda. Em geral, quando um servidor é adicionado, ele assume apenas as chaves entre ele e o seu antecessor — cerca de 1/(N+1) delas; quando um é removido, só as chaves dele se movem, para o sucessor.

Com um ponto por servidor, os arcos do anel têm comprimentos muito diferentes, e alguns servidores ficam com bem mais do que a sua parte. A solução são os nós virtuais⁵: cada servidor físico é colocado no anel muitas vezes (100–200 pontos, por exemplo), e os arcos se equilibram na média. Os nós virtuais também facilitam dar mais pontos a uma máquina maior (pesos) e, quando um servidor sai, espalhar as chaves dele por todos os outros em vez de despejá-las num único vizinho.

A simulação abaixo distribui 40.000 chaves de hold de assento em 5 nós. À esquerda, um ponto por nó contra 200 nós virtuais por nó; à direita, a fração de chaves que muda de dono quando um 6º nó entra:

Duas lições da figura. Com um único ponto por nó, um nó fica com cerca de metade de todas as chaves e outro com quase nenhuma — o anel fica muito desequilibrado. Com 200 nós virtuais, todo nó fica perto dos 20% ideais. E, quando o 6º nó chega, hash mod N remapeia cerca de 83% das chaves (5/6 delas, como a teoria prevê), enquanto o anel remapeia cerca de 17% — o 1/6 que o novo nó precisa assumir de qualquer jeito.

O hashing consistente aparece em todo lugar em system design: hash $key consistent do Nginx, o ring hash e os balanceadores Maglev do Envoy, clientes de memcached, o Dynamo da Amazon e o Cassandra para particionar dados (estudado em Bancos de dados — particionamento), e servidores de chat no estilo do Discord que fixam um canal num nó.

Service discovery: como o LB conhece as réplicas

Réplicas vêm e vão — o autoscaling as adiciona às 09:58, um deploy as substitui, um crash remove uma — e os seus endereços IP mudam toda vez. Antes de o load balancer poder escolher uma réplica saudável, alguém precisa contar a ele quais réplicas existem agora. Isso é service discovery, e ele tem dois formatos:

flowchart LR
    subgraph server ["Discovery no servidor"]
        C1([gateway]) -->|"inventory.svc"| LB1["load balancer / kube-proxy"]
        LB1 --> R1[inventory-1]
        LB1 --> R2[inventory-2]
        REG1[("registry<br/>(endpoints do K8s)")] -.->|"watch"| LB1
    end
    subgraph client ["Discovery no cliente"]
        C2([gateway]) -->|"1 · quem atende inventory?"| REG2[("registry<br/>(Consul, Eureka)")]
        REG2 -->|"2 · [10.0.1.7, 10.0.2.9]"| C2
        C2 -->|"3 · escolhe uma sozinho"| R3[inventory-3]
    end

O registro é feito pela plataforma (o Kubernetes adiciona o IP de um pod aos endpoints do Service quando a probe de readiness passa) ou pela própria instância (ela se registra ao subir e envia heartbeats; um heartbeat perdido a remove). De um jeito ou de outro, discovery e health checks são duas metades da mesma pergunta — quais réplicas conseguem atender agora? — e o registry é um store pequeno e fortemente consistente (etcd, o Raft do Consul), pelos motivos vistos em Sistemas distribuídos — consenso.

Health checks

Um load balancer só é tão bom quanto o que ele sabe sobre quais backends estão saudáveis. Há duas formas complementares de descobrir:

Projete o endpoint de saúde com cuidado. A readiness ("consigo atender tráfego agora?") deve verificar o que a instância precisa para responder às requisições — mas, se ela verificar uma dependência compartilhada, como o banco de dados, uma oscilação do banco marca todas as réplicas como não saudáveis ao mesmo tempo, e o LB fica sem nada para onde rotear. O meio-termo usual: a readiness reflete o estado da própria instância (iniciada, aquecida, não sobrecarregada, não em desligamento); falhas de dependências são tratadas com timeouts e circuit breakers (Confiabilidade — padrões).

Connection draining

Quando uma réplica é removida — por scale-in ou substituída por um deploy —, cortá-la de repente faz falhar toda requisição em andamento. O connection draining (deregistration delay) resolve isso: o LB para de mandar requisições novas para a réplica, espera as que estão em andamento terminarem (até, digamos, 30 s) e só então a remove. No Kubernetes, o pod passa a not ready, é removido dos endpoints do Service e recebe SIGTERM; a aplicação deve terminar as requisições em curso antes de sair (Spring Boot: server.shutdown=graceful).

Sticky sessions

A afinidade de sessão ("sticky sessions") faz o LB mandar toda requisição de um mesmo cliente para o mesmo backend, usando um cookie definido pelo LB ou um hash do IP do cliente. Ela existe para aplicações que guardam estado em memória — uma sessão no servidor, um cache no processo, um WebSocket.

Prefira réplicas stateless. Use afinidade só onde o estado é inerentemente local e barato de reconstruir — uma conexão WebSocket, um cache local que só melhora o hit ratio — e prefira hashing consistente sobre uma chave com significado (id do usuário, id da sala) à afinidade por cookie, porque ele sobrevive a reinícios do LB e escala suavemente.

O load balancer não pode ser o ponto fraco

Um único load balancer na frente de dez réplicas é um ponto único de falha. Como o próprio LB se mantém no ar depende de quem o opera:

• Load balancers gerenciados de nuvem (ALB/NLB, Google Cloud Load Balancing, Azure Load Balancer) são sistemas distribuídos operados pelo provedor em várias zonas de disponibilidade; você recebe um nome DNS ou um IP, e o provedor escala e substitui as máquinas por baixo.
• Auto-hospedados (Nginx, HAProxy, Envoy em VMs): rode pelo menos dois, num par ativo-passivo que compartilha um IP virtual (VIP), movido por VRRP (keepalived) quando o ativo falha, ou ativo-ativo atrás de DNS ou de uma camada L4.
• Anycast na borda: o mesmo IP anunciado de muitos locais (DNS & CDN).

Há também uma hierarquia de escopos: um load balancer global (anycast ou baseado em DNS) escolhe a região; um load balancer regional escolhe a zona e a instância; dentro do Kubernetes, o Service e o ingress escolhem o pod.

flowchart TB
    u([Fãs no mundo todo]) --> g["LB global / DNS<br/>escolhe a região"]
    g --> r1["LB regional São Paulo<br/>em 3 zonas"]
    g --> r2["LB regional Virgínia"]
    r1 --> i1["Ingress / Gateway<br/>no cluster"]
    i1 --> p1[pods de inventory]
    i1 --> p2[pods de order]

Experimente. Carregue o cenário scale-out e rode o perfil load com 2 réplicas; anote a latência p99 e os erros. Aumente o número de réplicas até o p99 se estabilizar. Depois derrube uma réplica com o teste rodando (chaos medium, ou pare-a no painel): veja os health checks a removerem, o pico de erros que dura até isso acontecer, e as réplicas restantes absorverem a carga. Experimente outro algoritmo de balanceamento e compare o p99.

Abrir o playground completo

Um load balancer na prática: Nginx

O Hands-on 3 coloca o Nginx na frente de três réplicas de catalog. O núcleo da configuração é um bloco upstream — o pool de réplicas e o algoritmo: round robin por padrão, ou uma linha como least_conn;, random two least_conn; (power of two choices) ou hash $arg_event consistent; — e um location que faz proxy para ele.

upstream catalog {
    zone catalog 64k;                 # shared memory, required by "resolve"
    # least_conn;                     # try it: pick the replica with fewest active requests
    server catalog-1:8082 resolve max_fails=3 fail_timeout=10s;
    server catalog-2:8082 resolve max_fails=3 fail_timeout=10s;
    server catalog-3:8082 resolve max_fails=3 fail_timeout=10s;
    keepalive 64;                     # reuse TCP connections to the replicas
}
    location /catalog/ {
        limit_req  zone=per_key  burst=40  nodelay;

        proxy_pass  http://catalog;
        proxy_http_version  1.1;
        proxy_set_header  Connection         "";      # keep upstream connections alive
        proxy_set_header  Host               $host;
        proxy_set_header  X-Real-IP          $remote_addr;
        proxy_set_header  X-Forwarded-For    $proxy_add_x_forwarded_for;
        proxy_set_header  X-Forwarded-Proto  $scheme;
        proxy_set_header  X-Request-Id       $request_id;
        add_header        X-Request-Id       $request_id always;

        # passive health checking: a failed attempt is retried on another replica
        proxy_connect_timeout  1s;
        proxy_read_timeout     5s;
        proxy_next_upstream    error timeout http_502 http_503 http_504;
        proxy_next_upstream_tries  2;
    }

Note o que é configurado além do algoritmo: timeouts em direção aos backends, conexões keep-alive com eles e proxy_next_upstream, que refaz uma requisição que falhou em outra réplica. O Nginx não refaz requisições não idempotentes (como POST) por padrão — refazer um POST /holds em outra réplica poderia criar dois holds. Os timeouts vêm de medição, não de gosto: um read timeout menor que o p99 saudável transforma respostas lentas em retries, e o lab usa 5 s para um serviço cujas listagens levam centenas de milissegundos sob carga.

Balanceamento de carga no Kubernetes

No Kubernetes, três objetos dividem o trabalho de balanceamento.

Service — um IP virtual e um nome DNS estáveis (inventory.boxoffice.svc.cluster.local) na frente dos pods que casam com um label selector. Só os pods ready aparecem como endpoints. O tráfego para o IP do Service é distribuído entre eles em L4, pelo kube-proxy (regras iptables/IPVS) ou por um data plane eBPF como o Cilium. Um Service do tipo LoadBalancer também pede ao provedor de nuvem um load balancer L4 externo.

apiVersion: v1
kind: Service
metadata:
  name: inventory
spec:
  selector:
    app: inventory
  ports:
    - port: 80
      targetPort: 8080

Ingress — a API original para roteamento HTTP em L7 para dentro do cluster: regras por host e path e terminação TLS, tudo implementado por um ingress controller (Traefik, HAProxy, controllers de nuvem; o controller comunitário ingress-nginx foi muito popular, mas foi aposentado pelo projeto Kubernetes). A API Ingress é simples, mas limitada: qualquer coisa além de roteamento por host/path (match de headers, divisão de tráfego, timeouts) exige anotações específicas de cada controller, que não são portáveis.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: boxoffice
spec:
  ingressClassName: traefik
  tls:
    - hosts: [api.boxoffice.com]
      secretName: boxoffice-tls
  rules:
    - host: api.boxoffice.com
      http:
        paths:
          - path: /api/holds
            pathType: Prefix
            backend:
              service:
                name: inventory
                port:
                  number: 80

Gateway API — a sucessora do Ingress, com disponibilidade geral desde 2023⁴. Ela divide a configuração por papel, para que cada time seja dono da sua parte:

Recursos que exigiam anotações no Ingress fazem parte do padrão: divisão de tráfego por peso (canaries), roteamento por header, espelhamento de requisições, timeouts e roteamento gRPC.

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: public
spec:
  gatewayClassName: envoy
  listeners:
    - name: https
      protocol: HTTPS
      port: 443
      hostname: api.boxoffice.com
      tls:
        certificateRefs:
          - name: boxoffice-tls
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: inventory
spec:
  parentRefs:
    - name: public
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /api/holds
      timeouts:
        request: 2s
      backendRefs:
        - name: inventory        # stable version: 95% of requests
          port: 80
          weight: 95
        - name: inventory-canary # new version: 5% of requests
          port: 80
          weight: 5

No hands-on 10 você implanta o BoxOffice num cluster local e o expõe por um ingress; releases canary voltam na aula de cloud-native.

Trade-offs num relance

Como se conecta

flowchart LR
    SD["service discovery"] --> LB["load balancer"]
    HC["health checks<br/>(readiness)"] --> LB
    LB --> ALG["algoritmo: RR, least conn,<br/>P2C, hashing consistente"]
    ALG --> STATELESS["réplicas stateless<br/>→ Computação"]
    ALG --> CH["hashing consistente<br/>→ sharding (aula 6)"]
    LB --> HA["redundância do LB, anycast<br/>→ Confiabilidade"]
    LB --> K8S["Service, Ingress, Gateway API<br/>→ Cloud-native"]
    STATELESS --> AS["autoscaling<br/>→ Computação"]
    HC --> OBS["endpoints de saúde<br/>→ Observabilidade"]

Componentes da paleta: lb · ingress · app (as réplicas atrás dele) · healthcheck · mesh (balanceamento no cliente, num sidecar). Cenários: scale-out, chat (conexões de longa duração). Continua em: Computação — serviços, Bancos de dados — particionamento (hashing consistente para dados), Cloud-native — Kubernetes, Hands-on 3.

Pontos-chave