Estratégias de Balanceamento de Carga do Nginx para Alta Disponibilidade

O balanceamento de carga do Nginx geralmente é introduzido após o primeiro limite doloroso: um servidor de aplicação está muito ocupado, precisa de manutenção ou falha de uma forma que derruba todo o site. Colocar o Nginx na frente de vários backends lhe dá espaço para distribuir requisições, drenar um servidor e sobreviver a falhas comuns.

Não é alta disponibilidade mágica por si só. O Nginx de código aberto pode parar de enviar tráfego para um backend após falhas de conexão, mas não entende profundamente se sua página de checkout, dependência de API ou conexão de banco de dados está saudável. Uma boa configuração combina a configuração de upstream do Nginx, timeouts sensatos, endpoints de saúde em nível de aplicação, monitoramento externo e um processo de implantação que pode remover rapidamente um backend ruim.

Entendendo o Balanceamento de Carga

Em sua essência, o balanceamento de carga é sobre direcionar inteligentemente as requisições dos clientes para um conjunto de servidores. Em vez de um único servidor lidar com todo o tráfego, vários servidores trabalham em conjunto. Isso oferece vários benefícios chave:

• Alta Disponibilidade: Se um servidor falhar de forma detectável, outros podem continuar a lidar com as requisições.
• Escalabilidade: À medida que o tráfego aumenta, você pode adicionar mais servidores ao conjunto para lidar com a carga.
• Desempenho: Distribuir o tráfego evita que qualquer servidor único fique sobrecarregado, levando a tempos de resposta mais rápidos.
• Confiabilidade: Ao remover pontos únicos de falha, sua aplicação se torna mais robusta.

O Nginx atua como um proxy reverso em uma configuração de balanceamento de carga. Ele recebe as requisições dos clientes que chegam e as encaminha para um dos servidores backend disponíveis com base em um algoritmo configurado. Ele também recebe a resposta do servidor backend e a envia de volta ao cliente, tornando o processo transparente para o usuário final.

Diretivas de Balanceamento de Carga do Nginx

O Nginx utiliza diretivas específicas dentro de seu arquivo de configuração (tipicamente nginx.conf ou arquivos incluídos a partir dele) para definir grupos de servidores upstream e seu comportamento de balanceamento de carga.

O Bloco upstream

O bloco upstream é usado para definir um grupo de servidores para os quais o Nginx balanceará o tráfego. Este bloco geralmente é colocado no contexto http.

http {
    upstream my_backend_servers {
        # Configurações do servidor vão aqui
    }

    server {
        listen 80;
        server_name example.com;

        location / {
            proxy_pass http://my_backend_servers;
        }
    }
}

Dentro do bloco upstream, você lista os servidores backend usando a diretiva server, especificando seus endereços IP ou nomes de host e portas.

upstream my_backend_servers {
    server backend1.example.com;
    server backend2.example.com;
    server 192.168.1.100:8080;
}

A Diretiva proxy_pass

A diretiva proxy_pass, usada dentro de um bloco location, aponta para o grupo upstream que você definiu. O Nginx usará então o algoritmo de balanceamento de carga configurado para selecionar um servidor deste grupo para cada requisição.

Algoritmos de Balanceamento de Carga do Nginx

O Nginx suporta vários algoritmos de balanceamento de carga, cada um com sua própria abordagem para distribuir o tráfego. O algoritmo padrão é o Round Robin.

1. Round Robin (Padrão)

No Round Robin, o Nginx distribui as requisições sequencialmente para cada servidor no grupo upstream. Cada servidor recebe uma parcela igual da carga ao longo do tempo. É simples, eficaz para servidores idênticos e o método mais comumente usado.

Configuração:

upstream my_backend_servers {
    server backend1.example.com;
    server backend2.example.com;
    server backend3.example.com;
}

Prós:

• Simples de implementar e entender.
• Distribui a carga uniformemente se os servidores tiverem capacidade semelhante.

Contras:

• Não leva em conta a carga do servidor ou os tempos de resposta. Um servidor lento ainda pode receber requisições.

2. Round Robin Ponderado

O Round Robin Ponderado permite que você atribua um peso a cada servidor. Servidores com um peso maior receberão uma parcela proporcionalmente maior do tráfego. Isso é útil quando você tem servidores com capacidades diferentes (por exemplo, hardware mais potente).

Configuração:

upstream my_backend_servers {
    server backend1.example.com weight=3;
    server backend2.example.com weight=1;
}

Neste exemplo, backend1.example.com receberá três vezes mais requisições do que backend2.example.com.

Prós:

• Permite o balanceamento com base na capacidade do servidor.

Contras:

• Ainda não leva em conta a carga do servidor em tempo real.

3. Least-Connected

O algoritmo Least-Connected direciona as requisições para o servidor com o menor número de conexões ativas. Este método é mais dinâmico, pois considera a carga atual em cada servidor.

Configuração:

Para habilitar o Least-Connected, você simplesmente adiciona o parâmetro least_conn ao bloco upstream:

upstream my_backend_servers {
    least_conn;
    server backend1.example.com;
    server backend2.example.com;
    server backend3.example.com;
}

Prós:

• Distribui a carga de forma mais inteligente, considerando a carga atual do servidor.
• Bom para aplicações com durações de conexão variáveis.

Contras:

• Pode ser um pouco mais complexo de gerenciar se as contagens de conexão flutuarem rapidamente.

4. IP Hash

Com o IP Hash, o Nginx determina qual servidor deve lidar com uma requisição com base em um hash do endereço IP do cliente. Isso garante que as requisições do mesmo endereço IP do cliente sejam consistentemente enviadas para o mesmo servidor backend. Isso é crucial para aplicações que dependem de persistência de sessão (sessões fixas) sem usar armazenamento de sessão compartilhado.

Configuração:

Adicione o parâmetro ip_hash ao bloco upstream:

upstream my_backend_servers {
    ip_hash;
    server backend1.example.com;
    server backend2.example.com;
}

Prós:

• Fornece persistência de sessão pronta para uso.

Contras:

• Pode levar a uma distribuição desigual de carga se muitos clientes compartilharem um único endereço IP (por exemplo, atrás de um gateway NAT).
• Se um servidor falhar, todos os clientes com hash para esse servidor serão afetados até que o servidor volte a ficar online ou o hash seja recalculado (embora o Nginx tente redirecionar).

5. Hash Genérico

Semelhante ao IP Hash, o Hash Genérico permite que você especifique uma chave para hash. Esta chave pode ser uma variável como $request_id, $cookie_jsessionid ou uma combinação de variáveis. Isso oferece mais flexibilidade para persistência de sessão ou roteamento com base em atributos específicos da requisição.

Configuração:

upstream my_backend_servers {
    hash $remote_addr consistent;
    server backend1.example.com;
    server backend2.example.com;
}

Usar consistent com hash implementa hashing consistente, que minimiza a redistribuição de chaves quando o conjunto de servidores muda.

Prós:

• Altamente flexível para lógica de roteamento personalizada.
• Suporta hashing consistente para melhor estabilidade durante mudanças de servidor.

Contras:

• Requer seleção cuidadosa da chave de hash.

Verificações de Saúde e Status do Servidor

Para uma alta disponibilidade útil, o Nginx precisa evitar backends que estão falhando. A versão de código aberto faz isso principalmente de forma passiva: ela percebe tentativas falhas ao fazer proxy de tráfego real. Isso ajuda com hosts mortos, conexões recusadas e alguns casos de timeout. Não é o mesmo que uma verificação de saúde ativa que chama /healthz a cada poucos segundos antes dos usuários atingirem o serviço.

max_fails e fail_timeout

Esses parâmetros, adicionados à diretiva server dentro de um bloco upstream, controlam como o Nginx trata servidores com falha.

• max_fails: O número de tentativas mal-sucedidas de comunicação com um servidor dentro de um período fail_timeout especificado. Após max_fails falhas, o servidor é marcado como indisponível.
• fail_timeout: A duração pela qual um servidor é considerado indisponível. Após este período, o Nginx tentará verificar seu status novamente.

Configuração:

upstream my_backend_servers {
    server backend1.example.com max_fails=3 fail_timeout=30s;
    server backend2.example.com max_fails=3 fail_timeout=30s;
}

Neste exemplo, se backend1.example.com tiver três tentativas mal-sucedidas durante a janela de falha, o Nginx o evita temporariamente. Após o timeout, o Nginx pode tentar novamente. As falhas são baseadas em tentativas de conexão/proxy, não em uma resposta de saúde de aplicação personalizada, a menos que você esteja usando ferramentas adicionais ou recursos do Nginx Plus.

Parâmetro backup

O parâmetro backup designa um servidor como backup. Ele só receberá tráfego se todos os outros servidores ativos no grupo upstream estiverem indisponíveis.

Configuração:

upstream my_backend_servers {
    server backend1.example.com;
    server backend2.example.com;
    server backup.example.com backup;
}

Se backend1 e backend2 estiverem inativos, backup.example.com assumirá.

Verificações de Saúde do Nginx Plus

O Nginx Plus, a versão comercial, inclui verificações de saúde ativas integradas. Ele pode enviar periodicamente requisições para backends, avaliar respostas e remover servidores não saudáveis antes que o tráfego do usuário seja roteado para lá. Se você estiver usando o Nginx de código aberto, ainda pode construir um sistema sólido, mas normalmente o combina com monitoramento externo, descoberta de serviços ou automação que edita/remove alvos upstream.

Exemplos Práticos de Configuração

Vamos colocar esses conceitos em prática com cenários comuns.

Cenário 1: Balanceamento de Carga Round Robin Simples

Distribuir o tráfego entre dois servidores web idênticos.

Configuração:

http {
    upstream web_servers {
        server 10.0.0.10;
        server 10.0.0.11;
    }

    server {
        listen 80;
        server_name yourdomain.com;

        location / {
            proxy_pass http://web_servers;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;
        }
    }
}

Explicação:

• upstream web_servers: Define um grupo chamado web_servers.
• server 10.0.0.10; e server 10.0.0.11;: Especifica os servidores backend.
• proxy_pass http://web_servers;: Direciona o tráfego para o grupo upstream web_servers.
• proxy_set_header: Essas diretivas são cruciais para passar informações originais do cliente para os servidores backend, o que geralmente é necessário para logging ou lógica de aplicação.

Cenário 2: Balanceamento de Carga com Persistência de Sessão (IP Hash)

Garantir que os usuários permaneçam conectados ao mesmo servidor backend, útil para aplicações que armazenam dados de sessão localmente.

Use isso apenas quando você entender a compensação. Se muitos usuários vierem através do mesmo NAT de escritório, gateway de operadora móvel ou proxy corporativo, o IP hash pode enviar muito tráfego para um backend. Armazenamento de sessão compartilhado, cookies sem estado assinados ou replicação de sessão em nível de aplicação são geralmente mais limpos do que depender da fixação do IP do cliente.

Configuração:

http {
    upstream app_servers {
        ip_hash;
        server 192.168.1.50:8000;
        server 192.168.1.51:8000;
    }

    server {
        listen 80;
        server_name api.yourdomain.com;

        location / {
            proxy_pass http://app_servers;
            # ... outras diretivas proxy_set_header ...
        }
    }
}

Cenário 3: Balanceamento de Carga Ponderado com Failover

Direcionar mais tráfego para um servidor mais potente e ter um backup pronto.

Configuração:

http {
    upstream balanced_app {
        server app_server_1.local weight=5;
        server app_server_2.local weight=2;
        server app_server_3.local backup;
    }

    server {
        listen 80;
        server_name staging.yourdomain.com;

        location / {
            proxy_pass http://balanced_app;
            # ... outras diretivas proxy_set_header ...
        }
    }
}

Aqui, app_server_1.local recebe 5 partes do tráfego, app_server_2.local recebe 2 partes, e app_server_3.local só atende requisições se os outros dois estiverem indisponíveis.

Melhores Práticas e Dicas

• Use proxy_set_header: Sempre defina cabeçalhos como Host, X-Real-IP, X-Forwarded-For e X-Forwarded-Proto para que suas aplicações backend conheçam os detalhes originais do cliente.
• Mantenha o Nginx Atualizado: Certifique-se de estar executando uma versão estável e atualizada do Nginx para melhorias de segurança e desempenho.
• Monitore os Servidores Backend: Implemente ferramentas de monitoramento externo além das verificações de saúde internas do Nginx. O Nginx só sabe se pode alcançar um servidor, não necessariamente se a aplicação no servidor está funcionando corretamente.
• Considere o Nginx Plus: Para aplicações de missão crítica, o Nginx Plus oferece recursos avançados como verificações de saúde ativas, persistência de sessão e monitoramento de atividade ao vivo, que podem simplificar o gerenciamento e melhorar a resiliência.
• Balanceamento de Carga DNS: Para distribuição de tráfego entre regiões ou múltiplos pontos de entrada do Nginx, o DNS pode ajudar, mas o failover de DNS depende do comportamento do resolvedor e dos TTLs. Não o trate como failover instantâneo.
• Terminação SSL: Você pode frequentemente terminar o SSL no balanceador de carga (Nginx) para aliviar o processamento SSL de seus servidores backend.

Um Ponto de Partida Prático

Para dois ou três servidores de aplicação idênticos, comece com round robin simples, timeouts de proxy conservadores e logging upstream claro. Adicione max_fails e fail_timeout, depois teste o que acontece quando você para um backend. Não espere por um incidente real para aprender como o Nginx se comporta.

Se as requisições levarem tempos muito diferentes, tente least_conn. Se um servidor for maior que os outros, use pesos. Se a aplicação armazenar estado de sessão localmente, corrija o design da sessão se puder; use ip_hash apenas quando precisar de uma ponte prática.

A melhor estratégia de balanceamento de carga do Nginx é aquela que corresponde a como sua aplicação falha. Uma VM morta, um backend lento, um lançamento quebrado e uma interrupção de banco de dados parecem todos diferentes do ponto de vista do proxy. Configure o algoritmo, depois prove o comportamento de falha com pequenos testes antes de chamar a configuração de altamente disponível.