Arquitetura de Projetos Web Corporativos

Visão Geral da Estrutura

Análise da Arquitetura

1. O cliente envia requisições através do firewall corporativo
2. Antes de os servidores de aplicação (como Tomcat) receberem as requisições, em ambientes de alto volume de acesso, servidores primários e secundários de balanceamento de carga são inseridos para distribuir as requisições entre diferentes servidores web
3. Os servidores interagem com o banco de dados — cenários de alta concorrência também demandam soluções específicas para o banco
4. Adicionalmente, múltiplos servidores são incluídos para cache, processamento de mensagens e outras tarefas

Alta Concorrência

Locais Onde a Alta Concorrência Ocorre

1. No nível do balanceador de carga
2. No nível do banco de dados

Abordagens Iniciais para Lidar com Alta Concorrência

As soluções para alta concorrência geralmente se concentram em dois eixos: nível de infraestrutura e nível de aplicação (hardware e software).

Primeiro eixo: Escalar verticalmente — aumentar CPU, memória ou adquirir servidores mais potentes. Porém, à medida que o negócio cresce, o desempenho do hardware atinge seus limites.

Segundo eixo: Otimizar no nível de software — utilizar HTML estático, separar servidores de imagens, empregar cache distribuído e reduzir a quantidade de dados requisitados simultaneamente pelos clientes.

Existem três estratégias principais utilizando balanceamento de carga para resolver problemas de acesso concorrente.

DNS como Balanceador

O que é DNS

Em termos simples, o Domain Name System (DNS) é uma base de dados distribuída na internet que mapeia nomes de domínio para endereços IP, facilitando o acesso dos usuários aos recursos online. Por exemplo, se uma aplicação é implantada nos servidores 192.168.55.145 e 192.168.55.144, o DNS permite configurar um ponto de acesso unificado como www.exemplo.com.br. O usuário acessa esse domínio sem precisar memorizar endereços IP — o sistema de resolução converte automaticamente o nome no IP correspondente.

Balanceamento via DNS

No servidor DNS, é possível associar múltiplos endereços IP a um mesmo nome de domínio. Quando diferentes clientes resolvem esse nome, recebem IPs distintos aleatoriamente, direcionando-os para servidores web diferentes. Ou seja, uma mesma URL pode levar usuários distintos a servidores distintos, distribuindo a carga.

Para volumes ainda maiores, o DNS pode ser configurado em estrutura hierárquica, onde múltiplos servidores DNS encadeiam a resolução antes de alcançar os servidores de aplicação, ampliando a capacidade de atendimento.

Contudo, no balanceamento via DNS, se um servidor falhar, o DNS continuará enviando requisições para a máquina com problema até que ela seja manualmente removida da configuração. O usuário só conseguirá acessar o site após o timeout de conexão DNS.

Benefícios do Balanceamento de Carga

Ao escalar horizontalmente os servidores de aplicação e inserir um balanceador entre clientes e servidores, três funcionalidades essenciais são obtidas:

1. Distribuição de requisições: Algoritmos como round-robin ou ponderação direcionam requisições para diferentes servidores, aliviando a carga individual e elevando a capacidade concorrente do sistema.
2. Remoção de falhas: Através de verificações periódicas de saúde (health checks), o balanceador identifica servidores indisponíveis e redireciona automaticamente as requisições para os demais.
3. Reintegração automática: Quando um servidor que falhou volta a operar, o balanceador o reincorpora automaticamente ao pool de servidores ativos.

Nginx

Visão Geral do Nginx

Aplicações do Nginx

O Nginx é um servidor web leve que também funciona como proxy reverso e servidor de e-mail (IMAP/POP3). Desenvolvido pelo engenheiro russo Igor Sysoev, destaca-se pelo baixo consumo de memória e alta capacidade de processamento concorrente. Grandes empresas como Baidu, Sina, NetEase e Tencent utilizam Nginx em seus ambientes de produção.

Vantagens do Nginx

1. Execução multiplataforma: Linux, Windows e outros sistemas
2. Sob alta concorrência, o Nginx pode suportar até 50.000 conexões simultâneas

Como o Nginx Realiza Balanceamento de Carga

Proxy Reverso com Nginx

O Nginx utiliza sua funcionalidade de proxy reverso, configurada no arquivo de configuração, para atuar como intermediário. Ele recebe requisições dos clientes e as encaminha para servidores de aplicação internos, retornando as respostas ao cliente. Para o mundo externo, o proxy se comporta como um servidor convencional, embora apenas repasse requisições sem processá-las.

Estratégias de Distribuição do Nginx (upstream)

O Nginx oferece múltiplos algoritmos para distribuir requisições: round-robin, hash por IP, hash por URL, ponderação e outros. Também suporta verificação de saúde dos servidores backend, implementando as funcionalidades de remoção de falhas e reintegração automática.

1. Round-Robin (padrão) Cada requisição é distribuída sequencialmente entre os servidores disponíveis. Se um servidor ficar indisponível, é automaticamente removido da rotação.
2. Ponderação (Weight) Através de pesos configurados, a proporção de requisições direcionadas a cada servidor é proporcional ao seu peso. Ideal quando os servidores possuem capacidades de hardware diferentes.
3. Hash por IP Cada requisição é direcionada com base no hash do IP do visitante, garantindo que um mesmo cliente sempre acesse o mesmo servidor. Soluciona problemas de compartilhamento de sessão.

Configuração do Balanceamento no Nginx (upstream)

Conceito adicional: O Nginx suporta balanceamento de carga na camada 4 (TCP/UDP) através da flag --with-stream, além do balanceamento padrão na camada 7 (HTTP).

O balanceamento TCP do Nginx opera em nível inferior e oferece desempenho superior ao balanceamento HTTP tradicional. Entretanto, o LVS opera em nível de kernel e tende a ser mais eficiente que o Nginx, que funciona em espaço de usuário e possui maior overhead.

Exemplo de configuração básica do upstream

upstream servidores_backend {
    server 10.0.1.10:8080 weight=3;
    server 10.0.1.11:8080;
}

server {
    listen 80;
    server_name app.meudominio.com.br;

    location / {
        proxy_pass http://servidores_backend;
        index index.html index.htm;
    }
}

Nesta configuração, ao acessar app.meudominio.com.br, todas as requisições passam pelo Nginx, que consulta o bloco upstream "servidores_backend". O servidor 10.0.1.10 recebe a maioria das requisições devido ao peso 3, enquanto 10.0.1.11 recebe o restante. O balanceamento é condicionado à capacidade de processamento de cada servidor.

Configuração avançada do upstream

upstream pool_aplicacao {
    server 10.0.1.10:9090 down;
    server 10.0.1.10:8080 weight=2;
    server 10.0.1.10:6060;
    server 10.0.1.10:7070 backup;
}

Parâmetros disponíveis:

1. down: Indica que o servidor está temporariamente fora do pool de balanceamento
2. weight: Valor padrão 1. Quanto maior o peso, maior a proporção de requisições recebidas
3. max_fails: Número máximo de falhas permitidas (padrão: 1). Ao exceder, retorna o erro definido pelo módulo proxy_next_upstream
4. fail_timeout: Período de pausa após atingir o limite de falhas (max_fails)
5. backup: Servidor ativado apenas quando todos os demais estão indisponíveis ou sobrecarregados, recebendo assim a menor carga

Alta Disponibilidade do Nginx

Além de garantir alta disponibilidade da aplicação através de múltiplos servidores, é crucial que o próprio balanceador de carga seja altamente disponível. Se o balanceador falhar, todo o sistema fica comprometido.

A solução é implementar redundância: adicionar múltiplos servidores Nginx para evitar ponto único de falha. Uma abordagem comum é utilizar Keepalived em conjunto com Nginx para garantir failover automático do balanceador.

LVS (Linux Virtual Server)

Visão Geral do LVS

O que é LVS

O LVS (Linux Virtual Server) é uma solução de cluster que utiliza tecnologias de virtualização implementadas diretamante no kernel Linux para criar um sistema de servidores virtuais de alto desempenho e alta disponibilidade.

Componentes Principais do LVS

1. Escalonador de Carga (Director) É a máquina frontal do cluster, visível externamente. Responsável por distribuir as requisições dos clientes entre o grupo de servidores. Para o cliente, o serviço parece originar de um único endereço IP virtual. Funcionalmente, equivale ao proxy reverso do Nginx ou à resolução DNS.
2. Pool de Servidores (Real Servers) Conjunto de máquinas que efetivamente processam as requisições dos clinetes. Podem executar serviços como web, e-mail, FTP e DNS.
3. Armazenamento Compartilhado Proporciona uma área de armazenamento unificada para o pool de servidores, facilitando a sincronização de conteúdo. Esta é uma diferença significativa em relação ao Nginx: o LVS pode utilizar armazenamento compartilhado para manter sessões consistentes entre múltiplos servidores de aplicação.

Como o LVS Implementa Balanceamento

O LVS emprega três técnicas de balanceamento baseadas em IP: VS/NAT, VS/TUN e VS/DR. No VS/NAT (o mais simples), todos os Real Servers configuram seu gateway apontando para o Director. O Director pode inclusive funcionar simultaneamente como um Real Server. Porém, nesta modalidade, a capacidade do Director em gerenciar Real Servers é limitada.

Comparação entre Modos de Operação

	NAT	TUN	DR
Requisitos do backend	Qualquer	Tunneling habilitado	Dispositivo Non-ARP
Rede dos servidores	Privada	LAN/WAN	LAN
Quantidade de servidores	Baixa (10-20)	Alta (100)	Alta (100)
Gateway dos servidores	Load Balancer	Roteador próprio	Roteador próprio

LVS-NAT vs LVS-FullNAT

• Tanto requisições quanto respostas passam pelo Director
• No modo NAT, o gateway dos Real Servers deve apontar para o DIP do Director
• No modo FullNAT, RIP e DIP não precisam estar na mesma rede IP, mas devem ser capazes de se comunicar

LVS-DR vs LVS-TUN

• Apenas a requisição passa pelo Director; a resposta é enviada diretamente pelo Real Server ao cliente
• No modo DR: encapsulamento via cabeçalho MAC, retransmissão na camada de enlace
• No modo TUN: encapsulamento com novo cabeçalho IP sobre o pacote original, permitindo comunicação em longa distância

Modo DR em Detalhe

O modo DR (Direct Routing) reescreve o endereço MAC de destino do pacote de requisição, encaminhando-o ao servidor real. O servidor real retorna a resposta diretamente ao cliente, sem passar pelo escalonador.

a) O escalonador altera o endereço MAC de destino do pacote. O IP de origem permanece como CIP e o IP de destino como VIP.

b) A requisição passa pelo escalonador, mas a resposta do Real Server vai direto ao cliente. Isso confere alta eficiência sob grande volume de acessos, superando o modelo de proxy do Nginx neste aspecto.

c) Como o modo DR depende de reescrita de endereços MAC, todos os Real Servers e o escalonador devem estar na mesma rede local (LAN). É necessário configurar o VIP nos Real Servers (lo:vip/32) e suprimir respostas ARP.

d) O gateway padrão dos Real Servers não deve ser o DIP do escalonador, mas sim o roteador superior designado pelo datacenter (para servidores com IP público).

e) O escalonador no modo DR opera na camada 2 (enlace de dados/MAC), enquanto o modo NAT opera nas camadas 3 (rede/IP) e 4 (transporte/porta).

f) O escalonador do LVS suporta praticamente todos os sistemas UNIX/Linux, mas não Windows. Os Real Servers podem executar Windows.

g) O modo DR é muito eficiente, porém mais complexo de configurar. Para volumes de acesso moderados (abaixo de 10-20 milhões de pageviews diários ou menos de 10.000 requisições simultâneas), soluções como HAProxy ou Nginx são alternativas viáveis e mais simples.

h) Servidores com serviços expostos externamente (como web) devem preferencialmente utilizar IP público. Servidores para serviços internos (como MySQL ou storage) devem usar apenas IP privado.

Fluxo de Pacotes no Modo DR

(a) A requisição do cliente chega ao Director Server. O pacote entra na cadeia PREROUTING do kernel. IP de origem: CIP. IP de destino: VIP.

(b) A cadeia PREROUTING identifica que o IP de destino pertace ao próprio host e encaminha para a cadeia INPUT.

(c) O módulo IPVS verifica que se trata de uma requisição para serviço em cluster. Altera o MAC de origem para o MAC do DIP e o MAC de destino para o MAC do RIP, enviando para a cadeia POSTROUTING. IPs de origem e destino permanecem inalterados.

(d) Como Director e Real Servers estão na mesma rede, a transmissão ocorre na camada 2. POSTROUTING direciona o pacote ao Real Server cujo MAC corresponde ao RIP.

(e) O Real Server identifica que o MAC de destino é o seu próprio e processa o pacote. A resposta é enviada via interface lo para a interface eth0 e transmitida externamente. IP de origem da resposta: VIP. IP de destino: CIP.

(f) A resposta chega ao cliente.

Algoritmos de Escalonamento do LVS

Algoritmos Comuns

• WRR (Weighted Round Robin): Escalonamento cíclico baseado nos pesos dos Real Servers.
• LC (Least Connections): Seleciona o servidor com menor número de conexões ativas.
• WLC (Weighted Least Connections): Combina pesos e conexões ativas para a seleção. É o algoritmo padrão do LVS.
• SH (Source Hashing): Utiliza o IP de origem como chave de hash para selecionar o servidor, garantindo que o mesmo cliente sempre acesse o mesmo servidor.
• DH (Destination Hashing): Oposto ao SH — utiliza o IP de destino como chave de hash para encontrar o servidor correspondente.

Algoritmos Avançados

• LBLC (Locality-Based Least Connections): Direcionado a clusters de cache. Seleciona o servidor que recentemente atendeu ao IP de destino, aplicando LC como fallback quando o servidor está sobrecarregado ou indisponível.
• LBLCR (LBLC with Replication): Similar ao LBLC, porém mantém mapeamento de um IP de destino para um grupo de servidores (ao invés de um único), proporcionando redundância no cache.
• SED (Shortest Expected Delay): Baseado no WLC, calcula o menor atraso esperado usando a fórmula: (conexões_ativas + 1) × 256 / peso.
• NQ (Never Queue): Se algum servidor não possui conexões ativas, a requisição é direcionada imediatamente a ele. Se todos estão ocupados, aplica o algoritmo SED.

LVS + Keepalived para Alta Disponibilidade

Assim como o Nginx, o LVS também requer redundância no escalonador. A combinação LVS com Keepalived implementa failover automático entre múltiplos Directors, garantindo que a falha de um escalonador não comprometa o sistema como um todo.