Teste a Resiliência do Seu App Simulando Falhas no SQS com AWS FIS

Por Que Testar o Tratamento de Falhas do SQS?

Quando sua aplicação perde acesso ao Amazon SQS — seja por configuração errada de IAM, partição de rede ou um deploy problemático — os sintomas são parecidos: envios e recebimentos começam a falhar. A diferença entre uma interrupção breve e uma indisponibilidade em cascata está em como seus serviços lidam com essas falhas. Eles falham rápido? Abrem circuit breakers? Fazem buffer local? Sem testar, você está chutando.

O AWS Fault Injection Service (FIS) permite injetar falhas controladas para validar seus mecanismos de resiliência e observabilidade. Este tutorial mostra um experimento progressivo que nega acesso ao data-plane do SQS e depois restaura, para você ver exatamente o que quebra e o que se recupera.

Princípio chave: Teste o comportamento da sua aplicação, não o SQS em si. O objetivo é descobrir se seus padrões de recuperação funcionam e se você perceberia se não funcionassem.

Passo a Passo: Montando o Experimento

1. Defina uma Hipótese Mensurável

Comece com uma afirmação clara do comportamento esperado. Por exemplo:

Quando nosso app de processamento de pedidos perde acesso ao SQS por 5 minutos, esperamos que o produtor abra seu circuit breaker em até 30 segundos, faça buffer das mensagens em armazenamento durável e as reproduza na recuperação. Mediremos o sucesso por NumberOfMessagesSent voltando à linha de base e ApproximateNumberOfMessagesVisible drenando para perto de zero em 15 minutos.

Se você nunca testou esse modo de falha, enquadre como descoberta: "Vamos bloquear o acesso por 2 minutos e observar como o produtor lida com envios falhos e se o consumidor se recupera sozinho." Escreva antes de começar.

2. Pré-requisitos

• Produtor e consumidor instrumentados – sua aplicação deve emitir métricas de estado do circuit breaker, envios falhos, mensagens descartadas e escritas no fallback.
• Role IAM para o FIS – confiável por fis.amazonaws.com, com permissões para executar SSM Automation e passar uma role.
• Role IAM para o SSM Automation – capaz de ler/modificar políticas de fila SQS (sqs:GetQueueAttributes, sqs:SetQueueAttributes).
• Filas SQS com a tag FIS-Ready: True – limita a automação a filas de não-produção.
• Dashboard e alarmes CloudWatch – combine métricas da aplicação e da fila; defina uma stop condition baseada em sinal de impacto ao cliente (ex.: pedidos falhos por minuto).
• Plano de rollback – caso a política de deny não possa ser removida.

⚠️ Crítico: Nunca negue sqs:*. Um Deny explícito sobrepõe todo Allow, incluindo a permissão da própria automação de limpar depois. Limite o deny a ações do data-plane apenas (SendMessage, ReceiveMessage, DeleteMessage, ChangeMessageVisibility, PurgeQueue).

3. Configure o Documento SSM Automation

A automação segue quatro passos:

1. getTargetQueues – encontra filas com a tag FIS-Ready: True.
2. applyDenyAllPolicyToQueues – adiciona uma declaração de deny com escopo na política de recurso de cada fila.
3. waitForDuration – dorme pela duração da falha (ISO 8601, ex.: PT2M).
4. removeDenyAllPolicyFromQueues – remove a declaração FISTemporaryDeny.

Você pode fazer o deny expirar sozinho adicionando uma condição DateLessThan em aws:CurrentTime.

4. Encadeie Fases com o FIS

O template FIS executa quatro fases de falha com períodos de recuperação entre elas:

Stop conditions param o experimento se um alarme CloudWatch disparar. Escolha um alarme em métrica de impacto ao cliente (ex.: taxa de erro da aplicação), não em métricas de fila que devem se mover durante a falha.

5. Execute e Observe

Use AWS CLI ou console para iniciar o experimento:

aws fis start-experiment --experiment-template-id <template-id>

Durante a falha, operações SQS retornam AccessDenied (403, não-retentável). Observe produtor e consumidor separadamente:

Lado do produtor:

• Primeiro SendMessage falho: falha rápido ou trava?
• Após 3–5 falhas: o circuit breaker abre?
• Quando o envio desiste: faz buffer em armazenamento durável ou descarta silenciosamente?

Lado do consumidor:

• Primeiro ReceiveMessage falho: faz backoff ou martela?
• Acúmulo de backlog: ApproximateNumberOfMessagesVisible fica estável?
• Recuperação: o backlog drena de forma constante?

💡 Nota: A DLQ não enche durante a falha porque ReceiveMessage está negado — o redrive depende do maxReceiveCount. Observe a DLQ durante a recuperação.

6. Analise os Resultados

Compare o que aconteceu com sua hipótese:

• Os circuit breakers ativaram dentro do alvo (ex.: 30 segundos)?
• As mensagens foram preservadas? Reconcilie envios tentados vs. processados + DLQ + fallback.
• A recuperação drenou o backlog de forma constante ou travou?
• Fases mais longas revelaram novos modos de falha (exaustão de thread-pool, pressão de memória)?

Cada gap entre hipótese e realidade é uma correção a fazer.

Armadilhas Comuns e Boas Práticas

Lógica de Retry

Não faça retry de tudo. Repita apenas erros transitórios (throttling, timeouts, 5xx) com backoff exponencial e jitter. Falhe rápido em erros não-retentáveis como AccessDenied (403). Os SDKs da AWS têm comportamento de retry configurável — use.

Circuit Breakers

Um circuit breaker para tentativas após um limiar de falhas consecutivas, depois deixa uma única chamada de teste passar após um timeout de recuperação. Escolha o comportamento em estado aberto deliberadamente: derrubar ou fazer buffer de carga é mais seguro que trocar silenciosamente para um caminho alternativo.

Dead Letter Queues

Configure uma DLQ para cada fila. É uma rede de segurança do lado do consumidor para mensagens poison, não um buffer de overflow do produtor. Defina maxReceiveCount em 3–5. Garanta que consumidores sejam idempotentes.

Estratégia de Monitoramento

Monte um dashboard CloudWatch combinando:

• Métricas de fila: NumberOfMessagesSent, NumberOfMessagesReceived, ApproximateNumberOfMessagesVisible, ApproximateAgeOfOldestMessage.
• Métricas de aplicação: taxas de erro por tipo (distinga AccessDenied), estado do circuit breaker, profundidade da DLQ, latência ponta a ponta.

Alarme em ApproximateAgeOfOldestMessage excedendo seu SLA como alerta de produção — mas não como stop condition do experimento.

Limpeza

• Verifique se a política de deny sumiu: aws sqs get-queue-attributes --queue-url <url> --attribute-names Policy.
• Processe mensagens que caíram na DLQ durante o experimento.
• Documente descobertas: o que bateu, o que não bateu, o que você está corrigindo.

🔗 Leitura Complementar: Para um mergulho em como modelos modernos de IA otimizam throughput de inferência, veja Holotron-12B: O Modelo SSM Híbrido que Dobra o Throughput de Agentes de IA. E se você curte gargalos em nível de hardware, confira Além da Matemática de Matrizes: Como a NVIDIA Blackwell Ultra Enfrenta o Gargalo do Softmax.

Conclusão

Testar o tratamento de falhas do SQS com AWS FIS transforma suposições em evidências. Comece com a fase de 2 minutos em ambiente de não-produção, corrija o que quebrar, depois rode a sequência completa conforme sua aplicação evolui. Os gaps entre sua hipótese e os resultados são sua lista de trabalho — e a melhor hora de encontrá-los é antes de uma indisponibilidade real.

Próximos passos:

• Estenda o experimento com falhas parciais (afete só um subconjunto de filas).
• Combine com outras falhas (terminação de EC2, latência de rede) para cenários compostos.
• Explore o AWS Resilience Hub para avaliação contínua.
• Veja os exemplos do AWS FIS no GitHub para código funcional.

Fonte: Testing application resilience with Amazon SQS and AWS Fault Injection Service