Escalabilidade vertical ou horizontal no Cloud Server

Resposta direta

A escalabilidade vertical aumenta CPU, RAM ou disco de um único Cloud Server. Ela costuma ser a melhor primeira medida quando a aplicação ainda cabe em uma instância, o gargalo está identificado e uma reinicialização curta é aceitável. A escalabilidade horizontal adiciona servidores e distribui requisições, workers ou dados entre eles. Essa abordagem atende melhor sistemas que precisam continuar disponíveis durante falhas, absorver picos frequentes ou crescer além do limite de uma máquina. A decisão não deve partir apenas do tráfego. Meça uso de CPU, pressão de memória, latência, filas, conexões de banco e taxa de erros. Em muitos projetos, o caminho mais seguro é verticalizar primeiro, remover estado local e adotar escala horizontal gradualmente.

Resumo rápido

• Escala vertical significa ampliar os recursos de uma instância existente.
• Escala horizontal significa adicionar instâncias e repartir o trabalho.
• Mais servidores não garantem alta disponibilidade se banco, arquivos ou balanceador continuarem como pontos únicos de falha.
• CPU sustentada acima de 70% e memória próxima do limite pedem investigação, não um upgrade automático.
• Aplicações sem estado são mais simples de distribuir entre servidores.
• Banco de dados, sessões, uploads e tarefas agendadas exigem tratamento específico.
• O custo horizontal inclui observabilidade, balanceamento, automação e tempo operacional.

O que muda entre escalabilidade vertical e horizontal

Escalar verticalmente, também chamado de scale up, consiste em trocar uma configuração como 2 vCPUs e 4 GB de RAM por outra com 4 vCPUs e 8 GB. O sistema operacional, a aplicação e os dados continuam concentrados na mesma instância. Em um Cloud Server, o redimensionamento pode ser simples, mas a necessidade de desligamento, a expansão de disco e a possibilidade de reduzir o plano depois variam conforme o provedor e a plataforma. Esses detalhes precisam ser confirmados antes da mudança.

Escalar horizontalmente, ou scale out, adiciona nós. Uma API executada em uma instância passa a operar em três servidores de 2 vCPUs e 4 GB, normalmente atrás de um balanceador de carga. As requisições podem ser distribuídas por round robin, menor número de conexões ou outro algoritmo. Se os nós forem equivalentes e a aplicação não guardar estado local, é possível retirar uma máquina com falha e manter as demais atendendo.

Capacidade não é o mesmo que disponibilidade

Uma instância com 16 vCPUs pode processar mais trabalho que outra com 4 vCPUs, mas continua sendo um único domínio de falha. Se o kernel travar, a aplicação cair ou uma atualização falhar, todo o serviço pode ficar indisponível. Três instâncias menores aumentam a tolerância a falhas somente quando há health checks, balanceamento, banco resiliente e capacidade restante para absorver a perda de um nó.

Considere um SaaS que recebe 120 requisições por segundo. Uma máquina atende 180 requisições por segundo em teste controlado, mas sua parada derruba o produto. Duas máquinas capazes de atender 110 cada oferecem 220 requisições por segundo de capacidade agregada. Ainda assim, após a perda de uma delas, o limite cai para 110, abaixo do pico. Nesse cenário, seriam necessários três nós ou redução planejada de carga.

Como identificar o limite atual

Observe CPU por núcleo, memória disponível, swap, espera de disco, latência nos percentis p95 e p99, conexões com o banco e tamanho das filas. Uma CPU média de 35% pode esconder um único núcleo saturado por uma rotina serial. Da mesma forma, 90% de RAM usada não representa problema quando grande parte é cache liberável do Linux. Antes de escolher recursos, o artigo sobre como dimensionar CPU, RAM e NVMe ajuda a separar uso saudável de pressão real.

Quando aumentar CPU e RAM é a decisão correta

A escala vertical funciona bem quando o software não pode ser distribuído facilmente, a equipe é pequena ou o gargalo exige resposta imediata. Um banco PostgreSQL com 4 GB de RAM, por exemplo, pode sofrer com leituras em disco porque o conjunto ativo de dados não cabe no cache. Subir para 8 GB ou 16 GB pode reduzir a pressão de I/O, desde que consultas, índices e parâmetros também sejam revisados. O ganho não deve ser presumido sem métricas antes e depois.

Outro exemplo é uma aplicação PHP com Nginx e PHP-FPM. Se cada processo consome 120 MB e o servidor tem 2 GB, configurar 20 workers já ultrapassa a memória disponível quando sistema operacional e banco local entram na conta. Um upgrade para 4 GB permite mais concorrência, mas também é possível corrigir pm.max_children, reduzir extensões e mover o banco para outro serviço. Adicionar RAM sem ajustar o pool apenas adia a próxima saturação.

Como dimensionar o próximo tamanho

Evite saltar diretamente de 2 vCPUs para 16. Se a CPU permanece entre 75% e 90% durante intervalos de dez minutos, teste primeiro 4 vCPUs e compare throughput, tempo de resposta e custo por requisição. Para memória, deixe margem para picos. Uma aplicação que usa 6,5 GB no horário mais intenso não deveria operar em uma instância de 8 GB sem alertas e controle de processos. Uma configuração de 12 GB ou 16 GB oferece espaço para cache, deploy e variações temporárias.

O disco também participa da decisão. Uma fila que grava milhares de eventos por minuto pode apresentar CPU baixa e alta espera de I/O. Nesse caso, migrar de armazenamento com menor capacidade de operações para um volume adequado ao padrão de escrita pode ser mais útil que dobrar vCPUs. O tipo de SSD, limites de IOPS, throughput e políticas de burst precisam ser consultados na documentação do provedor.

Limites e riscos da escala vertical

Todo catálogo possui um maior tamanho disponível, e instâncias grandes ampliam o impacto financeiro e operacional de uma falha. O redimensionamento também pode exigir reinicialização. Se o serviço tolera cinco minutos de manutenção mensal, isso talvez seja aceitável. Uma loja que processa pedidos continuamente pode precisar de uma estratégia diferente.

Antes do upgrade, gere backup consistente, teste a restauração e registre a configuração atual. Snapshot não substitui backup independente, principalmente quando banco e aplicação gravam durante a captura. Verifique ainda se o disco pode ser reduzido depois, pois muitas plataformas permitem expansão, mas não redução direta do volume.

Quando distribuir a aplicação entre vários servidores

A escala horizontal começa a fazer sentido quando os picos são recorrentes, o limite de uma instância se aproxima ou a interrupção de um único servidor deixou de ser aceitável. Ela combina bem com APIs HTTP, front-ends, consumidores de filas e processamento de mídia. Esses componentes podem receber unidades de trabalho independentes, desde que a aplicação não dependa do disco ou da memória de um nó específico.

Imagine uma API Node.js que atende 300 requisições por segundo em um servidor com 4 vCPUs. Em vez de migrar para 16 vCPUs, a equipe pode executar três instâncias de 4 vCPUs atrás de um balanceador. Um teste de carga deve confirmar a capacidade real, porque o ganho raramente é perfeitamente linear. Banco, rede, locks, APIs externas e serialização podem limitar o resultado. Três nós não significam automaticamente três vezes mais throughput.

Balanceamento e sessões

O balanceador precisa testar uma rota como /health e remover nós sem condições de atender. Um health check que apenas retorna HTTP 200, sem verificar dependências essenciais, pode manter no pool uma instância incapaz de consultar o banco. O extremo oposto também causa problemas: se a rota falhar por qualquer serviço secundário, todos os nós podem ser retirados ao mesmo tempo. A checagem deve refletir a capacidade de processar a função principal.

Sessões gravadas em memória local quebram quando a próxima requisição chega a outro servidor. Há três soluções comuns: armazenar sessões em Redis ou banco, usar tokens verificáveis sem sessão no servidor, ou ativar afinidade no balanceador. Sticky session pode servir como etapa de transição, mas reduz a liberdade de redistribuir carga. Para entender os componentes dessa camada, consulte a configuração de Cloud Server com HAProxy e balanceamento de carga.

Filas, workers e tarefas assíncronas

Nem toda escala horizontal precisa começar pelo tráfego web. Uma plataforma que converte vídeos pode manter duas instâncias web e aumentar apenas os workers. Se cada conversão utiliza uma vCPU por cinco minutos, quatro workers com 4 vCPUs cada podem executar até 16 tarefas simultâneas, respeitando memória e I/O. A fila controla a distribuição e permite reduzir o grupo quando a demanda termina.

Tarefas agendadas exigem cuidado. Se o mesmo cron estiver ativo em quatro servidores, uma cobrança diária poderá ser executada quatro vezes. Use eleição de líder, lock distribuído ou um scheduler separado. Deploys também precisam de rotação gradual, retirando cada nó do balanceador antes da atualização e devolvendo-o somente após os testes de saúde.

Banco de dados, arquivos e estado da aplicação

A camada web costuma ser a parte mais simples de escalar. O desafio aparece quando múltiplas instâncias precisam compartilhar banco, sessões, uploads e cache. Se cada servidor mantém arquivos próprios em /var/www/uploads, uma imagem enviada ao nó A não estará disponível no nó B. O balanceador pode direcionar a leitura seguinte ao servidor errado, produzindo erros intermitentes difíceis de reproduzir.

O padrão mais previsível é tornar os nós de aplicação descartáveis. Imagens e anexos vão para armazenamento de objetos ou sistema compartilhado apropriado. Sessões ficam em um serviço externo, enquanto configurações são injetadas no deploy sem segredos no repositório. Logs seguem para uma plataforma central. Assim, substituir uma instância não exige copiar manualmente dados locais.

O banco costuma virar o próximo gargalo

Adicionar servidores web aumenta o número de conexões e consultas concorrentes. Três instâncias com pool de 40 conexões podem abrir até 120 conexões no PostgreSQL. Se o banco foi configurado para 100, a escala da aplicação cria uma nova falha. Limite o pool por nó, reserve conexões administrativas e considere um proxy de conexões quando o padrão de uso justificar.

Réplicas de leitura ajudam em catálogos, relatórios e páginas com consultas predominantemente de leitura. Elas não resolvem gravações intensas e introduzem atraso de replicação. Após atualizar um cadastro no nó primário, uma leitura imediata na réplica pode devolver o valor anterior. Operações que exigem consistência forte devem continuar no primário ou adotar lógica explícita para esse intervalo.

Em um e-commerce, produtos e conteúdo podem usar réplicas, enquanto estoque e confirmação de pagamento devem consultar a fonte autoritativa. Em uma plataforma de métricas, registros podem ser particionados por cliente ou período, mas essa mudança aumenta a complexidade de consultas e migrações. Sharding raramente deve ser a primeira resposta para um banco mal indexado.

Arquivos e sessões precisam sair da instância

Um caso prático é a migração de um WordPress com uploads locais. Antes de adicionar um segundo servidor, a equipe precisa sincronizar a biblioteca de mídia ou adotar armazenamento compartilhado compatível. O cache de página também deve considerar invalidação entre nós. Já em uma API com autenticação por token, a remoção de sessão local pode ser mais simples, mas revogação, expiração e rotação de chaves continuam necessárias.

Faça testes de falha deliberados. Desligue um nó durante uploads, encerre um worker no meio de uma tarefa e simule indisponibilidade temporária do cache. Uma arquitetura horizontal só é confiável quando a aplicação trata repetição, timeout e retomada sem corromper dados.

Comparação de custo, disponibilidade e operação

A escolha não deve comparar apenas o preço de uma instância grande com a soma de duas pequenas. Escala horizontal pode exigir balanceador, rede privada, armazenamento compartilhado, observabilidade central, automação de deploy e mais horas de operação. Escala vertical preserva uma arquitetura simples, mas concentra risco e pode levar a tamanhos com custo crescente. Preços, limites de tráfego e recursos incluídos variam por provedor e precisam de revisão humana no momento da contratação.

Perfil de carga	Configuração inicial ilustrativa	Estratégia indicada	Disponibilidade esperada	Principal cuidado operacional
Aplicação interna com até 50 req/s	2 vCPUs, 4 GB de RAM, 60 GB SSD	Vertical até 4 vCPUs e 8 GB	Dependente de uma instância	Backup testado e janela de manutenção
API pública com picos de 400 req/s	3 nós de 4 vCPUs e 8 GB	Horizontal com balanceador	Tolera um nó indisponível se houver folga	Sessões externas, health checks e pool de banco
Processamento assíncrono variável	2 nós web e 2 a 10 workers	Horizontal por tamanho da fila	Web e workers escalam separadamente	Idempotência, timeout e reprocessamento
Banco transacional com conjunto ativo de 10 GB	4 vCPUs e 16 GB no primário	Vertical primeiro, réplica depois	Réplica não substitui failover testado	Índices, conexões e consistência de leitura

Uma comparação baseada no perfil da carga

Para um painel administrativo usado por 30 pessoas, duas instâncias e um balanceador podem custar mais tempo de manutenção do que entregam em benefício. Uma máquina de 4 vCPUs e 8 GB, monitorada e protegida por backup restaurável, pode ser suficiente. Já uma API que sustenta vendas não deve depender apenas de um servidor, mesmo que ele opere com 20% de CPU. Nesse caso, o requisito central é continuidade, não falta de capacidade.

Há também estratégias híbridas. Dois nós de 4 vCPUs podem ser ampliados temporariamente para 8 vCPUs durante uma campanha. Outra opção é manter três nós no horário comercial e dois durante a madrugada, desde que a remoção seja automatizada e não interrompa requisições em andamento. A melhor unidade de escala depende da carga mínima, do tempo de inicialização e do custo de manter reserva.

O custo que não aparece na configuração

Mais componentes criam mais pontos para observar. A equipe precisa acompanhar taxa de erro por nó, distribuição de tráfego, saturação do banco, profundidade de fila e falhas de deploy. Alertas devem representar impacto real. Notificar a cada pico de CPU de 30 segundos gera ruído; alertar quando latência p95 e erros sobem durante cinco minutos tende a produzir sinal mais útil.

A disponibilidade também depende do desenho completo. O conteúdo sobre alta disponibilidade e failover em VPS mostra por que dois servidores ainda podem compartilhar um único ponto de falha. Rede, DNS, balanceador, banco e processo de recuperação precisam entrar no cálculo.

Como migrar da escala vertical para a horizontal

A transição mais segura não começa com a criação de dez instâncias. Primeiro, descubra onde o sistema perde desempenho e remova dependências locais. Uma aplicação monolítica pode operar horizontalmente sem ser convertida imediatamente em microsserviços. Se duas cópias do mesmo processo conseguem atender requisições usando banco, cache e arquivos compartilhados, já existe uma base para distribuir carga.

Instrumente antes de redesenhar

Colete pelo menos uma semana de métricas, incluindo horário de pico. Registre CPU por núcleo, memória e swap, latência p50, p95 e p99, requisições por segundo, erros HTTP, IOPS, tempo de consultas e conexões abertas. Para workers, acompanhe idade da mensagem mais antiga e tempo de processamento. Uma fila com mil tarefas pode estar saudável se for drenada em dois minutos, mas crítica se continuar crescendo por uma hora.

Faça um teste controlado. Envie 100, 200 e 400 requisições por segundo e observe quando a latência deixa de crescer de forma previsível. Repita com uma instância maior e depois com dois nós menores. A comparação precisa usar a mesma versão, base de dados equivalente e duração suficiente para aquecer caches. Sem metodologia consistente, qualquer conclusão de performance fica frágil.

Faça a transição em etapas reversíveis

Comece externalizando sessões e uploads. Depois, crie uma imagem reproduzível ou rotina automatizada de provisionamento. Suba o segundo nó, coloque o balanceador na frente e direcione uma parcela pequena do tráfego. Se a plataforma permitir pesos, envie 10% para o novo servidor e compare erros, latência e logs. Aumente para 50% somente quando o comportamento estiver estável.

No deploy, use rolling update. Retire um nó do pool, aguarde as conexões terminarem, atualize, execute verificações e recoloque-o. Repita nos demais. Para mudanças incompatíveis de banco, prefira migrações em duas fases: primeiro adicione a nova estrutura mantendo compatibilidade, depois atualize a aplicação e só então remova a estrutura antiga.

Teste o cenário de perda. Desligue uma instância e confirme se o balanceador a remove dentro do intervalo previsto. Verifique se os nós restantes suportam o pico. Em seguida, simule falha do banco e valide mensagens, timeouts e recuperação. Se não houver capacidade para exercícios em produção, mantenha um ambiente de homologação proporcional e execute testes periódicos de restauração.

Recomendações por perfil

A arquitetura adequada depende mais do impacto de uma interrupção e do padrão de carga do que do nome da tecnologia usada. Um Cloud Server oferece recursos virtualizados e gerenciamento por API em muitas plataformas, enquanto uma VPS tradicional pode ter provisionamento e expansão menos flexíveis. A nomenclatura comercial não garante elasticidade, failover ou armazenamento distribuído. Confirme cada capacidade na documentação do provedor.

Desenvolvedor solo e projetos pequenos

Para um sistema com até algumas dezenas de requisições por segundo, comece com uma instância de 2 vCPUs e 4 GB de RAM. Separe aplicação e banco apenas quando houver motivo operacional ou consumo suficiente. Configure monitoramento, backup diário com retenção e teste de restauração. Se a CPU permanecer alta ou ocorrer pressão de memória, avance para 4 vCPUs e 8 GB antes de adotar vários nós. Essa escolha reduz componentes e facilita diagnóstico. Ainda assim, evite gravar arquivos essenciais apenas no disco local se o projeto tiver expectativa de crescimento. Use deploy reproduzível e documente o procedimento de recuperação desde o início.

Times com produto em crescimento

Quando o produto recebe picos previsíveis ou já possui mais de um desenvolvedor realizando deploy, prepare a aplicação para operar sem estado. Uma base razoável é usar duas ou três instâncias de 4 vCPUs e 8 GB, balanceador com health checks, sessões externas e banco separado. Não trate esses números como padrão universal. Teste a carga real e mantenha capacidade para perder um nó durante o pico. Centralize logs, limite conexões por instância e automatize a entrada e a saída de servidores. Workers podem escalar por profundidade da fila, enquanto a camada web segue requisições por segundo e latência.

Produção crítica e operação contínua

Sistemas que não podem parar exigem redundância em cada dependência relevante. Considere no mínimo três nós de aplicação distribuídos de acordo com as opções reais da plataforma, balanceamento redundante, banco com estratégia documentada de failover e backups externos testados. Defina objetivos de recuperação, como RTO de 15 minutos e RPO de 5 minutos, e confirme se a arquitetura consegue cumpri-los. Execute testes de falha, rotação de credenciais e restauração em calendário fixo. Para campanhas, mantenha margem de 30% a 50% ou escalonamento automatizado validado. A escala horizontal entrega flexibilidade, mas só produz disponibilidade quando automação, observabilidade e procedimentos operacionais recebem o mesmo cuidado que CPU e RAM.