Escalabilidade no ECS

Escrito pelo Claude Code em 18/10/2026, a partir dos testes de carga e de falha executados no ambiente dev do arglabs-workload entre 16 e 18 de outubro de 2026: nove rodadas, quatro relatórios, mais de 24 milhões de requisições. O módulo é o arglabs-tfmod-ecs-app; o arglabs-workload é o template que todo repositório de app do ARGLabs copia.

Com que velocidade um serviço ECS Fargate adiciona tasks quando a carga dispara, o que cada opção de scaling do módulo muda e o que o próprio app precisa fazer. Todos os números abaixo foram medidos, no mesmo serviço, com os mesmos testes, a partir de um único cliente.

1. Resumo

2. O ambiente de teste

Os testes, cada um começando com 2 tasks, salvo indicação em contrário:

3. Por que as políticas padrão são lentas

O ECS publica CPUUtilization e MemoryUtilization e o ALB publica RequestCountPerTarget como datapoints de um minuto. Nestes testes, o datapoint de um minuto chegou ao alarme cerca de 3 minutos depois do fim daquele minuto. Tudo o que é construído sobre eles herda o atraso:

Os dados atrasados também agem depois do fato. Um alarme de emergência de CPU voltou para ALARM 1 min 23 s depois que uma carga havia terminado, com um datapoint de 3 minutos antes, e levou um serviço ocioso de 2 para 4 tasks. Na primeira rodada, um AlarmLow de memória ainda ligado desde antes de um teste de memória fez a política de CPU remover duas tasks enquanto a memória estava a 76%: o Application Auto Scaling faz scale-in quando todas as políticas de target tracking concordam, e uma delas estava lendo o passado.

4. Instrumentando o app

O scaling rápido move o sinal para dentro da task: o app mede a si mesmo e publica três métricas de alta resolução no CloudWatch, e o módulo escala com alarmes de 10 segundos sobre elas.

O contrato

• Namespace e dimensões são o contrato. O módulo injeta METRICS_NAMESPACE (<scope>/<app>), METRICS_INTERVAL (10), METRICS_DIMENSIONS (ClusterName=<cluster>,ServiceName=<service>) e METRICS_BURST_THRESHOLD. Toda task publica sob as mesmas dimensões, então a estatística de um alarme em um período é uma estatística sobre as tasks; os alarmes do módulo usam a mediana (p50).
• StorageResolution 1, a cada 10 s, a partir de uma thread própria.
• Publique na hora em um burst. Quando as requisições em andamento chegam a METRICS_BURST_THRESHOLD (o módulo o define a partir de fast_scaling_inflight_threshold), o publicador não espera o fim do seu intervalo, no máximo uma vez a cada 3 s: o alarme vê o pico no período em que ele começa, cerca de 10 s antes.
• Fique quieto nos primeiros 20 s. Os sidecars e o interpretador começam com um burst de CPU (81% da task no primeiro intervalo): publicado, toda task nova pareceria saturada e todo deployment faria scale-out.
• Conte a fila. Uma requisição esperando na accept queue é carga que a task ainda não tocou; deixá-la de fora faz uma task saturada parecer ociosa.

O módulo concede cloudwatch:PutMetricData à task role com a condição cloudwatch:namespace igual ao namespace (a API não aceita ARN de recurso). O essencial do que o app de exemplo faz, como um esboço sem tratamento de erros:

import json, os, threading, time, urllib.request
import boto3

NAMESPACE = os.environ.get("METRICS_NAMESPACE", "")
INTERVAL = float(os.environ.get("METRICS_INTERVAL", "10"))
BURST = int(os.environ.get("METRICS_BURST_THRESHOLD") or 0)
DIMS = [{"Name": k, "Value": v} for k, v in (p.split("=", 1)
        for p in os.environ.get("METRICS_DIMENSIONS", "").split(",") if "=" in p)]
in_flight = 0  # the request handler adds 1 on entry and subtracts 1 on exit (under a lock)


def meta(path):
    with urllib.request.urlopen(os.environ["ECS_CONTAINER_METADATA_URI_V4"] + path, timeout=2) as r:
        return json.load(r)


def publish_forever():
    cw = boto3.client("cloudwatch")
    limits = meta("/task")["Limits"]  # {"CPU": 0.25, "Memory": 512}
    started, last, prev, samples = time.monotonic(), time.monotonic(), None, []
    while True:
        time.sleep(1)
        samples.append(in_flight)  # plus the accept queue, if the server has one
        now = time.monotonic()
        burst = BURST and samples[-1] >= BURST and now - last >= 3
        if now - last < INTERVAL and not burst:
            continue
        last = now
        stats = [c for c in meta("/task/stats").values() if c]
        cpu_ns = sum(c["cpu_stats"]["cpu_usage"]["total_usage"] for c in stats)
        mem = sum(c["memory_stats"]["usage"] - c["memory_stats"]["stats"].get(
            "total_inactive_file", c["memory_stats"]["stats"].get("inactive_file", 0)) for c in stats)
        data = [{"MetricName": "RequestsInFlight", "Dimensions": DIMS, "Unit": "Count",
                 "StorageResolution": 1,
                 "StatisticValues": {"SampleCount": len(samples), "Sum": sum(samples),
                                     "Minimum": min(samples), "Maximum": max(samples)}}]
        if prev and now - started >= max(2 * INTERVAL, 20):
            cpu = 100 * (cpu_ns - prev[0]) / ((now - prev[1]) * 1e9) / limits["CPU"]
            for name, value in (("CpuUtilization", cpu),
                                ("MemoryUtilization", 100 * mem / (limits["Memory"] * 2**20))):
                data.append({"MetricName": name, "Dimensions": DIMS, "Unit": "Percent",
                             "StorageResolution": 1, "Value": round(min(value, 100), 2)})
        prev, samples = (cpu_ns, now), []
        cw.put_metric_data(Namespace=NAMESPACE, MetricData=data)


if NAMESPACE:
    threading.Thread(target=publish_forever, daemon=True).start()

Qualquer linguagem serve: o contrato são os três nomes, suas unidades e as dimensões. Um app que não publica nada deixa os alarmes sem dados (notBreaching), então nada acontece e nada quebra; para esse app, mantenha o scaling rápido desligado e o passo de emergência de CPU ligado.

O que custa, a preços de tabela de us-east-1: uma chamada PutMetricData por task a cada 10 s são cerca de 259.000 chamadas por mês, USD 2,60 por task-mês a USD 0,01 por 1.000; mais três métricas customizadas e três alarmes de alta resolução por serviço e região, USD 1,80 por mês. É mais ou menos o que custa uma task Spot de 0,25 vCPU; um intervalo de 30 s divide as chamadas por três, e os alarmes então usam períodos de 30 s.

5. As opções, uma a uma

Inputs do módulo arglabs-tfmod-ecs-app, o padrão, o valor no arglabs-workload (dev) e o que cada um fez nos testes.

Scaling rápido

Políticas em métricas da AWS

Em volta do scaling: load balancer e deployments

6. Scaling rápido ligado e desligado, medido

Os mesmos três testes, executados com enable_fast_scaling ligado e desligado em dev, com a mesma imagem do app e a mesma configuração: só a opção mudou entre as duas rodadas.

Nada falhou com o scaling rápido desligado: este app enfileira em vez de recusar, então a falta de tasks aparece como latência e throughput, não como erros, desde que fique abaixo do timeout do cliente. Um app com timeouts mais apertados, ou que recuse conexões, transformaria esses minutos em erros. O preço do scaling rápido é a capacidade usada mais cedo: as mesmas 10 tasks, minutos antes. A mesma opção medida duas vezes, em duas versões do app, variou até 11 s no primeiro scale-out e 33 s para 10 tasks saudáveis: ruído bem abaixo da diferença acima.

7. Dentro da task: o que o app precisou mudar

O pico de 600 contra 2 tasks, o mesmo teste após cada mudança. As duas primeiras linhas são as primeiras rodadas, sem scaling rápido; a partir de T1, o scaling rápido está ligado.

O que cada passo ensinou, para qualquer app atrás de um ALB:

• Verifique o listen backlog e o keep-alive antes de um teste de carga. O HTTPServer do Python escuta com backlog de 5 e responde HTTP/1.0, então o ALB abre uma conexão por requisição; a cerca de 470 conexões novas por segundo por task a fila estourou, o kernel descartou SYNs e o ALB respondeu 504 após seu timeout de conexão de 10 s. Nenhum target chegou a ficar não saudável.
• Concorrência ilimitada é pior que uma fila. Com backlog de 1024, o ALB colocou todas as 600 requisições dentro das 2 tasks: cerca de 300 threads Python por task em 0,25 vCPU disputaram o interpretador, cada requisição custou o dobro de CPU, e o health check de 2 s deu timeout no meio do pico. O antigo backlog de 5 tinha sido um controle de admissão por acidente.
• Mantenha a thread que aceita alimentada. Com 8 threads worker, a que aceitava conexões esperava atrás delas e as conexões novas ficavam até 10 s sem ser aceitas. Uma thread worker, com as requisições que dormem repassadas a threads próprias, resolveu.
• Desligue o Nagle com keep-alive. Cabeçalhos e corpo em duas escritas esperavam o ACK atrasado do ALB: 40 ms em toda resposta. TCP_NODELAY, depois uma escrita por resposta.
• Faça drain no SIGTERM, e deixe o ALB fazer drain. Deploys, scale-in e interrupções de Spot param tasks com SIGTERM; o app continua aceitando até a fila do kernel esvaziar, e deregistration_delay dá 5 s às requisições em andamento.
• Meça a CPU por requisição onde ela roda. Um profile local no Python 3.9 culpava o JSON indentado por 30% de uma requisição; no Python 3.14 e posteriores, o da imagem, indent= também usa o encoder em C e custa cerca de 0,5 µs. Uma imagem base sem versão fixada muda a CPU por requisição sem nenhuma mudança de código.
• Cuidado com os limites de file descriptors de APIs antigas. select.select() falha acima de 1.024 descriptors: 3000 requisições lentas fizeram toda requisição falhar, health checks inclusive. poll() não tem esse limite.

Capacidade com o serviço fixo em 10 tasks, req/s a 300, 400 e 600 em andamento: 2.390, 3.083 e 3.537 na primeira rodada; 2.404, 3.205 e 4.679 com o código final. Abaixo de 300 em andamento, o throughput é a concorrência dividida pela latência de rede, igual em todas as versões.

8. Armadilhas

• Um alarme de step ainda em ALARM dispara de novo. Definir o desired count à mão depois de um teste foi desfeito por um alarme que não tinha voltado para OK. Espere os alarmes antes.
• Datapoints atrasados escalam o próximo teste. Com o scaling rápido desligado, espere cerca de 4 minutos depois de uma carga antes de medir qualquer outra coisa, ou a carga anterior dispara o scaling.
• Alarmes de deployment também veem o passado. Um deploy iniciado logo depois de um flood de requisições de 40 s sofreu rollback: o alarme de tempo de resposta pegou o flood dois minutos atrasado, dentro do bake time. Faça o deploy quando os alarmes estiverem OK.
• HealthyHostCount perde quedas curtas. O ALB o publica com 2 amostras por minuto: 40 s sem nenhum target saudável nunca apareceu na métrica, um minuto inteiro apareceu.
• Os logs atrasam quando a CPU está saturada. O Fluent Bit divide os 0,25 vCPU da task: só 13% das linhas chegaram ao CloudWatch no próprio minuto, o resto até 5 minutos depois. Nenhuma se perdeu; filtre pelo @timestamp dentro do JSON, não pelo do CloudWatch.
• Uma task nova leva cerca de um minuto. Cerca de 19 s da criação até o download da imagem, 30 a 60 s de downloads (a imagem do Fluent Bit tem 113 MB compactada), depois dois health checks: imagens menores são o próximo ganho.
• Interrupções de Spot são baratas quando a task faz drain. Cinco reais durante os testes. A que ocorreu no meio de um pico, antes do drain de 5 s, cortou 21 requisições em andamento; as outras quatro não custaram nenhuma: a substituta começou um segundo depois do aviso e ficou saudável em 40 a 50 s.

9. A configuração que resultou disso

Os inputs do módulo como o arglabs-workload os define em dev, por meio de seus locals:

module "ecs_app" {
  source = "git::https://bitbucket.org/arglabs/arglabs-tfmod-ecs-app.git//terraform?ref=main"
  # ...
  min_capacity_value         = 2
  max_capacity_value         = 10
  cpu_target_value           = 70
  mem_target_value           = 70
  request_count_target_value = 1000 # requests a minute per task: size it from a measured task

  # Fast scaling: the app publishes CpuUtilization, MemoryUtilization and RequestsInFlight
  fast_scaling_metrics_namespace      = "aio/workload"
  fast_scaling_metrics_interval       = 10
  fast_scaling_evaluation_periods     = 1
  fast_scaling_datapoints_to_alarm    = 1
  fast_scaling_statistic              = "p50"
  fast_scaling_inflight_threshold     = 8
  fast_scaling_step_percent           = 200
  fast_scaling_saturated_step_percent = 400
  fast_scaling_cooldown               = 60
  fast_scaling_target_tracking        = true

  # The steps on late metrics only where fast scaling is off
  enable_emergency_step_scaling     = false
  emergency_request_count_threshold = 0

  # Draining, and deployments that roll back on errors
  deregistration_delay            = 5
  deployment_bake_time_in_minutes = 5
  deployment_module_alarms        = ["http_5xx", "target_response_time"]
  http_5xx_threshold              = 10
  target_response_time_threshold  = 1
}

Para um app que não consegue publicar as métricas: deixe fast_scaling_metrics_namespace vazio, mantenha enable_emergency_step_scaling ligado e defina request_count_target_value a partir de uma task medida; espere de 4 a 6 minutos até o primeiro scale-out.

10. Método e limites

• Um cliente, no Brasil, a cerca de 120 ms do serviço: o throughput medido no cliente inclui essa latência; o TargetResponseTime do ALB deu o lado do servidor.
• Fargate Spot em Graviton2, dias e horas diferentes: os números da rampa da primeira rodada vieram em parte do hardware daquele dia. Sua imagem, executada de novo nas tasks posteriores, fez 2.308, 2.540 e 2.584 req/s a 300, 400 e 600 em andamento, contra 2.390, 3.083 e 3.537 naquele dia.
• Uma execução por configuração na maioria dos testes; a variação entre execuções do mesmo código está no texto onde foi medida.
• O scale-in não foi medido depois da primeira rodada: entre os testes o desired count voltava a 2 à mão, quando os alarmes de scaling estavam OK.
• Só dev: stg e prd rodam o mesmo código com outros valores (o prd mantém 2 tasks on-demand antes do Spot).