resistano<\/strong> ai guasti delle regioni.<\/p>\n\n\n\nQuesto paradigma non serve solo a creare soluzioni ad alta disponibilit\u00e0, ma anche a raggiungere utenti in tutto il mondo, avvicinando i contenuti alla loro posizione. In questa discussione, ci concentreremo principalmente sul cambiamento del paradigma per migliorare la resilienza e l’alta disponibilit\u00e0 delle nostre applicazioni.<\/p>\n\n\n\n
Tuttavia, anche se utilizziamo solo servizi serverless, cambiare paradigma non \u00e8 sempre cos\u00ec semplice come sembra.<\/p>\n\n\n\n
Intraprendere un cambiamento da mono-region a multi-region comporta alcune sfide<\/strong>. Bisogna pensare diversamente e scegliere il servizio appropriato che meglio si adatta alle nostre esigenze e al nuovo paradigma multi-region. <\/p>\n\n\n\nE anche prestando attenzione a tutti questi problemi, a volte ci si accorge che non esiste una soluzione pronta e facile da usare.<\/p>\n\n\n\n
Il data layer<\/strong> \u00e8 uno dei primi aspetti da affrontare: ogni servizio memorizza e gestisce i dati con le proprie complessit\u00e0 (e i propri limiti). Per questo bispgna progettare replica e sincronizzazione dei dati in modo accurato.<\/p>\n\n\n\nPrendiamo poi in considerazione il layer di autenticazione<\/strong>: in AWS, l’unico servizio che consente di autenticare le nostre API \u00e8 Amazon Cognito.<\/p>\n\n\n\nSfortunatamente, ad oggi questo servizio non pu\u00f2 essere distribuito su pi\u00fa region<\/strong> (e non sappiamo se mai sar\u00e0 possibile farlo). Quindi, come possiamo ottenere l’alta disponibilit\u00e0 in questo caso?\u00a0<\/p>\n\n\n\nE per quanto riguarda il logging e il monitoring<\/strong>? <\/p>\n\n\n\nIn una soluzione mono-region, i log e le metriche sono nella stessa regione dell’applicazione e sappiamo per certo che, se un utente avesse dei problemi, potremmo semplicemente consultare i log in AWS Cloudwatch (per esempio) e capire il perch\u00e9 degli errori riscontrati. In una soluzione multi-region, invece, i log e le metriche sono sparsi in pi\u00f9 Region. Cercare un errore specifico relativo ad un utente, \u00e8 quindi pi\u00f9 difficile poich\u00e9 non sappiamo dove si trova l’utente e quale regione sta contattando.<\/p>\n\n\n\n
In questo articolo, ci concentreremo su soluzioni per Database, Object Storage, Route53 e sistemi di Cache per trasformare la nostra semplice configurazione mono-region in una soluzione multi-region active-active.<\/p>\n\n\n\n
Ma prima, vediamo alcuni vantaggi e svantaggi della scelta di un deployment multi-region.<\/p>\n\n\n\n
Deployment Multi-Region: PRO e CONTRO<\/h2>\n\n\n\n Come per ogni soluzione, ci sono pro e contro da considerare prima di scegliere ci\u00f2 che \u00e8 appropriato per la nostra applicazione. Quindi non perdiamo tempo e iniziamo ad analizzare tutti i vantaggi e gli svantaggi della soluzione Multi-Region – Active \/ Active.<\/p>\n\n\n\n
PRO:<\/strong><\/p>\n\n\n\n\nCome abbiamo gi\u00e0 detto, se ci sono problemi in una regione, il nostro servizio continua a funzionare perfettamente senza il nostro intervento<\/strong>.<\/li>\n\n\n\nIl traffico verso la nostra applicazione \u00e8 distribuito<\/strong> tra tutte le regioni configurate, permettendoci di configurare meglio<\/strong> tutte le parti computazionali in base al traffico specifico della regione. Questo potrebbe portare a una migliore ottimizzazione dei costi e delle prestazioni.<\/li>\n\n\n\nPossiamo portare i contenuti pi\u00f9 vicino alla posizione dei nostri utenti, offrendo loro migliori prestazioni.<\/li>\n\n\n\n Per alcuni servizi AWS, esistono limiti regionali non aggiustabili (come l’API GetSecretValue di AWS Secrets Manager che ha un limite non aumentabile di 10.000 richieste al secondo). Avere la stessa risorsa distribuita in diverse regioni, aumenta<\/strong> di conseguenza il limite del servizio, permettendoci una migliore scalabilit\u00e0.<\/li>\n<\/ul>\n\n\n\nCONTRO:<\/strong><\/p>\n\n\n\n\nIl logging<\/strong> e il monitoring<\/strong> sono pi\u00f9 difficili poich\u00e9 sono distribuiti in tutte le regioni.<\/li>\n\n\n\nIn base ai servizi utilizzati, i costi<\/strong> possono essere pi\u00f9 alti<\/strong>.<\/li>\n\n\n\nLa progettazione e l’implementazione<\/strong> sono pi\u00f9 complesse<\/strong>.<\/li>\n\n\n\nL’iinfrastructure as Code (IaC<\/strong>) funziona diversamente<\/strong>.<\/li>\n<\/ul>\n\n\n\nOra che abbiamo visto alcuni pro e contro della soluzione multi-region, andiamo ad approfondire il cuore di questo articolo.<\/p>\n\n\n\n
Un’applicazione single-region<\/h2>\n\n\n\n Immaginiamo una semplice applicazione in cui dobbiamo gestire delle API CRUD con paradigma REST. Avremo un database con alcune tabelle e un layer API che ci consente di creare, aggiornare, eliminare e ottenere tutti i dati da quelle tabelle.<\/p>\n\n\n\n
Una possibile infrastruttura per questo tipo di applicazione \u00e8 la classica API Gateway \/ Lambda Function per esporre le API e DynamoDB o RDS Aurora per la parte di database.<\/p>\n\n\n\n
Ora che abbiamo definito la nostra infrastruttura di base mono-region, possiamo iniziare a pensare a come riprogettarla nel paradigma multi-region. Per i componenti Amazon APIGateway e AWS Lambda, non ci sono particolari considerazioni. Possiamo semplicemente distribuirli in tutte le regioni scelte.<\/p>\n\n\n\n
Il primo oggetto che merita qualche considerazione, quindi, \u00e8 il nostro database<\/strong>. Per evitare fastidiosi problemi di sistema come gli scenari di split-brain, dobbiamo renderlo globalmente distribuito<\/strong> in tutte le regioni senza compromettere la struttura dei dati. Per questo, il cloud AWS ci viene in aiuto, mettendo a nostra disposizione diverse soluzioni<\/strong> in base al servizio che stiamo utilizzando.<\/p>\n\n\n\nDatabase<\/h2>\n\n\n\n Una delle migliori soluzioni \u00e8 Amazon DynamoDB. <\/p>\n\n\n\n
AWS ha creato una configurazione perfetta di DynamoDB che ci permette di distribuire la stessa tabella in diverse regioni in modo multi-master chiamato DynamoDB Global Tables<\/strong>. Grazie a questo, l’applicazione pu\u00f2 leggere e scrivere dati nella tabella regionale, la quale verr\u00e1 replicata automaticamente in tutte le regioni configurate. \u00c8 importante ricordare che se diverse istanze scrivono lo stesso record in regioni diverse e nello stesso istante di tempo, AWS utilizza un meccanismo di riconciliazione last-writer-wins<\/strong> per salvare e replicare gli aggiornamenti concorrenti<\/strong>. Un’altra cosa da sapere \u00e8 che le scritture transazionali funzionano all’interno della regione e non a livello globale. Il record viene replicato nelle altre regioni solo quando viene salvato nella regione corrente. Quindi, prestate attenzione a questi limiti durante lo sviluppo della vostra applicazione.<\/p>\n\n\n\nMa cosa succede se abbiamo bisogno di database relazionali <\/strong>tradizionali o di altri tipi di database? Fortunatamente, AWS ha creato configurazioni globali per alcuni dei suoi servizi di database, tra cui AWS RDS Aurora e AWS ElastiCache. Ma sono un po’ diversi dalla soluzione DynamoDB. Sfortunatamente, non sono in una configurazione multi-master, consistono, invece, in un’istanza master attiva in una regione scelta e diverse istanze di replica<\/strong> (in sola lettura) in tutte le altre regioni. In caso di guasti regionali, AWS promuove automaticamente una delle repliche a nodo principale entro pochi minuti. Per soluzioni relazionali multi-region active-active \u00e8 necessaria una progettazione pi\u00f9 complessa, ma oggi ci accontenteremo solo delle configurazioni active-passive.<\/p>\n\n\n\nCon questa soluzione, abbiamo trasformato il nostro database deployato in una singola regione in un database globalmente distribuito che ci permette di salvare e leggere i nostri dati in diverse regioni.<\/p>\n\n\n\n
Ora dobbiamo solo instradare il traffico verso la nostra infrastruttura multi-region, e per questo sono necessarie ulteriori considerazioni.<\/p>\n\n\n\n
Object Storage<\/h2>\n\n\n\n E i dati che non sono memorizzati nel database?<\/p>\n\n\n\n
Uno dei metodi di archiviazione dati pi\u00f9 comuni \u00e8 sicuramente quello basato su Amazon S3.<\/p>\n\n\n\n
Grazie alla funzionalit\u00e0 Amazon S3 Cross Region Replication (CRR) replicare e sincronizzare i dati su S3 \u00e8 molto semplice.<\/p>\n\n\n\n
CRR copia asincronamente ogni oggetto in uno o pi\u00f9 bucket di destinazione in diverse Region di AWS. Il processo di replica include non solo l’oggetto stesso, ma anche i suoi metadati e le access control list conservando le propriet\u00e0 originali dell’oggetto.<\/p>\n\n\n\n
Similmente all’approccio con i database relazionali, anche questo \u00e8 un sistema di replica primary – standby, quindi con un bucket primario che viene replicato tra le regioni. Sfortunatamente, l’aggiornamento delle repliche non propaga le modifiche agli altri bucket.<\/p>\n\n\n\n
Con questa configurazione possiamo trasformare il nostro database single-region in uno distribuito a livello globale <\/p>\n\n\n\n
A questo punto, non ci resta che instradare il traffico verso la nostra infrastruttura multi-region. A questo proposito, vanno fatte ulteriori considerazioni.<\/p>\n\n\n\n
Configurazione DNS<\/h2>\n\n\n\n Possiamo usare diverse soluzioni. La scelta dipende dagli obiettivi. <\/p>\n\n\n\n
La prima domanda a cui dobbiamo rispondere \u00e8: Come vogliamo dividere il traffico nelle regioni configurate? Vogliamo dividere il traffico in base al volume? Prossimit\u00e0 dell’utente? Latenza dell’utente? Disponibilit\u00e0 del servizio? <\/p>\n\n\n\n
Approfondiamo alcune di queste soluzioni.<\/p>\n\n\n\n
Weighted Records<\/h5>\n\n\n\n La soluzione pi\u00f9 semplice \u00e8 dividere il traffico bilanciandolo su tutte le regioni disponibili utilizzando i record di tipo weighted<\/strong>. Questo ci permetter\u00e1 di avere circa lo stesso traffico in entrata<\/strong> su tutte le regioni. <\/p>\n\n\n\nSupponiamo di aver configurato tre regioni per la nostra applicazione. Possiamo creare tre diversi record di tipo weighted (uno per ciascuna regione) con un peso di 85 (255 come peso massimo diviso sulle 3 regioni). Con questa configurazione, Route53 bilancer\u00e0<\/strong> automaticamente il traffico in entrata nelle tre regioni.<\/p>\n\n\n\n<\/p>\n\n\n
\n
<\/figure><\/div>\n\n\n<\/p>\n\n\n\n
Latency-Based Records<\/h5>\n\n\n\n Un altro modo per configurare il routing DNS \u00e8 utilizzare i record basati sulla latenza<\/strong>. Questo ci permette di instradare il traffico nella regione configurata che \u00e8 pi\u00f9 vicina<\/strong> all’utente che sta effettuando la richiesta. Se non abbiamo vincoli applicativi che impediscono questo tipo di configurazione, questa \u00e8 la migliore soluzione per il routing DNS poich\u00e8 migliora le prestazioni per l’utente finale.<\/p>\n\n\n\n<\/p>\n\n\n
\n
<\/figure><\/div>\n\n\n<\/p>\n\n\n\n
Health Check<\/h5>\n\n\n\n Ma cosa succede se una regione ha interruzioni<\/strong> e diventa non pi\u00fa disponibile?<\/strong> <\/p>\n\n\n\nPer risolvere questo problema, abbiamo un’altra cosa importante da configurare:l’health chek<\/strong>. Grazie ad esso, Route53 sar\u00e1 in grado di instradare il traffico solo verso le regioni funzionanti. Nel nostro caso, poich\u00e9 stiamo usando API Gateway, possiamo usare i record alias<\/strong> che ci permettono di abilitare la funzione “Evaluate Target Health”. Con questo flag, Route53 effettua automaticamente un controllo di stato sui nostri servizi e capisce se il target sta funzionando correttamente. Questo check automatico non controlla i codici HTTP o altre metriche ma verifica semplicemente che il servizio sia raggiungibile entro pochi secondi. <\/p>\n\n\n\nSe abbiamo bisogno di usare metriche specifiche o non stiamo usando servizi compatibili con i record alias, possiamo creare i nostri controlli personalizzati. I Custom health checks<\/strong> possono verificare il codice HTTP di una specifica API o controllare una metrica specifica di Cloudwatch, permettendoci di personalizzare<\/strong> come Route53 dichiara un servizio funzionante.<\/p>\n\n\n\n<\/p>\n\n\n
\n
<\/figure><\/div>\n\n\n<\/p>\n\n\n\n
A questo punto, siamo riusciti con successo a configurare la nostra infrastruttura iniziale in una soluzione multi-region active-active.<\/p>\n\n\n\n
Tutto funziona come previsto, ma le lamentele degli utenti sono dietro l’angolo. <\/p>\n\n\n\n
Le prestazioni sono cruciali: dobbiamo migliorare l’esperienza degli utenti memorizzando nella cache i risultati delle nostre API in lettura.<\/p>\n\n\n\n
Cache Globale<\/h2>\n\n\n\n Tipicamente, con API Gateway possiamo configurare una cache che utilizza istanze per memorizzare automaticamente i dati delle API GET. Questo tipo di configurazione ha costi aggiuntivi addebitati in base alle ore di utilizzo e alla dimensione dell’istanza selezionata. In una soluzione multi-region, questo significa costi pi\u00f9 alti.<\/p>\n\n\n\n
Una semplice soluzione a questo problema \u00e8 usare Amazon Cloudfront come sistema di cache davanti alla nostra infrastruttura multi-region.<\/p>\n\n\n\n
Immaginiamo di voler esporre le nostre API utilizzando il dominio “api.example.com”. Possiamo creare la nostra distribuzione Cloudfront e configurarla per memorizzare nella cache tutti gli endpoint GET. In base ai vincoli della nostra applicazione, possiamo configurare il Time To Live della nostra cache per scadere:<\/p>\n\n\n\n
\ndopo un certo tempo: i dati verranno automaticamente eliminati dalla cache dopo il tempo configurato.<\/li>\n\n\n\n mai: possiamo modificare il nostro codice backend per creare una richiesta di invalidazione della cache di CloudFront sul percorso appropriato solo quando i dati cambiano.<\/li>\n<\/ul>\n\n\n\nPoi, come origine, useremo l’integrazione HTTP utilizzando il dominio “regional.example.com”, che \u00e8 collegato ai nostri ApiGateway con una delle configurazioni discusse in precedenza. E questo \u00e8 tutto. Ora, abbiamo un sistema di cache davanti alla nostra infrastruttura.<\/p>\n\n\n\n
Conclusioni<\/h2>\n\n\n\n In questo articolo, abbiamo visto quali passi dobbiamo compiere per trasformare una semplice soluzione che utilizza una singola Region, in una soluzione multi-region active-active.<\/p>\n\n\n\n
L’obiettivo non era solo mostrarvi come possiamo trasformare la nostra applicazione mono-region in una globalmente distribuita, ma anche farvi riflettere su quanti aspetti debbano essere presi in considerazione prima di iniziare a pensare a questo tipo di approccio. Un suggerimento \u00e8 pensarci prima dell’implementazione effettiva, cambiando il paradigma “from mono-region to multi-region” a “Go Global” direttamente.<\/p>\n\n\n\n
Specialmente in un mondo data-driven, essere sicuri che i nostri dati siani sempre aggiornati e accessibili, anche in caso di guasti a livello di region, \u00e8 una priorit\u00e0, sia per garantire continuit\u00e0 operativa, che per ottenere vantaggi competitivi.<\/p>\n\n\n\n
Ma c’\u00e8 molto altro da dire quando si parla del paradigma “Go Global”. Come menzionato nell’introduzione, durante l’implementazione possono verificarsi diversi problemi:<\/p>\n\n\n\n
\nCome risolviamo il problema dell’autenticazione?<\/li>\n\n\n\n Come monitoriamo la nostra soluzione globale?<\/li>\n\n\n\n Come centralizziamo i log?<\/li>\n<\/ul>\n\n\n\n…e molti altri che approfondiremo nei prossimi articoli.\u00a0\u00a0<\/p>\n\n\n\n
Quale argomento vorreste affrontare per primo? <\/p>\n\n\n\n
Faccelo sapere nei commenti!<\/p>\n\n\n\n
\n\n\n\nAbout Proud2beCloud<\/h4>\n\n\n\n Proud2beCloud \u00e8 il blog di beSharp<\/a>, APN Premier Consulting Partner italiano esperto nella progettazione, implementazione e gestione di infrastrutture Cloud complesse e servizi AWS avanzati. Prima di essere scrittori, siamo Solutions Architect che, dal 2007, lavorano quotidianamente con i servizi AWS. Siamo innovatori alla costante ricerca della soluzione pi\u00f9 all’avanguardia per noi e per i nostri clienti. Su Proud2beCloud condividiamo regolarmente i nostri migliori spunti con chi come noi, per lavoro o per passione, lavora con il Cloud di AWS. Partecipa alla discussione!<\/p>\n","protected":false},"excerpt":{"rendered":"Introduzione Per fare la differenza nel mercato competitivo odierno, avere un servizio sempre disponibile \u00e8 un aspetto imprescindibile.\u00a0 Mentre progettare […]<\/p>\n","protected":false},"author":11,"featured_media":7113,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[481],"tags":[325,670,697],"class_list":["post-7108","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-architecting","tag-amazon-cognito","tag-high-availability-ha-it","tag-multi-region-deployment-it"],"yoast_head":"\n
Multi-Region Deployment: cosa sapere per migliorare affidabilit\u00e0, disponibilit\u00e0 e sicurezza delle applicazioni - Proud2beCloud Blog<\/title>\n \n \n \n \n \n \n \n \n \n \n \n \n\t \n\t \n\t \n \n \n \n \n \n \n\t \n\t \n\t \n