Auto-scaling: como fazer a aplicação crescer conforme a demanda

O que é auto-scaling e por que instâncias fixas são um problema

O custo de superdimensionar versus o risco de subdimensionar

Auto-scaling é a capacidade do sistema de ajustar automaticamente o número de instâncias em execução com base na demanda atual, sem intervenção manual. Sistemas com capacidade fixa enfrentam um dilema: dimensionar para o pico de demanda resulta em desperdício de recursos e custo excessivo durante períodos de baixa utilização, enquanto dimensionar para a demanda média resulta em degradação ou falha durante picos. Um e-commerce que experimenta 10x o tráfego normal na Black Friday, um sistema de processamento de pagamentos com picos diários ao meio-dia, ou uma API com carga uniforme às 2h da madrugada mas intensa às 9h da manhã — todos se beneficiam de auto-scaling. A nuvem tornou auto-scaling viável por prover infraestrutura elástica que pode ser provisionada e desprovisionada em segundos, mudando o custo de capital de hardware fixo para custo operacional proporcional ao uso.

Escalabilidade horizontal vs vertical

Scale-out versus scale-up — quando cada estratégia é mais adequada

Escalabilidade vertical (scale-up) significa aumentar os recursos de uma instância existente — mais CPU, mais RAM, disco mais rápido. É simples de implementar, não requer mudanças na aplicação, mas tem limites físicos e financeiros, e geralmente requer downtime para resize. Escalabilidade horizontal (scale-out) significa adicionar mais instâncias idênticas atrás de um load balancer — não tem limite teórico, permite zero downtime, e é a base do auto-scaling. A maioria das aplicações modernas é projetada para escalar horizontalmente: stateless, com sessão no Redis ou JWT, sem afinidade com hosts específicos. Aplicações que mantêm estado local (arquivos em disco, sessão em memória sem compartilhamento) não escalam horizontalmente sem refatoração — resolver esses problemas é um pré-requisito para auto-scaling eficiente.

Métricas de scaling — CPU, memória, requests, latência

Escolhendo o sinal correto para disparar scaling automático

A métrica de scaling determina quando adicionar ou remover instâncias e deve refletir a pressão real sobre a capacidade do sistema. CPU acima de 70% é a métrica mais comum e funciona bem para workloads CPU-bound. Memória é útil para workloads de processamento de dados mas problemática porque JVMs e runtimes managed (Node.js, .NET CLR) não liberam memória ao SO mesmo quando ociosos, gerando scaling desnecessário. Request count por instância é uma métrica de negócio mais direta — quando cada instância está processando mais requisições do que seu throughput ótimo, adicionar instâncias é a resposta certa. Latência como métrica de scaling é sofisticada: se o p95 de latência excede o threshold configurado, o sistema está sob pressão e precisa de mais capacidade — essa métrica conecta diretamente o scaling à experiência do usuário.

Scale-out e scale-in — thresholds e cooldown

Configurando políticas de scaling para evitar thrashing e reação lenta

Políticas de scaling definem quando e quanto escalar. Thresholds de scale-out (adicionar instâncias) devem ser mais baixos que os de scale-in (remover instâncias) para criar uma zona de histerese que evita thrashing — o comportamento de adicionar e remover instâncias repetidamente em curtos intervalos. Se o scale-out ocorre com CPU acima de 70% e o scale-in com CPU abaixo de 30%, há uma zona estável entre 30% e 70% onde nenhuma ação é tomada. Cooldown é o período após uma ação de scaling durante o qual o sistema ignora as métricas para dar tempo às novas instâncias de inicializarem e estabilizarem as métricas antes da próxima decisão. Cooldown muito curto causa thrashing; muito longo torna o scaling lento para reagir a picos repentinos. Step scaling (múltiplos passos de tamanho proporcional ao desvio da métrica) e target tracking (manter a métrica em um valor alvo) são estratégias mais sofisticadas que simples threshold on/off.

Auto-scaling em Kubernetes com HPA

Horizontal Pod Autoscaler — scaling declarativo baseado em métricas

O Horizontal Pod Autoscaler (HPA) do Kubernetes monitora métricas e ajusta automaticamente o número de réplicas de um Deployment ou StatefulSet. A configuração básica usa CPU e memória via metrics-server; configurações avançadas usam métricas customizadas do Prometheus via Prometheus Adapter ou métricas externas (SQS queue depth, Kafka consumer lag) via provedores de métricas externas. O HPA calcula o número desejado de réplicas dividindo a métrica atual pelo valor alvo: se o target é 50% de CPU e a utilização atual é 100%, o HPA dobra o número de réplicas. O intervalo de reconciliação padrão é 15 segundos, e o HPA respeita as configurações de minReplicas e maxReplicas como limites absolutos. Cluster Autoscaler complementa o HPA escalando os nodes do cluster quando pods não conseguem ser agendados por falta de recursos.

Auto-scaling em AWS EC2 e ECS

Auto Scaling Groups e ECS Service Auto Scaling na prática

EC2 Auto Scaling Groups (ASG) gerenciam um conjunto de instâncias EC2, ajustando o número de instâncias com base em políticas de scaling e CloudWatch Alarms. Launch Templates definem a configuração de cada instância nova — AMI, tipo de instância, user data, security groups e IAM Role — garantindo que todas as instâncias do grupo sejam idênticas. ECS Service Auto Scaling usa a AWS Application Auto Scaling para ajustar o número de tasks de um ECS Service com base em métricas do CloudWatch — CPU da task, memória, métricas customizadas. A combinação de ECS Service Auto Scaling (ajusta o número de tasks) com EC2 ASG ou Fargate (ajusta a capacidade de compute) cria um sistema completamente elástico. Scaling policies baseadas em Predictive Scaling da AWS usam machine learning para antecipar padrões históricos e pré-provisionar capacidade antes do pico, reduzindo a latência de scaling.

Preditivo vs reativo — quando cada um faz sentido

Reagir à demanda versus antecipar a demanda

Scaling reativo adiciona capacidade em resposta a métricas que já ultrapassaram o threshold — há sempre um lag entre o início do pico e a capacidade extra ficar disponível. Para workloads com padrões previsíveis (horário comercial, horário de pico noturno, Black Friday), scaling preditivo agenda a capacidade extra para estar disponível antes do pico começar. AWS Predictive Scaling analisa histórico de 14 dias para identificar padrões semanais e diários, pre-scaling o ASG automaticamente. Scheduled scaling permite configurar manualmente ações de scaling em horários específicos — aumentar para 20 instâncias toda segunda-feira às 8h e reduzir para 5 às 19h. A estratégia ideal combina os dois: scheduled ou preditivo para padrões previsíveis, reativo para eventos não antecipados como picos de viral nas redes sociais.

Auto-scaling de banco de dados — read replicas e sharding automático

Quando o gargalo de scaling está no banco, não na aplicação

Escalar a camada de aplicação resolve gargalos de CPU e memória, mas eventualmente o banco de dados se torna o gargalo — especialmente para operações de leitura intensiva. Read replicas permitem distribuir queries de leitura entre múltiplas instâncias do banco: Aurora Auto Scaling adiciona e remove read replicas automaticamente com base no uso de CPU ou conexões. Para cargas de escrita intensiva, sharding distribui dados entre múltiplas instâncias de banco — cada shard processa uma fração do total de escritas. DynamoDB é o exemplo mais extremo de banco com auto-scaling nativo: on-demand mode ajusta automaticamente o throughput de leitura e escrita baseado no tráfego real, sem configuração de capacidade provisioned. Caches como ElastiCache (Redis/Memcached) são a primeira linha de defesa para reduzir a pressão no banco antes de precisar escalar o banco em si.

Testar auto-scaling antes de pico real

Validar que o scaling funciona antes que a demanda real exija

Testar auto-scaling em produção antes de um pico previsto é obrigatório — a descoberta de que o scaling não funciona durante a Black Friday é o pior momento possível. Load tests com k6, Locust ou AWS Load Testing simulam o crescimento gradual de carga e permitem observar se as políticas de scaling disparam no momento correto, se as novas instâncias ficam saudáveis dentro do tempo esperado, e se o scale-in acontece adequadamente quando a carga reduz. Pontos de atenção durante os testes: o warm-up time das novas instâncias (JVMs, conexões de banco, cache aquecimento), os limites de cotas da AWS (vCPUs por região, IPs disponíveis), e se o banco suporta o aumento repentino de conexões quando dezenas de novas instâncias iniciam simultaneamente. Documentar o comportamento observado durante testes e ajustar thresholds e cooldowns antes do evento real é a prática que diferencia times preparados dos que apenas torcem para que funcione.

Conclusão — auto-scaling como capacidade fundamental de sistemas modernos

Elasticidade como vantagem competitiva e eficiência operacional

Auto-scaling transforma infraestrutura de custo fixo em custo variável proporcional ao uso, ao mesmo tempo em que garante disponibilidade durante picos sem superdimensionamento contínuo. Sistemas sem auto-scaling são vulneráveis a picos imprevisíveis e desperdiçam recursos em períodos de baixa demanda. Configurar auto-scaling corretamente — escolhendo a métrica certa, calibrando thresholds e cooldowns com dados reais, testando antes de picos previsíveis e combinando estratégias reativas e preditivas — é uma das competências mais valiosas de um engenheiro de backend moderno. Continue em: Fundamentos obrigatórios antes de produção.