Principi fondamentali per più regioni 4: prontezza operativa

La gestione di un carico di lavoro multiregionale è un'attività complessa che comporta sfide operative specifiche di un'architettura multiregionale. Queste includono la Account AWS gestione, la riorganizzazione dei processi di implementazione, la creazione di una strategia di osservabilità multiregionale, la creazione e il test dei processi di ripristino e quindi la gestione dei costi. Un Operational Readiness Review (ORR) può aiutare i team a preparare un carico di lavoro per la produzione, indipendentemente dal fatto che venga eseguito in una singola regione o in più regioni.

4.a: gestione Account AWS

Per distribuire un carico di lavoro in tutte le regioni Regioni AWS, assicurati che vi sia parità tra tutte le Servizio AWS quote all'interno di un account. Innanzitutto, identifica tutti gli Servizi AWS elementi che fanno parte dell'architettura, esamina l'utilizzo pianificato nelle regioni di standby e quindi confronta l'utilizzo pianificato con l'utilizzo corrente. In alcuni casi, se la regione di standby non è mai stata utilizzata in precedenza, puoi fare riferimento alle quote di servizio predefinite per comprendere il punto di partenza. Quindi, per tutti i servizi che verranno utilizzati, richiedi un aumento della quota utilizzando la console Service Quotas (è richiesto il login) oppure. APIs

Configura i ruoli AWS Identity and Access Management (IAM) in ciascuna regione per fornire agli operatori, agli strumenti di automazione e Servizi AWS le autorizzazioni appropriate alle risorse all'interno della regione di standby. Per ottenere l'isolamento regionale per le architetture multiregionali, isola i ruoli per regione. Assicurati che le autorizzazioni siano disponibili prima di passare alla modalità live con una regione in standby.

4.b: Pratiche di implementazione

Le funzionalità multiregionali possono complicare la distribuzione di un carico di lavoro in più regioni. È necessario assicurarsi di eseguire la distribuzione in una regione alla volta. Ad esempio, se si utilizza un approccio attivo-passivo, è necessario eseguire la distribuzione prima nella regione principale e poi nella regione di standby. AWS CloudFormationti aiuta a distribuire l'infrastruttura in una o più regioni e può essere personalizzato in base alle tue esigenze. AWS CodePipelineti aiuta a creare una pipeline integration/continuous delivery (CI/CD (continua), che prevede azioni interregionali che consentono la distribuzione in regioni diverse dalla regione in cui si trova la pipeline. Questo, combinato con solide strategie di implementazione come blu/green, consente un'implementazione con tempi di inattività minimi o pari a zero.

Tuttavia, l'implementazione delle funzionalità stateful può diventare più complessa quando lo stato dell'applicazione o dei dati non viene esternalizzato in un archivio persistente. In queste situazioni, personalizza attentamente il processo di implementazione in base alle tue esigenze. Progetta la pipeline e il processo di distribuzione in modo da distribuirli in una regione alla volta anziché distribuirli in più regioni contemporaneamente. Ciò riduce la possibilità di guasti correlati tra le regioni. Per conoscere le tecniche utilizzate da Amazon per automatizzare le distribuzioni di software, consulta l'articolo della AWS Builders' Library Automating safe hands-off deployments.

4.c: Osservabilità

Quando progetti per più regioni, considera in che modo monitorerai lo stato di tutti i componenti di ciascuna regione per ottenere una visione olistica dello stato di salute regionale. Ciò potrebbe includere il monitoraggio delle metriche per il ritardo di replica, che non è una considerazione per un carico di lavoro a regione singola.

Quando crei un'architettura multiregionale, prendi in considerazione l'osservazione delle prestazioni del carico di lavoro anche nelle regioni di standby. Ciò include il controllo dello stato di salute e l'esecuzione di canarini (test sintetici) dalla regione di standby per fornire una visione esterna dello stato di salute della regione primaria. Inoltre, puoi utilizzare Amazon CloudWatch Internet Monitor per comprendere lo stato della rete esterna e le prestazioni dei tuoi carichi di lavoro dal punto di vista dell'utente finale. La regione principale deve avere la stessa osservabilità per monitorare la regione di standby.

I canarini della regione di standby dovrebbero monitorare le metriche relative all'esperienza del cliente per determinare lo stato generale del carico di lavoro. Ciò è necessario perché se si verifica un problema nella regione principale, l'osservabilità nella regione primaria potrebbe essere compromessa e influirebbe sulla capacità di valutare lo stato del carico di lavoro.

In tal caso, osservare al di fuori di quella regione può fornire informazioni. Queste metriche devono essere raggruppate in dashboard disponibili in ogni regione e negli allarmi creati in ciascuna regione. Poiché CloudWatchsi tratta di un servizio regionale, è necessario disporre di allarmi in entrambe le regioni. Questi dati di monitoraggio verranno utilizzati per effettuare il failover della chiamata da una regione principale a una di standby.

4.d: Processi e procedure

Il momento migliore per rispondere alla domanda «Quando devo effettuare il failover?» è molto prima che sia necessario. Definisci piani di ripristino che includano persone, processi e tecnologia con largo anticipo rispetto al problema e testali regolarmente. Decidi un quadro decisionale di recupero. Se esiste un processo di ripristino ben collaudato e i tempi necessari per il ripristino sono ben compresi, è possibile scegliere di avviare il processo di ripristino utilizzando un failover che soddisfi l'obiettivo RTO. Questo momento può avvenire immediatamente dopo l'identificazione di un problema con l'applicazione nella regione principale, oppure potrebbe avvenire in un momento successivo in cui le opzioni di ripristino all'interno dell'applicazione nella regione sono state esaurite.

L'azione di failover stessa dovrebbe essere automatizzata al 100%, ma la decisione di attivare il failover dovrebbe essere presa dagli esseri umani, in genere da un piccolo numero di individui predeterminati all'interno dell'organizzazione. Queste persone dovrebbero prendere in considerazione la perdita di dati e le informazioni sull'evento. Inoltre, i criteri per un failover devono essere chiaramente definiti e compresi a livello globale all'interno dell'organizzazione. Per definire e completare questi processi, è possibile utilizzare i AWS Systems Manager runbook, che consentono l' end-to-endautomazione completa e garantiscono la coerenza dei processi in esecuzione durante i test e il failover.

Questi runbook devono essere disponibili nelle regioni primarie e in standby per avviare i processi di failover o failback. Quando questa automazione è attiva, definisci e segui una cadenza di test regolare. Ciò garantisce che, quando si verifica un evento reale, la risposta segua un processo ben definito e pratico in cui l'organizzazione ha fiducia. È anche importante considerare le tolleranze stabilite per i processi di riconciliazione dei dati. Verifica che il processo proposto soddisfi i requisiti RPO/RTO stabiliti.

4.e: Test

Avere un approccio di ripristino non testato equivale a non avere un approccio di ripristino. Un livello base di test consisterebbe nell'eseguire una procedura di ripristino per cambiare la regione operativa dell'applicazione. A volte si parla di approccio di rotazione delle applicazioni. Si consiglia di sviluppare la capacità di passare da una regione all'altra mantenendo la normale postura operativa; tuttavia, questo test da solo non è sufficiente.

Il test di resilienza è fondamentale anche per convalidare l'approccio di ripristino di un'applicazione. Ciò comporta l'introduzione di particolari scenari di errore, la comprensione di come reagiscono l'applicazione e il processo di ripristino e quindi l'implementazione delle eventuali mitigazioni necessarie se il test non è andato come previsto. Il test della procedura di ripristino in assenza di errori non vi dirà come si comporta l'intera applicazione in caso di guasti. È necessario sviluppare un piano per testare il ripristino rispetto agli scenari di errore previsti. AWS Fault Injection Servicefornisce un elenco crescente di scenari per iniziare.

Ciò è particolarmente importante per le applicazioni ad alta disponibilità, in cui sono necessari test rigorosi per garantire il raggiungimento degli obiettivi di continuità aziendale. Il test proattivo delle funzionalità di ripristino riduce il rischio di guasti nella produzione, il che aumenta la fiducia che l'applicazione possa raggiungere il tempo di ripristino limitato desiderato. I test regolari rafforzano anche le competenze operative, che consentono al team di riprendersi in modo rapido e affidabile dalle interruzioni quando si verificano. Esercitare l'elemento umano, o processo, dell'approccio di ripristino è fondamentale tanto quanto gli aspetti tecnici.

4.f: Costo e complessità

Le implicazioni in termini di costi di un'architettura multiregionale sono determinate da un maggiore utilizzo dell'infrastruttura, dal sovraccarico operativo e dal tempo impiegato per le risorse. Come accennato in precedenza, il costo dell'infrastruttura in una regione di standby è simile al costo dell'infrastruttura in una regione principale durante il pre-provisioning, quindi raddoppia il costo totale. Fornisci capacità in modo che sia sufficiente per le operazioni quotidiane, riservando comunque una capacità di buffer sufficiente per tollerare i picchi di domanda. Quindi configura gli stessi limiti in ogni regione.

Inoltre, se state adottando un'architettura active-active, potrebbe essere necessario apportare modifiche a livello di applicazione per eseguire correttamente l'applicazione in un'architettura multiregionale. Queste modifiche possono richiedere molto tempo e risorse per la progettazione e il funzionamento. Come minimo, le organizzazioni devono dedicare del tempo alla comprensione delle dipendenze tecniche e commerciali in ciascuna regione e alla progettazione di processi di failover e failback.

I team devono inoltre eseguire i normali esercizi di failover e failback per sentirsi a proprio agio con i runbook da utilizzare durante un evento. Sebbene questi esercizi siano fondamentali per ottenere i risultati attesi da un investimento in più regioni, rappresentano un costo-opportunità e sottraggono tempo e risorse ad altre attività.

4.g: Strategia di failover organizzativa multiregionale

Regioni AWS forniscono limiti di isolamento dei guasti che impediscano guasti correlati e contengano l'impatto dei Servizio AWS danni, quando si verificano, su una singola regione. È possibile utilizzare questi limiti di errore per creare applicazioni multiregionali costituite da repliche indipendenti e isolate dai guasti in ciascuna regione per limitare gli scenari di destino condiviso. Ciò consente di creare applicazioni multiregionali e utilizzare una gamma di approcci, dal backup e ripristino, alla versione pilota, alla modalità active-active, per implementare l'architettura multiregionale. Tuttavia, le applicazioni in genere non funzionano in modo isolato, quindi considera sia i componenti che utilizzerai sia le loro dipendenze come parte della tua strategia di failover. In genere, più applicazioni collaborano per supportare una storia utente, ovvero una funzionalità specifica offerta a un utente finale, ad esempio la pubblicazione di una foto e di una didascalia su un'app di social media o il check-out su un sito di e-commerce. Per questo motivo, è necessario sviluppare una strategia di failover organizzativa multiregionale che fornisca il coordinamento e la coerenza necessari per il successo del proprio approccio.

Esistono quattro strategie di alto livello tra cui le organizzazioni possono scegliere per guidare un approccio multiregionale. Queste sono elencate dall'approccio più granulare a quello più ampio:

• Failover a livello di componente

• Failover delle singole applicazioni

• Failover del grafico delle dipendenze

• Failover dell'intero portafoglio di applicazioni

Ogni strategia presenta dei compromessi e affronta diverse sfide, tra cui la flessibilità del processo decisionale in materia di failover, la capacità di testare le combinazioni di failover, la presenza di comportamenti modali e gli investimenti organizzativi nella pianificazione e nell'implementazione. Per approfondire ogni strategia in modo più dettagliato, consulta il post AWS sul blog Creazione di una strategia di failover organizzativa multiregionale.

Linee guida chiave

• Rivedi tutte le Servizio AWS quote per assicurarti che siano uguali in tutte le regioni in cui verrà eseguito il carico di lavoro.

• Il processo di implementazione dovrebbe riguardare una regione alla volta anziché coinvolgere più regioni contemporaneamente.

• Le metriche aggiuntive, come il ritardo di replica, sono specifiche degli scenari multiregionali e devono essere monitorate.

• Estendi il monitoraggio del carico di lavoro oltre la regione principale. Monitora le metriche relative all'esperienza del cliente per ogni regione e misura questi dati dall'esterno di ciascuna regione in cui è in esecuzione un carico di lavoro.

• Verifica regolarmente il failover e il failback. Implementa un singolo runbook per i processi di failover e failback e utilizzalo sia per i test che per gli eventi live. I runbook per i test e gli eventi live non dovrebbero essere diversi.

• Comprendi i compromessi delle strategie di failover. Implementa un grafico delle dipendenze o una strategia per l'intero portafoglio di applicazioni.