Load balancer — distribuindo tráfego entre servidores

Um servidor tem um teto de requisições que aguenta processar por segundo. Duas formas de crescer: escalar verticalmente (um servidor mais potente — tem limite físico e fica caro rápido) ou escalar horizontalmente (vários servidores idênticos, dividindo o trabalho). Um load balancer é a peça que torna a segunda opção possível — ele decide, a cada requisição, qual servidor vai atender.

Repare que o load balancer fica conectado aos 3 servidores o tempo todo — a diferença entre uma requisição e outra é só qual dessas 3 conexões recebe o tráfego daquela vez.

Requisição 1 → Servidor A

Requisição 2 (logo em seguida) → Servidor B

Estratégias de distribuição

Round-robin        → alterna entre os servidores em sequência (A, B, C, A, B, C...)
Least connections   → manda pro servidor com menos conexões ativas no momento
IP hash              → o mesmo cliente sempre cai no mesmo servidor (útil sem sessão compartilhada)

Health check — o LB precisa saber quem está de pé

upstream backend {
  server 10.0.0.1:3000;
  server 10.0.0.2:3000;
  server 10.0.0.3:3000 max_fails=3 fail_timeout=30s;
}

server {
  location / {
    proxy_pass http://backend;
  }
}

Se o Servidor C parar de responder, o load balancer precisa parar de mandar tráfego pra ele automaticamente (via health check periódico) — senão parte das requisições dos usuários cairia num servidor morto.