Auto scaling do ECS fica até 76% mais rápido com métricas de 20 segundos

Quem desenha o Auto Scaling de um serviço ECS sabe qual número mais dói num incidente de pico: o tempo entre o estouro de tráfego e a task nova de pé, recebendo requisição. Um deep dive publicado no AWS Containers Blog detalha duas mudanças que atacam exatamente esse número: métricas de CPU e memória publicadas a cada 20 segundos, em vez dos 60 segundos padrão, e um caminho de publicação otimizado para essas métricas chegarem à política de target tracking com menos atraso.

O resultado, no benchmark da própria AWS: o tempo para disparar o scale-out caiu 76%, de 363 para 86 segundos. O tempo entre disparar o scale-out e a task nova estar rodando caiu 72%, de 386 para 109 segundos. Para quem opera ECS ou Fargate em produção no Brasil, isso é o intervalo em que o serviço serve requisição lenta ou erro 5xx antes da capacidade nova entrar, e é o buffer que muita equipe mantém ligado o tempo todo só para sobreviver a esse atraso.

Este texto é o roteiro para ativar a métrica de alta resolução num serviço ECS, observar o efeito com carga real e decidir, com número na mão, se vale pagar por ela.

O que você vai construir

Você vai pegar um serviço ECS que já escala por target tracking em CPU (o caso mais comum em produção) e trocar a métrica padrão ECSServiceAverageCPUUtilization, resolução de 60 segundos, pela nova métrica pré-definida ECSServiceAverageCPUUtilizationHighResolution, resolução de 20 segundos. O exemplo usa um serviço fictício chamado checkout-api, rodando em Fargate no cluster prod-sa-east-1, mas o procedimento é idêntico em ECS Managed Instances e em EC2 launch type.

Quando vale ativar isso

A própria AWS recomenda ligar a métrica de alta resolução em serviços específicos, não em todo cluster por padrão. Ela compensa em três cenários:

• Workload com tráfego em rajada, como API atrás de evento ou integração assíncrona.
• Aplicação sensível a latência, onde mesmo um minuto de degradação já é visível pro usuário.
• Serviço que hoje roda super-provisionado só para aguentar o lag do scaling.

Para workload estável e de crescimento lento, os 60 segundos padrão continuam suficientes, e trocar a métrica só aumenta a fatura do CloudWatch sem ganho real.

Pré-requisitos

• Conta AWS com um cluster ECS existente e um serviço já em produção (Fargate ou Managed Instances), de preferência já registrado como scalable target no Application Auto Scaling.
• Permissões IAM mínimas: ecs:UpdateService, ecs:DescribeServices, application-autoscaling:RegisterScalableTarget, application-autoscaling:PutScalingPolicy, application-autoscaling:DescribeScalingPolicies e cloudwatch:GetMetricData para inspecionar os dados depois.
• AWS CLI v2 configurado, apontando para a região onde o serviço roda (sa-east-1 neste exemplo).
• Opcional, mas recomendado para o teste de carga: k6 ou outra ferramenta capaz de gerar uma rampa de requisições controlada.
• Atenção ao custo: a AWS não cobra pelo recurso em si nem pelas métricas padrão de 60 segundos. Publicar CPU e memória a cada 20 segundos as transforma em métricas de alta resolução do CloudWatch, cobradas por métrica. A fonte não detalha o valor por métrica; confira o preço atual na página de preços do CloudWatch antes de ligar isso em todo serviço do cluster.

Passo a passo

1. Ativar as métricas de alta resolução no serviço. No console do ECS, vá em Clusters > prod-sa-east-1 > Services > checkout-api > Update service. Na seção Monitoring configuration, marque as opções de alta resolução para CPU e memória e confirme a atualização. Se o serviço já está em produção, faça esse passo primeiro e espere o deployment terminar: é só depois dele que o ECS começa a emitir os pontos de 20 segundos.

2. Confirmar que a métrica de 20 segundos já está chegando ao CloudWatch. No console, abra CloudWatch > Metrics > All metrics > namespace ECS, filtre por ClusterName e ServiceName e confira se os datapoints de CPU aparecem a cada 20 segundos, não mais a cada 60.

3. Trocar a política de target tracking pela métrica de alta resolução. Crie (ou atualize) a política via AWS CLI, usando o novo tipo de métrica pré-definida:

aws application-autoscaling put-scaling-policy \
 --service-namespace ecs \
 --resource-id service/prod-sa-east-1/checkout-api \
 --scalable-dimension ecs:service:DesiredCount \
 --policy-name checkout-api-cpu-highres \
 --policy-type TargetTrackingScaling \
 --target-tracking-scaling-policy-configuration file://policy.json \
 --region sa-east-1

O arquivo policy.json aponta para a métrica nova:

{
 "TargetValue": 60.0,
 "PredefinedMetricSpecification": {
 "PredefinedMetricType": "ECSServiceAverageCPUUtilizationHighResolution"
 },
 "ScaleOutCooldown": 60,
 "ScaleInCooldown": 180
}

Para memória, o nome equivalente é ECSServiceAverageMemoryUtilizationHighResolution. Use um dos dois, ou os dois em políticas separadas, dependendo de qual recurso realmente limita o checkout-api.

4. Remover a política antiga, se existir. Se o serviço já tinha uma política de target tracking usando ECSServiceAverageCPUUtilization (resolução de 60 segundos), apague-a com aws application-autoscaling delete-scaling-policy, apontando o --policy-name antigo. Duas políticas de target tracking no mesmo recurso competem e deixam o comportamento imprevisível.

5. Validar o DesiredCount e os limites de escala. Confirme no RegisterScalableTarget que MinCapacity e MaxCapacity ainda fazem sentido: com reação mais rápida, o serviço vai bater no teto de escala mais cedo durante um pico real, então vale revisar se o MaxCapacity atual ainda cobre o cenário de pior caso.

Testando

O benchmark da AWS usou k6 gerando uma rampa de chegada em curva normal, até 32 mil usuários virtuais, contra três perfis de carga diferentes (uma API em Rust com Rocket, um serviço Java com JVM e um serviço Node.js), medindo CPU a 1 vCPU por task em us-west-2. Reproduzir exatamente esses números em sa-east-1 não é o objetivo aqui, até porque o perfil de carga, a linguagem e o tamanho da task mudam o resultado; o objetivo é comparar o checkout-api contra ele mesmo, antes e depois da troca de métrica.

O procedimento prático: rode o mesmo teste de carga duas vezes, uma com a política antiga (60 segundos) e outra com a nova (20 segundos), e compare duas coisas no console do ECS, na aba Scaling activities do serviço: o timestamp entre o início do pico e o primeiro evento de scale-out, e o timestamp até o DesiredCount estabilizar no valor necessário. Para referência de ordem de grandeza, a tabela abaixo reproduz o tempo de violação de SLA (janelas de 6 segundos com mais de 10% de falha) medido pela AWS em cada perfil:

Um ponto que vale observar no seu próprio teste: a AWS registrou que, com métrica de 20 segundos, rodar o mesmo teste várias vezes dá resultado quase idêntico a cada rodada, enquanto com 60 segundos a variação entre rodadas é bem maior. Se o seu teste também mostrar essa consistência, é sinal de que o checkout-api está de fato reagindo à carga, não ao acaso do timing da métrica.

Limpando os recursos

Se você criou uma política ou um serviço só para este teste, remova nesta ordem:

1. Apague a política de target tracking de teste: aws application-autoscaling delete-scaling-policy --service-namespace ecs --resource-id service/prod-sa-east-1/checkout-api --scalable-dimension ecs:service:DesiredCount --policy-name checkout-api-cpu-highres --region sa-east-1.
2. Se decidiu não manter a resolução de 20 segundos no serviço, volte em Update service > Monitoring configuration e desmarque as opções de alta resolução para CPU e memória, depois confirme a atualização.
3. Se criou um cluster ou serviço exclusivamente para o teste, derrube com aws ecs delete-service --cluster prod-sa-east-1 --service checkout-api --force e, em seguida, aws ecs delete-cluster --cluster prod-sa-east-1.

O ponto que mais gera cobrança esquecida: o ECS continua publicando métricas a cada 20 segundos enquanto o Monitoring configuration do serviço estiver marcado como alta resolução, mesmo que você já tenha apagado a política de scaling. É o passo 2 acima, não o 1, que faz a cobrança de métrica de alta resolução do CloudWatch parar.

Próximos passos

Target tracking rápido resolve a reação a um pico, mas não é a única peça do quebra-cabeça de capacidade. Vale combinar com scaling preditivo, que aprende padrão diário ou semanal e já deixa o serviço escalado antes do horário de pico, deixando o target tracking de 20 segundos cuidar só do que o forecast não previu. Para evento pontual conhecido, como lançamento de produto, scheduled scaling ainda é a ferramenta certa.

Se o checkout-api não escala por CPU, e sim por profundidade de fila SQS ou por requisição por target, o mesmo princípio vale: publique essa métrica customizada no CloudWatch na resolução que fizer sentido, inclusive alta resolução, e use target tracking sobre ela.

Vale também decidir entre Fargate e ECS Managed Instances olhando esse benchmark: nos Managed Instances, o ECS roda várias tasks por instância e pode colocar a task nova numa instância que já está de pé, com a imagem em cache, sem provisionar máquina nova. É por isso que os ganhos de SLA breach time nos Managed Instances chegaram a 98% no perfil de rampa gradual, contra 69% no Fargate: no Fargate, cada task sobe em ambiente isolado que o ECS provisiona na hora, e a imagem precisa ser baixada antes de a task começar.

Para aprofundar, a documentação de faster auto scaling do ECS e a documentação de service auto scaling trazem o passo a passo completo via CloudFormation e SDKs, o roadmap de containers da AWS no GitHub mostra o que vem a seguir, e o AWS re:Post for ECS é o canal oficial para dúvida ou feedback sobre o recurso.

Fonte: AWS Containers Blog