Projetando aplicações tolerantes a falhas e resilientes na AWS

Desenvolvendo Aplicações na AWS

Ricardo Sueiras

Principal Technologist

Construindo para resiliência

Falhas temporárias

 

• Entenda os modos comuns de falha:
• Erros temporários se resolvem sozinhos; geralmente é seguro tentar de novo.

Timeouts

 

• Entenda os modos comuns de falha:
• Erros temporários se resolvem sozinhos; geralmente é seguro tentar de novo.
• Timeouts: serviço externo demora demais para responder.

Erros permanentes

 

• Entenda os modos comuns de falha:
• Erros temporários se resolvem sozinhos; geralmente é seguro tentar de novo.
• Timeouts: serviço externo demora demais para responder.
• Erros permanentes: a requisição está com problema fundamental; repetir não ajuda.

Limites de API

 

• Entenda os modos comuns de falha:
• Erros temporários se resolvem sozinhos; geralmente é seguro tentar de novo.
• Timeouts: serviço externo demora demais para responder.
• Erros permanentes: a requisição está com problema fundamental; repetir não ajuda.
• Limites de taxa da API: muitas requisições; espere HTTP 429 Too Many Requests.

Estratégias de retentativa

• Falhas em sistemas distribuídos costumam ser temporárias.
• Uma requisição repetida muitas vezes funciona.
• Adicione retentativas com cuidado; repetir às cegas pode piorar.
• Exponential backoff: aumente o atraso entre tentativas.
• Jitter: adicione aleatoriedade para evitar picos de retentativa.
• Limites de retentativa: evite loops infinitos.

 

Recursos nativos do AWS SDK

• Os SDKs da AWS tratam retentativas automaticamente.
• As retentativas nativas incluem exponential backoff e jitter.
• Requisições com falha ou com throttling são repetidas com atrasos crescentes.
• Reduz o código de tratamento de erros que você precisa escrever.

 

Gerenciando retentativas

 

• Retentativa nem sempre é a resposta.
• Erros HTTP 4xx: o servidor entendeu e rejeitou sua requisição.
• Requisições não idempotentes: repetir pode gerar ações duplicadas ou inconsistentes.

Gerenciando timeouts

 

• Repetir sem limites pode ampliar problemas sob carga.
• Combine retentativas com timeouts.
• Um timeout define o tempo máximo de espera por resposta.
• Toda chamada a serviço externo deve ter timeout.

Circuit breakers

• Quando um serviço segue falhando, só retentar não basta.
• Continuar enviando requisições pode sobrecarregar o serviço com falha.
• O padrão circuit breaker pausa temporariamente chamadas para uma dependência instável.
• Estado fechado: as requisições fluem normalmente.

 

Circuit breakers

• Quando as falhas passam do limite, o circuito abre.
• As próximas requisições são bloqueadas.

 

Circuit breakers

• Após um cooldown, o circuito entra em meio-aberto para testar a recuperação.
• Serviço responde com sucesso: a operação normal volta.
• Ainda falhando: o circuito permanece aberto.
• Implemente circuit breakers no nível da aplicação.

 

Dead letter queues

 

• Mensagens que continuam falhando podem travar o sistema.
• Tire-as do fluxo principal de processamento.
• Mensagens com falha vão para uma Dead Letter Queue.
• Parte essencial de apps resilientes.
• Mas entenda os trade-offs

Limites de API da AWS

 

• Você interage com serviços AWS via APIs.
• Cada serviço define seus próprios limites de taxa.
• Ultrapassar limites aciona throttling (HTTP 429 Too Many Requests).
• Projete sua aplicação para lidar com throttling de forma elegante.

Integração com serviços de terceiros

• Serviços de terceiros trazem incerteza.
• Você não controla desempenho nem disponibilidade.
• Defina timeouts para evitar esperas longas.
• Use retentativas com backoff para problemas temporários.
• Isole dependências para limitar o raio de impacto.

 

Integração com terceiros

• Considere trocar comunicação síncrona por assíncrona.
• Seu sistema continua processando mesmo se o serviço externo atrasar.

 

Vamos praticar!

Desenvolvendo Aplicações na AWS