Scenario a cinque 9 (99,999%) o superiore con un tempo di ripristino inferiore a 1 minuto

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 che potrebbero avere questo obiettivo di disponibilità includono, ad esempio, alcune applicazioni bancarie, di investimento, finanziarie, governative e di business cruciali che costituiscono le attività principali di un'azienda che genera entrate estremamente elevate. L'obiettivo è di avere archivi di dati fortemente coerenti e completa ridondanza a tutti i livelli. Abbiamo selezionato un archivio dati basato su SQL. Tuttavia, in alcuni scenari, troveremo difficile ottenere un RPO molto basso. Se riesci a partizionare i tuoi dati è possibile che non ci siano perdite di dati. Ciò potrebbe richiedere l'aggiunta di logica e di latenza nell'applicazione per garantire la coerenza dei dati tra le posizioni geografiche, nonché la capacità di spostare o copiare i dati tra le partizioni. L'esecuzione di questo partizionamento potrebbe essere più semplice se si utilizza un database NoSQL.

Possiamo migliorare ulteriormente la disponibilità utilizzando un approccio Attivo-attivo approccio su più regioni AWS. Il carico di lavoro verrà distribuito in tutte le regioni desiderate che sono staticamente stabili tra regioni (in modo che le regioni rimanenti possano gestire il carico con la perdita di una regione). Un instradamento indirizza il traffico verso le posizioni geografiche integre e modifica automaticamente la destinazione quando una posizione non è integra, interrompendo anche temporaneamente i livelli di replica dei dati. Amazon Route 53 offre controlli di integrità a intervalli di 10 secondi e offre anche TTL sui set di record fino a un secondo.

Monitoraggio delle risorse

Come per lo scenario a 3½ 9, e inoltre vengono emessi avvisi quando una regione viene rilevata come non integra e il traffico viene allontanato da essa.

Adattarsi alle modifiche nella domanda

Uguale allo scenario a 3 9 e ½.

Implementazione della modifica

La pipeline di distribuzione avrà una suite di test completa, inclusi test di prestazioni, carico e inserimento degli errori. Distribuiremo gli aggiornamenti utilizzando le distribuzioni canary o blue/green in una zona di isolamento alla volta, in una singola regione, prima di passare a un'altra. Durante la distribuzione, le versioni precedenti continueranno a essere in esecuzione su altre istanze per facilitare un rollback più veloce. Queste sono completamente automatizzate, incluso un rollback se gli indicatori KPI indicano un problema. Il monitoraggio includerà parametri di successo e avvisi quando si verificano problemi.

Esistono runbook per requisiti di reporting rigorosi e monitoraggio delle prestazioni. Se le operazioni riuscite tendono a non raggiungere gli obiettivi di prestazione o disponibilità, verrà utilizzato un manuale per stabilire cosa sta causando la tendenza. Esistono dei manuali per le modalità di errore non scoperte e gli incidenti di sicurezza. Esistono anche playbook per stabilire la causa principale dei guasti.

Il team che costruisce il sito Web gestisce anche il sito Web. Quel team identificherà la correzione per qualsiasi guasto imprevisto e darà la priorità alla correzione da distribuire dopo che è stata implementata. Ci impegneremo anche con AWS Support per l'offerta di Infrastructure Event Management.

Eseguire il backup dei dati

Uguale allo scenario a 3 9 e ½.

Architettura mirata alla resilienza

L'applicazione verrà creata utilizzando i modelli di resilienza software/applicazione. È possibile che siano necessari molti altri livelli di routing per implementare la disponibilità necessaria. La complessità di questa implementazione aggiuntiva non deve essere sottovalutata. L'applicazione verrà implementata nelle zone di isolamento degli errori di distribuzione e partizionata e distribuita in modo tale che anche un evento su tutta la regione non influirà su tutti i clienti.

Testare la resilienza

Eserciteremo costantemente le nostre procedure di recupero degli errori durante i giorni di attività, utilizzando i runbook per assicurarci di poter eseguire le attività e non deviare dalle procedure.

Pianificazione per il disaster recovery (DR)

Attiva-attiva e distribuzione multi-regione con infrastruttura completa del carico di lavoro e dati in più regioni. Utilizzando una strategia globale di lettura locale e di scrittura, una regione è il database master per tutte le scritture e i dati vengono replicati per le letture in altre regioni. Se la regione database master ha esito negativo, sarà necessario promuovere un nuovo database. La strategia di lettura locale e di scrittura prevede l'assegnazione di utenti a una regione di origine in cui vengono gestite le scritture DB. Ciò consente agli utenti di leggere o scrivere da qualsiasi regione, ma richiede una logica complessa per gestire potenziali conflitti di dati tra scritture in regioni diverse.

Quando una regione viene rilevata come non integra, il livello di instradamento instrada automaticamente il traffico verso le regioni integre rimanenti. Non è richiesto alcun intervento manuale.

Gli archivi di dati devono essere replicati tra le regioni in modo da poter risolvere potenziali conflitti. Sarà necessario creare strumenti e processi automatizzati per copiare o spostare i dati tra le partizioni per motivi di latenza e per bilanciare richieste o quantità di dati in ciascuna partizione. Anche la risoluzione dei conflitti di dati richiederà runbook operativi aggiuntivi.

Obiettivo di progettazione della disponibilità

Partiamo dal presupposto che vengono effettuati ingenti investimenti per automatizzare tutto il ripristino e che il ripristino può essere completato in un minuto. Non prevediamo ripristini attivati ​​manualmente, ma fino a un'azione di ripristino automatizzata al trimestre. Ciò implica quattro minuti all'anno per il ripristino. Ipotizziamo che l'applicazione sia costantemente online durante gli aggiornamenti. Sulla base di questo, il nostro obiettivo di progettazione della disponibilità è pari al 99,999%.

Riepilogo

Argomento	Implementazione
Monitoraggio delle risorse	Controlli di integrità a tutti i livelli, compresi i DNS a livello di regione AWS, e sugli indicatori KPI; avvisi inviati quando vengono attivati ​​gli allarmi configurati; allerta su 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 della modifica	Distribuzione automatizzata tramite canary o blue/green 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.
Eseguire il 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 automaticamente e in modo asincrono da una regione attiva a una regione passiva.
Architettura mirata alla resilienza	Implementate zone di isolamento degli errori per l'applicazione; auto scaling per fornire livelli di applicazione e web autorigeneranti; RDS con Multi-AZ, failover regionale automatizzato.
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 dei manuali per diagnosticare problemi sconosciuti; ed esiste un processo di analisi della causa principale, con percorsi di comunicazione per individuare il problema e come questo è stato corretto o prevenuto. La correzione RCA ha la priorità rispetto al rilascio delle funzionalità per l'implementazione e la distribuzione immediate.
Pianificazione per il disaster recovery (DR)	Configurazione attiva-attiva distribuita in almeno due regioni. L'infrastruttura è completamente ridimensionata e staticamente stabile tra le regioni. I dati vengono partizionati e sincronizzati tra regioni. Backup crittografati tramite RDS. Il guasto di una regione viene praticato in una giornata di gioco ed è coordinato con AWS. Durante il ripristino, potrebbe essere necessario promuovere un nuovo master del database.