Conceito (Escalar horizontal e vertical)

Escalar é aumentar a capacidade de um sistema para atender mais carga; a produção real exige que esse aumento aconteça de forma automatizada, com segurança e previsibilidade de custo. Existem duas famílias de estratégia: escala vertical, que aumenta a potência da mesma unidade, e escala horizontal, que aumenta a quantidade de unidades. Auto scaling é a automatização dessas decisões a partir de métricas, e elasticidade é a capacidade de crescer e encolher conforme a demanda, devolvendo capacidade ociosa. O tema é central na arquitetura de produção porque nenhuma aplicação de sucesso mantém carga constante: promoções, sazonalidades e virais transformam o padrão de tráfego em horas, e um sistema que depende de redimensionamento manual falha exatamente nos momentos que geram receita. Este registro estabelece o vocabulário conceitual sobre o qual os arquivos seguintes detalham políticas, grupos de auto scaling na AWS, autoscaling de serviços ECS e o HPA do Kubernetes.

Conceitos fundamentais: escala vertical e horizontal

Escala vertical, ou scale up, aumenta os recursos de uma mesma unidade: uma instância t3.large substitui a t3.medium, um Pod recebe mais memória, um banco ganha uma classe superior. A aplicação não precisa saber que cresceu, pois o processo continua único; em contrapartida, a mudança quase sempre exige reinício, há teto físico superior e o custo por capacidade cresce de forma não linear nas classes maiores. Escala horizontal, ou scale out, adiciona unidades: três réplicas viram nove, cada uma idêntica e atrás de um balanceador. A unidade é mais barata, a falha tem raio menor e o teto é prático, não físico; em contrapartida, a aplicação precisa tolerar múltiplas instâncias concorrentes.

A comparação estruturada revela que não existe vencedor absoluto, existe adequação ao workload.

Na prática, arquiteturas maduras combinam as duas formas. Serviços sem estado escalam horizontalmente de forma automática, enquanto o banco de dados escala verticalmente até o limite e depois recorre a réplicas de leitura ou sharding, que são formas horizontais com complexidade própria. A regra de decisão é preferir horizontal na camada de aplicação e reservar vertical para componentes que dificilmente se tornam stateless.

Elasticidade versus escalabilidade

Os dois termos confundem-se no dia a dia, mas descrevem propriedades distintas. Escalabilidade é a capacidade estrutural do sistema de suportar crescimento quando acionada; é uma propriedade estática do desenho. Elasticidade é a capacidade de ajustar automaticamente os recursos alocados ao longo do tempo, acompanhando a demanda em ambas as direções; é uma propriedade dinâmica da operação. Um sistema pode ser escalável sem ser elástico, como um cluster que cresce apenas com intervenção humana em dias úteis; e teoricamente elástico sem ser escalável, se a automação cresce em amplitude dentro de um desenho que satura em algum limite.

Elasticidade tem um componente econômico direto: crescer no pico e encolher na vale transforma despesa fixa em variável, alinhada ao modelo de cobrança por uso da nuvem. A elasticidade também reduz o risco da superprovisionamento defensivo, em que times compram capacidade para o pior caso e pagam o ano inteiro por um dia de pico. O contraponto é o custo da automação: políticas mal calibradas geram oscilação, reações tardias ou custos surpresa, por isso os arquivos seguintes dedicam atenção a janelas de estabilização, warm-up e métricas.

Stateless como pré-requisito

A escala horizontal automática pressupõe que qualquer instância possa ser criada, receber tráfego e morrer sem perder nada que importe. Essa propriedade chama-se statelessness, e é o pré-requisito mais violado em migrações para auto scaling. O estado que impede a troca livre de instâncias aparece em formas variadas, cada uma com solução consolidada.

• Sessão em memória do processo, quebrando requisições que caem em outra réplica; substitua por sessões em Redis, ElastiCache ou tokens sem estado, como JWT com revogação adequada.
• Arquivos gravados em disco local, perdidos na substituição da instância; mova para S3, EFS ou armazenamento de objetos equivalente.
• Cache local de dados críticos, gerando inconsistências entre réplicas; prefira cache distribuído quando a coerência importa.
• Contadores e locks em memória, como rate limiting por instância; centralize em Redis com operações atômicas.
• Conexões persistentes assumidas como estáveis, como WebSocket sem estratégia de reconexão e descoberta; use bus de mensagem ou estado compartilhado para roteamento.

Mesmo os componentes que mantêm estado podem participar do modelo, desde que o estado esteja fora da unidade escalável. O padrão é claro: computação sem estado e escalável horizontalmente; dados com estado em serviços projetados para isso, escalados com mecanismos próprios, como réplicas de leitura e sharding.

Limites e riscos da escala vertical

A escala vertical parece a saída fácil, e é útil em cenários restritos, mas tem limites duros que a arquitetura precisa antecipar. O primeiro é físico: não existe instância infinita, e classes de instância enormes concentram risco em um único domínio de falha, pois uma instância de 24 TB de memória que falha derruba o sistema inteiro. O segundo é operacional: redimensionar exige parada ou migração na maioria dos cenários, o que conflita com disponibilidade contínua. O terceiro é econômico: o custo cresce mais rápido que a capacidade, e classes superiores carregam prêmio por unidade de recurso.

O risco operacional mais insidioso é o uso da vertical como solução permanente para cada problema de desempenho. Consultas ruins escondem-se atrás de memória nova, e a dívida de desempenho cresce até que a próxima classe de instância custe mais que o projeto de otimização. Um registro de decisões que exija justificar cada scale up com análise de gargalo mantém o time honesto e adia a necessidade de crescimento vertical desnecessário.

Ciclo de vida da escala automática

Auto scaling funciona como um controlador de malha fechada que opera em quatro etapas contínuas. Entender o ciclo inteiro evita surpresas de latência entre o pico e a reação.

• Observação: o sistema coleta métricas de CloudWatch, métricas do orquestrador ou endpoints customizados, em intervalos fixos, geralmente de um minuto.
• Decisão: uma política compara a métrica com o alvo ou com os limites configurados e calcula o ajuste necessário, respeitando janelas de estabilização.
• Provisionamento: novas unidades são criadas, com boot, dependências e registro no balanceador; essa é a parte mais lenta do ciclo.
• Drenagem: ao reduzir, unidades recebem requisições de encerramento, completam trabalho em andamento e são removidas do pool com segurança.

O tempo total entre o início do pico e a capacidade plena, às vezes chamado de tempo de reação do sistema, soma a latência da métrica, a latência da decisão e o tempo de boot da unidade. Em instâncias EC2, o boot pode levar de um a três minutos; em contêineres, segundos. Esse atraso é o argumento principal para manter capacidade mínima acima de zero e para conhecer o comportamento de pré-aquecimento da sua plataforma.

Exemplo prático em infraestrutura como código

O exemplo abaixo ilustra a mecânica declarativa de um grupo elástico com política de escala por alvo, que será detalhada nos arquivos seguintes.

# Grupo de auto scaling com capacidade variável entre mínimo e máximo
resource "aws_autoscaling_group" "api" {
  name                = "api-producao"
  min_size            = 2   # piso para disponibilidade, mesmo na madrugada
  max_size            = 12  # teto de segurança contra custo descontrolado
  desired_capacity    = 4   # tamanho inicial na criação
  vpc_zone_identifier = ["subnet-a", "subnet-b", "subnet-c"]

  # Template de lançamento define AMI, tipo e configuração da instância
  launch_template {
    id      = aws_launch_template.api.id
    version = "$Latest"
  }

  # Distribuição em múltiplas zonas de disponibilidade
  health_check_type         = "ELB"
  health_check_grace_period = 120
}

# Política de target tracking mantém a média de CPU próxima de 60%
resource "aws_autoscaling_policy" "cpu" {
  name                   = "api-cpu-60"
  autoscaling_group_name = aws_autoscaling_group.api.name
  policy_type            = "TargetTrackingScaling"

  target_tracking_configuration {
    target_value = 60

    predefined_metric_specification {
      predefined_metric_type = "ASGAverageCPUUtilization"
    }
  }
}

A leitura do exemplo reforça o conceito central: ninguém programa passos de escalar, declara-se a intenção, manter CPU em 60%, e a plataforma converge. A próxima etapa do estudo é compreender quais métricas justificam cada tipo de política e por que a CPU não é sempre a escolha certa.

Custo por tipo de escala

Cada estratégia de escala carrega um perfil de custo distinto. A escala vertical cobra prêmio por classe, com descontinuidades entre categorias de instância; reservas e Savings Plans mitigam quando a capacidade é estável. A escala horizontal elástica cobra pelo uso efetivo, mas exige sobrecarga de orchestration e pode gerar churn de instâncias, com custo oculto em API calls, bootstrapping e perda de warm cache. O ponto ótimo do desenho econômico costuma combinar uma base estável de capacidade reservada, uma camada elástica com auto scaling para a variabilidade e buffer de segurança para picos extremos.

A governança de custo também depende de limites. Todo grupo escalável em produção precisa de máximo explicitamente definido, alarmes quando o máximo é atingido e revisão periódica das configurações. Sem isso, um bug de loop ou uma campanha viral gera conta surpresa, e o time descobre a ausência de guardrails no fim do mês.

Erros comuns e boas práticas

Erros conceituais neste tema se manifestam como incidentes clássicos de capacidade. Os mais comuns merecem reconhecimento imediato.

• Assumir que a aplicação é stateless sem verificar sessões, arquivos e caches locais, descobrindo no pico que metade das requisições quebra.
• Escalar verticalmente como reflexo, sem análise de gargalo, encarecendo o custo unitário e aumentando o raio de falha.
• Confundir elasticidade com escalabilidade, dimensionando automação sobre um desenho que não suporta distribuição.
• Esquecer componentes downstream: escalar a API dez vezes sobrecarrega o banco, que não escala na mesma cadência, e o gargalo apenas muda de lugar.
• Definir máximo alto sem alarme, transformando um incidente de custo em surpresa financeira mensal.
• Testar escala apenas no tráfego normal; sem teste de carga simulando o pico, as políticas descobrem seus limites em produção.
• Tratar drenagem de instâncias como opcional; encerrar unidades com requisições em voo gera erros 502 no cliente e falha intermitente difícil de reproduzir.

Boas práticas consolidadas: desenhe para a horizontal desde o início, mesmo que comece com uma réplica; extraia todo estado compartilhado para serviços projetados para estado; meça o custo unitário por requisição para comparar estratégias com dados; trate limites de escala como parâmetros de produção com revisão periódica; e valide a elasticidade com testes de carga programados, confirmando que o crescimento e a redução acontecem nos prazos esperados. Com esse vocabulário estabelecido, os arquivos seguintes detalham como cada plataforma implementa essas decisões na prática.