Framework de regressão da AWS replica tráfego real antes do deploy

Um engenheiro da AWS descreveu, no AWS Architecture Blog, um framework modular que captura tráfego de produção e o replaya contra o código novo para travar deploys arriscados antes de chegarem ao cliente.

Um engenheiro da AWS descreveu, no AWS Architecture Blog, um framework modular que captura tráfego de produção e o replaya contra o código novo para travar deploys arriscados antes de chegarem ao cliente.

O problema

Sistemas que calculam preço, processam pedido ou decidem elegibilidade não podem quebrar silenciosamente. Teste de integração tradicional ajuda, mas costuma depender de mocks e de ambientes que simulam dependências externas, e essas dependências falham de formas imprevisíveis. O resultado prático: falsos positivos que travam deploys válidos, ou falsos negativos que deixam passar uma mudança que alterou comportamento sem ninguém perceber.

No AWS Architecture Blog, um engenheiro da AWS descreveu como construiu, para o próprio time, um framework de teste de regressão que ataca o problema por outro ângulo. Em vez de simular entradas com dados sintéticos, o framework captura uma amostra do tráfego real que já passou pela produção e replaya essa amostra contra o código novo, antes (ou durante) o deploy, comparando a saída.

Em mais de seis meses de uso em produção no nosso sistema, o framework capturou cinco regressões que teriam afetado clientes, com zero falsos positivos que bloqueassem deploys válidos.

In more than 6 months of production use in our system, the framework caught five regressions that would have affected customers, with zero false positives that blocked valid deployments.Autor do post, AWS Architecture Blog

O relato não traz data de início do uso em produção, só o período de observação. Vale o recorte: o framework não testa lógica de negócio nova, não substitui teste de unidade e não faz o papel de A/B testing. A pergunta que ele responde é mais estreita e mais específica para quem opera pipeline de deploy: essa mudança quebrou algo que já funcionava?

A arquitetura

O desenho, descrito na fonte como um diagrama de componentes conectados por eventos, segue este fluxo do deploy até o veredito:

1. O pipeline de deploy chega no gate de produção e publica um evento no Amazon SNS.
2. O SNS entrega o evento para uma fila Amazon SQS.
3. Uma função AWS Lambda lê a fila e inicia uma execução do AWS Step Functions.
4. O workflow liga o replay: habilita o event source mapping entre o stream de captura (Amazon DynamoDB Streams, no caso do time que escreveu o post) e a função de replay.
5. Com o replay ligado, a função de replay lê as requisições capturadas do stream, marca cada uma com um simulationId e isSimulation: true, e envia essa cópia para o código novo (ambiente de pré-produção ou o próprio caminho atrás de um feature flag).
6. A função reduz a resposta de produção e a resposta simulada aos campos que carregam lógica de negócio, descarta timestamp e normaliza listas, compara as duas e grava uma linha JSON no Amazon CloudWatch Logs com um campo match igual a 1 (bateu) ou 0 (divergiu ou falhou).
7. O workflow desliga o replay (desabilita o mapping) e espera alguns minutos antes de avaliar, porque o Lambda pode levar tempo para parar de consumir o stream.
8. Uma query do CloudWatch Logs Insights calcula a fração de match (stats avg(match) as matchFraction) e publica o resultado como métrica customizada do CloudWatch.
9. Um alarme do CloudWatch sobre essa métrica avisa o gate do pipeline (no exemplo da fonte, uma regra CloudWatchAlarm no estágio de produção do AWS CodePipeline) se o deploy pode ser promovido ou precisa ser bloqueado.

O ponto central do desenho é que cada componente pode ser inserido em qualquer fronteira do sistema: no API gateway, entre microsserviços, na camada de banco ou na fila de mensagens. A comparação pode cobrir a saída de ponta a ponta ou só um bloco específico de lógica de negócio, deixando formatação e chamadas downstream fora do escopo.

Os serviços envolvidos

A escolha dos serviços segue um critério declarado na fonte: manter baixo o overhead operacional e pagar só pelo que cada simulação consome, o que empurra o desenho inteiro para componentes serverless e orientados a evento em vez de um ambiente de teste sempre ligado.

Trade-offs

Confiabilidade (reliability): sistemas stateful, como processamento de pagamento, pedido ou estoque, não podem simplesmente receber tráfego replayado sem controle, porque cada escrita duplicada vira um efeito colateral real. A saída descrita na fonte é checar isSimulation antes de qualquer gravação ou disparo de notificação:

if (!request.isSimulation()) {
 database.write(result);
 notificationService.send(result);
}

Para lógica com aleatoriedade (sorteio de grupo A/B, amostragem), o padrão é usar o simulationId como seed de um Random, tornando a simulação determinística e comparável execução após execução.

Segurança (security): o marcador simulationId/isSimulation só funciona se todo serviço na cadeia respeitar a flag. Se um serviço downstream ignorar o marcador, o replay vira tráfego de produção disfarçado, com todos os efeitos colaterais reais que o framework deveria evitar. Isso significa que adotar o padrão exige revisar cada serviço no caminho, não só o que recebe a chamada.

Otimização de custo e desempenho (cost optimization, performance efficiency): a fonte trava, no próprio código, um limite de fração de tráfego replayado (if (props.trafficFraction > 0.1) throw new Error('Traffic fraction too high')) e usa reservedConcurrentExecutions: 3 para limitar o pico de chamadas contra o ambiente de teste. A configuração típica citada é 5% do tráfego, em lotes de 200 registros: cobertura suficiente sem arriscar sobrecarregar o ambiente que recebe o replay.

Excelência operacional (operational excellence): a própria fonte inclui uma seção chamada "When to reconsider", recomendando abandonar o framework se manter a infraestrutura de idempotência virar um fardo de manutenção maior que o valor da regressão automatizada. É um reconhecimento raro de que nem todo sistema justifica o custo de engenharia de adicionar marcação de simulação em cada ponto de escrita.

Custo estimado

A fonte publica os valores com a ressalva explícita de que são da região US East (N. Virginia), referência de outubro de 2026, e recomenda a AWS Pricing Calculator para estimar o custo em outras regiões; não há número publicado para sa-east-1 (São Paulo), então os valores abaixo seguem exatamente o que a fonte informa, sem conversão.

Os componentes de custo do framework em si:

• AWS Lambda: $0.0000166667 por GB-segundo mais $0.0000002 por requisição.
• CloudWatch Logs: $0.50 por GB ingerido mais $0.03 por GB armazenado ao mês.
• CloudWatch Logs Insights: $0.005 por GB escaneado por query.
• Step Functions: $0.025 a cada 1.000 transições de estado.
• DynamoDB Streams: sem cobrança de leitura quando uma função Lambda padrão lê o stream.
• Amazon SNS e Amazon SQS: $0.40 a $0.50 por milhão de requisições.

No exemplo de cálculo da fonte, uma simulação de 24 horas replayando 5% de 100 mil requisições diárias (5.000 requisições replayadas, 1 segundo médio de duração, 256 MB de memória) fica em torno de $0.02 de Lambda, $0.013 de ingestão de log mais $0.001 de armazenamento, $0.0001 de uma query de Logs Insights e cerca de $0.01 de Step Functions e mensageria: total estimado de aproximadamente $0.05 por simulação. Em 500 mil requisições diárias (25 mil replayadas), o custo sobe para cerca de $0.25 por simulação, e multi-Região multiplica o valor pelo número de regiões ativas.

Em resumo: o framework em si é barato porque é inteiramente serverless; o verdadeiro custo variável é o que o próprio sistema do time gasta para processar as requisições replayadas, e isso depende da arquitetura de cada aplicação, não do framework.

Como adaptar

A fonte sugere construir o framework em três fases, cada uma já útil antes da próxima começar:

1. Componentes centrais: captura de tráfego com a fonte de evento escolhida, motor de replay com simulationId, logging estruturado centralizado e orquestração em Step Functions.
2. Verificação automatizada: cálculo da fração de match com filtros de variância específicos do domínio, queries de CloudWatch Logs Insights e alarmes do CloudWatch como gate de qualidade.
3. Automação completa: integração com o pipeline de deploy, expansão multi-Região, dashboards de monitoramento e ajuste fino de limiares com dados reais de produção.

Para quem desenha arquitetura em AWS no Brasil, o ponto prático de adaptação é a fonte de captura: o time original usou DynamoDB Streams porque já fazia parte da stack, mas o padrão funciona com Amazon Kinesis Data Streams para sistemas de alto throughput, change data capture em Amazon RDS ou Aurora para bancos relacionais, Amazon MSK para arquitetura orientada a Kafka, ou até CloudWatch Logs quando a captura acontece no nível do API gateway. A escolha de storage não muda o resto do desenho: replay, comparação e orquestração continuam os mesmos.

Dois pontos exigem atenção redobrada na hora de portar o padrão para produção: o maximum record age no event source mapping, para descartar registros antigos quando o replay volta a ligar depois de um período desligado; e a necessidade real de idempotência em qualquer caminho que grave dado ou dispare notificação. Sistemas majoritariamente stateless, como motor de preço, de validação ou de elegibilidade, adotam o padrão quase sem mudança de código; sistemas com escrita transacional (pagamento, pedido, estoque) exigem o trabalho extra descrito em "Trade-offs" antes de valer a pena.

Fonte

Fonte: AWS Architecture Blog, "Modular regression testing framework built on AWS for large-scale systems" (https://aws.amazon.com/blogs/architecture/modular-regression-testing-framework-built-on-aws-for-large-scale-systems/).

Fonte: AWS Architecture Blog