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

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

Con 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

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