Controlli di integrità, circuit breaker e logica di retry

Nei sistemi distribuiti, i componenti si guastano continuamente: le istanze si arrestano, si verificano partizioni di rete e i servizi downstream vengono sovraccaricati. Senza il rilevamento automatico dei guasti, il traffico continua a essere inviato ai componenti guasti, causando guasti a cascata. AWS offre più livelli di health check: gli health check di ELB rilevano le istanze non integre, gli health check di Route 53 rilevano gli endpoint non integri e Auto Scaling sostituisce le istanze guaste. I pattern a livello applicativo, come circuit breaker e retry, completano il quadro della resilienza.

I controlli di integrità di Elastic Load Balancer inviano periodicamente richieste alle destinazioni registrate per determinare se sono integre. È possibile configurare il percorso del controllo di integrità (ad esempio /health), il protocollo, la porta, l'intervallo (30 secondi per impostazione predefinita) e la soglia di integrità/non integrità (il numero di successi o errori consecutivi). Quando una destinazione non supera i controlli di integrità, ELB interrompe l'instradamento del traffico verso di essa. La destinazione viene rivalutata continuamente e aggiunta nuovamente non appena supera la soglia di integrità.

I controlli di integrità di Route 53 monitorano gli endpoint da più posizioni in tutto il mondo e funzionano insieme all'instradamento DNS con failover. Ne esistono tre tipi: i controlli degli endpoint interrogano direttamente l'URL dell'applicazione. I controlli calcolati combinano più controlli di integrità secondari usando la logica AND/OR (utile per il monitoraggio complesso). I controlli basati sugli allarmi di CloudWatch delegano a CloudWatch la determinazione dello stato di integrità: sono utili quando non è possibile esporre un endpoint di integrità pubblico o quando servono decisioni sullo stato basate sulle metriche.

Gli Auto Scaling Groups possono usare due tipi di controlli di integrità: i controlli di integrità EC2 rilevano i guasti delle istanze a livello di hypervisor (errore del controllo dello stato dell'istanza). I controlli di integrità di ELB sono più consapevoli dello stato dell'applicazione: un'istanza potrebbe essere in esecuzione ma restituire errori, e i controlli di integrità di ELB lo rilevano. È possibile configurare ASG affinché utilizzi i controlli di integrità di ELB, in modo che anche i guasti a livello applicativo attivino la sostituzione dell'istanza, non solo i guasti dell'infrastruttura EC2 sottostante.

Un circuit breaker è un pattern a livello applicativo che previene i guasti a cascata monitorando le chiamate a un servizio downstream e interrompendole temporaneamente quando i guasti superano una soglia. Il circuito ha tre stati: Closed (funzionamento normale), Open (la soglia di guasti è stata superata e le chiamate vengono bloccate immediatamente) e Half-Open (dopo un timeout, viene consentito un numero limitato di chiamate di test per verificare se il servizio è stato ripristinato). AWS App Mesh e SDK applicativi come Resilience4j implementano questo pattern.

AWS App Mesh è un service mesh che implementa circuit breaker, tentativi e criteri di timeout a livello infrastrutturale, senza modifiche al codice. È possibile definire i criteri del circuit breaker nella configurazione del virtual node o del virtual router. Quando un servizio upstream diventa non integro, il proxy Envoy di App Mesh apre automaticamente il circuito e restituisce immediatamente gli errori invece di attendere i timeout. Questo è particolarmente utile nelle architetture a microservizi eseguite su ECS o EKS.

La logica dei tentativi ripete automaticamente le operazioni non riuscite, ma una logica ingenua (un nuovo tentativo immediato in un ciclo serrato) può peggiorare le situazioni di sovraccarico. Il backoff esponenziale aumenta esponenzialmente il tempo di attesa tra i tentativi: 1s, 2s, 4s, 8s... Questo riduce il carico su un servizio in difficoltà e gli dà il tempo di riprendersi. Il jitter (la randomizzazione degli intervalli tra i tentativi) previene il problema dell'assalto simultaneo, in cui tutti i client riprovano contemporaneamente dopo una breve interruzione. AWS SDK implementa automaticamente il backoff esponenziale con jitter.

I tentativi sono sicuri solo se le operazioni sono idempotenti, ovvero se l'esecuzione della stessa operazione più volte produce lo stesso risultato. Ad esempio, la creazione di un oggetto S3 con la stessa chiave è idempotente (produce lo stesso risultato). L'invio due volte di un ordine, invece, crea due ordini: non è idempotente. Progetti le API in modo idempotente usando chiavi di idempotenza fornite dal client: il server memorizza il risultato della prima richiesta e restituisce lo stesso risultato per le richieste successive con la stessa chiave. DynamoDB, SQS e API Gateway supportano i pattern basati sulle chiavi di idempotenza.

Senza timeout espliciti, un servizio downstream lento fa sì che i thread rimangano bloccati indefinitamente, esaurendo il pool di connessioni e causando guasti a cascata. Imposti i timeout a ogni livello: timeout di connessione (tempo necessario per stabilire la connessione TCP), timeout di lettura (tempo necessario per ricevere una risposta) e timeout complessivo della richiesta. In AWS, configuri il timeout di inattività di ELB (60 s per impostazione predefinita), il timeout di esecuzione di Lambda (massimo 15 min) e il timeout di integrazione di API Gateway (massimo 29 s). I timeout attivano la logica di tentativi o del circuit breaker.

Quando l'elaborazione dei messaggi non riesce ripetutamente, una Dead Letter Queue (DLQ) raccoglie i messaggi che non è stato possibile elaborare dopo il numero massimo di tentativi di ricezione. Configuri le DLQ per le code SQS e le mappature delle origini eventi di Lambda, per evitare che i messaggi problematici blocchino indefinitamente la coda. I messaggi nella DLQ possono essere analizzati, rielaborati dopo la correzione del bug o archiviati. Le DLQ sono un componente essenziale delle architetture resilienti basate sugli eventi.

Per comprendere i modelli di guasto, i controlli di integrità e i circuit breaker richiedono un monitoraggio efficace. CloudWatch è il livello di osservabilità: crei allarmi per ELB UnHealthyHostCount (istanze che non superano i controlli di integrità), la frequenza di Lambda Errors, SQS NumberOfMessagesSentToDLQ (messaggi inviati alla DLQ) e RequestCountPerTarget del gruppo di destinazioni. Configuri notifiche SNS affinché il team reperibile venga avvisato immediatamente quando i controlli di integrità automatici rilevano un degrado.

Verifichi la comprensione dei concetti AWS Solutions Architect (SAA-C03) presentati in questa lezione.

In questa lezione ha imparato che: i controlli di integrità di ELB e Route 53 automatizzano il rilevamento dei guasti a livello infrastrutturale, i circuit breaker prevengono i guasti a cascata interrompendo le chiamate ai servizi non integri e il backoff esponenziale con jitter rende sicuri i tentativi in condizioni di carico. Le Dead Letter Queue raccolgono i messaggi non elaborati per consentirne l'analisi. Ora esamineremo RTO, RPO e i livelli di disaster recovery.