Balanceamento de carga na loja virtual: como o acesso é dividido entre o servidor fixo e os servidores extras que sobem no pico

Subir uma segunda máquina não divide o acesso sozinho: sem uma porta de entrada única que receba o visitante e reparta entre os servidores disponíveis, todo mundo continua caindo no primeiro.

Balanceamento de carga na loja virtual é a peça que recebe o visitante e o reparte entre as máquinas disponíveis. Sem ela, o domínio aponta para um IP só, todo mundo cai no mesmo servidor e a segunda máquina fica ligada, cobrando e parada.

• Sem balanceador na frente, o domínio aponta para um IP só e todo visitante cai no mesmo servidor, por mais máquinas ligadas que existam.
• Apontar dois IPs no DNS não é balanceamento: o cache de TTL atrasa a entrada do reforço e o mantém recebendo gente depois de desligado.
• Sem health check, o balanceador manda cliente para máquina que ainda está subindo ou já morreu.
• O balanceador vira o novo ponto único de falha: quem tem uma VPS só troca de risco, não elimina o risco.
• Balancear não conserta gargalo de banco, estado em disco local nem aplicação lenta — aí dividir o acesso só espalha o problema.

Por que o acesso continua caindo no primeiro servidor depois que você subiu o segundo

A segunda máquina só recebe visitante se alguém mandar visitante para ela. Quem chega pelo domínio bate sempre na mesma máquina, no teto ou não.

O servidor novo fica ligado, custando por hora e ocioso, enquanto a lentidão continua igual. No painel de monitoramento da VPS, o sintoma aparece assim:

• a primeira máquina com processador no talo e fila de requisição crescendo;
• a segunda praticamente parada, no mesmo minuto.

Sem balanceador de carga, você comprou um servidor de reserva, não capacidade.

O que é balanceador de carga e o que é proxy reverso

Proxy reverso é o programa que atende o visitante no lugar da aplicação e repassa o pedido para quem responde de verdade.

Balanceador de carga é o proxy reverso com mais de uma máquina de trás, que decide a cada pedido para qual delas mandar. Três programas gratuitos fazem esse papel:

• nginx — o servidor web que já serve muita loja; poucas linhas de configuração o transformam em balanceador.
• HAProxy — feito para esse papel, com relatório de estado detalhado.
• Traefik — desenhado para contêiner, descobre sozinho os serviços que sobem e descem.

O critério de repartição é escolha sua: rodízio, menos conexões abertas ou peso maior para a máquina mais forte. E o domínio passa a apontar para o balanceador, não mais para o servidor da aplicação.

DNS round robin não é balanceamento de carga na loja virtual — o TTL explica por quê

O atalho é cadastrar dois registros A no domínio, um por IP, e deixar o DNS alternar os endereços. Esse DNS round robin não sabe se a máquina está no ar nem se está no teto, e não redistribui nada depois de responder.

TTL é o tempo que o resolvedor guarda a resposta antes de perguntar de novo. Enquanto dura, o visitante continua indo para o IP que recebeu.

• Na entrada: a máquina nova demora a aparecer, porque o endereço em cache ainda aponta só para a antiga. Você paga por capacidade que ninguém usa.
• Na saída, que é pior: depois de desligar o reforço, o IP dele continua circulando e parte dos clientes bate numa máquina que não existe mais — site fora do ar para uma fatia das pessoas.

Baixar o TTL antes ajuda, mas nenhum provedor garante que todo resolvedor respeite o valor. O reforço precisa entrar e sair por dentro da infraestrutura — a diferença entre multiplicar réplica e multiplicar máquina está em auto scaling em VPS.

Health check: o que impede o balanceador de mandar cliente para uma máquina que ainda está subindo

Health check é a checagem repetida que o balanceador faz em cada máquina de trás — pedir uma URL a cada poucos segundos e conferir se a resposta é 200. Quem não responde sai da fila até voltar; sem isso, o cliente recebe erro 502 ou 504.

No burst, o intervalo crítico é o nascimento do nó: a máquina de reforço passa minutos ligada e ainda subindo contêiner e abrindo conexão com o banco. Tráfego nesse intervalo vira erro.

• Checagem rasa demais: responder na porta 80 não prova que a loja funciona; uma URL que toque a aplicação, e quando fizer sentido o banco, prova.
• Checagem pesada demais: verificação cara em frequência alta vira carga extra na máquina que você quer poupar.

Do outro lado está a retirada graciosa: antes de desligar o reforço, ele para de receber pedidos novos e termina os que estão em curso. Evita derrubar carrinho no meio do checkout.

O que o balanceamento não resolve: banco no teto, estado local e aplicação lenta

Dividir o acesso só ajuda se o que está no teto for a máquina de aplicação. Se o gargalo for outro, você espalha o problema.

• Banco de dados é recurso único. Duas máquinas de aplicação abrem o dobro de conexões contra o mesmo MySQL, e o aperto piora: gargalo de banco de dados MySQL na VPS.
• Estado em disco local quebra na hora. Cliente deslogado, carrinho vazio, imagem que abre para um e dá 404 para outro: o que some quando a loja roda em dois servidores.
• Aplicação lenta continua lenta. Consulta ruim ou plugin pesado custa o mesmo em qualquer máquina — achar esse gargalo é assunto de WooCommerce lento com muito acesso.

Sticky session é o remendo dessa hora: o balanceador amarra cada visitante à mesma máquina, por cookie. Segura o sintoma do carrinho e cobra por fora — a fila desequilibra, e quem estava no reforço perde a sessão quando ele sai.

Onde o balanceador vira o novo ponto único de falha

Todo o tráfego passa a entrar por uma peça só: se o balanceador cair, o site cai inteiro. Você não eliminou o ponto único de falha, moveu ele de lugar. A troca costuma compensar, porque o balanceador repassa dado e não executa PHP nem consulta banco — mas é troca.

Instalar o balanceador na mesma VPS que roda a loja funciona e é o arranjo comum de quem tem uma máquina só. A ressalva: a queda dessa VPS derruba tudo, inclusive o caminho até os nós de reforço.

Balanceador redundante — dois nós com IP flutuante, que passa de um para o outro quando um morre — custa mais máquina e mais configuração, e raramente é o primeiro passo de uma loja pequena. Antes de alta disponibilidade, resolva o que derruba a loja hoje: falta de capacidade no pico.

Balancear na sua VPS ou contratar o balanceador do provedor de nuvem

Máquina dedicada para o balanceador não é obrigatória: justifica-se para isolá-lo da loja ou quando o volume é alto o bastante para ele competir com a aplicação por processador.

A desvantagem do gerenciado é a mesma do servidor superdimensionado: cobrança recorrente todo mês, inclusive nos dias sem pico — o oposto de pagar reforço só quando ele existe. A conta de horas está em aumentar o plano ou pagar reforço só no pico.

Como o SwarmBurst reparte o acesso sem mexer em DNS no meio do pico

No Docker Swarm a distribuição já vem embutida: a malha interna recebe o pedido em qualquer nó e entrega para uma réplica disponível. Não existe cadastrar IP novo e torcer para o endereço propagar.

Quando o agente SwarmBurst sobe um nó de reforço na nuvem, ele entra no cluster e recebe requisição pela própria malha, com o domínio apontando para o mesmo lugar do dia normal. Quando o nó sai, para de receber tráfego na hora — sem TTL na entrada nem na saída.

Os pré-requisitos, sem maquiagem:

• Loja em contêiner e estado fora do disco local. Sem os dois, o reforço entra no cluster e quebra em vez de ajudar: loja virtual em contêiner Docker.
• Gargalo na máquina de aplicação. Se o aperto for do banco, o burst piora antes de melhorar; quanto a máquina atual aguenta sai de um teste de carga antes do pico.
• Clareza sobre o que é o burst. O conceito está em o que é cloud bursting.

O acesso é dividido entre o servidor fixo e os extras por uma peça que precisa existir de propósito: um balanceador na frente das máquinas ou a malha de um cluster que já sabe repartir. O que não divide acesso é ligar a segunda máquina e esperar que o tráfego encontre o caminho sozinho.

Quero discutir como dividir o acesso da minha loja no pico

Se a sua loja já está em contêiner e o próximo pico tem data, é uma conversa no WhatsApp para olhar o arranjo atual e dizer o que falta antes do primeiro reforço.

Perguntas frequentes

Qual é a diferença entre load balancer e DNS round robin?

Load balancer é um proxy reverso que atende o visitante e repassa o pedido para uma de várias máquinas, decidindo a cada pedido para qual delas mandar. DNS round robin é apenas um cadastro no servidor de DNS com dois registros A para o mesmo domínio — o DNS não sabe se a máquina está no ar, não redistribui nada depois de ter respondido e o TTL (tempo que o resolvedor guarda a resposta) faz com que a máquina nova demore a aparecer para a maioria dos visitantes.

Enquanto o load balancer toma decisão a cada requisição e verifica se as máquinas estão saudáveis, o DNS round robin é um atalho tentador mas insuficiente: você paga por capacidade que ninguém usa na entrada e, pior ainda, clientes continuam batendo numa máquina que não existe mais na saída.

Nginx pode ser usado como load balancer?

Sim. Nginx é o mesmo servidor web que já serve muita loja e poucas linhas de configuração o transformam em balanceador de carga. Ele funciona como proxy reverso que recebe o visitante e repassa para uma de várias máquinas de trás, com critério de repartição à sua escolha: rodízio simples, menos conexões abertas ou peso maior para a máquina mais forte.

O que é sticky session e quando usar?

Sticky session é quando o balanceador amarra cada visitante à mesma máquina, em geral por cookie. Aparece como remendo quando o gargalo não é a máquina de aplicação — por exemplo, quando há estado em disco local que quebra se o cliente for repartido para outra máquina. Pesa a fila, porque o visitante fica preso onde caiu, e causa perda de sessão quando uma máquina é removida no fim do pico.

Preciso de um servidor adicional só para o balanceador de carga?

Não é obrigatório. Máquina dedicada só para o balanceador se justifica para isolá-lo da loja ou quando o volume é alto o bastante para ele competir por processador com a aplicação. Instalar o balanceador na mesma VPS que roda a loja funciona e é o arranjo comum de quem tem uma máquina só, mas é preciso deixar explícito que a queda daquela VPS derruba tudo, inclusive o caminho até os nós de reforço.