{"id":7108,"date":"2024-07-03T16:07:26","date_gmt":"2024-07-03T14:07:26","guid":{"rendered":"https:\/\/blog.besharp.it\/?p=7108"},"modified":"2024-07-03T16:08:05","modified_gmt":"2024-07-03T14:08:05","slug":"multi-region-deployment-cosa-sapere-per-migliorare-affidabilita-disponibilita-e-sicurezza-delle-applicazioni","status":"publish","type":"post","link":"https:\/\/blog.besharp.it\/it\/multi-region-deployment-cosa-sapere-per-migliorare-affidabilita-disponibilita-e-sicurezza-delle-applicazioni\/","title":{"rendered":"Multi-Region Deployment: cosa sapere per migliorare affidabilit\u00e0, disponibilit\u00e0 e sicurezza delle applicazioni"},"content":{"rendered":"\n

Introduzione<\/h2>\n\n\n\n

Per fare la differenza nel mercato competitivo odierno, avere un servizio sempre disponibile<\/strong> \u00e8 un aspetto imprescindibile.\u00a0<\/p>\n\n\n\n

Mentre progettare infrastrutture in alta affidabilit\u00e0 \u00e8 ormai una best practice, l\u2019approccio Multi-Region resta una strada relativamente poco battuta a causa di alcune complessit\u00e0 che la sua implementazione comporta.<\/p>\n\n\n\n

Una strategia mutli-region richiede una pianificazione attenta che deve tenerer conto di moltissimi fattori.  Lo scenario si complica ulteriormente nel caso di progetti data-driven in cui bisogna prestare particolare attenzione anche a tutti gli aspetti infrastrutturali legati al dato: dal trasferimento, alla gestione, fino all\u2019archivio  e all\u2019integrit\u00e0 delle informazioni.<\/p>\n\n\n\n

I vantaggi offerti da un approccio multi-region sono moltissimi: distribuendo i dati su diverse posizioni geografiche le applicazioni possono resistere a interruzioni a livello di Region assicurando cos\u00ec integrit\u00e0 del servizio e continuit\u00e0 operativa<\/strong>.\u00a0<\/p>\n\n\n\n

Ma non solo: i benefici vanno oltre alta disponibilit\u00e0, RTO\/RPO e resielineza: progettare in Multi-region permette di supportare anche la scalabilit\u00e0 globale<\/strong>, consentendo alle applicazioni di servire una base di utenti mondiale con latenza ridotta e prestazioni superiori.<\/p>\n\n\n\n

In questo articolo, forniremo una panoramica completa su questo approccio: partiremo dai PRO e i CONTRO di questa strategia e daremo uno sguardo agli aspetti da curare durante l’implementazione, con particolare attenzione ai database e, in generale, a tutti gli aspetti legati al dato.\u00a0<\/p>\n\n\n\n

Cominciamo!<\/p>\n\n\n\n

Quando Serverless e Servizi Gestiti non sono abbastanza<\/h2>\n\n\n\n

Tipicamente, quando iniziamo un nuovo progetto, cerchiamo di utilizzare solo servizi serverless o gestiti (come AWS Lambda, Amazon APIGateway, Amazon DynamoDB, Amazon Cognito, Amazon SQS e tutti i numerosi servizi gestiti di AWS) pensando di ottenere automaticamente tolleranza ai guasti e alta disponibilit\u00e0.<\/p>\n\n\n\n

E questo \u00e8 vero; utilizzare servizi serverless ci consente di sfruttare tutte le zone di disponibilit\u00e0 in una regione, rendendo la nostra applicazione resistente ai fallimenti dei singoli data center.<\/p>\n\n\n\n

Ma cosa succede se un’intera regione o, pi\u00f9 realisticamente, un servizio in tutta la regione, smette di funzionare?<\/p>\n\n\n\n

Come possiamo vedere da questo sito<\/a> che registra tutte le interruzioni dei servizi AWS<\/strong> negli ultimi anni, i fallimenti di una regione<\/strong>, sebbene molto rari, possono accadere.<\/p>\n\n\n\n

Come Solutions Architect, il nostro compito \u00e8 progettare soluzioni altamente disponibili in termini di zone di disponibilit\u00e0 e creare infrastrutture che resistano<\/strong> ai guasti delle regioni.<\/p>\n\n\n\n

Questo 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\n

E 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\n

Prendiamo 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\n

Sfortunatamente, 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\n

E per quanto riguarda il logging e il monitoring<\/strong>? <\/p>\n\n\n\n

In 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