{"id":7601,"date":"2025-01-29T15:41:03","date_gmt":"2025-01-29T14:41:03","guid":{"rendered":"https:\/\/blog.besharp.it\/?p=7601"},"modified":"2025-01-29T15:09:40","modified_gmt":"2025-01-29T14:09:40","slug":"managed-databases-su-aws-scegliere-il-servizio-perfetto-per-soddisfare-requisiti-di-alta-disponibilita-disaster-recovery-e-scalabilita","status":"publish","type":"post","link":"https:\/\/blog.besharp.it\/it\/managed-databases-su-aws-scegliere-il-servizio-perfetto-per-soddisfare-requisiti-di-alta-disponibilita-disaster-recovery-e-scalabilita\/","title":{"rendered":"Managed databases su AWS: scegliere il servizio perfetto per soddisfare requisiti di Alta Disponibilit\u00e0, Disaster Recovery e Scalabilit\u00e0"},"content":{"rendered":"\n

“Quando non hai nulla, non hai nulla da perdere” <\/em><\/p>\n\n\n\n

Bob Dylan, Like a Rolling Stone<\/p>\n\n\n\n

Se ci pensiamo bene, questa citazione ha un fondo di verit\u00e0; abbiamo sempre qualcosa su cui contare: le nostre abilit\u00e0, la nostra esperienza e, ovviamente, i dati. Nessuno pu\u00f2 portarci via le nostre competenze e la nostra esperienza, ma i dati possono sparire in tanti modi e trovare la soluzione giusta per minimizzare la marea di problemi legati alla persistenza, alla disponibilit\u00e0 e alla scalabilit\u00e0 dell’archiviazione dei dati pu\u00f2 rivelarsi un vero rompicapo.<\/p>\n\n\n\n

Come sappiamo, AWS offre diversi tipi e varianti di servizi gestiti per i database; non \u00e8 per niente facile scegliere quello giusto che soddisfi le nostre esigenze senza aumentare i costi in bolletta con funzionalit\u00e0 non necessarie. <\/p>\n\n\n\n

Oggi faremo luce sulle differenze nelle declinazioni dei servizi database gestiti nel Cloud Amazon, offrendo una panoramica utile per decidere come e quando scegliere un servizio.<\/p>\n\n\n\n

Engine: Amazon RDS vs Amazon Aurora\u00a0<\/h2>\n\n\n\n

Il primo fattore di confusione quando ci si approccia ai servizi di database gestiti su AWS \u00e8 la differenza tra Amazon RDS (per MsSql, MySQL, PostgreSQL\u2026, ecc.) e Amazon Aurora (MySQL o PostgreSQL).<\/p>\n\n\n\n

Amazon RDS per\u2026 (scegli il tuo engine preferito)\u00a0<\/h4>\n\n\n\n

Quando scegliamo di avviare un’istanza RDS, dietro le quinte AWS far\u00e0 il deploy e configurer\u00e0 un’istanza compute con l\u2019engine scelto e la versione supportata corrispondente.<\/p>\n\n\n\n

\u00c8 possibile selezionare la capacit\u00e0 di calcolo e lo storage, che pu\u00f2 scalare automaticamente fino a raggiungere il limite massimo scelto. Allo stesso modo, possiamo scegliere di applicare in modo automatico le patch del sistema operativo e dell\u2019engine (ma solo le minori) durante una finestra di manutenzione personalizzabile. <\/p>\n\n\n\n

Per quanto riguarda gli aggiornamenti delle versioni principali dell\u2019engine, \u00e8 necessario invece pianificarne l\u2019applicazione. Attenzione: nel caso gli upgrade siano rimandati per un lungo tempo, rimarremo indietro rispetto alla matrice di versioni supportate ed entreremo nella fase di \u201csupporto esteso\u201d, con costi aggiuntivi.<\/p>\n\n\n\n

Avvertenze<\/strong>\u00a0<\/p>\n\n\n\n

Ecco un esempio pratico: se avessimo scelto di fare il deploy di un’istanza Amazon RDS per MySQL nell’ottobre 2022, avremmo ricevuto tutti gli aggiornamenti minori, se non avessimo applicato gli aggiornamenti delle versioni principali saremmo entrati nel supporto esteso il 29 febbraio 2024.<\/p>\n\n\n\n

Un altro punto di attenzione riguarda lo scaling dello storage: se viene raggiunto il limite superiore per lo storage allocato (anche con l’autoscaling), dovremo ridimensionarlo, provocando downtime. Inoltre, non \u00e8 possibile scalare facilmente verso il basso lo storage: \u00e8 infatti necessario un deployment blue\/green per questo tipo di operazione.<\/p>\n\n\n\n

Amazon RDS Custom\u00a0<\/h4>\n\n\n\n

RDS Custom permette di avere accesso al sistema operativo. Viene utilizzato solitamente quando si ha a che fare con applicazioni legacy e database engine Microsoft SQL Server o Oracle. In questo modo, si modifica lo shared responsibility model tipico di RDS, dove la manutenzione del sistema operativo sottostante \u00e8 a carico di AWS. Non tratteremo in dettaglio la sua architettura, ma \u00e8 un’opzione per questo scenario specifico.\u00a0Come sempre, raccomandiamo l’uso di servizi gestiti per ridurre lo sforzo operativo e concentrarci sul business. A questo indirizzo<\/a> sono disponibili pi\u00f9 informazioni sul modello di responsabilit\u00e0 condivisa per Amazon RDS Custom.<\/p>\n\n\n\n

Amazon Aurora\u00a0<\/h4>\n\n\n\n

Amazon Aurora \u00e8 un servizio gestito che separa l\u2019engine del database dallo storage. In questo modo possiamo preoccuparci meno di aspetti come la replica dello storage e il suo scaling. Come per RDS “tradizionale”, dobbiamo scegliere la dimensione della parte di compute, con un modello pay-as-you-go.<\/p>\n\n\n\n

Al deploy di un’istanza Amazon Aurora RDS non viene richiesta la dimensione dello storage, questo perch\u00e9 l’autoscaling dello spazio \u00e8 garantito da funzionalit\u00e0 aggiuntive. Lo storage viene anche replicato automaticamente su tre Availability Zone, con due copie per ogni zona, tollerando quindi la perdita di fino a due copie dei dati.<\/p>\n\n\n\n

In caso di fallimento di un’istanza, Amazon Aurora RDS tenter\u00e0 di auto-ripararsi riavviando i servizi rilevanti.<\/p>\n\n\n\n

Avvertenze<\/strong>\u00a0<\/p>\n\n\n\n

Dobbiamo tenere presente che una singola istanza tenter\u00e0 s\u00ec di auto-ripararsi, ma si verificher\u00e0 del downtime. Inoltre, le versioni dell\u2019engine Aurora sono leggermente diverse e non seguono il ciclo di rilascio standard.<\/p>\n\n\n\n

Nel caso in cui sia necessario utilizzare un insieme di funzionalit\u00e0 particolari (come MyISAM per MySQL), occorre verificare che siano supportate.<\/p>\n\n\n\n

Aurora Serverless<\/h4>\n\n\n\n

Aurora serverless spinge ulteriormente il disaccoppiamento fra storage e compute, containerizzando la parte computazionale per facilitare lo scaling. Facendo il deploy di Aurora in modalit\u00e0 serverless, invece di scegliere la dimensione CPU e Memoria, dobbiamo selezionare la dimensione minima e massima in termini di Aurora Capacity Units (ACU).<\/p>\n\n\n\n

Una ACU misura le risorse in termini di RAM, CPU e Networking; ogni ACU corrisponde a 2 GB di RAM e un valore proporzionale di CPU. Lavorare con le ACU permette di scalare “al volo” la potenza computazionale assegnata al database.<\/p>\n\n\n\n

Possiamo\u00a0 specificare i valori minimi e massimi (da 0,5 a 256 ACU) ed anche mettere automaticamente in pausa il database, in modo da non avere addebiti durante i periodi di inattivit\u00e0 (come nel caso di un cluster di sviluppo o a un workload\u00a0utilizzato solo durante l’orario lavorativo).<\/p>\n\n\n\n

Avvertenze<\/strong>\u00a0<\/p>\n\n\n\n

Dobbiamo tenere presente che, come per le istanze “tradizionali”, il numero di connessioni simultanee \u00e8 determinato dalla dimensione della memoria RAM assegnata al cluster. Quando configuriamo un’istanza serverless, il numero di connessioni simultanee \u00e8 determinato dal limite superiore delle ACU configurate. Se \u00e8 necessario aumentare il numero di connessioni, dobbiamo cambiare il numero massimo di ACU e riavviare l’istanza per applicare le modifiche.<\/p>\n\n\n\n

Alta Disponibilit\u00e0: Multi-AZ, read-replicas. Facciamo chiarezza!<\/h2>\n\n\n\n

Anche se la documentazione spiega chiaramente le singole funzionalit\u00e0, c\u2019\u00e8 sempre confusione riguardo le istanze RDS Multi-AZ, Cluster Multi-AZ e\u00a0 Read Replica Aurora. Affrontiamo questo problema!<\/p>\n\n\n\n

Prima di tutto, un’istanza Amazon RDS Multi-AZ<\/strong> \u00e8 una copia sincrona da un’istanza primaria a una replica standby. Non \u00e8 possibile\u00a0 utilizzare l’istanza standby per leggere dati o per alleggerire il carico dato dalle letture<\/strong>; \u00e8 disponibile solo come opzione di failover in caso di problemi o di manutenzione. In caso di failover, il ripristino avviene in 60 – 120 secondi.<\/p>\n\n\n\n

<\/p>\n\n\n

\n
\"\"
Source: https:\/\/docs.aws.amazon.com\/AmazonRDS\/latest\/UserGuide\/Concepts.MultiAZSingleStandby.html<\/figcaption><\/figure><\/div>\n\n\n


Possiamo poi creare cluster Amazon RDS Multi-AZ<\/strong>. In questo caso, la replica \u00e8 semi-sincrona<\/strong> e utilizza la replica nativa del database engine. Si possono avere fino a due istanze di sola lettura (read replica) <\/strong>accessibili per distribuire il carico dato dalle letture. Tuttavia, con questa configurazione, ci potrebbe essere un ritardo nella replica, ma di contro la latenza di scrittura \u00e8 inferiore rispetto a una istanza Multi-AZ. I failover vengono solitamente completati in meno di 35 secondi.<\/p>\n\n\n\n

<\/p>\n\n\n

\n
\"\"
Source: https:\/\/docs.aws.amazon.com\/AmazonRDS\/latest\/UserGuide\/multi-az-db-clusters-concepts.html<\/figcaption><\/figure><\/div>\n\n\n

Come abbiamo detto prima, quando si usa il motore Aurora<\/strong> i dati vengono replicati automaticamente su tre Availability Zone. Possiamo aggiungere fino a 15 read replica per scalare le letture. In caso di fallimento, il failover avviene in meno di 30 secondi. Dobbiamo tenere presente che con un cluster Aurora Multi-AZ, l\u2019applicazione deve utilizzare l\u2019endpoint del cluster, gestito e aggiornato da Aurora.<\/p>\n\n\n\n

<\/p>\n\n\n

\n
\"\"
Source: https:\/\/aws.amazon.com\/blogs\/database\/improve-application-availability-on-amazon-aurora\/<\/figcaption><\/figure><\/div>\n\n\n

Consigli e trucchi per ridurre il tempo di failover<\/h2>\n\n\n\n

Amazon RDS Proxy<\/strong> pu\u00f2 ridurre il tempo di failover in ogni caso preso in esame perch\u00e9 gestisce il pooling delle connessioni tra l\u2019applicazione l\u2019architettura database scelta. Inoltre, permette di ridurre il numero massimo di connessioni al database necessarie, alleviando cos\u00ec i picchi tipici dovuti alle applicazioni serverless. Dobbiamo tenere presente che Amazon RDS Proxy \u00e8 un servizio che pu\u00f2 influire sui costi!<\/p>\n\n\n\n

Disponibilit\u00e0 e scalabilit\u00e0 globale: Amazon Aurora Global Database vs Amazon Aurora Postgres Limitless vs Amazon Aurora Distributed SQL<\/h2>\n\n\n\n

Scopriamo ora le versioni di Aurora per quanto riguarda gli ambienti distribuiti. Queste implementazioni si concentrano su aspetti diversi, ma potrebbero generare confusione per le loro simitudini.<\/p>\n\n\n\n

Amazon Aurora Global Database<\/h4>\n\n\n\n

Amazon Aurora Global Database<\/strong> si concentra sulla resilienza<\/strong>: sfrutta infatti l’indipendenza tra i lo storage ed il compute per replicare i dati in una regione diversa. Quando si configura un’istanza Global Database, sar\u00e0 definito un cluster primario (contenente un’istanza reader ed una writer) e un cluster secondario contenente solo read replica.<\/p>\n\n\n\n

Il forwarding delle scritture (write forwarding<\/strong>) \u00e8 supportato, quindi se viene effettuata una scrittura utilizzando l’endpoint del cluster secondario, Aurora se ne occuper\u00e0 inoltrandola al cluster DB primario.\u00a0<\/p>\n\n\n\n

Se l\u2019applicazione \u00e8 sensibile alla latenza, dobbiamo tenere a mente che quando sono coinvolte lunghe distanze, la velocit\u00e0 della luce \u00e8 un limite fisico che non pu\u00f2 essere evitato (almeno al momento della stesura di questo articolo!).<\/p>\n\n\n\n

<\/p>\n\n\n

\n
\"\"
Source: https:\/\/docs.aws.amazon.com\/AmazonRDS\/latest\/AuroraUserGuide\/aurora-global-database.html<\/figcaption><\/figure><\/div>\n\n\n

Switchover, Managed Failover e Manual Failover: le differenze\u00a0<\/h4>\n\n\n\n

Quando si tratta di resilienza<\/strong>, ci sono diversi meccanismi che permettono di eseguire test, programmare la manutenzione e, naturalmente, avere una rete di sicurezza in caso di problemi.<\/p>\n\n\n\n

Con l\u2019operazione di switchover<\/strong>, tutto \u00e8 sotto controllo e i dati sono completamente replicati nel cluster secondario. Pertanto, l’RPO (Recovery Point Objective) \u00e8 zero, senza perdita di dati. Questa operazione aiuta a eseguire manutenzioni programmate, test di failover, rotazione di region o ripristino da uno scenario di disastro nella region originale.<\/p>\n\n\n\n

La seconda opzione disponibile \u00e8 il failover gestito (managed failover)<\/strong>. In caso di problemi a livello di region o servizio, un failover gestito aiuta a mantenere la business continuity, passando dal cluster primario a quello secondario senza attendere la sincronizzazione dei dati. Ci sar\u00e0 ovviamente perdita di dati, ma non verranno apportate modifiche alla topologia di replica (eccetto per lo switch di ruolo del cluster).<\/p>\n\n\n\n

Il failover manuale (manual failover)<\/strong> \u00e8 un’operazione critica; dobbiamo essere sicuri di quel che facciamo e capirne le implicazioni. Infatti, viene interrotta la replica del cluster esistente, passando ad un cluster standalone nella region secondaria e promuovendone una read replica a writer instance. Per ripristinare l\u2019architettura dovremo ricreare la topologia di replica aggiungendo una region secondaria: non sono disponibili opzioni automatiche per il failback.<\/p>\n\n\n\n

Consiglio bonus:<\/strong> se l\u2019RTO non \u00e8 molto vicino a zero, \u00e8 possibile ridurre i costi sfruttando la configurazione headless<\/strong>; una volta fatto il deploy del cluster in una region secondaria baster\u00e0 terminare la nuova istanza Aurora reader appena creata. La replica dei dati non si interromper\u00e0 e, avviando una nuova istanza nel cluster secondario, questa si avvier\u00e0 senza problemi.<\/p>\n\n\n\n

Amazon Aurora PostgreSQL Limitless Database\u00a0<\/h4>\n\n\n\n

Come suggerisce il nome, questa implementazione \u00e8 attualmente disponibile solo per la compatibilit\u00e0 con il motore PostgreSQL. Si concentra sulla scalabilit\u00e0<\/strong> utilizzando la tecnica dello sharding per distribuire i dati tra i nodi. Questo permette di scalare orizzontalmente, raggiungendo milioni di transazioni in scrittura e petabyte di dati.<\/p>\n\n\n\n

La sua architettura differisce leggermente dalle altre perch\u00e9, quando si fa sharding dei dati, occorre\u00a0 instradare le query ai nodi corretti per\u00a0 interrogare i dati. I nodi router possono ricevere query e inviarle allo nodo shard corretto. Questa scalabilit\u00e0 comporta un costo in termini di effort operativo: dobbiamo sapere come partizionare correttamente i dati e, poich\u00e9 sono partizionati, non vogliamo che si verifichi il fenomeno dello “hot shard” che riceve pi\u00f9 query rispetto agli altri.<\/p>\n\n\n\n

<\/p>\n\n\n

\n
\"\"<\/figure><\/div>\n\n\n

<\/p>\n\n\n\n

Dovremo anche gestire i nodi shard e monitorarne il carico utilizzando le metriche CloudWatch. Per gestire il carico \u00e8 possibile cambiare la capacit\u00e0 dei nodi shard, dividere gli shard in pi\u00f9 gruppi di shard (ma attenzione: non \u00e8 possibile unire gli shard) e aggiungere nodi router.<\/p>\n\n\n\n

Avvertenze<\/strong>\u00a0<\/p>\n\n\n\n

Come suggerisce il nome, non \u00e8 prevista la compatibilit\u00e0 con MySQL. Inoltre, Amazon Aurora PostgreSQL Limitless non \u00e8 disponibile in tutte le region e non \u00e8 possibile modificare le chiavi usate per lo shard (incluso il loro valore nelle righe delle tabelle); \u00e8 necessario eliminarle e ricrearle. A questo indirizzo<\/a> l\u2019elenco completo delle limitazioni. <\/p>\n\n\n\n

Infine, a questo indirizzo<\/a> sono contenute le limitazioni per le query di definizione e manipolazione dati (DDL e DML).<\/p>\n\n\n\n

Amazon Aurora Distributed SQL<\/h4>\n\n\n\n

Con il suo annuncio recente, Amazon Aurora Distributed SQL (DSQL) si concentra su resilienza e scalabilit\u00e0<\/strong>. \u00c8 un cluster HA multi-region active-active che scala automaticamente e con infrastruttura completamente gestita. Sebbene combini le funzionalit\u00e0 dei cluster Global e Limitless, al momento della stesura di questo articolo ha molte limitazioni. Attualmente \u00e8 in anteprima solo in region selezionate. Diventer\u00e0 pi\u00f9 ricco di funzionalit\u00e0 in futuro e, per alcuni casi d’uso, potrebbe essere sufficiente per garantire la scalabilit\u00e0 e resilienza dell’applicazione senza ulteriore effort operativo.<\/p>\n\n\n\n

Limitazioni di Aurora Distributed SQL\u00a0<\/h4>\n\n\n\n

Attualmente, \u00e8 disponibile solo PostgreSQL e ci sono limitazioni su oggetti disponibili e query. \u00c8 possibile avere solamente un singolo database per cluster senza viste, trigger, tabelle temporanee o sequence. Le chiavi esterne non sono supportate e non \u00e8 possibile eseguire TRUNCATE, VACUUM o creare funzioni utilizzando plpgsql (o qualsiasi altro linguaggio diverso da SQL standard). <\/p>\n\n\n\n

Sebbene supporti operazioni ACID, le transazioni non possono avere operazioni DDL e DML miste e possono contenere al massimo una dichiarazione DDL.<\/p>\n\n\n\n

TL;DR <\/h2>\n\n\n\n