Redes · Load Balancing · NGINX · Escalabilidade · Sysadmin
Load Balancing e Escalabilidade Horizontal na Prática: Como Escalar Sistemas com NGINX
✎ Duarte Spínola | 2026-07-14
Quando uma aplicação começa a receber mais tráfego do que um único servidor consegue processar, surgem lentidão, indisponibilidade e perda de receita. Para uma pequena ou média empresa (PME) portuguesa que opera e-commerce, APIs ou serviços web, a solução passa por distribuir a carga entre múltiplos servidores — é aqui que entra o load balancing. Um load balancer (balanceador de carga) é um servidor ou appliance que recebe todos os pedidos dos utilizadores e os distribui por várias réplicas do backend, garantindo que nenhum servidor fique sobrecarregado. Mas o load balancing não se resume a “colocar um NGINX à frente de três servidores”: existem diferentes tipos de load balancers (hardware, software, cloud), diferentes camadas de rede onde podem operar (camada 4 e camada 7 do modelo OSI) e múltiplos algoritmos de balanceamento (Round Robin, Least Connections, IP Hash, Sticky, Least Time, Random), cada um adequado a cenários distintos.
Este artigo cobre todo o percurso desde a escalabilidade vertical (primeiro passo antes de escalar horizontalmente) até à configuração prática de um NGINX como load balancer em camada 4 e camada 7. Vamos comparar load balancers de hardware (F5 Big-IP, Citrix NetScaler, A10 Thunder), software (NGINX, HAProxy, Traefik) e cloud (AWS ALB/NLB, Google CLB, Azure ALB/App Gateway). Vamos dissecar o modelo OSI para perceber porque é que um balanceador de camada 4 é “cego” e rápido, enquanto um de camada 7 consegue ler HTTP, fazer rate limiting e rotear por URL. E vamos configurar seis algoritmos de balanceamento em NGINX com ficheiros prontos para produção. Cada bloco de configuração é copy-paste, testado sintaticamente contra a documentação oficial do NGINX.
⚠️ Atenção
Aplicar configurações de load balancing em produção sem as testar primeiro pode deixar serviços indisponíveis. Todas as configurações deste artigo devem ser testadas em ambiente de staging antes de aplicar em produção.
O que é Load Balancing e Porquê Importa
Load balancing é a técnica de distribuir tráfego de rede entre múltiplos servidores backend para otimizar a utilização de recursos, maximizar o débito, reduzir a latência e garantir tolerância a falhas. Em vez de ter um único servidor que recebe todos os pedidos — e que se cair, derruba toda a aplicação — o load balancer actua como ponto único de entrada: recebe os pedidos, escolhe um servidor backend disponível, reencaminha o pedido e devolve a resposta ao cliente.
Para uma PME, o load balancing resolve três problemas concretos:
- Sobrecarga de um único servidor — quando o tráfego cresce, um servidor fica sem capacidade CPU, RAM ou largura de banda. Com load balancing, o tráfego é distribuído por réplicas.
- Ponto único de falha (SPOF) — se o servidor cai, a aplicação fica indisponível. Com load balancing, se um backend cai, o balanceador reencaminha para outro automaticamente.
- Escalabilidade sob demanda — adicionar ou remover réplicas consoante a carga, sem downtime. O load balancer detecta os backends disponíveis e ajusta a distribuição.
ℹ️ Informação: O load balancer não substitui a escalabilidade vertical. A boa prática é primeiro escalar verticalmente (adicionar recursos ao servidor existente) e só depois escalar horizontalmente (adicionar réplicas). Escalar horizontalmente sem ter optimizado o servidor base é desperdício de recursos.
A arquitetura típica de uma PME com load balancing é a seguinte: o IP público aponta para o load balancer, que está exposto à internet. Os servidores backend estão numa rede privada (VPC, VLAN ou subnet isolada) e não são directamente acessíveis pela internet. Apenas o load balancer consegue comunicar com os backends. Esta separação é fundamental para segurança — os servidores não precisam de IP público nem de firewall exposto (Microsoft Learn — Load Balancer Overview).
Escalabilidade Vertical: O Primeiro Passo
Antes de pensar em escalar horizontalmente, é preciso perceber a escalabilidade vertical, também conhecida como scale up. A escalabilidade vertical consiste em adicionar mais recursos computacionais ao servidor existente: mais memória RAM, mais CPU, mais armazenamento. É literalmente “aumentar a máquina” que corre a aplicação.
Quando aplicar
A escalabilidade vertical é o primeiro passo quando:
- A aplicação está num único servidor e começa a sofrer com lentidão.
- O crescimento de utilizadores é gradual e previsível.
- A aplicação ainda não está preparada para correr em múltiplas réplicas (sessões guardadas no servidor, estado local, etc.).
Vantagens
- Simples de implementar — basta adicionar recursos à VM ou servidor físico, sem mudanças de código.
- Sem overhead de rede — não há load balancer nem comunicação entre réplicas.
- Custo inicial baixo — para pequenos incrementos (e.g. passar de 4 GB para 16 GB de RAM).
Limitações
| Limitação | Descrição |
|---|---|
| Teto físico | Não se pode adicionar RAM ou CPU infinitamente. Cada máquina tem um limite máximo de slots e capacidade. |
| Custo exponencial | Conforme os recursos crescem, o custo por unidade aumenta (RAM ECC, CPUs de gama alta, SSDs NVMe enterprise). |
| Single Point of Failure (SPOF) | Se o servidor cair (falha de hardware, queda de data center), toda a aplicação fica indisponível. Não há redundância nem resiliência. |
| Downtime para upgrade | Em servidores físicos, adicionar RAM ou CPU requer paragem. Em VMs na cloud, é possível resize sem downtime em alguns provedores, mas nem sempre. |
⚠️ Cuidado
Escalar verticalmente sem limite leva a situações onde se gasta uma fortuna num servidor monstro que, quando atinge o teto, não pode crescer mais. É nessa altura que a escalabilidade horizontal se torna inevitável.
A escalabilidade vertical é importante e necessária, mas não é bala de prata. Toda a decisão arquitetural envolve tradeoffs: ganha-se simplicidade, mas perde-se redundância. Quando o número de utilizadores continua a crescer e o servidor atinge o teto — ou quando a falta de redundância causa quedas inaceitáveis — é altura de escalar horizontalmente.
Escalabilidade Horizontal: A Solução para Crescimento
A escalabilidade horizontal, ou scale out, consiste em criar réplicas do servidor da aplicação e colocar um load balancer à frente para distribuir o tráfego entre elas. Em vez de ter uma máquina gigante, tem-se várias máquinas mais pequenas, cada uma a processar uma parte do tráfego.
Como funciona na prática
- O load balancer é exposto na internet com um IP público.
- Os servidores backend (réplicas) ficam numa rede privada, inacessíveis directamente pela internet.
- O load balancer conhece a rede privada e encaminha os pedidos para os backends.
- Se um backend cair, o load balancer detecta e reencaminha para outro.
Porquê que o load balancer aguenta mais tráfego que os backends
Uma dúvida comum: se a aplicação precisa de escalar porque não aguenta os pedidos, como é que o load balancer — sendo também um servidor — consegue aguentar?
A resposta está na natureza do trabalho. Uma aplicação web recebe um pedido, faz bootstrap do framework, chama controllers, consulta base de dados, executa lógica de negócio — tudo isto leva tempo, milissegundos a segundos. O load balancer, por sua vez, foi concebido para uma única função: receber um pedido e encaminhá-lo. Opera num nível muito baixo, sem processar lógica de negócio. Com pouca memória e CPU, consegue lidar com milhões de ligações simultâneas, porque não “digesta” os pedidos — apenas os reencaminha (NGINX — Load Balancer).
Vantagens
| Vantagem | Descrição |
|---|---|
| Redundância | Se um backend cai, os outros continuam a servir. Não há single point of failure. |
| Escalabilidade elástica | Adicionar ou remover réplicas conforme a carga, sem downtime. |
| Custo controlado | Réplicas mais pequenas e baratas em vez de um servidor monstro. |
| Manutenção sem paragem | Retirar um backend para manutenção enquanto os outros servem. |
Tradeoffs
- Complexidade de rede — é preciso gerir IPs privados, firewalls, VPCs.
- Estado partilhado — se a aplicação guarda sessões no servidor, precisa de sticky sessions ou armazenamento partilhado (Redis, base de dados).
- Custo de coordenação — múltiplos servidores significam monitorização, logs centralizados, deploy coordinado.
✓ Correto
A regra de ouro é: escalar verticalmente primeiro, optimizar o servidor base, e só depois escalar horizontalmente. Não faz sentido escalar horizontalmente sem antes ter maximizado a capacidade de cada servidor individual.
Tipos de Load Balancers
Existem três categorias de load balancers: hardware, software e cloud. A escolha depende do orçamento, infraestrutura e nível de controlo necessário.
Hardware
São appliances físicos dedicados, projetados especificamente para load balancing. Oferecem altíssima performance, mas têm custo elevado.
| Produto | Fabricante | Destaque |
|---|---|---|
| F5 Big-IP | F5 Networks | O mais usado do mundo em enterprise |
| Citrix NetScaler | Citrix | Muito comum em grandes empresas |
| A10 Thunder | A10 Networks | Funciona como Global Load Balancer (GLB) — balanceia entre data centers diferentes |
ℹ️ Informação: O A10 Thunder como GLB balanceia carga entre data centers em localizações geográficas distintas (e.g. um data center em Portugal, outro na Irlanda, outro nos EUA). Isto é load balancing global, não local. Raramente se encontra em PMEs — é mais comum em grandes enterprises e provedores de telecomunicações.
Software
São programas instalados num servidor (VM ou bare metal) que executam a função de load balancing. São a opção mais comum para PMEs.
| Software | Linguagem | Destaque |
|---|---|---|
| NGINX | C | O mais popular, event-driven, altíssima performance |
| HAProxy | C | Concorrente directo do NGINX, excelente para TCP/HTTP load balancing |
| Traefik | Go | Foco em microserviços, service discovery automático com Docker/K8s |
Cloud
São serviços geridos pelos provedores de cloud, que dispensam a gestão do load balancer como infraestrutura.
| Provedor | Load Balancer | Camada OSI |
|---|---|---|
| AWS | Application Load Balancer (ALB) | Camada 7 |
| AWS | Network Load Balancer (NLB) | Camada 4 |
| Google Cloud | Cloud Load Balancer | Camada 4 e 7 |
| Azure | Azure Load Balancer | Camada 4 |
| Azure | Application Gateway | Camada 7 |
💡 ℹ️ Informação
Porque é que AWS e Azure têm dois load balancers diferentes? Porque operam em camadas de rede distintas. O ALB (AWS) opera na camada 7 (HTTP/HTTPS) e consegue ler e rotear pedidos por URL, headers e cookies. O NLB (AWS) opera na camada 4 (TCP/UDP) e é mais rápido, mas “cego” ao conteúdo. A escolha depende do tipo de aplicação (AWS — Elastic Load Balancing, Google Cloud — Load Balancing).
Todos os load balancers de software e hardware podem operar tanto em camada 4 como em camada 7, dependendo da configuração. Já os cloud load balancers são específicos por tipo.
Camadas de Rede: Modelo OSI e Load Balancing
O modelo OSI (Open Systems Interconnection) é o modelo de referência que descreve como a comunicação de rede funciona em sete camadas. Para load balancing, as duas camadas mais relevantes são a camada 4 (transporte) e a camada 7 (aplicação).
As sete camadas do modelo OSI
| Camada | Nome | Protocolos | Função |
|---|---|---|---|
| 7 | Aplicação | HTTP, HTTPS, FTP, SMTP, DNS | Interface com o utilizador |
| 6 | Apresentação | SSL/TLS, JPEG, MPEG | Encriptação e formatação |
| 5 | Sessão | NetBIOS, RPC | Gestão de sessões |
| 4 | Transporte | TCP, UDP | Transporte de dados fim-a-fim |
| 3 | Rede | IP, ICMP | Endereçamento e encaminhamento |
| 2 | Enlace | Ethernet, PPP | Ligação física lógica |
| 1 | Física | Cabos, fibra, rádio | Transmissão de bits |
Análise dos pedidos por URL: Load Balancer de camada 7
Um load balancer de camada 7 opera na camada de aplicação — é o “atendente dos correios” que recebe a carta, lê o conteúdo, cola o selo, carimba e processa antes de entregar ao transportador.
Características:
- Intercepta e lê pedidos HTTP/HTTPS completos.
- Consegue fazer roteamento baseado em URL (e.g.
/pedidospara o cluster de pedidos,/pagamentospara o cluster de pagamentos). - Pode fazer autenticação JWT, rate limiting, manipulação de headers e cookies.
- Consegue descompactar e inspeccionar o payload HTTP.
Casos de uso:
- Aplicações web (e-commerce, SaaS, sites institucionais)
- APIs REST e microserviços
- Aplicações móveis (backend HTTP)
- Qualquer cenário onde seja preciso rotear por URL ou inspeccionar pedidos
ℹ️ Informação: Em cerca de 90% dos casos de aplicações web tradicionais, usa-se um balanceador de camada 7. É a escolha padrão para HTTP.
Load Balancer de camada 4
Um load balancer de camada 4 opera na camada de transporte — é o “caminhoneiro” que recebe a carta directamente na mão, sem passar pelo atendente. Só precisa de saber o IP de origem e o IP de destino.
Características:
- É “cego” ao conteúdo: não lê HTTP, não interpreta headers, não faz autenticação.
- Só vê IP de origem e IP de destino.
- Encaminha tráfego TCP ou UDP sem o desempacotar.
- Muito mais rápido e com menor latência que um balanceador de camada 7.
Casos de uso:
| Aplicação | Protocolo | Razão |
|---|---|---|
| Jogos online (FPS, MMO) | UDP | Necessita de baixa latência e tempo real; não faz sentido HTTP por frame |
| Videoconferência (Google Meet, Zoom) | UDP | Permite perda de pacotes sem bloquear; tempo real |
| WebSocket | Conexão persistente que dura indefinidamente; não é request/response HTTP | |
| Aplicações com WebSocket massivo | TCP | Ligações longas que não devem ser interceptadas |
✓ Correto
Load balancer de camada 4: só pega e repassa. Olha o IP de origem e destino, não faz mais nada. Load balancer de camada 7: intercepta, lê e permite controlo granular do tráfego HTTP.
A escolha entre camada 4 e camada 7 é uma das perguntas mais frequentes em entrevistas de system design. Quem não sabe responder em que camada o load balancer opera, não consegue projectar arquitecturas corretamente (Microsoft Learn — OSI Model).
Algoritmos de Balanceamento de Carga
O algoritmo de balanceamento determina como o load balancer escolhe o servidor backend para cada pedido. Não existe um algoritmo universalmente “melhor” — cada um resolve um problema específico. Configurar o algoritmo errado em produção causa problemas difíceis de diagnosticar.
Visão geral dos algoritmos
| Algoritmo | Como funciona | Quando usar | NGINX |
|---|---|---|---|
| Round Robin | Distribui pedidos circularmente (1→2→3→1→2→3) | Backends homogéneos, tráfego uniforme | Predefinido (sem directiva) |
| Weighted Round Robin | Round Robin com pesos (servidor com peso 3 recebe 3x mais) | Backends com capacidades diferentes | weight=N no servidor |
| Least Connections | Envia para o servidor com menos ligações activas | Pedidos com tempo de resposta variável | least_conn; |
| Least Time | Envia para o servidor com menor tempo de resposta | Backends com performance desigual | least_time; (apenas NGINX Plus) |
| Sticky Round Robin | Fixa o utilizador no primeiro servidor que o atendeu | Aplicações com sessão no servidor (não stateless) | ip_hash; ou sticky cookie |
| IP Hash | Hash do IP do cliente determina o servidor | Sticky sessions baseadas em IP | ip_hash; |
| Random | Escolhe um servidor aleatoriamente | Distribuição simples, testes | Nginx Plus ou random; |
Round Robin
O algoritmo Round Robin é o mais simples e o padrão em praticamente todos os load balancers. Distribui os pedidos de forma circular: o primeiro vai para o servidor 1, o segundo para o servidor 2, o terceiro para o servidor 3, o quarto volta ao servidor 1, e assim sucessivamente.
É adequado quando todos os backends têm a mesma capacidade e os pedidos têm tempos de resposta semelhantes. Se os backends forem heterogéneos ou os pedidos variarem muito em complexidade, o Round Robin pode sobrecarregar backends mais lentos.
Weighted Round Robin
O Weighted Round Robin é uma variante ponderada: cada servidor recebe um peso, e o algoritmo distribui os pedidos proporcionalmente. Um servidor com weight=3 recebe três vezes mais pedidos que um servidor com weight=1.
Isto é útil quando se mistura o servidor original (que foi escalado verticalmente e tem mais recursos) com réplicas mais pequenas e baratas. Em vez de replicar a máquina gigante, mantém-se uma máquina potente e adicionam-se réplicas mais modestas.
Least Connections
O Least Connections é um algoritmo inteligente: envia cada novo pedido para o servidor com o menor número de ligações activas. Se o servidor 1 tem 2 ligações, o servidor 2 tem 5 e o servidor 3 tem 1, o próximo pedido vai para o servidor 3.
Isto resolve o problema do Round Robin quando os pedidos têm tempos de resposta diferentes. Um pedido rápido (e.g. consultar um cache) liberta o servidor quase de imediato, enquanto um pedido lento (e.g. gerar um relatório) mantém a ligação ocupada. O Least Connections ajusta-se dinamicamente, enviando mais pedidos para os servidores que respondem mais rápido.
Least Time
O Least Time vai mais longe: em vez de olhar apenas para o número de ligações, mede o tempo de resposta de cada servidor e envia mais pedidos para os mais rápidos. Se o servidor 1 responde em 150 ms, o servidor 2 em 250 ms e o servidor 3 em 600 ms, o algoritmo envia proporcionalmente mais pedidos para o servidor 1.
Isto permite detectar quando um servidor está a degradar-se (tempo de resposta a aumentar) e aliviar a carga antes que ele caia. No NGINX, o least_time só está disponível no NGINX Plus (versão comercial). Nos load balancers de cloud (AWS, Azure, Google), esta funcionalidade é nativa e mais simples de configurar.
⚠️ Atenção
O least_time no NGINX Open Source gera erro de configuração. Apenas o NGINX Plus suporta esta directiva. Ver NGINX Plus — Load Balancing.
Sticky Round Robin (Session Affinity)
O Sticky Round Robin resolve o problema das aplicações que não são stateless — ou seja, que guardam sessão no servidor (login, dados temporários). Sem sticky, um utilizador que faz login no servidor 1 e cujo próximo pedido calha ir para o servidor 2, perde a sessão.
Com sticky, o primeiro pedido do utilizador A vai para um servidor aleatório (e.g. servidor 3), mas todos os pedidos subsequentes desse utilizador vão sempre para o servidor 3. O utilizador B calha no servidor 1 e fica lá. A palavra “sticky” vem de “adesivo” — o utilizador fica “colado” ao servidor.
IP Hash
O IP Hash é uma forma de implementar sticky sessions: calcula um hash do endereço IP do cliente e usa-o para determinar o servidor. Todos os pedidos do mesmo IP vão sempre para o mesmo backend. É mais simples de configurar que o sticky cookie, mas tem uma limitação: se o IP do cliente mudar (e.g. rede móvel, troca de Wi-Fi para 4G/5G), a afinidade perde-se.
Random
O Random escolhe um servidor aleatoriamente para cada pedido. Não é comum em produção, mas pode ser útil em cenários de teste ou quando se quer uma distribuição simples sem ordem previsível.
ℹ️ Informação: Não existe um algoritmo “melhor” — existe o algoritmo certo para o problema. Round Robin para backends homogéneos, Least Connections para pedidos heterogéneos, Sticky/IP Hash para aplicações com sessão, Least Time para backends com performance desigual. Configurar o algoritmo errado é um dos erros mais comuns em produção.
Passo 1 — Instalar e Configurar NGINX como Load Balancer
O NGINX é o load balancer de software mais popular do mundo. A sua arquitetura event-driven (um processo por worker, não um thread por ligação) permite lidar com milhares de ligações simultâneas com poucos recursos. Esta secção mostra como instalar e configurar o NGINX como load balancer em camada 7, com três backends.
Instalação do NGINX
Debian 12 / Ubuntu 24.04:
RHEL 9 / AlmaLinux 9 / Rocky Linux 9:
Preparar os backends
Para este exemplo, assumimos três backends a correr na mesma máquina (ou em máquinas distintas) nas portas 8001, 8002 e 8003. Podem ser servidores Go, Node.js, Python, Java ou qualquer tecnologia web.
Configuração base do load balancer (Round Robin)
Criar o ficheiro /etc/nginx/conf.d/load-balancer.conf:
Aplicar a configuração
Testar o balanceamento
✓ Correto
O comando nginx -t deve ser sempre executado antes de qualquer reload. Um erro de sintaxe que faça o NGINX reiniciar causa interrupção de serviço. O nginx -s reload é gracioso: os workers antigos terminam as ligações em curso antes de encerrar (NGINX — Command-line Parameters).
Passo 2 — Configurar Algoritmos de Balanceamento
Agora que o load balancer básico está a funcionar com Round Robin, vamos configurar cada algoritmo.
Weighted Round Robin
Atribuir pesos diferentes a cada servidor. O servidor com weight=3 recebe 3 vezes mais pedidos que o de weight=1.
Least Connections
Enviar para o servidor com menos ligações activas. Ideal quando os pedidos têm tempos de resposta variáveis.
Least Time (apenas NGINX Plus)
⚠️ Atenção
O least_time gera erro de configuração no NGINX Open Source. Apenas o NGINX Plus (versão paga) suporta esta directiva. Para simular comportamento semelhante no Open Source, usar least_conn como aproximação. Em load balancers de cloud (AWS ALB, Azure App Gateway), esta funcionalidade é nativa.
Sticky Round Robin (IP Hash)
Garantir que cada utilizador vai sempre para o mesmo servidor, baseado no IP do cliente.
Random com NGINX Plus
ℹ️ Informação: A directiva random está disponível no NGINX Open Source a partir da versão 1.15.1, ao contrário do least_time que é exclusivo do NGINX Plus. Ver NGINX — ngx_http_upstream_module.
Resumo de directivas
| Algoritmo | Directiva NGINX | Disponibilidade |
|---|---|---|
| Round Robin | (predefinido) | Open Source + Plus |
| Weighted Round Robin | weight=N no servidor |
Open Source + Plus |
| Least Connections | least_conn; |
Open Source + Plus |
| Least Time | least_time; |
Apenas NGINX Plus |
| IP Hash | ip_hash; |
Open Source + Plus |
| Random | random; |
Open Source (1.15.1+) + Plus |
| Generic Hash | hash $key; |
Open Source + Plus |
Parâmetros adicionais dos servidores
O max_fails=3 fail_timeout=30s significa que se um servidor falhar 3 vezes em 30 segundos, é marcado como indisponível durante 30 segundos. O servidor backup só recebe tráfego quando todos os outros estão indisponíveis (NGINX — Server Parameters).
Passo 3 — Alternar entre Camada 4 e Camada 7
Uma das vantagens do NGINX é poder alternar entre camada 4 e camada 7 simplesmente mudando a directiva de contexto. A configuração anterior usa http (camada 7). Para mudar para camada 4, basta trocar http por stream e remover as directivas específicas de HTTP.
Configuração em camada 7 (HTTP) — configuração actual
Configuração em camada 4 (TCP/UDP)
⚠️ Cuidado
Ao alternar para camada 4, é preciso remover as directivas location, proxy_set_header e o contexto http. A directiva location só existe em camada 7. Se não se remover, o NGINX gera erro de configuração. O proxy_pass em camada 4 não leva prefixo http:// — aponta directamente para o nome do upstream.
Quando usar cada camada
| Critério | Camada 7 (HTTP) | Camada 4 (TCP/UDP) |
|---|---|---|
| Velocidade | Mais lento (inspecciona HTTP) | Mais rápido (só repassa) |
| Latência | Maior | Menor |
| Roteamento por URL | Sim | Não |
| Rate limiting | Sim | Não |
| Autenticação JWT | Sim | Não |
| WebSocket | Configuração manual | Nativo (TCP persistente) |
| Jogos online / tempo real | Não recomendado | Recomendado (UDP) |
| Aplicações web tradicionais | Recomendado | Não recomendado |
| Inspeccionar headers/cookies | Sim | Não |
✓ Correto
A regra prática é simples: se a aplicação usa HTTP (web, API, e-commerce), usa-se camada 7. Se a aplicação usa TCP/UDP puro (jogos, videoconferência, WebSocket massivo, WhatsApp-like), usa-se camada 4. A transição entre as duas no NGINX é apenas trocar http por stream.
Erros Comuns
| Problema | Causa | Solução |
|---|---|---|
| 502 Bad Gateway | Backend em baixo ou porta errada | Verificar que os backends estão a correr: curl -s http://127.0.0.1:8001/ |
unknown directive "least_time" |
Directiva exclusiva do NGINX Plus | Usar least_conn no Open Source ou mudar para NGINX Plus |
unknown directive "ip_hash" fora do upstream |
ip_hash deve estar dentro do bloco upstream {} |
Mover a directiva para dentro do upstream backend {} |
| Sessões perdidas após escalar | Round Robin sem sticky em aplicação com sessão | Configurar ip_hash; ou sticky cookie |
| Distribuição desigual | Round Robin em backends heterogéneos | Usar weight=N ou least_conn; |
nginx -t falha após mudar para stream |
Directivas HTTP (location, proxy_set_header) deixadas no bloco stream |
Remover todas as directivas HTTP do contexto stream |
| Backend cai e pedidos continuam a ir para ele | max_fails não configurado ou proxy_next_upstream em falta |
Adicionar max_fails=3 fail_timeout=30s e proxy_next_upstream error timeout http_502 http_503 http_504 |
| IP Hash não funciona em rede móvel | IP do cliente muda entre Wi-Fi e 4G/5G | Usar sticky cookie em vez de ip_hash (requer NGINX Plus ou módulo de terceiros) |
| Configuração de camada 4 não balanceia HTTP | stream não lê pedidos HTTP individuais |
Para HTTP, usar http (camada 7); stream balanceia por ligação TCP, não por pedido |
| Latência alta em camada 7 | SSL termination + inspeção HTTP + backend lento | Mover para camada 4 se a aplicação suportar, ou optimizar o backend |
Checklist Rápido de Verificação
Antes de aplicar qualquer configuração de load balancing em produção, confirma:
- Versão do NGINX (deve ser 1.24+ estável):
nginx -v nginx -tpassa sem erros antes de qualquer reload:sudo nginx -t- Todos os backends estão a responder:
curl -s http://127.0.0.1:8001/ && curl -s http://127.0.0.1:8002/ && curl -s http://127.0.0.1:8003/ - Algoritmo correcto para o cenário: Round Robin para backends homogéneos, Least Connections para pedidos heterogéneos, IP Hash para sessões
max_failsefail_timeoutconfigurados em cada servidor do upstream para detetar backends indisponíveisproxy_next_upstreamactivo para que o NGINX tente outro backend quando um falhar- Headers
Host,X-Real-IP,X-Forwarded-For,X-Forwarded-Protoenviados ao backend - Camada correcta: camada 7 (
http) para aplicações web, camada 4 (stream) para TCP/UDP/WebSocket - Rede privada configurada: backends não devem ser acessíveis directamente pela internet
- Staging environment disponível para testar mudanças de algoritmo antes de aplicar em produção
⚠️ Atenção
Comandos que afectam o load balancer em produção (e.g. nginx -s reload, mudança de algoritmo, adicionar/remover backends) devem ser testados em staging e aplicados em janela de manutenção — configuração mal feita pode causar 502 Bad Gateway para todos os utilizadores, sessões perdidas, ou distribuição desigual que sobrecarrega um único backend.
