Autoscaling horizontal vs vertical: guia completo

Autoscaling horizontal e vertical resolvem o mesmo problema por caminhos opostos: um adiciona máquinas, o outro engorda a máquina que já existe. A decisão raramente é binária, e a maioria dos ambientes produtivos usa os dois em conjunto. Este guia mostra como cada um funciona, quando aplicá-lo e quais armadilhas evitar na implementação.

A resposta curta: autoscaling horizontal (scale out/in) cria e remove réplicas de uma aplicação, enquanto o vertical (scale up/down) altera os limites de CPU e memória de uma instância existente. O horizontal é mais flexível e sem teto prático, mas exige aplicação stateless. O vertical é mais simples de configurar, porém esbarra na capacidade física do servidor.

Passo 1: Entenda a natureza da sua carga de trabalho

Antes de configurar qualquer política, classifique sua aplicação. Cargas stateless, como APIs e workers de fila, aceitam múltiplas instâncias sem conflito. Cargas stateful, como bancos de dados relacionais, têm consistência interna que dificulta a replicação cega.

Uma API REST com sessão em cache externo escala horizontalmente sem dor. Um PostgreSQL com transações longas não aceita réplicas de escrita sem estratégia de sharding. Para o segundo caso, o vertical é o caminho natural até o limite do hardware.

Dica prática: se sua aplicação mantém estado em memória local, o horizontal vai gerar inconsistência. Corrija isso antes de pensar em autoscaling.

Passo 2: Defina métricas de escala confiáveis

Autoscaling reage a métricas, e a escolha errada causa flutuação constante. CPU e memória são padrão, mas nem sempre refletem a experiência do usuário. Latência de requisição e profundidade de fila são melhores indicadores de gargalo real.

No Kubernetes, o Horizontal Pod Autoscaler (HPA) monitora métricas via Metrics API. O Vertical Pod Autoscaler (VPA) recomenda limites com base no uso histórico. Ambos precisam de métricas estáveis, sem picos de ruído.

Erro comum: usar média de CPU em janela curta demais. Um pico de 5 segundos dispara réplicas desnecessárias, e o custo sobe sem benefício. Configure janelas de pelo menos 1 minuto e com histerese (subir mais rápido que descer).

Passo 3: Configure o autoscaling horizontal no Kubernetes

O HPA ajusta o número de réplicas entre um mínimo e um máximo definidos. A fórmula básica é: réplicas atuais vezes (métrica atual dividida pela métrica desejada). Se a CPU média é 80% e o alvo é 50%, o HPA dobra as réplicas.

Na prática, defina limites de mínimo e máximo com folga. Um mínimo de 2 réplicas protege contra falha de nó. Um máximo alto demais gera custo imprevisível; um baixo demais causa queda de performance.

Exemplo concreto: uma aplicação de e-commerce que recebe 10 mil requisições por minuto em horário de pico. Com HPA entre 3 e 15 réplicas e alvo de 60% de CPU, o sistema escala durante a promoção e reduz fora dela. O erro comum é esquecer o timeout de escala: o HPA não espera a inicialização do pod. Use readiness probes e defina stabilizationWindowSeconds para evitar oscilação.

Passo 4: Implemente o autoscaling vertical com VPA

O VPA analisa o uso real de recursos e recomenda novos limites de CPU e memória. Ele opera em três modos: off (só recomenda), initial (aplica na criação do pod) e auto (atualiza limites e reinicia o pod).

O modo auto é o mais útil, mas reinicia pods para aplicar novos limites. Isso causa downtime se a aplicação não tolera reinício. Por isso, combine VPA com disruption budgets e janelas de manutenção.

Erro comum: usar VPA e HPA na mesma métrica de CPU. Eles competem e causam efeito sanfona: o HPA adiciona réplicas, o VPA reduz limites de cada uma. A recomendação da comunidade é usar HPA para métricas de carga e VPA apenas para ajuste fino de limites.

Passo 5: Avalie custo e limite físico

O vertical scaling é limitado pelo maior tipo de máquina disponível no provedor. Se o maior servidor tem 64 vCPUs e você precisa de 128, o vertical não resolve. O horizontal não tem teto, mas cada réplica nova paga licença e overhead de orquestração.

Custo real: em cloud pública, o horizontal tende a ser mais econômico para cargas variáveis, pois você desliga réplicas fora do pico. O vertical mantém a mesma máquina ligada, mesmo ociosa.

Contraexemplo: um banco de dados que precisa de 32 GB de RAM. Com vertical, você paga por uma instância grande. Com horizontal, precisaria de sharding, o que adiciona complexidade de aplicação. Para bancos, o vertical costuma ser mais barato em esforço de engenharia.

Passo 6: Combine as duas abordagens com estratégia

O padrão recomendado é usar HPA como camada principal e VPA como ajuste de limites base. O HPA cuida da demanda variável, o VPA evita desperdício de recursos em cada pod.

Na prática, configure primeiro o VPA em modo off para coletar recomendações por uma semana. Analise os números, ajuste requests e limits manualmente, e só então ative o HPA com métricas de carga. Depois, ligue o VPA em modo auto com restrição de reinício.

Dica: para cargas stateful, prefira vertical e limite o horizontal a réplicas de leitura. Para cargas stateless, o horizontal é a regra.

Checklist final

• [ ] Classifique sua carga: stateless ou stateful?
• [ ] Defina métricas de escala (CPU, latência, fila)
• [ ] Configure HPA com mínimo e máximo realistas
• [ ] Use readiness probes e stabilization window
• [ ] Ative VPA em modo off primeiro, depois auto
• [ ] Evite HPA e VPA na mesma métrica
• [ ] Verifique o limite físico do maior servidor
• [ ] Monitore custo por réplica e por hora

Perguntas frequentes

Qual a diferença entre autoscaling horizontal e vertical?

Horizontal adiciona ou remove instâncias completas (réplicas). Vertical aumenta ou diminui os recursos de uma instância existente, como CPU e memória. O horizontal é ilimitado em escala, mas exige aplicação stateless. O vertical é simples, porém limitado pelo hardware do servidor.

Quando usar autoscaling horizontal em vez de vertical?

Use horizontal para cargas stateless, como APIs e workers, que podem rodar em múltiplas instâncias sem conflito. Use vertical para cargas stateful, como bancos de dados, onde a replicação de escrita é complexa. Em geral, o horizontal resolve demanda variável com melhor custo.

O autoscaling vertical reinicia a aplicação?

Sim, no modo auto o VPA reinicia o pod para aplicar novos limites de CPU e memória. Isso causa downtime se a aplicação não tolera reinício. Use disruption budgets e janelas de manutenção para minimizar impacto.

Posso usar HPA e VPA juntos no Kubernetes?

Pode, mas evite que ambos atuem na mesma métrica. O HPA deve gerenciar réplicas com base em carga, e o VPA ajusta limites de recursos. Se os dois usarem CPU, eles competem e geram oscilação. Configure o VPA em modo off primeiro para coleta de dados.

Qual é mais barato: horizontal ou vertical?

Depende da carga. Para demanda variável, o horizontal desliga réplicas ociosas e reduz custo. Para cargas constantes e stateful, o vertical evita complexidade de sharding, o que pode ser mais barato em esforço de engenharia, mesmo com máquina maior.

O que é o efeito sanfona no autoscaling?

É a oscilação causada por HPA e VPA atuando na mesma métrica. O HPA adiciona réplicas quando a CPU sobe, e o VPA reduz limites de cada réplica, o que aumenta a CPU relativa e dispara mais mudanças. Isso gera instabilidade e custo desnecessário.