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 AWS servizi utilizzati, dipendenze 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 l'una dall'altra. A tal fine, è necessario esaminare attentamente tutte le dipendenze del carico di lavoro per garantire che siano disponibili all'interno di ciascuna regione. Ciò è necessario perché un errore nella regione principale non dovrebbe avere un impatto nella regione di standby. Inoltre, è fondamentale conoscere il funzionamento del 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.

3a: servizi AWS 

Quando si progetta un'architettura multiregionale, è necessaria una comprensione dei AWS servizi specifici che verranno utilizzati. Il primo aspetto è capire quali funzionalità dispone il servizio per abilitare più regioni e se è necessario progettare una soluzione per raggiungere gli obiettivi multiregionali. Ad esempio, con Amazon Aurora e Amazon DynamoDB, è disponibile una funzionalità per replicare in modo asincrono i dati in una regione di standby. Qualsiasi dipendenza dal AWS servizio dovrà essere disponibile in tutte le regioni da cui verrà eseguito un carico di lavoro. Per garantire che i servizi che verranno utilizzati siano disponibili nelle regioni desiderate, consulta l'Regione AWSelenco dei servizi. 

3b: Dipendenze interne e di terze parti

Per tutte le dipendenze interne di un carico di lavoro, assicurati che sia disponibile nelle regioni da cui verrà utilizzato il carico di lavoro. Ad esempio, se il carico di lavoro è composto da molti microservizi, informati su tutti i microservizi che costituiscono una funzionalità aziendale. Da lì, assicurati che tutti questi microservizi siano distribuiti in ogni regione in cui il carico di lavoro funzionerà.

Le chiamate interregionali tra microservizi all'interno di un carico di lavoro non sono consigliate e l'isolamento regionale dovrebbe essere mantenuto. Questo perché la creazione di dipendenze tra regioni aumenta il rischio di errori correlati, il che annulla i vantaggi che si stanno cercando di ottenere con implementazioni regionali isolate del carico di lavoro. Anche le dipendenze locali potrebbero far parte del carico di lavoro, quindi è fondamentale comprendere 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 avrà un impatto negativo.

Comprendere le soluzioni Software as a Service (SaaS), i kit di sviluppo software (SDK) 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 possono rientrare in un codice applicativo, dal modo in cui i segreti vengono gestiti esternamente utilizzando AWS Secrets Manager o una soluzione di vault di terze parti (come Hashicorp), ai sistemi di autenticazione che dipendono da IAM Identity Center per gli accessi federati.

La ridondanza quando si tratta di dipendenze può contribuire ad aumentare la resilienza. Esiste anche la possibilità che una soluzione SaaS o una dipendenza di terze parti utilizzi lo stesso carico di lavoro primarioRegione AWS. In tal caso, è necessario collaborare con il fornitore per determinare se il suo livello di resilienza corrisponde ai requisiti per il carico di lavoro.

Inoltre, tieni presente il destino condiviso tra il carico di lavoro e le sue dipendenze, ad esempio 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.

3c: meccanismo di failover

Il Domain Name System (DNS) viene comunemente utilizzato 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 negli Stati Uniti orientali 1 significa che stai assumendo una dipendenza dal piano di controllo in quella regione specifica. Questa operazione non è consigliata come parte di un meccanismo di failover se anche la regione principale è US-East-1. Se si utilizza un altro meccanismo di failover, è necessaria una conoscenza approfondita di qualsiasi scenario in cui non funzionerebbe come previsto. Una volta stabilita questa comprensione, pianificate gli imprevisti o sviluppate un nuovo meccanismo, se necessario. Consulta la sezione 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 sulle dipendenze interne, 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, le funzionalità aziendali devono essere integrate per eliminare la possibilità di chiamate tra regioni diverse. In alternativa, se i microservizi effettuano il failover in modo indipendente, ciò comporta il rischio di un comportamento indesiderato, in cui i microservizi possono effettuare chiamate tra regioni diverse, con conseguente latenza e l'indisponibilità del carico di lavoro in caso di timeout del client.

3d: dipendenze di configurazione

I certificati, le chiavi, i segreti e i parametri fanno parte dell'analisi delle dipendenze necessaria durante la progettazione per più regioni. 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. Per quanto riguarda i certificati, la scadenza dovrebbe variare da un paese all'altro e, se possibile, da una regione all'altra, per evitare che un certificato in scadenza (con allarmi impostati per notificare 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.

• È necessario coordinare il failover a livello di capacità aziendale per eliminare la possibilità di un aumento della latenza e della dipendenza delle chiamate interregionali.