DevOpsQuest
0 XP

DEVOPSQUEST

Minha Trilha
Módulo 2 · Redes, HTTP e Nginx

Load balancer e alta disponibilidade explicados do zero

Intermediário 30 min+25 XPNginxLoad Balancer

Objetivos desta aula

  • Entender por que uma única instância é um ponto único de falha
  • Conhecer algoritmos de balanceamento
  • Configurar upstream com várias instâncias no Nginx
  • Usar health checks para retirar instâncias doentes

Se sua aplicação roda em um único servidor e ele cai, todos os clientes ficam sem serviço. Isso é um ponto único de falha (SPOF). Alta disponibilidade significa ter réplicas para que a falha de uma não derrube tudo.

Um load balancer (balanceador de carga) fica na frente das réplicas e distribui as requisições entre elas. Para o cliente, existe um único endereço; por trás, várias instâncias trabalham.

Algoritmos comuns: round robin (uma de cada vez, em sequência), least connections (manda para quem está menos ocupado) e ip hash (o mesmo cliente vai sempre para a mesma instância).

Os health checks são essenciais: o balanceador testa periodicamente cada instância (ex.: GET /health). Se falhar, ela é retirada do rodízio até se recuperar.

Existem balanceadores de camada 4 (TCP, olham só IP e porta, muito rápidos) e de camada 7 (HTTP, conseguem rotear por caminho, domínio e cabeçalhos).

Na nuvem você usa serviços gerenciados (AWS ALB/NLB, Google Cloud Load Balancing). No Kubernetes, o Service e o Ingress fazem esse papel.

Para funcionar bem, a aplicação precisa ser stateless: nenhuma informação de sessão guardada só na memória de uma instância. Sessões vão para Redis ou banco.

Distribua réplicas em zonas de disponibilidade diferentes: se um datacenter inteiro falhar, as outras zonas continuam atendendo.

Na prática

Nginx balanceando três instâncias

nginx

upstream api_backend {
    least_conn;                     # manda para a menos ocupada
    server 10.0.1.11:3000 max_fails=3 fail_timeout=30s;
    server 10.0.1.12:3000 max_fails=3 fail_timeout=30s;
    server 10.0.1.13:3000 backup;   # só entra se as outras caírem
}

server {
    listen 80;
    location / {
        proxy_pass http://api_backend;
        proxy_next_upstream error timeout http_502;
    }
}

Por que isso importa

Clientes esperam serviços sempre no ar; balanceamento e réplicas são a base de qualquer SLA sério.

Erro comum

Guardar sessão na memória da instância: o usuário é deslogado quando o balanceador o manda para outra réplica.

Dica de produção

Faça o /health verificar dependências críticas de forma leve e rápida, sem sobrecarregar o banco.

Pergunta de entrevista

Qual a diferença entre um load balancer de camada 4 e de camada 7?

Glossário

SPOF
Ponto único de falha: se cair, tudo cai.
Round robin
Distribuição em rodízio sequencial.
Health check
Teste periódico de saúde de uma instância.
Stateless
Aplicação que não guarda estado local entre requisições.

Conexão com o CloudShop

A API do CloudShop roda com três réplicas atrás de um balanceador com health check em /health.

Quiz da aula

  1. 1. O que é um SPOF?

  2. 2. Qual algoritmo envia para a instância menos ocupada?

  3. 3. Por que a app deve ser stateless?

Minhas anotações

Salvo automaticamente neste navegador.

AnteriorPróxima