Revisado em 12/11/2026.
Resposta direta: aumentar réplicas inicia mais cópias da aplicação nos servidores disponíveis. Adicionar nós amplia os recursos do cluster. Uma ação não substitui a outra: se o gargalo está no banco, numa API externa ou no código, nenhuma delas garante que a aplicação fique mais rápida.
Este guia é para quem mantém uma aplicação em containers numa VPS e quer entender o que precisa mudar para atender um pico. O exemplo usa Docker Swarm; os comandos de inspeção devem ser executados por quem administra o cluster. Os comandos que alteram réplicas ou drenam nós devem ser ensaiados em homologação antes de qualquer mudança em produção.
Réplicas e nós são duas decisões diferentes
Uma réplica é uma cópia do serviço. Um nó é um servidor que participa do cluster. O Swarm agenda tarefas nos nós elegíveis, considerando disponibilidade, reservas de recursos e regras de posicionamento.
| Situação observada | Hipótese | Próxima verificação |
|---|---|---|
| Aplicação em fila e nós com recursos livres | Poucas réplicas ou limite de concorrência no serviço | Medir tempo de resposta, recursos por container e capacidade do banco antes de aumentar réplicas |
| Nós sem recursos disponíveis para a aplicação | Falta de capacidade de máquina | Conferir reservas, limites, tarefas concorrentes e possibilidade de adicionar nó |
| Réplicas pendentes | Falta de recursos ou regra que impede o agendamento | Ler o erro da tarefa; não concluir que falta CPU só pelo estado pendente |
| CPU baixa e banco ou API externa lentos | Gargalo fora da execução da aplicação | Investigar consultas, conexões, rede e serviços externos |
| Mais réplicas e mais erros no banco | Concorrência excedeu a capacidade de uma dependência | Rever pools de conexão e trabalho por requisição |
O comando abaixo é um exemplo ilustrativo de alteração, não uma recomendação de quantidade para seu ambiente:
# Executado no manager; substitua pelo serviço e pela quantidade avaliada.
docker service scale loja_backend=3
Ele muda o número desejado de réplicas de um serviço replicado. Não cria VPS nem instância AWS. A referência de docker service scale descreve esse escopo.
Como verificar o que o Swarm está fazendo
Comece pelo estado desejado e pelo estado real, sem alterar o serviço:
# No manager: nós disponíveis e réplicas dos serviços.
docker node ls
docker service ls
# Substitua loja_backend pelo nome real.
docker service ps --no-trunc loja_backend
docker service inspect --pretty loja_backend
Em service ps, leia as colunas de nó, estado e erro. Mensagens de imagem indisponível, restrição de posicionamento ou recursos insuficientes pedem ações diferentes. Confira também se o novo nó consegue baixar a imagem e alcançar as dependências privadas.
Para observar consumo, docker stats --no-stream mostra os containers do host onde foi executado. Ele não é um painel agregado do cluster. Colete no período do pico, nos nós relevantes, junto das métricas de resposta e erros da aplicação. Use o guia de teste de carga para planejar uma medição controlada.
Não dimensione memória apenas pelo uso instantâneo. Considere o que está reservado, o pico observado, os limites dos serviços e a capacidade que deve sobrar para o sistema e para dependências.
Adicionei um nó: por que ele continua sem tarefas?
Um nó novo não provoca redistribuição automática de todas as tarefas que já estão saudáveis. O Swarm evita movê-las só para equilibrar os servidores. Novas tarefas podem ser agendadas no nó, desde que ele cumpra os requisitos do serviço.
Esse comportamento é documentado no guia de administração do Swarm. O guia também explica que forçar uma atualização redistribui tarefas reiniciando-as, o que pode interromper clientes. Por isso, não use docker service update --force como uma otimização automática sem avaliar disponibilidade, atualização gradual e impacto.
O fluxo a testar é:
- Registrar o estado e a capacidade atuais.
- Adicionar o nó por um processo de provisionamento verificado.
- Confirmar que ele está pronto, tem conectividade e atende às regras de posicionamento.
- Aumentar a quantidade desejada de réplicas de acordo com a capacidade e o cenário de carga.
- Conferir onde as novas tarefas foram agendadas e se respondem pelo caminho real do cliente.
- Comparar latência, erros e uso das dependências antes de manter a mudança.
O desenho abaixo ilustra o mecanismo, sem representar um benchmark:
Antes: cliente → entrada HTTP → aplicação na VPS → banco
Depois: cliente → entrada HTTP → réplicas na VPS e no nó extra → banco
O banco continua sendo uma dependência compartilhada. Mais aplicação pode aumentar conexões e consultas sem aumentar a capacidade dele. Veja o diagnóstico de gargalo de MySQL.
O que precisa existir para usar servidores temporários
Métrica e política de decisão
Um comando manual de réplica não é uma política automática. Defina o sinal que justifica expandir, por quanto tempo ele precisa persistir e quais condições permitem reduzir a capacidade. CPU e memória precisam ser lidas junto dos erros, filas e tempo de resposta; CPU baixa não prova que está tudo bem.
Evite decisões opostas a cada leitura. Janelas de observação, limites e intervalos entre ações precisam ser testados para o tempo de inicialização da sua aplicação. Não há valor universal para todo serviço.
Provisionamento e conectividade
A nova máquina precisa receber o runtime, entrar no cluster e alcançar imagens e dependências com credenciais apropriadas. A comunicação entre VPS e nuvem exige regras de firewall e rede privadas compatíveis com a arquitetura. Não publique portas internas indiscriminadamente.
Estar Ready no Swarm não comprova que a aplicação funciona de ponta a ponta. Teste uma resposta real, tamanho de payload, conectividade ao banco e caminho pelo balanceador. Túnel e rede overlay acrescentam encapsulamento; ajuste de MTU deve partir do caminho e da configuração reais, não de um número copiado de outro ambiente.
Estado acessível às réplicas
Sessões, uploads e jobs não podem depender de um container que será removido. Decida o que fica no servidor fixo e o que pode executar nos nós extras. Compartilhar arquivos ou serviços pela rede também introduz latência e pontos de falha. O guia de estado local detalha sintomas dessa dependência.
Redução de capacidade e encerramento
O Swarm permite mudar um nó para drain, retirando dele tarefas de serviços gerenciados pelo Swarm e agendando substituições em nós elegíveis. Isso não migra o estado de memória de uma requisição em andamento. Aplicação, proxy, tempo de encerramento e capacidade restante precisam permitir a transição.
Antes de destruir a máquina, confirme o destino das tarefas, a saúde das réplicas substitutas e o comportamento de requisições longas. Containers avulsos, fora de serviços do Swarm, exigem tratamento separado. O procedimento oficial de drain explica esse limite.
Orçamento e limpeza de recursos
Defina quantidade máxima de nós e critérios para bloquear novas criações. Registre recursos criados e confira o que continua cobrável depois de encerrá-los, como volumes e outros serviços utilizados. Encerrar computação não equivale a zerar toda a conta de nuvem.
Preciso migrar para Kubernetes para ter autoscaling?
Não necessariamente. Kubernetes tem recursos e integrações para autoscaling, mas a operação depende de métricas e componentes apropriados ao ambiente. Migrar também envolve avaliar rede, manifests, armazenamento e conhecimento da equipe. Não é possível afirmar que seja sempre mais caro ou sempre melhor.
Se sua aplicação já usa Swarm e a necessidade é capacidade temporária, vale comparar uma expansão do ambiente atual com uma migração. Compare esforço de implantação e manutenção, recursos necessários, riscos e custo total. Não decida apenas pela existência de uma função chamada autoscaling.
Onde o SwarmBurst entra
O SwarmBurst é um agente instalado na infraestrutura do cliente para coordenar cloud bursting de Docker Swarm para AWS. A proposta é manter a VPS como base e usar nós temporários nos picos. A compatibilidade da aplicação e a configuração precisam ser avaliadas antes da implantação.
Ele não corrige consulta lenta, plugin com defeito, estado local ou limite de uma API de terceiro. Também não oferece cadastro self-service neste site. O próximo passo disponível é conversar sobre a implantação assistida e conferir requisitos, controle de gasto e comportamento de expansão e redução no seu cenário. GCP e Azure não devem ser tratados como provedores disponíveis do produto atual.
Não apresentamos aqui economia garantida nem resultado de cliente. Um teste em ambiente controlado também não substitui a validação da aplicação real.
Perguntas frequentes
Aumentar réplicas aumenta a capacidade da VPS?
Não aumenta CPU ou RAM. Pode aproveitar melhor recursos livres e atender mais concorrência quando a aplicação permite. Também pode aumentar a contenção e o trabalho do banco. Compare medições antes e depois.
Por que a réplica ficou pendente?
Leia o erro em docker service ps --no-trunc. Recursos reservados, regras de posicionamento, disponibilidade dos nós e outros requisitos podem impedir o agendamento. O estado, sozinho, não identifica a causa.
Posso manter o banco na VPS e executar a aplicação na AWS?
É uma arquitetura possível, mas exige conferir latência, segurança, conexões e capacidade do banco. Ela não se aplica automaticamente a toda aplicação.
Avalie o próximo pico antes de contratar capacidade
Se você administra uma aplicação em VPS e quer avaliar a expansão com Docker Swarm, leve à conversa as métricas do pico, a arquitetura e as dependências. A análise pode concluir que otimizar ou ampliar a VPS é mais adequado.