Nozioni fondamentali su più regioni 3: Comprendere le dipendenze del carico di lavoro

Un carico di lavoro specifico può avere diverse dipendenze in una regione, ad esempio dipendenze Servizi AWS utilizzate, interne, dipendenze di terze parti, dipendenze di rete, certificati, chiavi, segreti e parametri. Per garantire il funzionamento del carico di lavoro durante uno scenario di errore, non dovrebbero esserci dipendenze tra la regione principale e la regione di standby; ciascuna dovrebbe essere in grado di funzionare indipendentemente dall'altra. A tal fine, esamina tutte le dipendenze del carico di lavoro per assicurarti che siano disponibili all'interno di ciascuna regione. Ciò è necessario perché un errore nella regione principale non dovrebbe influire sulla regione di standby. Inoltre, è necessario comprendere come funziona il carico di lavoro quando una dipendenza si trova in uno stato degradato o completamente non disponibile, in modo da poter progettare soluzioni per gestirla in modo appropriato.

3.a: Servizi AWS

Quando si progetta un'architettura multiregionale, è importante comprendere cosa verrà utilizzata, le funzionalità multiregionali di tali servizi e quali soluzioni sarà necessario progettare per raggiungere gli obiettivi multiregionali. Servizi AWS Ad esempio, Amazon Aurora e Amazon DynamoDB possono replicare in modo asincrono i dati in una regione di standby. Tutte le Servizio AWS dipendenze dovranno essere disponibili in tutte le regioni da cui verrà eseguito un carico di lavoro. Per confermare che i servizi che utilizzi sono disponibili nelle regioni desiderate, consulta l'elenco Servizi AWS per regione.

3.b: Dipendenze interne e di terze parti

Assicurati che le dipendenze interne di ogni carico di lavoro siano disponibili nelle regioni da cui operano. Ad esempio, se il carico di lavoro è composto da molti microservizi, identifica tutti i microservizi che comprendono una funzionalità aziendale e verifica che tutti quei microservizi siano distribuiti in ogni regione da cui opera il carico di lavoro. In alternativa, definisci una strategia per gestire in modo corretto i microservizi che diventano non disponibili.

Le chiamate interregionali tra microservizi all'interno di un carico di lavoro non sono consigliate e l'isolamento regionale deve essere mantenuto. Questo perché la creazione di dipendenze tra regioni aumenta il rischio di errori correlati, il che compensa i vantaggi delle implementazioni regionali isolate del carico di lavoro. Anche le dipendenze locali potrebbero far parte del carico di lavoro, quindi è importante capire come le caratteristiche di queste integrazioni potrebbero cambiare se la regione principale dovesse cambiare. Ad esempio, se la regione di standby si trova più lontana dall'ambiente locale, l'aumento della latenza potrebbe avere un impatto negativo.

Comprendere le soluzioni SaaS (Software as a Service), i kit di sviluppo software (SDKs) e altre dipendenze da prodotti di terze parti e la possibilità di utilizzare scenari in cui tali dipendenze sono degradate o non disponibili forniranno maggiori informazioni su come la catena di sistemi opera e si comporta in diverse modalità di errore. Queste dipendenze potrebbero risiedere all'interno del codice dell'applicazione, ad esempio gestire i segreti esternamente tramite l'utilizzo AWS Secrets Manager, oppure potrebbero coinvolgere una soluzione di vault di terze parti (ad esempio HashiCorp) o sistemi di autenticazione che dipendono dagli accessi federati. AWS IAM Identity Center

La ridondanza quando si tratta di dipendenze può aumentare la resilienza. Se una soluzione SaaS o una dipendenza da terze parti utilizza lo stesso carico di lavoro primario Regione AWS , collabora con il fornitore per determinare se la sua posizione di resilienza corrisponde ai tuoi requisiti per il carico di lavoro.

Inoltre, tieni presente il destino condiviso tra il carico di lavoro e le sue dipendenze, come le applicazioni di terze parti. Se le dipendenze non sono disponibili in (o da) una regione secondaria dopo un failover, il carico di lavoro potrebbe non essere ripristinato completamente.

3.c: meccanismo di failover

Il DNS è comunemente usato come meccanismo di failover per spostare il traffico dalla regione principale a una regione di standby. Esamina e analizza in modo critico tutte le dipendenze assunte dal meccanismo di failover. Ad esempio, se il tuo carico di lavoro utilizza Amazon Route 53, sapere che il piano di controllo è ospitato in us-east-1 significa dipendere dal piano di controllo in quella regione specifica. Questa operazione non è consigliata come parte di un meccanismo di failover se la regione primaria lo è anche us-east-1 perché crea un singolo punto di errore. Se si utilizza un altro meccanismo di failover, è necessario avere una conoscenza approfondita degli scenari in cui il failover non funzionerebbe come previsto e quindi pianificare eventuali situazioni di emergenza o sviluppare un nuovo meccanismo, se necessario. Leggi il post sul blog Creazione di meccanismi di disaster recovery con Amazon Route 53 per scoprire gli approcci che puoi utilizzare per eseguire correttamente il failover.

Come discusso nella sezione precedente, tutti i microservizi che fanno parte di una funzionalità aziendale devono essere disponibili in ogni regione in cui viene distribuito il carico di lavoro. Nell'ambito della strategia di failover, tutti i microservizi che fanno parte della funzionalità aziendale devono eseguire il failover contemporaneamente per eliminare la possibilità di chiamate tra regioni. In alternativa, se i microservizi eseguono il failover in modo indipendente, è possibile che si verifichino comportamenti indesiderati, ad esempio che i microservizi effettuino chiamate tra regioni diverse. Ciò introduce la latenza e potrebbe rendere il carico di lavoro non disponibile durante i timeout del client.

3.d: dipendenze dalla configurazione

Certificati, chiavi, segreti, Amazon Machine Images (AMIs), immagini dei container e parametri fanno parte dell'analisi delle dipendenze necessaria per progettare un'architettura multiregionale. Quando possibile, è meglio localizzare questi componenti all'interno di ciascuna regione in modo che non abbiano un destino condiviso tra le regioni per queste dipendenze. Ad esempio, è necessario variare le date di scadenza dei certificati per evitare che si verifichi uno scenario in cui un certificato in scadenza (con allarmi impostati su «notifica in anticipo») influisca su più regioni.

Anche le chiavi e i segreti di crittografia devono essere specifici della regione. In questo modo, se si verifica un errore nella rotazione di una chiave o di un segreto, l'impatto è limitato a una regione specifica.

Infine, tutti i parametri del carico di lavoro devono essere archiviati localmente affinché il carico di lavoro possa essere recuperato nella regione specifica.

Linee guida chiave

• Un'architettura multiregionale trae vantaggio dalla separazione fisica e logica tra le regioni. L'introduzione di dipendenze interregionali a livello di applicazione annulla questo vantaggio. Evita tali dipendenze.

• I controlli di failover dovrebbero funzionare senza dipendenze dalla regione principale.

• Il failover deve essere coordinato lungo tutto il percorso dell'utente per eliminare la possibilità di un aumento della latenza e della dipendenza delle chiamate interregionali.