Auto scaling em VPS: por que subir réplica não resolve pico de tráfego

Resposta direta: aumentar réplicas de um serviço redistribui carga dentro da capacidade de máquina que já existe. Quando o cluster inteiro está com CPU e memória no teto, não falta réplica: falta servidor. Auto scaling em VPS de verdade exige cinco peças que nenhum orquestrador de contêineres entrega sozinho: gatilho por métrica, provisionamento de máquina na nuvem, rede entre o servidor fixo e o efêmero, scale-in que drena antes de encerrar, e teto de custo.

Este post é para quem mantém a infra de clientes e já ouviu a pergunta “por que o site caiu se a gente tinha réplica sobrando?”.

Subir réplica é auto scaling?

Não, ou não completamente. Escalar réplica muda quantas instâncias do seu processo o orquestrador quer manter rodando. Ele então distribui essas instâncias pelos servidores que já estão no cluster. Se todos estão saturados, o resultado é um de dois:

• Mais processo disputando o mesmo hardware. A latência sobe em vez de cair. Você trocou uma fila por várias filas menores no mesmo caixa.
• Réplica parada em estado pendente. Nenhum servidor tem recurso livre para aceitar a tarefa, então ela nunca sai do agendador.

Em Docker, o comando que ilustra isso é direto:

# quantas réplicas o orquestrador deve manter de pé
docker service scale loja_backend=12

O comando é honesto sobre o que faz: ele fala de réplica. Ele não cria máquina nenhuma. É a diferença entre lotar mais gente no mesmo ônibus e chamar outro ônibus.

Escalar réplica x escalar servidor: qual é a diferença

A leitura prática: réplica é ajuste de distribuição, servidor é ajuste de capacidade. Escalar um cluster de contêineres automaticamente significa automatizar os dois, na ordem certa. Primeiro a máquina entra e fica pronta, depois as réplicas se espalham por ela.

Por que não simplesmente migrar para Kubernetes?

Kubernetes resolve os dois níveis de fábrica, com autoscaler de pod e autoscaler de nó. É maduro e é a escolha certa para muita gente. O ponto é o preço da mudança quando o cliente tem uma loja rodando bem numa VPS e o único problema são três picos por ano.

Se o motivo único da migração é auto scaling, a migração é o caminho mais caro para o objetivo. Uma infraestrutura híbrida VPS + nuvem cobre o caso concreto: capacidade extra durante o pico, e nada além disso no resto do mês.

O que precisa existir para escalar máquina de verdade

Estas são as lacunas. Se você for construir por conta, é essa a lista de trabalho, e cada item já derrubou o cluster de alguém.

1. Gatilho por métrica que não oscile

Alguém precisa ler CPU e memória dos servidores e decidir. Decidir na leitura crua de cada ciclo é a receita do flapping: um spike de dois segundos sobe máquina, uma queda momentânea derruba. O que funciona é média móvel com pesos assimétricos (sobe moderado, desce devagar), cooldown separado para scale-up e scale-down, e exigência de carga fria sustentada antes de remover servidor.

Um detalhe que se descobre tarde: medir por host é diferente de medir por contêiner. A média de CPU da máquina inclui tudo que roda nela. Para o gatilho “o cluster está no teto”, isso basta. Para atribuir consumo a um serviço específico, não basta.

2. Provisionamento que entra sozinho no cluster

Criar a instância é a parte fácil, é uma chamada de API. O difícil é a máquina nascer com o runtime de contêiner instalado, subir a rede privada e se apresentar ao cluster sem ninguém digitar nada, com o token de entrada chegando até lá sem virar segredo exposto. Isso é script de inicialização (cloud-init) escrito com cuidado. Adicionar servidor no pico de tráfego manualmente é um comando; fazer isso às 23h de uma Black Friday, com o dono da loja no telefone, é outra coisa.

3. Rede: a parte que quebra silenciosamente

Duas armadilhas específicas, e a segunda é traiçoeira.

Portas de controle expostas. Muito tutorial manda liberar as portas de controle e de rede do cluster para 0.0.0.0/0 no Security Group. Isso publica o plano de controle da sua infra na internet. O caminho sadio é um túnel: o servidor de reforço sobe o túnel em direção à VPS e entra no cluster pelo IP privado, sem nenhuma porta de entrada aberta na instância nova.

MTU. O encapsulamento VXLAN das redes overlay do Docker custa cerca de 50 bytes. Dentro de um túnel WireGuard com MTU 1420, o teto útil da overlay cai para 1370. Se você deixar a rede no default, o pior acontece: a máquina entra no cluster, aparece pronta, os healthchecks passam, e só as respostas maiores que ~1,3 KB desaparecem. Parece bug da aplicação. É pacote sumindo no meio do caminho.

4. Scale-in que não mata requisição em andamento

Marcar um servidor como indisponível retorna imediatamente, mas as réplicas ainda estão migrando para os outros nós. Encerrar a instância nesse instante derruba conexões vivas. A sequência correta tem espera no meio: drenar, aguardar as réplicas de fato migrarem (com teto de tempo, para o servidor nunca ficar preso no processo), parar, confirmar que parou, encerrar, remover do cluster. E stop_grace_period configurado no serviço, senão o contêiner morre no meio do request de qualquer forma.

5. Teto de custo, porque o risco aqui é financeiro

Auto scaling com credencial de nuvem é permissão para gastar dinheiro em loop. O mínimo defensável: orçamento mensal obrigatório que bloqueia novo scale-up, limite de servidores simultâneos, alerta antes de estourar, varredura periódica procurando instância órfã (a que sobrou porque o agente caiu no meio de uma operação) e watchdog para ação travada. Sem isso, o pior cenário não é o site cair. É o site ficar de pé e a fatura chegar.

6. E o estado, que não pode ir para a máquina efêmera

Banco, cache, uploads e frontend ficam pinados no servidor fixo por regra de posicionamento. Só o serviço stateless da aplicação escala para fora. Se uploads vão para disco local, os servidores de reforço precisam montar esse volume pela rede privada. Nada permanente vive numa máquina que vai ser destruída em uma hora.

Onde o SwarmBurst entra

O SwarmBurst é um agente de cloud bursting VPS + AWS para cluster de contêineres. Ele roda no servidor de controle do cluster do cliente. Não é SaaS multi-tenant, é software instalado na infra de quem contrata, e existe exatamente para preencher as seis lacunas acima:

• A VPS do cliente é o único servidor de controle e guarda todo o estado. Os servidores de reforço entram sempre em papel subordinado, nunca de controle.
• O reforço nasce com o túnel WireGuard estabelecido pelo script de inicialização e entra no cluster pelo IP de túnel. O Security Group da instância não precisa de porta de entrada.
• Gatilhos por CPU e memória, com média móvel exponencial e cooldowns configuráveis. Os defaults são 75% de CPU e 80% de memória.
• Escala um serviço nomeado, o da aplicação, pela fórmula base + servidores × réplicas por servidor. O agente não enumera nem toca nos outros serviços do cluster.
• O scale-in drena, espera a migração das réplicas e só então para e encerra a instância.
• Orçamento mensal obrigatório bloqueando scale-up, alertas por e-mail e no painel, limite de servidores, varredura de instâncias órfãs e watchdog de ação travada.
• Credenciais da nuvem cifradas no banco. Telemetria dos servidores de reforço por gRPC, autenticada com token HMAC por instância.
• Catálogo de preço on-demand por região, com sa-east-1, para a estimativa de custo mensal não subestimar quem roda em São Paulo. Na coleta registrada no catálogo do agente em 13/07/2026, uma t3.medium custava US$ 0,0672/h em São Paulo contra US$ 0,0416/h em us-east-1, valores do pricing público da AWS.

O que ele não faz, dito antes de você perguntar:

• Só AWS. GCP e Azure falham com erro explícito em modo real, por decisão de projeto: preferimos quebrar na cara do operador a fingir suporte. São roteiro, não funcionalidade.
• Pré-requisito real: a aplicação precisa rodar em contêineres, num cluster. Se a loja do seu cliente roda direto na VPS sem Docker, existe um passo anterior, e ele não é pequeno.
• Não há cadastro self-serve. A instalação é feita junto com você.
• Não há notificação por WhatsApp. E-mail e in-app funcionam.
• Ainda não passou por um pico real de produção. O agente já provisiona, faz a máquina entrar no cluster, escala o serviço e encerra instância real na AWS em teste validado, com o ciclo completo verificado em smoke test pago. O que falta é o pico de uma loja de verdade, com carga de verdade. Não temos cliente, depoimento nem número de resultado para mostrar, e não vamos inventar nenhum.

Perguntas frequentes

Existe auto scaling em VPS sem trocar de provedor?

Sim. O padrão é infraestrutura híbrida: a aplicação continua na VPS que você já paga, e capacidade extra é alugada por hora na nuvem pública somente durante o pico. A VPS segue sendo o servidor principal. As máquinas da nuvem são acréscimo temporário, e a cobrança delas termina quando são encerradas.

Aumentar réplicas resolve um pico de tráfego?

Só se o gargalo for distribuição, não capacidade. Se o cluster ainda tem CPU e memória livres, mais réplicas ajudam. Se todos os servidores estão no teto, mais réplicas pioram a latência ou ficam pendentes sem serem agendadas. O diagnóstico é olhar o uso de recurso dos nós antes de mexer na contagem de réplicas.

Preciso migrar para Kubernetes só para ter autoscaling?

Não, se auto scaling for o único motivo. A migração traz reescrita de manifests, escolha de CNI, Ingress Controller e curva de aprendizado da equipe. Faz sentido quando você quer o ecossistema inteiro. Para “aguentar o pico da Black Friday”, resolver capacidade no cluster que já roda sai bem mais barato.

Dá para escalar para a nuvem mantendo o banco na VPS?

Sim, e é o desenho recomendado. Banco, cache e uploads ficam pinados no servidor fixo por regra de posicionamento. Só o serviço stateless recebe réplicas nos servidores de reforço, que conversam com a VPS pela rede privada do túnel. Confira o max_connections do banco antes: réplicas máximas × tamanho do pool + margem.

Quanto tempo leva do pico até o reforço estar atendendo?

Depende do provedor, do tipo de instância e da imagem usada. Temos alvo interno para a etapa de detecção do pico, mas não temos o número de ponta a ponta medido num pico de produção real. Quando tivermos, ele vai vir de um cliente com autorização para publicar, não de estimativa nossa.

Piloto do Primeiro Pico

O SwarmBurst está em pré-tração e a oferta reflete isso: um piloto por vez, com implantação gratuita ou simbólica, em troca de autorização para medir e publicar os dados reais do pico e de um depoimento no fim, se a experiência tiver sido boa. Se o caso do seu cliente não encaixar, a gente diz na hora em vez de vender.

Quero o piloto do primeiro pico

Para a versão em linguagem de dono de loja, útil quando é você que precisa explicar ao cliente, a página inicial tem o resumo curto.