Progettare applicazioni tolleranti ai guasti e resilienti su AWS

Sviluppare applicazioni su AWS

Ricardo Sueiras

Principal Technologist

Progettare per la resilienza

Guasti temporanei

 

• Capire i modelli di guasto comuni:
• Gli errori temporanei si risolvono da soli, in genere è sicuro riprovare.

Timeout

 

• Capire i modelli di guasto comuni:
• Gli errori temporanei si risolvono da soli, in genere è sicuro riprovare.
• Timeout: il servizio esterno impiega troppo a rispondere.

Errori permanenti

 

• Capire i modelli di guasto comuni:
• Gli errori temporanei si risolvono da soli, in genere è sicuro riprovare.
• Timeout: il servizio esterno impiega troppo a rispondere.
• Errori permanenti: la richiesta è sbagliata alla base, riprovare non aiuta.

Limiti API

 

• Capire i modelli di guasto comuni:
• Gli errori temporanei si risolvono da soli, in genere è sicuro riprovare.
• Timeout: il servizio esterno impiega troppo a rispondere.
• Errori permanenti: la richiesta è sbagliata alla base, riprovare non aiuta.
• Limiti di frequenza API: troppe richieste, aspettati HTTP 429 Too Many Requests.

Strategie di retry

• Nei sistemi distribuiti i guasti sono spesso temporanei.
• Una richiesta ritentata spesso riesce.
• Aggiungi i retry con cura: ritentare alla cieca può peggiorare.
• Exponential backoff: aumenta l'attesa tra i tentativi.
• Jitter: aggiungi casualità per evitare picchi di retry.
• Limiti ai retry: evita loop infiniti.

 

Funzionalità native degli AWS SDK

• Gli AWS SDK gestiscono i retry in automatico.
• I retry integrati includono exponential backoff e jitter.
• Le richieste non riuscite o limitate vengono ritentate con attese crescenti.
• Riduci il codice di gestione errori che devi scrivere.

 

Gestire la logica di retry

 

• Il retry non è sempre la soluzione.
• Errori HTTP 4xx: il server ha capito ma ha rifiutato la richiesta.
• Richieste non idempotenti: ritentare può causare azioni duplicate o incoerenti.

Gestire i timeout

 

• Ritentare senza limiti può amplificare i problemi sotto carico.
• Combina retry e timeout.
• Un timeout imposta il tempo massimo di attesa per una risposta.
• Ogni chiamata a servizi esterni dovrebbe avere un timeout.

Circuit breaker

• Se un servizio continua a fallire, i retry non bastano.
• Continuare a inviare richieste può sovraccaricare il servizio in errore.
• Il pattern circuit breaker interrompe temporaneamente le richieste a dipendenze non sane.
• Stato closed: le richieste scorrono normalmente.

 

Circuit breaker

• Quando i guasti superano una soglia, il circuito si apre.
• Le richieste successive vengono bloccate.

 

Circuit breaker

• Dopo un cooldown, il circuito entra in half-open per testare il recupero.
• Il servizio risponde correttamente: riprende l'operatività normale.
• Continua a fallire: il circuito resta aperto.
• Implementa i circuit breaker a livello applicativo.

 

Dead letter queue

 

• I messaggi che falliscono di continuo possono bloccare il sistema.
• Spostali fuori dal flusso principale.
• I messaggi falliti finiscono in una Dead Letter Queue.
• Parte chiave per creare applicazioni resilienti.
• Tuttavia, valuta i compromessi

Limiti delle API AWS

 

• Interagisci con i servizi AWS tramite API.
• Ogni servizio definisce i propri limiti di frequenza.
• Superarli attiva il throttling (HTTP 429 Too Many Requests).
• Progetta l'app per gestire il throttling in modo elegante.

Integrare servizi di terze parti

• I servizi di terze parti introducono incertezza.
• Non hai controllo su prestazioni o disponibilità.
• Imposta timeout per evitare attese lunghe.
• Usa retry con backoff per problemi temporanei.
• Isola le dipendenze per limitare il raggio d'azione dei guasti.

 

Integrare con terze parti

• Valuta il passaggio da comunicazione sincrona ad asincrona.
• Il tuo sistema continua a elaborare anche se il servizio esterno è in ritardo.

 

Esercitiamoci!

Sviluppare applicazioni su AWS