O SwarmBurst acrescenta servidores temporários na AWS para reforçar aplicações em VPS durante picos. Entenda os pré-requisitos, os limites e como avaliar a instalação antes da campanha.
Sua loja funciona no dia a dia, mas fica lenta quando a campanha começa? Adicionar nós AWS automaticamente ao Docker Swarm pode ajudar quando falta capacidade para executar a aplicação. O SwarmBurst faz esse reforço mantendo a VPS como base, desde que a aplicação esteja preparada para atender em várias máquinas.
- O SwarmBurst cria servidores na AWS conforme gatilhos configurados de processamento e memória.
- A VPS continua como base; os servidores temporários executam cópias da aplicação.
- Sessões, arquivos e distribuição dos acessos precisam funcionar entre máquinas antes da campanha.
- Mais servidores de aplicação não corrigem banco saturado nem serviço externo lento.
- Depois do pico, o agente encerra as máquinas extras; a VPS e outros custos aplicáveis permanecem.
Quando adicionar nós AWS automaticamente ao Docker Swarm pode ajudar
VPS é um servidor virtual contratado com capacidade definida. Atender o movimento habitual não significa suportar os acessos concentrados de uma campanha. O reforço faz sentido quando falta processamento ou memória para executar a aplicação e esse trabalho pode ser dividido entre máquinas.
A AWS é a nuvem da Amazon, onde o SwarmBurst cria os servidores temporários. Docker Swarm é o sistema que organiza a execução de contêineres, pacotes que reúnem a aplicação e suas dependências. O conjunto de máquinas coordenadas forma o cluster; cada máquina participante é um nó.
O SwarmBurst é um agente instalado no nó gerente, responsável por coordenar o cluster do próprio cliente. Ele acrescenta capacidade ao ambiente existente, sem exigir a transferência de toda a operação para a AWS. A VPS permanece como base fixa.
Essa combinação de estrutura fixa com reforço temporário na nuvem é chamada de cloud bursting. Você usa a capacidade adicional durante o pico e a retira depois. Antes da instalação, porém, é necessário confirmar se o gargalo está na aplicação: acrescentar máquinas sem esse diagnóstico pode gerar despesa sem melhorar o atendimento.
Como o SwarmBurst coloca os servidores extras para trabalhar
O agente acompanha o uso de recursos, não vendas ou pedidos. Sua atuação depende dos gatilhos definidos na configuração. A sequência de reforço envolve:
- Acompanhar CPU, o recurso de processamento, e memória, usada pelos programas em execução.
- Comparar as medições com os gatilhos configurados para solicitar reforço.
- Criar instâncias EC2, as máquinas virtuais da AWS, na conta do cliente.
- Conectar as máquinas ao cluster por WireGuard, um túnel de rede criptografado.
- Ajustar as réplicas, cópias em execução do serviço da aplicação, para aproveitar a capacidade adicional.
Criar uma máquina e colocar a aplicação para atender nela são etapas diferentes. O SwarmBurst acrescenta nós e ajusta as réplicas do serviço configurado. Isso não multiplica automaticamente o banco de dados, os arquivos ou todos os componentes da loja.
O cooldown é um intervalo de espera entre ações, usado para reduzir mudanças repetidas quando o consumo oscila perto do gatilho. Ele precisa combinar com o comportamento da aplicação. Um ajuste inadequado pode atrasar o reforço ou provocar movimentação desnecessária.
O reforço não é instantâneo: criar a máquina, preparar a rede e iniciar a aplicação leva tempo. Os gatilhos precisam ser testados com margem antes de a VPS esgotar sua capacidade. Instalar o agente não garante ausência de interrupções, especialmente diante de uma subida abrupta dos acessos.
O que precisa estar pronto antes da campanha
Leve esta lista ao desenvolvedor ou responsável pela infraestrutura. Ela separa a instalação do agente da preparação necessária para distribuir a aplicação:
- Aplicação em contêineres, cluster Docker Swarm compatível e conta AWS própria. Se a instalação é direta na VPS, comece por verificar se a loja já roda em contêiner. Pode haver trabalho anterior ao SwarmBurst.
- Réplicas consistentes. Todas precisam executar a mesma versão da aplicação, com configuração coerente e acesso às dependências. Uma cópia que inicia, mas não consulta o banco, não oferece capacidade útil.
- Estado disponível entre máquinas. Estado é a informação que precisa ser preservada ou compartilhada, como sessão do usuário, carrinho e uploads, os arquivos enviados. Prepare sessões e arquivos para várias máquinas; eles não podem depender exclusivamente de uma réplica temporária.
- Dados permanentes no nó fixo. Banco e arquivos precisam de regras de posicionamento, que determinam onde cada componente executa. Permanecer na VPS não os torna automaticamente acessíveis às réplicas na AWS.
- Distribuição dos acessos e conectividade testadas. Confirme como distribuir acessos entre os servidores. Verifique também se as réplicas alcançam banco e arquivos com tempo de resposta adequado.
O teste precisa incluir navegação, login, carrinho e envio de arquivos, conforme a aplicação. Abrir apenas a página inicial não demonstra que a loja funciona entre máquinas. A comunicação entre VPS e AWS também pode acrescentar demora, que precisa entrar na avaliação.
Quando mais servidores não resolvem a lentidão
Site lento é um sintoma, não um diagnóstico. Antes de contratar reforço, diferencie a falta de capacidade da aplicação de problemas que continuam existindo mesmo com novas máquinas:
- Aplicação sem capacidade disponível: processamento ou memória se esgotam ao atender os acessos. Distribuir o trabalho entre máquinas pode ajudar, desde que ele seja replicável.
- Banco saturado: consultas e conexões encontram o limite do banco. Mais réplicas podem aumentar a pressão sobre esse mesmo componente.
- Espera por serviço externo: pagamento, frete ou outro fornecedor demora a responder. Acrescentar servidores de aplicação não acelera a resposta dele e pode ampliar a demanda.
Lentidão constante e problemas de configuração pedem investigação antes de capacidade adicional. Hospedagem compartilhada sem controle do servidor também exige outro caminho. Ela não oferece o ambiente necessário para instalar e operar o agente.
Um teste de carga, uma simulação de acessos, ajuda a medir quanto a VPS aguenta antes do pico. Ele precisa representar as operações relevantes da aplicação, incluindo as que exigem mais processamento ou consultas ao banco. Não existe uma quantidade universal de visitantes suportados por uma VPS.
Para decidir sobre a campanha, a pergunta útil é se o reforço melhora essas operações antes de outro componente atingir seu limite. CPU alta, isoladamente, não comprova esse encaixe. É preciso observar também erros e tempo de resposta durante o teste.
Depois do pico: retirada dos nós e limites de custo
Quando a demanda cai, o agente faz a drenagem: retira tarefas do nó e aguarda sua realocação antes de encerrar a instância. O encerramento correto das requisições também depende da configuração da aplicação. Essa sequência não equivale a uma garantia de que nenhuma conexão será interrompida.
Encerrar a instância interrompe a cobrança de computação daquela máquina. A VPS continua contratada, e podem permanecer cobranças por armazenamento, transferências ou outros recursos da AWS. O custo total não volta necessariamente a zero.
O teto mensal configurável bloqueia a criação de novas máquinas quando é atingido. Ele não funciona como um limite absoluto de toda a fatura AWS: máquinas já ativas e outros recursos podem continuar gerando cobrança. A cobrança da nuvem é feita diretamente na conta do cliente.
O agente também faz uma varredura de instâncias órfãs, máquinas que possam ter sobrado após uma falha. Essa proteção ajuda no controle operacional, mas não elimina todo risco financeiro. A estimativa precisa considerar região, recursos escolhidos e configuração real da aplicação.
Antes da próxima campanha, avalie a instalação do SwarmBurst
O SwarmBurst é uma opção quando o pico exige capacidade adicional de uma aplicação preparada para atender em várias máquinas. Se a AWS não fornecer o reforço, os nós fixos permanecem disponíveis com sua capacidade original. Isso não garante que suportem sozinhos a campanha.
A oferta inclui instalação e configuração acompanhadas, ajuste dos gatilhos e do orçamento e acompanhamento ao vivo no primeiro pico. O ciclo de criação e encerramento de servidores AWS já foi validado em testes próprios. Ainda não há pico de cliente real medido.
A página inicial do SwarmBurst oferece implantação gratuita da primeira loja em troca de autorização para medir e publicar os resultados. É um piloto por vez, com disponibilidade a confirmar. Os recursos consumidos na AWS continuam sendo cobrados na conta do cliente.
Para conversar, reúna a data da campanha, os sintomas anteriores, a configuração da VPS e a informação sobre uso de Docker. Não envie credenciais pelo WhatsApp. Fale no WhatsApp para avaliar a instalação do SwarmBurst antes da campanha.
Perguntas frequentes
Preciso tirar minha aplicação da VPS para usar servidores AWS no pico?
Não. A VPS, seu servidor virtual, permanece como base fixa. O SwarmBurst acrescenta servidores temporários na AWS, a nuvem da Amazon, para executar cópias da aplicação durante o pico. A aplicação precisa estar preparada para funcionar em várias máquinas, com sessões, arquivos e distribuição dos acessos configurados.
Minha aplicação precisa estar em Docker Swarm para usar o SwarmBurst?
Sim. O SwarmBurst atua em um cluster Docker Swarm, conjunto de máquinas que coordena a execução de contêineres, pacotes com a aplicação e suas dependências. Se a aplicação roda diretamente na VPS, existe uma preparação anterior ao uso do agente. Também é necessária uma conta AWS própria.
O que acontece se a AWS não conseguir fornecer o reforço durante a campanha?
Os nós fixos, máquinas que já fazem parte do ambiente, permanecem disponíveis com sua capacidade original. Isso não garante que consigam suportar sozinhos os acessos da campanha. O reforço também leva tempo para entrar em operação, por isso os gatilhos precisam ser testados antes do pico.
O teto configurado no SwarmBurst limita toda a minha fatura AWS?
Não. O teto mensal configurável bloqueia a criação de novas máquinas quando é atingido. Máquinas já ativas e outros recursos, como armazenamento e transferências, podem continuar gerando cobranças. A AWS cobra os recursos diretamente na conta do cliente.
Como avaliar a instalação e o acompanhamento do primeiro pico?
Fale pelo WhatsApp indicado na página inicial do SwarmBurst e informe a data da campanha, os sintomas anteriores, a configuração da VPS e se a aplicação usa Docker. Não envie credenciais. A implantação da primeira loja é gratuita em troca de autorização para medir e publicar os resultados, com configuração acompanhada e acompanhamento ao vivo do primeiro pico. É um piloto por vez, sujeito à disponibilidade; os recursos da AWS são cobrados na conta do cliente.