Scenario a tre 9 e ½ (99,95%) con un tempo di ripristino compreso tra 5 e 30 minuti

Questo obiettivo di disponibilità per le applicazioni richiede tempi di inattività estremamente brevi e una perdita di dati molto ridotta per periodi specifici. Le applicazioni con questo obiettivo di disponibilità includono applicazioni nei settori: bancario, investimenti, servizi di emergenza e acquisizione dei dati. Queste applicazioni hanno tempi di ripristino e punti di ripristino molto brevi.

Possiamo migliorare ulteriormente i tempi di ripristino utilizzando un approccio Warm Standby in due regioni AWS. Implementeremo l'intero carico di lavoro in entrambe le regioni, procedendo a ridurre verticalmente il nostro sito passivo e mantenere la coerenza finale di tutti i dati. Entrambe le implementazioni saranno stabili staticamente nelle rispettive regioni. Le applicazioni vanno create utilizzando i modelli di resilienza del sistema distribuito. Dovremo creare un componente di instradamento leggero che monitori lo stato del carico di lavoro e, se necessario, possa essere configurato per instradare il traffico verso la regione passiva.

Monitoraggio delle risorse

Inoltre, ci saranno avvisi per ogni sostituzione di un server Web, in caso di failover del database e di errore di regione. Monitoreremo anche la disponibilità dei contenuti statici su Amazon S3 e sarà previsto un avviso in caso di mancata disponibilità. I log verranno aggregati per semplificare la gestione e per agevolare l'analisi della causa principale in ciascuna regione.

Il componente di instradamento monitora sia lo stato della nostra applicazione sia le dipendenze hard regionali che abbiamo.

Adattarsi alle modifiche nella domanda

Uguale allo scenario a quattro 9.

Implementazione delle modifiche

La distribuzione di nuovo software ha una scadenza fissa ogni due o quattro settimane. Gli aggiornamenti del software saranno automatizzati, utilizzando modelli di implementazione blu/verde o canary.

Esistono runbook per quando si verifica il failover della regione, per problemi comuni dei clienti che si verificano durante tali eventi e per report comuni.

Avremo playbook per problemi di database comuni, incidenti relativi alla sicurezza, implementazioni non riuscite, problemi imprevisti dei clienti nel failover della regione e per stabilire la causa principale dei problemi. Una volta identificata la causa principale, la correzione dell'errore sarà identificata dalla sinergia fra team operativi e di sviluppo e implementata una volta sviluppata.

Ci impegneremo anche con AWS Support per l'offerta di Infrastructure Event Management.

Esecuzione del backup dei dati

Come per lo scenario a quattro 9, usiamo backup RDS automatici e la funzione di controllo delle versioni di S3. La replica dei dati avviene in automatico e in modo asincrono dal cluster Aurora RDS nella regione attiva alle repliche di lettura tra regioni nella regione passiva. La replica tra regioni S3 consente di spostare automaticamente e in modo asincrono i dati dalla regione attiva a quella passiva.

Architettura mirata alla resilienza

Come nello scenario a quattro 9, inoltre è possibile il failover regionale. Questa operazione viene gestita manualmente. Durante il failover, indirizzeremo le richieste a un sito Web statico utilizzando il failover DNS fino al ripristino nella seconda regione.

Testare la resilienza

Come per lo scenario a quattro 9 più una convalida dell'architettura attraverso le giornate di gioco utilizzando i runbook. Inoltre, la correzione RCA ha la priorità rispetto al rilascio delle funzionalità per l'implementazione e la distribuzione immediate

Pianificazione per il ripristino di emergenza

Il failover regionale viene gestito manualmente. Tutti i dati vengono replicati in modo asincrono. Si procede ad aumentare orizzontalmente l'infrastruttura warm standby. L'operazione può essere automatizzata utilizzando un flusso di lavoro richiamato su AWS Step Functions. AWS Anche Systems Manager (SSM) può essere d'aiuto con questa automazione, poiché è possibile creare documenti SSM che aggiornano i gruppi Auto Scaling e ridimensionano le istanze.

Obiettivo di progettazione della disponibilità

Partiamo dal presupposto che almeno alcuni guasti richiederanno una decisione manuale per eseguire il ripristino, tuttavia, con una buona automazione, in questo scenario ipotizziamo che solo due eventi l'anno richiedano questa decisione. Dedichiamo 20 minuti per decidere di eseguire il ripristino e supponiamo che il ripristino venga completato entro 10 minuti. Questo implica occorrono circa 30 minuti per eseguire il ripristino da un guasto. Supponendo due guasti all'anno, il nostro tempo di impatto stimato per l'anno è di 60 minuti.

Ciò significa che il limite massimo di disponibilità è del 99,95%. La disponibilità effettiva dipenderà anche dal tasso reale di errore, dalla durata del guasto e dalla rapidità effettiva del ripristino da ciascun guasto. Per questa architettura ipotizziamo che l'applicazione sia costantemente online durante gli aggiornamenti. In base a ciò, il nostro obiettivo di progettazione della disponibilità è del 99,95%.

Riepilogo

Argomento	Implementazione
Monitoraggio delle risorse	Controlli dell'integrità a tutti i livelli, compresi i DNS a livello di regione AWS, e sugli indicatori KPI; avvisi inviati in caso di attivazione de​​gli allarmi configurati; avvisi per tutti i guasti. Le riunioni operative sono rigorose per rilevare le tendenze e raggiungere gli obiettivi di progettazione.
Adattarsi alle modifiche nella domanda	ELB per il livello applicativo di scalabilità automatica e Web; storage di scalabilità automatica e repliche di lettura in più zone nelle regioni attive e passive per Aurora RDS. Dati e infrastruttura sincronizzati tra regioni AWS per una stabilità statica.
Implementazione delle modifiche	Implementazione automatizzata tramite canary o blu/verde e rollback automatico quando i KPI o gli avvisi indicano problemi non rilevati nell'applicazione, le distribuzioni vengono effettuate in una zona di isolamento in una regione AWS alla volta.
Esecuzione del backup dei dati	Backup automatizzati in ciascuna regione AWS tramite RDS per soddisfare RPO e ripristino automatico effettuato regolarmente in una giornata di gioco. I dati di Aurora RDS e S3 vengono replicati in automatico e in modo asincrono da una regione attiva a una regione passiva.
Architettura mirata alla resilienza	Scalabilità automatica per fornire un livello di applicazione e Web autorigeneranti; RDS con Multi-AZ; gestione del failover regionale manuale con il sito statico mostrato durante il failover.
Testare la resilienza	La verifica dei guasti delle componenti e della zona di isolamento è nella pipeline ed effettuata regolarmente con il personale operativo in una giornata di gioco; esistono playbook per diagnosticare problemi sconosciuti; ed esiste un processo di analisi della causa principale, con percorsi di comunicazione per individuare il problema e le relative modalità di correzione o prevenzione. La correzione RCA ha la priorità rispetto al rilascio delle funzionalità per l'implementazione e la distribuzione immediate.
Pianificazione per il ripristino di emergenza	Warm Standby implementato in un'altra regione. Si procede ad aumentare orizzontalmente l'infrastruttura utilizzando flussi di lavoro richiamati mediante AWS Step Functions o documenti AWS Systems Manager. Backup crittografati tramite RDS. Repliche di lettura tra regioni tra due regioni AWS. Replica tra regioni di asset statici in S3. Il ripristino è nella regione AWS attiva corrente, viene effettuato in una giornata di gioco ed è coordinato con AWS.