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 quando si adottano 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 una maggiore latenza in un carico di lavoro che utilizza un'architettura multiregionale. Sia che si utilizzi la replica asincrona o sincrona, sarà necessario modificare l'applicazione per gestire i cambiamenti comportamentali imposti dalla tecnologia di replica. Le sfide relative alla coerenza e alla latenza dei dati rendono molto difficile convertire un'applicazione esistente progettata per una singola regione e renderla multiregionale. Comprendere i requisiti di coerenza dei dati e i modelli di accesso ai dati per carichi di lavoro particolari è fondamentale per valutare i compromessi.
2.a: 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. Solo due di questi requisiti possono essere soddisfatti contemporaneamente per un carico di lavoro. Per definizione, un'architettura multiregionale include 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 operazioni di scrittura transazionale, poiché la dipendenza dalla replica asincrona dei dati impegnati tra le regioni si traduce in una riduzione della coerenza tra le regioni fino al completamento della replica. Con la replica asincrona, in caso di errore nella regione principale, è molto probabile che le operazioni di scrittura siano 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 che ha subito l'interruzione. Questo scenario richiede la comprensione della logica aziendale e la creazione di un processo specifico per riprodurre la transazione o confrontare gli archivi di dati tra le regioni.
Per i carichi di lavoro in cui è preferita la replica asincrona, puoi utilizzare servizi come Amazon Aurora e
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 una singola regione, un processo di failover o failback regionale deve includere un meccanismo per reindirizzare i flussi di dati di input dei client. Il processo deve inoltre riconciliare i payload in volo o non consegnati immagazzinati nella regione che ha subito l'interruzione.
Se si sceglie il requisito di coerenza CAP e si utilizza un database replicato in modo sincrono tra le regioni per supportare le applicazioni eseguite contemporaneamente da più regioni, si elimina il rischio di perdita di dati e si mantengono i dati sincronizzati tra le regioni. Tuttavia, ciò introduce caratteristiche di latenza più elevate, poiché le scritture devono essere trasferite in più di una regione e le regioni possono trovarsi a centinaia o migliaia di miglia l'una dall'altra. È necessario tenere conto di questa caratteristica di latenza nella progettazione dell'applicazione. Inoltre, la replica sincrona può comportare la possibilità di errori correlati perché, per avere successo, le scritture dovranno essere eseguite su più di una regione. Se si verifica un problema all'interno di una regione, sarà necessario creare un quorum affinché le scritture abbiano esito positivo. Ciò comporta in genere la configurazione del database in tre regioni e la creazione di un quorum di due regioni su tre. Tecnologie come Paxos
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 in genere non è possibile adattarla a un'applicazione senza modifiche significative, come rivisitare la strategia di timeout e riprovare per l'applicazione. 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à,AWS Partner le soluzioni possono essere utili.
2.b: Comprensione dei modelli di accesso ai dati
I modelli di accesso ai dati dei carichi di lavoro richiedono un'intensa attività di lettura o scrittura. La comprensione di questa caratteristica per un particolare carico di lavoro ti aiuterà a selezionare un'architettura multiregionale appropriata.
Per carichi di lavoro ad alta intensità di lettura, come il contenuto statico completamente di sola lettura, è possibile ottenere un'architettura multiregionale attiva e attiva che presenta una minore complessità ingegneristica rispetto
Per carichi di lavoro ad alta intensità di lettura che hanno una percentuale di traffico di lettura maggiore rispetto al traffico di scrittura, puoi utilizzare una strategia globale di lettura
I database globali Aurora
Per i carichi di lavoro ad alta intensità di scrittura, è necessario selezionare una regione principale e incorporare nel carico di lavoro la capacità di eseguire il failover in una regione di standby. Rispetto a un approccio attivo-attivo, un approccio di standby primario presenta ulteriori compromessi.
La maggior parte dei carichi di lavoro che utilizzano un approccio multiregionale per la resilienza non richiederà un approccio attivo-attivo. È possibile utilizzare una strategia di sharding
È possibile combinare l'approccio di sharding con un approccio di standby primario per fornire funzionalità di failover per gli shard. Dovrai progettare un processo di failover collaudato nel carico di lavoro e anche un processo per la riconciliazione dei dati, per garantire la coerenza transazionale degli archivi di dati dopo il failover. Questi aspetti sono trattati più dettagliatamente più avanti in questa guida.
Linee guida chiave
-
È molto probabile che le scritture in sospeso per la replica non vengano salvate nella regione di standby in caso di errore. I dati non saranno disponibili fino alla ripresa della replica (presupponendo la replica asincrona).
-
Come parte del failover, sarà necessario un processo di riconciliazione dei dati per garantire il mantenimento di uno stato transazionale coerente per gli archivi di dati che utilizzano la replica asincrona. Ciò richiede una logica aziendale specifica e non è gestita dall'archivio dati stesso.
-
Quando è richiesta una forte coerenza, i carichi di lavoro dovranno essere modificati per tollerare la latenza richiesta di un data store che si replica in modo sincrono.
