Scenari di architetture resilienti e ad alta disponibilità

Scenario: Un'azienda esegue un'applicazione web a due livelli (ALB → EC2 → RDS) e vuole eliminare ogni singolo punto di errore all'interno della Regione AWS. Soluzione: Distribuire le istanze EC2 in un Auto Scaling Group che si estende su almeno 2 Availability Zone dietro un ALB, che è nativamente multi-AZ. Abilitare RDS Multi-AZ per la replica sincrona in standby. Configurare i controlli dello stato sull'ALB per instradare automaticamente il traffico lontano dalle istanze non integre. Con questa architettura, la perdita di una singola AZ attiva il failover automatico a ogni livello.

Scenario: L'istanza RDS di un'applicazione di e-commerce raggiunge i limiti della CPU durante le ore di punta a causa di query di analisi ad alta intensità di lettura eseguite dal team di business intelligence. Soluzione: Creare delle RDS Read Replicas e indirizzare le query BI all'endpoint della replica. Le Read Replica utilizzano la replica asincrona: per le analisi è accettabile un lieve ritardo. In questo modo il traffico di lettura viene scaricato dall'istanza RDS primaria, riservata alle operazioni di scrittura e alle letture dell'applicazione. Per carichi di lavoro con un'intensità di lettura estremamente elevata, aggiungere un livello ElastiCache davanti a RDS per i dati consultati di frequente.

Scenario: Un'API stateless viene eseguita su EC2 dietro un ALB. L'utilizzo della CPU raggiunge il 90% durante l'orario lavorativo e scende quasi a zero di notte. L'azienda vuole che il parco di istanze venga dimensionato automaticamente. Soluzione: Configurare un Auto Scaling Group con una policy di scaling Target Tracking che punti a un utilizzo medio della CPU del 60%. ASG aggiungerà automaticamente istanze quando la CPU supera il 60% e le rimuoverà quando scende sotto il valore obiettivo. Aggiungere un'azione di scaling pianificata per preriscaldare la capacità minima prima dell'inizio dell'orario lavorativo, evitando rallentamenti durante il picco di traffico mattutino.

Scenario: Un'azienda esegue un'applicazione web primaria in us-east-1 e vuole eseguire il failover verso una pagina di manutenzione statica ospitata su S3 in us-west-2 se il sistema primario non è integro. Soluzione: Creare un controllo dello stato di Route 53 che monitori l'endpoint dell'ALB primario. Creare due record Route 53 con una policy di routing di failover: il record primario punta all'ALB ed è associato al controllo dello stato, mentre il record secondario punta al sito statico su S3. Se il controllo dello stato fallisce, Route 53 restituisce automaticamente la risposta DNS del record secondario.

Scenario: Un backend di elaborazione degli ordini scrive in un database, ma il database a volte non è disponibile durante le finestre di manutenzione, causando la perdita degli ordini. Soluzione: Inserire una coda SQS tra il front end, che accetta gli ordini, e il backend, che li elabora. Gli ordini vengono inseriti immediatamente nella coda, fornendo al cliente una conferma istantanea. I worker in background prelevano gli ordini dalla coda e li elaborano quando il database è disponibile. Durante la manutenzione, gli ordini si accumulano nella coda invece di essere eliminati, garantendo resilienza grazie al disaccoppiamento asincrono.

Scenario: Un'azienda necessita di una soluzione di disaster recovery con un RPO di 1 ora e un RTO di 4 ore, disponendo di un budget moderato. Soluzione: Implementare una strategia DR Pilot Light. Mantenere il database principale replicato nella Regione DR utilizzando una RDS Cross-Region Read Replica. I server applicativi non vengono eseguiti nella Regione DR durante il normale funzionamento: viene mantenuto attivo solo il componente 'core' minimo, cioè il database. In caso di disastro, promuovere la Read Replica a istanza autonoma e avviare i server applicativi da AMI precreate utilizzando CloudFormation. L'RTO è dell'ordine delle ore, anziché dei minuti, perché è necessario avviare i server.

Scenario: I messaggi in una coda SQS non vengono elaborati ripetutamente a causa di un bug nella Lambda consumer. I messaggi continuano a ricomparire e a bloccare la coda. Soluzione: Configurare una Dead-Letter Queue (DLQ) sulla coda principale. Dopo che un messaggio non è stato elaborato per un numero configurabile di volte (maxReceiveCount), SQS lo sposta automaticamente nella DLQ invece di riconsegnarlo all'infinito. In questo modo la coda principale resta disponibile per i messaggi corretti. Impostare un allarme CloudWatch sulla metrica ApproximateNumberOfMessagesVisible della DLQ per avvisare il team di sviluppo quando i messaggi iniziano ad accumularsi nella DLQ.

Scenario: Un'azienda opera negli Stati Uniti e in Europa. Gli utenti europei riscontrano un'elevata latenza nelle letture del database perché RDS si trova in us-east-1. Soluzione: Utilizzare Amazon Aurora Global Database. Il cluster primario si trova in us-east-1; in eu-west-1 viene aggiunto un cluster secondario di sola lettura. Aurora replica i dati nella Regione secondaria con una latenza tipica inferiore a 1 secondo, utilizzando la replica a livello di storage. Gli utenti europei leggono dal cluster secondario in eu-west-1. In caso di disastro regionale, il secondario può essere promosso a primario in meno di 1 minuto, il miglior RTO tra tutte le opzioni di database multi-Regione di AWS.

Scenario: Un servizio API containerizzato in esecuzione su ECS Fargate deve scalare in base all'utilizzo della CPU e resistere ai guasti delle AZ. Soluzione: Registrare il servizio ECS in un gruppo target dell'Application Load Balancer in modo che il traffico venga distribuito tra i task in esecuzione. Distribuire i task su più AZ specificando più subnet nella configurazione del servizio. Configurare ECS Service Auto Scaling con una policy Target Tracking sull'utilizzo della CPU del servizio ECS, per aumentare e ridurre automaticamente il numero di task. Se un'AZ si guasta, ECS riavvia i task non riusciti nelle AZ integre.

Scenario: Un'azienda esegue due istanze EC2 in AZ diverse che servono lo stesso dominio. Vuole che Route 53 smetta automaticamente di inviare traffico a un'istanza non integra. Soluzione: Utilizzare il Weighted Routing di Route 53 con pesi uguali (50/50) e associare un controllo dello stato dell'endpoint a ciascun record. Quando Route 53 rileva che un endpoint non è integro, rimuove il relativo record dalle risposte DNS e invia il 100% del traffico all'endpoint integro. Quando l'istanza torna disponibile e i controlli dello stato hanno nuovamente esito positivo, Route 53 riequilibra automaticamente il traffico: non sono necessarie modifiche DNS manuali.

Scenario: Un'applicazione di gioco mobile deve consentire la lettura e la scrittura dei dati dei giocatori con bassa latenza sia da us-east-1 sia da ap-southeast-1. Una tabella DynamoDB in una singola Regione causa un'elevata latenza per gli utenti asiatici. Soluzione: Abilitare DynamoDB Global Tables. Global Tables replica automaticamente i dati nelle Regioni specificate utilizzando la replica multi-master: qualsiasi Regione può accettare scritture. Gli utenti asiatici scrivono e leggono dalla replica in ap-southeast-1 con latenza locale (~5ms). Global Tables gestisce la risoluzione dei conflitti utilizzando una strategia 'vince l'ultima scrittura', basata sui timestamp. L'RTO per un guasto regionale completo è quasi nullo: il traffico viene semplicemente indirizzato alla Regione ancora disponibile.

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

In questa lezione ha affrontato scenari riguardanti: ASG e RDS multi-AZ per l'alta disponibilità all'interno della Regione, il routing di failover di Route 53 per il DR tra Regioni, SQS DLQ per isolare i messaggi non elaborati senza bloccare le code e Aurora Global Database per la scalabilità in lettura tra Regioni e il failover con RTO inferiore al minuto. Ora affronteremo scenari di architetture ad alte prestazioni e ottimizzate in termini di costi.