Muitos desenvolvedores acreditam que a escalabilidade horizontal se resume a criar cópias de um servidor e colocar um balanceador de carga na frente. No entanto, o desenvolvimento de sistemas resilientes exige um entendimento profundo de redes, do Modelo OSI e do comportamento da sua aplicação.
Com base no conteúdo técnico de especialistas em arquitetura de software, este artigo detalha os fundamentos essenciais para você dominar o balanceamento de carga e escalar sistemas na vida real.
1. Escalabilidade Vertical vs. Escalabilidade Horizontal
Antes de distribuir o seu sistema em várias máquinas, é preciso entender a ordem natural de evolução de uma infraestrutura.
Escalabilidade Vertical (Scale Up)
Consiste em adicionar mais recursos computacionais ao servidor existente, como mais memória RAM, maior poder de processamento (CPU) ou armazenamento. É o primeiro passo recomendado antes de qualquer alteração arquitetural.
Contudo, ela possui limites físicos óbvios, torna-se extremamente cara a partir de certo ponto e mantém um problema crítico: o SPOF (Single Point of Failure). Se essa máquina única falhar ou o data center cair, a aplicação inteira fica fora do ar.
Escalabilidade Horizontal (Scale Out)
É a estratégia de criar réplicas do servidor da sua aplicação para trabalharem em conjunto. Um Load Balancer (balanceador de carga) é posicionado na ponta para receber todas as requisições dos usuários e distribuí-las entre as réplicas. Isso remove o ponto único de falha e permite o uso de hardware mais simples e barato.
Uma dúvida comum é: se a aplicação precisa de escala por não aguentar o tráfego, por que o Load Balancer, que também é um servidor único, aguenta?
A resposta está no nível de operação. Uma aplicação web tradicional consome muito tempo iniciando frameworks, processando regras de negócio e consultando bancos de dados. O Load Balancer foi projetado exclusivamente para extrair o máximo do hardware em baixo nível, atuando apenas como um direcionador ultraveloz sem executar lógicas pesadas.
2. Camadas de Operação: Camada 4 vs. Camada 7
Os balanceadores de carga não funcionam todos da mesma forma. Eles operam em diferentes camadas do Modelo OSI, e essa escolha muda completamente o comportamento do tráfego.
Camada 4 (Layer 4 - Camada de Transporte)
Opera ao nível de protocolos raiz como TCP e UDP. Este balanceador é considerado "cego", pois não abre e não analisa o conteúdo da requisição; ele enxerga apenas o IP de origem e o IP de destino.
Por não interceptar o pacote, entrega altíssima velocidade, baixíssima latência e grande vazão de dados (throughput). É ideal para:
- Jogos online em tempo real (FPS).
- Aplicações de streaming de vídeo ou chamadas (como Google Meet), que utilizam UDP e aceitam pequenas perdas de pacotes.
- Arquiteturas de mensageria massiva baseadas em conexões persistentes de WebSockets (como o WhatsApp).
Camada 7 (Layer 7 - Camada de Aplicação)
Opera diretamente no nível do protocolo HTTP. Ao contrário da Camada 4, ele intercepta a requisição, desempacota o conteúdo e consegue ler a URL, os headers, os cookies e os tokens de autenticação (como JWT).
Embora adicione uma pequena latência pelo processamento, ele permite um roteamento contextual inteligente. É recomendado para 90% das aplicações web tradicionais, e-commerces e microsserviços, permitindo regras como:
- Se a URL contiver
/pedidos, envie para o Cluster A. - Se a URL contiver
/pagamentos, envie para o Cluster B. - Aplicação centralizada de Rate Limiting e segurança.
3. Configuração Prática no Nginx
Para tirar o conceito do papel e implementar um balanceador de carga em Camada 7, o arquivo de configuração nginx.conf pode ser estruturado de maneira simples. No exemplo abaixo, o bloco upstream backend agrupa as três instâncias da aplicação rodando localmente (nas portas 8001, 8002 e 8003). O servidor do Nginx escuta na porta 8080 e repassa o tráfego usando a diretiva proxy_pass:
4. Algoritmos de Balanceamento e Complementações no Nginx
A escolha do algoritmo correto de distribuição de carga define o sucesso da infraestrutura. Veja abaixo como complementar o bloco upstream do seu Nginx para alterar a estratégia de balanceamento:
Round Robin (Circular)
É o algoritmo padrão (default) do Nginx. Ele distribui as requisições de forma estritamente sequencial e circular. Não exige nenhuma palavra-chave adicional, bastando listar os servidores como no exemplo base:
http {
upstream backend {
server localhost:8001;
server localhost:8002;
server localhost:8003;
}
server {
listen: 8080;
location / {
proxy_pass http://backend;
}
}
}
Weighted Round Robin (Ponderado)
Utilizado quando os servidores possuem capacidades de hardware diferentes. Adiciona-se o parâmetro weight para definir a proporção de carga que cada um deve receber. No exemplo abaixo, a porta 8001 receberá três vezes mais requisições que as outras duas:
http {
upstream backend {
server localhost:8001 weight=3;
server localhost:8002;
server localhost:8003;
}
server {
listen: 8080;
location / {
proxy_pass http://backend;
}
}
}
Least Connections (Menor número de conexões)
Direciona a nova requisição sempre para o servidor que tiver menos conexões ativas no momento da chamada, sendo ideal para aplicações com processamentos pesados e demorados. Para ativá-lo, basta adicionar a diretiva least_conn; no topo do bloco:
http {
upstream backend {
least_conn;
server localhost:8001;
server localhost:8002;
server localhost:8003;
}
server {
listen: 8080;
location / {
proxy_pass http://backend;
}
}
}
Outros Algoritmos Notáveis
- Least Response Time (Menor tempo de resposta): Identificado pela diretiva
least_time(disponível apenas no Nginx Plus), direciona o tráfego com base na latência e saúde em tempo real do servidor. - Sticky Round Robin (Sessões Coladas): Utiliza mecanismos como cookies ou a diretiva
ip_hash;para garantir que um usuário específico seja sempre direcionado para a mesma instância. Essencial para escalar monólitos que guardam estado de sessão em memória (stateful).
Considerações finais
A arquitetura de software de alta disponibilidade é guiada por escolhas e compensações (tradeoffs). Conexões de Camada 4 mantêm o cliente preso a uma conexão TCP aberta de forma persistente, o que é inviável para navegação web comum, mas indispensável para tempo real. Por outro lado, a Camada 7 oferece inteligência de roteamento à custa de mais processamento.
Dominar esses fundamentos de rede e saber configurar o algoritmo correto para a natureza do seu tráfego é o que separa um desenvolvedor comum de um verdadeiro engenheiro de sistemas escaláveis.
Referência
https://nginx.org/en/docs/http/load_balancing.html
Feito!
