Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Principi fondamentali per più regioni 2: comprensione dei dati

La gestione dei dati è un problema non banale con le architetture multiregionali. La distanza geografica tra le regioni impone una latenza inevitabile, che si manifesta con il tempo necessario per replicare i dati tra le regioni. Saranno necessari compromessi tra disponibilità, coerenza dei dati e introduzione di ordini di grandezza di latenza più elevati in un carico di lavoro che utilizza un'architettura multiregionale. Che si utilizzi la replica asincrona o sincrona, sarà necessario modificare l'applicazione per gestire i cambiamenti comportamentali imposti dalla tecnologia di replica. È molto difficile prendere un'applicazione esistente progettata per una singola regione e renderla multiregionale a causa delle sfide legate alla coerenza e alla latenza dei dati. Comprendere i requisiti di coerenza dei dati e i modelli di accesso ai dati per carichi di lavoro particolari è fondamentale per valutare i compromessi.

2a: Comprendere i requisiti di coerenza dei dati

Il teorema CAP fornisce un riferimento per ragionare sui compromessi tra coerenza dei dati, disponibilità e partizioni di rete, di cui solo due possono essere soddisfatte contemporaneamente per un carico di lavoro. La multiregione per definizione include le partizioni di rete tra regioni, quindi è necessario scegliere tra disponibilità e coerenza.

Se si seleziona la disponibilità dei dati tra le regioni, non si verificherà una latenza significativa durante le scritture transazionali, poiché si fa affidamento sulla replica asincrona dei dati impegnati tra le regioni, con conseguente riduzione della coerenza tra le regioni fino al completamento della replica. Con la replica asincrona, in caso di errore nella regione principale, c'è un'alta probabilità di scritture in attesa della replica dalla regione principale. Ciò porta a uno scenario in cui i dati più recenti non sono disponibili fino alla ripresa della replica ed è necessario un processo di riconciliazione per gestire le transazioni in corso che non sono state replicate dalla regione in cui si è verificata l'interruzione.

Per i carichi di lavoro in cui è preferita la replica asincrona, puoi utilizzare servizi come Amazon Aurora e Amazon DynamoDB, che forniscono la replica asincrona tra regioni. Sia le tabelle globali Amazon Aurora Global Database che Amazon DynamoDB dispongono di parametri CloudWatchAmazon predefiniti per facilitare il monitoraggio del ritardo di replica.

Progettare il carico di lavoro per sfruttare le architetture basate sugli eventi è un vantaggio per una strategia multiregionale, perché significa che il carico di lavoro può includere la replica asincrona dei dati e consente la ricostruzione dello stato mediante la riproduzione degli eventi. Poiché i servizi di streaming e messaggistica memorizzano nel buffer i dati del payload dei messaggi in un'unica regione, un processo di failover/failback regionale deve includere un meccanismo per reindirizzare i flussi di dati di input dei client, nonché per riconciliare i payload in volo e/o non consegnati archiviati nella regione in cui si è verificata l'interruzione.

Se si seleziona la coerenza, si verificherà una latenza significativa poiché i dati vengono replicati in modo sincrono durante le scritture transazionali. Quando si scrive in più regioni in modo sincrono, se la scrittura non riesce in tutte le regioni, la disponibilità è potenzialmente ridotta perché la transazione non verrà confermata e dovrà essere ritentata. I nuovi tentativi di scrivere i dati in tutte le regioni in modo sincrono vengono eseguiti a scapito della latenza ad ogni tentativo. A un certo punto, quando i nuovi tentativi saranno esauriti, sarà necessario decidere se annullare completamente la transazione, riducendo così la disponibilità, oppure affidarla solo alle regioni disponibili, con conseguenti incongruenze. Esistono tecnologie di formazione del quorum come Paxos, che possono aiutare a replicare e inviare dati in modo sincrono, ma che richiedono investimenti significativi da parte degli sviluppatori.

Quando le scritture prevedono la replica sincrona su più regioni per soddisfare elevati requisiti di coerenza, la latenza di scrittura aumenta di un ordine di grandezza. Una latenza di scrittura più elevata non è qualcosa che in genere può essere adattata a posteriori in un'applicazione senza modifiche significative. Idealmente, deve essere presa in considerazione quando l'applicazione viene progettata per la prima volta. Per i carichi di lavoro multiregionali in cui la replica sincrona è una priorità, le soluzioni dei AWSpartner possono essere d'aiuto.

2b: Comprensione dei modelli di accesso ai dati

I modelli di accesso ai dati dei carichi di lavoro rientrano in uno dei seguenti tipi: intensivo in lettura o in scrittura. La comprensione di questa caratteristica per un particolare carico di lavoro guiderà la selezione di un'architettura multiregionale appropriata.

Per carichi di lavoro ad alta intensità di lettura, come i contenuti statici completamente di sola lettura, è possibile realizzare un'architettura multiregionale attiva/attiva senza complessità significative. La distribuzione di contenuti statici all'edge tramite una rete di distribuzione dei contenuti (CDN) garantisce la disponibilità memorizzando nella cache i contenuti più vicini all'utente finale; l'utilizzo di set di funzionalità come il failover Origin all'interno di Amazon CloudFront può contribuire a raggiungere questo obiettivo. Un'altra opzione consiste nell'implementare l'elaborazione stateless in più regioni e utilizzare il DNS per indirizzare gli utenti alla regione più vicina per leggere il contenuto. A tal fine è possibile utilizzare Route 53 con politica di routing di geolocalizzazione.

Per carichi di lavoro ad alta intensità di lettura che hanno una percentuale maggiore di letture rispetto alle scritture, è possibile utilizzare una strategia globale di lettura locale e scrittura. Ciò implica che tutte le scritture vadano a un database in una regione specifica con replica asincrona dei dati in tutte le altre regioni e a tal fine le letture possono essere eseguite in qualsiasi regione. Questo approccio richiede un carico di lavoro tale da garantire la coerenza finale, in quanto le letture locali potrebbero risultare obsolete a causa della maggiore latenza per la replica delle scritture tra regioni diverse.

Aurora Global Database può aiutare a fornire repliche di lettura in una regione di standby in grado di gestire esclusivamente tutto il traffico di lettura a livello locale e un singolo datastore primario in una regione specifica per gestire le scritture. I dati vengono replicati in modo asincrono dai database primari a quelli di standby (Read Repliche) e i database di standby possono essere promossi a primari se è necessario eseguire il failover delle operazioni nella regione di standby. Se un carico di lavoro è più adatto per modelli di dati non relazionali, DynamoDB può essere utilizzato anche in questo approccio. Anche in questo caso, il carico di lavoro deve garantire la coerenza finale, il che potrebbe richiedere una riscrittura se non è stato progettato per questo scopo fin dall'inizio.

Per i carichi di lavoro ad alta intensità di scrittura, è necessario selezionare una regione principale e incorporare nel carico di lavoro la capacità di failover su una regione di standby. Rispetto a un approccio attivo/attivo, un approccio primario/standby è meno complicato. Questo perché per un'architettura attiva/attiva, il carico di lavoro dovrà essere riscritto per gestire il routing intelligente verso le regioni, stabilire l'affinità delle sessioni, garantire transazioni idempotenti e gestire potenziali conflitti.

La maggior parte dei carichi di lavoro che utilizzano la resilienza multiregionale non richiederà un approccio attivo/attivo. È possibile utilizzare una strategia di sharding per fornire una maggiore resilienza limitando il raggio d'azione di un danno all'interno della base clienti. Se è possibile suddividere in modo efficace una base di clienti, è possibile selezionare diverse regioni primarie per ogni shard. Ad esempio, se è possibile suddividere i client in modo che metà dei client siano allineati alla Regione Uno e l'altra metà alla Regione Due, trattando le regioni come celle, è possibile creare un approccio cellulare multiregionale, che si traduce in una riduzione del raggio di impatto del carico di lavoro.

L'approccio di sharding può essere combinato con un approccio primario/standby per fornire funzionalità di failover per gli shard. Sarà necessario integrare nel carico di lavoro un processo di failover testato e un processo di riconciliazione dei dati per garantire la coerenza transazionale degli archivi di dati dopo il failover. Questi sono trattati più dettagliatamente più avanti in questo paper.

Linee guida chiave