Utilizzo del cloud per creare un'architettura multi-regione

Esistono molti documenti e raccomandazioni su come costruire un'architettura nel cloud, supponendo che il cliente si trovi in una regione specifica, ma cosa succede se siamo un'organizzazione che fornisce informazioni o servizi a clienti in tutto il mondo o varie regioni.

Esempio di tali servizi: siti di e-commerce, servizi di streaming video, siti di notizie, piattaforme di gioco, servizi IoT, ecc.

In questo articolo, proverò a mappare alcune delle considerazioni per la scelta dei servizi globali, che ci consentiranno di costruire un'architettura comune per i clienti di tutto il mondo.

Approfondimento

Quando si progetta un'architettura multi-regione, è necessario prendere in considerazione aspetti come la distribuzione in più aree, la capacità di gestire i guasti (o problemi di connettività) in una regione specifica, la capacità di replicare i dati tra aree geografiche remote, la capacità di scrivere/aggiornare i dati in un intervallo di tempo specifico su più aree geografiche e la possibilità di distribuire nuove applicazioni per creare o controllare la scala di un'applicazione in modo semplice, su più aree geografiche remote (come aggiornamenti graduali delle applicazioni).

In alcuni scenari (come lo streaming multimediale), potremmo voler sincronizzare lo stesso contenuto in diverse aree del mondo. In altri scenari (come siti di e-commerce, siti di notizie, ecc.), Potremmo voler costruire un'architettura simile in diverse regioni, conservando i dati stessi (come catalogo dei prodotti, preferenze dei clienti, lingua, ecc.) Nella stessa area geografica del cliente.

Quando si esamina l'esigenza di costruire un'architettura multi-regione, ci sono caratteristiche comuni per tale architettura:

Latenza di rete tra il cliente e il servizio cloud:

Memorizzare i dati vicino al cliente, migliora l'esperienza del cliente Esempio di tale scenario - Streaming multimediale. In questo scenario desideriamo sincronizzare lo stesso contenuto con più aree geografiche

Ripristino dati in caso di emergenza:

Sito attivo-attivo - Una soluzione costosa, ma che ci consente un rapido ripristino da un disastro, supponendo che sincronizziamo i dati in tempo reale (o quasi in tempo reale) tra più aree geografiche
Sito attivo-passivo: ci consente di recuperare da un disastro, ma richiede un meccanismo di sincronizzazione dei dati e l'aggiornamento manuale dei record DNS tra i siti e il passaggio manuale tra i ruoli del database dalla replica al ruolo principale

Regolamento o requisiti relativi al cliente:

La necessità di archiviare i dati dei clienti in una specifica area geografica, in base ai requisiti normativi (come il GDPR) Esempio di tale scenario: sito di e-commerce. In questo scenario, costruiremo un'architettura simile in diverse aree geografiche, ma memorizzeremo i dati relativi ai clienti (come catalogo dei prodotti, preferenze dei clienti, ecc.) Nella stessa area geografica del cliente

Esempio di architettura multi-regione

Aspetti relativi alla rete

Quando si progetta un'architettura multi-regione, il primo aspetto che desideriamo rivedere, dal punto di vista del cliente (browser, dispositivo mobile, dispositivo IoT, ecc.), È l'aspetto della rete.

Servizi DNS: utilizzando questi servizi, il cliente accede alla nostra infrastruttura (o applicazione) da Internet.

Di seguito sono riportati i servizi DNS comuni per l'architettura multi-regione:

Amazon Route 53 — Servizio distribuito a livello globale, che ci consente di configurare le regole di risoluzione dei nomi delle risorse in base alla geolocalizzazione
Azure Traffic Manager — Servizio distribuito a livello globale, che ci consente di reindirizzare il traffico in base alle richieste DNS
Google Cloud DNS — Servizio distribuito a livello globale, che ci consente di configurare le regole di risoluzione dei nomi delle risorse

‍

Servizi CDN (Content Delivery Network): infrastruttura di rete distribuita a livello globale, che consente ai nostri clienti un rapido accesso alle risorse (utilizzando la cache).

Di seguito sono riportati i servizi CDN comuni:

Amazon CloudFront — Infrastruttura CDN distribuita a livello globale, basata su Edge Locations
Azure CDN — Infrastruttura CDN distribuita a livello globale (in alcuni paesi, basata sull'infrastruttura CDN di Akamai)
Google Cloud CDN — Infrastruttura CDN distribuita a livello globale, basata sull'infrastruttura di rete globale di Google

‍

Difesa dagli attacchi DDoS (Distributed Denial of Service) e delle applicazioni (Layer 7): poiché stiamo progettando un'infrastruttura accessibile ed esposta da Internet, desideriamo proteggere la nostra infrastruttura ed essere in grado di integrarci con altri servizi (come DNS, Load Bilanciamento, ecc.)

Di seguito sono riportati i servizi di protezione comuni:

AWS Shield — Servizio di protezione DDoS distribuito a livello globale, con funzionalità WAF (Web Application Firewall)
Azure Front Door — Servizio di protezione DDoS distribuito a livello globale, con funzionalità WAF (Web Application Firewall)
Google Cloud Armor — Servizio di protezione DDoS distribuito a livello globale, con funzionalità WAF (Web Application Firewall)

‍

Servizi di bilanciamento del carico di rete: servizi che ci consentono di distribuire il carico di rete tra diversi data center o diverse aree geografiche.

Di seguito sono riportati i servizi comuni di bilanciamento del carico:

Amazon Application Load Balancer —Servizio di bilanciamento del carico di livello 7 (applicazione). Sebbene si tratti di un servizio regionale, possiamo costruire un'infrastruttura globale, reindirizzando il traffico DNS da Amazon Route 53 al nostro Amazon ALB regionale
AWS Global Accelerator — Servizio globale, che ci consente di accelerare il traffico di rete verso la nostra applicazione, utilizzando al contempo un unico indirizzo IP pubblico globale e supportando il traffico HTTP / HTTPS e TCP / UDP
Azure Front Door — Servizio di bilanciamento del carico globale, che supporta il traffico HTTP / HTTPS
Google Cloud Load Balancing — Servizio di bilanciamento del carico globale, utilizza un unico indirizzo IP pubblico globale e supporta il traffico HTTP/HTTPS, TCP/ SSL e UDP

‍

Aspetti relativi all'archiviazione dei file

Come in qualsiasi altro sistema, la maggior parte delle possibilità è che desideriamo condividere contenuti statici (file) in più aree geografiche, sia che si tratti dell'origine da cui desideriamo condividere contenuti utilizzando servizi CDN, file di configurazione, backup, ecc.

Servizi di archiviazione oggetti: questo tipo di servizi ci consente di archiviare i file per la lettura e l'aggiornamento.

Di seguito sono riportati i servizi di archiviazione oggetti comuni:

Amazon S3 — Servizio di archiviazione oggetti gestiti. Sebbene si tratti di un servizio regionale, è possibile replicare i file tra bucket S3 situati in regioni remote, utilizzando la funzionalità di replica Cross Region
Azure Blob Storage — Servizio di archiviazione oggetti gestiti. Sebbene si tratti di un servizio regionale, è possibile replicare i file tra l'archiviazione BLOB situata in aree remote, utilizzando le funzionalità di archiviazione ridondante geografica o Geo Zone
Google Cloud Storage — Servizio di archiviazione oggetti gestito a livello globale, che ci consente di archiviare e replicare automaticamente i file tra aree remote

Aspetti relativi all'archiviazione del database

Quasi ogni sistema esistente oggi contiene vari tipi di database per l'archiviazione e l'interrogazione dei dati.

Database relazionali - Database per lavorare con dati strutturati e uno schema chiaramente definito Servizi comuni di database relazionali:

Amazon Aurora — Servizio di database gestito, basato sul motore MySQL o PostgreSQL. Usando una funzione chiamata Aurora Multi-Master, possiamo costruire un processo di replica dei dati (modalità lettura/scrittura) tra regioni remote
Azure SQL Database — Servizio di database gestito, basato sul motore MS-SQL. Sebbene si tratti di un servizio regionale, è possibile creare un processo di replica dei dati asincroni tra aree remote, utilizzando le funzionalità di replica geografica attiva e replica automatica asincrona
Google Cloud Spanner — Servizio di database gestito a livello globale, che ci consente di replicare i dati (modalità lettura/scrittura) tra regioni remote

Database NoSQL / Non relazionali - Database per la memorizzazione di grandi quantità di dati non strutturati Servizi di database NoSQL comuni:

Amazon DynamoDB — Servizio di database NoSQL gestito. Utilizzare una funzionalità denominata Tabelle globali, siamo in grado di creare un processo di replica dei dati (modalità lettura/scrittura) tra aree remote
Azure Cosmos DB — Servizio di database NoSQL gestito a livello globale, che ci consente di eseguire il processo di replica dei dati (modalità lettura/scrittura) tra regioni remote
Google Cloud BigTable — Servizio di database NoSQL gestito a livello globale, che ci consente di eseguire il processo di replica dei dati (modalità lettura/scrittura) tra regioni remote

Aspetti dei costi

Quando si progetta un'architettura multi-regione, è necessario considerare gli aspetti dei costi, come:

Costo del servizio: in molti scenari citati in questo articolo, la soluzione globale richiede una costosa licenza premium
Costo del traffico in uscita (in uscita) - La replica tra regioni e il traffico inter-regione ha il proprio modello di costo per ciascun provider cloud

Aspetti operativi

Quando si progetta un'architettura multi-regione, è necessario considerare gli aspetti operativi, come:

DevOps, distribuzione e aggiornamenti delle applicazioni - Possibilità di eseguire distribuzioni o aggiornamenti graduali delle applicazioni su più aree remote
Registro di origine/configurazione: necessità di creare un registro centrale di configurazione/contenitore per archiviare la configurazione, le immagini del contenitore e qualsiasi altro tipo di dati necessari per la sincronizzazione tra più aree remote in tutto il mondo
Monitoraggio: requisito per il monitoraggio costante di più servizi (dalla disponibilità, all'utilizzo delle risorse, alla scala, ecc.), altre regioni remote
Integrità/coerenza dei dati: la capacità di assicurarsi che i dati vengano sincronizzati e archiviati coerentemente tra più aree remote
Disponibilità: la capacità di monitorare la disponibilità del servizio su più aree remote
Ripristino di emergenza: capacità di eseguire esercitazioni di ripristino di emergenza tra aree remote, inclusi failover e reindirizzamento del traffico dei clienti tra aree
Sicurezza e governance - La capacità di applicare politiche di accesso e configurazioni di sicurezza su più aree
Conformità alle normative - La capacità di mantenere l'infrastruttura globale, nel rispetto delle normative locali e della privacy in alcune parti del mondo (come il GDPR)

Sommario

In questo articolo, ho esaminato molti aspetti e conseguenze della progettazione e costruzione di architetture multiregione, che consentono alle organizzazioni di scalare e fornire un servizio clienti migliore, in base alla loro origine.

È importante ricordare che non esiste un'architettura istantanea, adatta a tutte le organizzazioni e tutti i tipi di sistemi, e per ogni scenario dobbiamo effettuare le opportune regolazioni e scegliere il servizio più appropriato (che sia gestito o meno). L'elenco dei servizi menzionato in questo articolo ti consentirà di rivedere le tue alternative.

Dobbiamo considerare che l'architettura multi-regione (o globale) è solo la media e non l'obiettivo stesso. La costruzione e la progettazione di infrastrutture globali sono costose e richiedono considerazioni al di là del lato tecnico: nuovi servizi di monitoraggio, diverse capacità di monitoraggio, effetto del processo di sviluppo, ecc.

Riferimenti aggiuntivi: