Políticas de Escala (CPU, Memória, Métricas customizadas)

Políticas de escala são as regras que traduzem métricas de carga em decisões de capacidade: quando adicionar unidades, quantas adicionar e quando devolver capacidade ao pool. A AWS oferece três famílias principais, target tracking, step scaling e scheduled scaling, e todas dependem da qualidade da métrica escolhida, que é a parte mais difícil e mais negligenciada do desenho. Uma política tecnicamente perfeita sobre uma métrica errada produz superprovisionamento constante ou falha no pico, e nenhum alarme corrige uma escolha conceitual ruim. Este registro cobre os tipos de política, as métricas mais usadas, incluindo CPU, memória, requisições por alvo e profundidade de fila, e o caminho para métricas customizadas no CloudWatch. O objetivo final é dar critérios objetivos para escolher a métrica certa para cada perfil de serviço, com atenção a cool-down, flapping e estabilização.

Target tracking: escala por alvo

A política de target tracking é o modelo declarativo do auto scaling: você define que uma métrica deve permanecer próxima de um valor alvo, e o controlador calcula continuamente quantas unidades são necessárias para cumprir o alvo, adicionando ou removendo conforme necessário. A matemática interna é uma proporção simples, replicada por ética de segurança: unidades desejadas igual a unidades atuais multiplicadas pela razão entre métrica atual e alvo, com limites mínimos e máximos respeitados. Se a CPU média está em 90% com 4 instâncias e o alvo é 60%, o cálculo indica 6 instâncias.

As vantagens operacionais explicam por que é a política padrão recomendada. Ela reage a aumentos e diminuições com o mesmo mecanismo, sem passo a passo para manter; incorpora estabilização embutida, evitando remoções abruptas após picos breves; e dispensa o desenho de pares de alarmes com dimensões de cada estágio. A recomendação prática da AWS é começar com target tracking e recorrer a step scaling apenas quando a reação precisa ser mais agressiva que o alvo permite.

O exemplo abaixo combina uma métrica predefinida de CPU com a métrica de requisições por alvo do ALB, mostrando que um mesmo grupo pode ter mais de uma política, e o controlador responde ao ajuste mais amplo necessário entre elas.

# Política 1: mantém a CPU média em 55% no grupo de instâncias
aws autoscaling put-scaling-policy \
  --auto-scaling-group-name api-asg \
  --policy-name api-cpu-55 \
  --policy-type TargetTrackingScaling \
  --target-tracking-configuration '{
    "TargetValue": 55.0,
    "PredefinedMetricSpecification": {
      "PredefinedMetricType": "ASGAverageCPUUtilization"
    }
  }'

# Política 2: mantém 500 requisições por minuto por alvo, métrica do ALB
aws autoscaling put-scaling-policy \
  --auto-scaling-group-name api-asg \
  --policy-name api-requisicoes-por-alvo \
  --policy-type TargetTrackingScaling \
  --target-tracking-configuration '{
    "TargetValue": 500.0,
    "PredefinedMetricSpecification": {
      "PredefinedMetricType": "ALBRequestCountPerTarget",
      "ResourceLabel": "app/meu-alb/1234567890/targetgroup/api/abc"
    }
  }'

A nota prática sobre múltiplas políticas: quando várias apontam para direções diferentes, o sistema aplica a que exige maior capacidade, o que é seguro por padrão, mas pode encarecer se uma política estiver mal calibrada; revise o comportamento combinado com teste de carga antes de produção.

Step scaling: graduações por alarme

A política de step scaling aciona ajustes quando um alarme do CloudWatch cruza limites definidos, e cada faixa de violação aplica um ajuste proporcional. Um alarme de CPU acima de 75% por três períodos pode instruir: até 80%, adicione 1; de 80% a 90%, adicione 2; acima de 90%, adicione 4. O modelo dá controle fino e permite reações escalonadas, mas exige desenhar alarmes em ambos os sentidos, com dimensões coerentes para não oscilar.

A escolha entre os dois tipos é, na prática, uma escolha de simplicidade: target tracking cobre a esmagadora maioria dos casos, e step scaling entra quando há evidência de que a reação precisa de graduações específicas.

Scheduled scaling: cargas previsíveis

Quando a demanda segue padrão temporal conhecido, agendamento é mais eficiente que reação a métrica. Scheduled scaling ajusta capacidade mínima, desejada ou máxima em horários definidos: ampliar antes da campanha das 10h, reduzir após as 21h, dimensionar o fim de semana diferente do dia útil. O ganho duplo é antecipação e disciplina: a capacidade já está pronta quando o pico começa, sem esperar boot, e a redução programada evita a tendência de esquecer o sistema inflado.

A combinação com políticas reativas é a configuração madura típica: scheduled scaling define a moldura de capacidade para a janela previsível, e target tracking reage ao imprevisível dentro dessa moldura. Em ambientes que exigem conformidade com janelas de manutenção e eventos de marketing, o agendamento costuma ser disparado pelo mesmo pipeline que coordena o deploy, mantendo a escala como parte da mudança revisada.

Métricas: CPU, memória, requisições e filas

A escolha da métrica é a decisão mais importante do desenho, e a CPU é tanto a mais usada quanto a mais mal usada. A tabela resume as candidatas e seus perfis.

A CPU funciona como alvo quando o consumo de processamento é a variável dominante do tempo de resposta, típico de transformação de dados e endpoints computacionais. Para serviços orientados a I/O, onde o tempo é gasto esperando banco e rede, a CPU fica estável enquanto a latência explode, e o alvo correto passa a ser requisições por alvo, que distribui tráfego de forma proporcional à capacidade declarada. Para consumidores de fila, a profundidade da fila, ou a idade da mensagem mais antiga, reflete a dívida de processamento melhor que qualquer métrica da unidade escalável.

Como escolher a métrica certa

A escolha tem um método simples e eficaz, executável em uma tarde de análise e um teste de carga.

• Identifique o gargalo dominante observando o serviço sob carga real ou simulada: CPU, memória, espera de I/O, concorrência ou fila pendente.
• Verifique se a métrica candidata correlaciona com o indicador que o usuário sente, geralmente latência ou erro; se a métrica sobe e o usuário não nota, ela não serve.
• Teste a correlação no teste de carga: dobre a carga e confirme se a métrica reage proporcionalmente e no intervalo de um minuto.
• Verifique a disponibilidade da métrica na frequência necessária; métrica de cinco minutos não serve para tráfego que dobra em dois.
• Considere o custo de coleta; métricas customizadas de alta cardinalidade cobram por série distinta e podem sair mais caras que a própria capacidade.
• Documente a decisão e o teste que a sustentou; a métrica de escala é uma decisão de arquitetura, e seu histórico evita trocas cíclicas sem evidência.

O resultado esperado é uma política que não precisa de ajuste frequente. Uma política saudável escala de forma perceptível em horários previsíveis, permanece estável fora deles e nunca satura o teto sem alarme. Se o time ajusta o alvo toda semana, o problema não é o número, é a métrica escolhida.

Métricas customizadas no CloudWatch

Quando nenhuma métrica predefinida representa o gargalo real, o caminho é publicar a própria. As formas principais são o PutMetricData da API, o agente CloudWatch com StatsD e collectd, e a publicação via EMF, Embedded Metric Format, que extrai métricas de logs estruturados sem chamada extra. A política de auto scaling consome a métrica por namespace e dimensão, com math expression quando é preciso combinar sinais, por exemplo, profundidade por worker.

# Publica métrica customizada de jobs pendentes por worker via CLI
aws cloudwatch put-metric-data \
  --namespace "Acme/Pedidos" \
  --metric-name "JobsPendentesPorWorker" \
  --value 14.5 \
  --unit Count \
  --dimensions Environment=producao,Servico=processador \
  --region sa-east-1

# Política de target tracking usando a métrica customizada
aws autoscaling put-scaling-policy \
  --auto-scaling-group-name processador-asg \
  --policy-name processador-jobs-alvo \
  --policy-type TargetTrackingScaling \
  --target-tracking-configuration '{
    "TargetValue": 10.0,
    "CustomizedMetricSpecification": {
      "MetricName": "JobsPendentesPorWorker",
      "Namespace": "Acme/Pedidos",
      "Dimensions": [
        { "Name": "Environment", "Value": "producao" },
        { "Name": "Servico", "Value": "processador" }
      ],
      "Statistic": "Average",
      "Unit": "Count"
    }
  }'

Métricas customizadas exigem disciplina de engenharia: namespace e dimensões padronizadas, cadência estável de publicação, granularidade de um minuto quando possível, porque agregações mais largas atrasam a reação, e cuidado com custo, pois cada métrica distinta por combinação de dimensões é cobrada. Um padrão saudável é publicar a métrica como parte do serviço, versionada junto do código, e não como script solto no ambiente.

Cool-down, flapping e estabilização

Três fenômenos definem a qualidade operacional de uma política. O cool-down, período de espera após uma ação de escala antes de permitir outra, evita reações em cadeia enquanto métricas ainda refletem o boot anterior. O flapping é a oscilação de sobe e desce que ocorre quando a política reage rápido demais a sinais ruidosos, criando churn de instâncias e custo de boot sem ganho. A estabilização é a janela em que o controlador desconta sinais breves antes de agir, mantendo a média ponderada do período recente.

Na AWS, o target tracking incorpora estabilização padrão para scale down, e o parâmetro de warm-up do grupo de auto scaling desconta do cálculo as instâncias ainda em inicialização, evitando a falsa leitura de sobrecarga enquanto o boot não terminou. Em Kubernetes, o HPA expressa o mesmo cuidado em behavior.scaleUp e behavior.scaleDown, com stabilizationWindowSeconds e taxas de crescimento. Os valores não são decoração: reduzir antes do warm-up acabar provoca o ciclo clássico de desligar instâncias que ainda estavam subindo.

Erros comuns e boas práticas

Políticas de escala acumulam erros recorrentes que se manifestam como custos altos ou falhas no pico. Reconhecê-los orienta a revisão.

• Escolher CPU como alvo em serviço de I/O, mantendo a capacidade estável enquanto a latência cresce; valide a métrica contra o perfil de resposta.
• Definir alvo agressivo demais, como 90% de CPU, deixando margem zero para picos rápidos e boot; valores entre 40% e 70% são típicos.
• Ignorar o warm-up, causando decisões baseadas em instâncias ainda aquecendo; configure o período igual ao tempo real de boot do serviço.
• Métrica customizada com granularidade de cinco minutos, tornando a reação lenta demais para o padrão de tráfego.
• Falta de mínimo adequado, permitindo que a política reduza a capacidade a um nível que viola redundância mínima.
• Alarmes de máxima capacidade ausentes, escondendo o momento em que a política deixou de reagir por teto.

Boas práticas consolidam a operação. Comece com target tracking e uma métrica validada por teste de carga; adicione scheduled scaling para a parte previsível da demanda; monitore a métrica escolhida com alarme de estagnação, que dispara quando a escala bate no teto; e registre a justificativa da métrica em documentação de arquitetura, porque quem vier depois precisa saber por que aquela decisão foi tomada. A política de escala é parte da arquitetura de produção, e merece o mesmo rigor de revisão que o código de negócio.