Utilizzando AWS DMS, hai la possibilit\u00e0 di collegare un database di destinazione direttamente come endpoint, oppure di utilizzare Amazon Kinesis Data Streams per acquisire ed elaborare i dati in streaming.<\/p>\n\n\n\n
Ecco alcune differenze tra i due approcci:<\/p>\n\n\n\n
- \n
- Latenza: durante lo streaming dei dati direttamente a un database di destinazione, potrebbe esserci una certa latenza nell’elaborazione e nella scrittura dei dati. Con Kinesis Data Streams, i dati vengono acquisiti ed elaborati in tempo reale, senza ritardi nell’elaborazione.<\/li>\n\n\n\n
- Scalabilit\u00e0: Kinesis Data Streams \u00e8 progettato per gestire grandi volumi di dati in streaming e pu\u00f2 essere ridimensionato automaticamente per adattarsi all’aumento del traffico. Quando si effettua lo streaming dei dati direttamente in un database di destinazione, potrebbe essere necessario ridimensionare manualmente il database per gestire i picchi di traffico.<\/li>\n\n\n\n
- Flessibilit\u00e0: con Kinesis Data Streams puoi facilmente elaborare e analizzare i dati in streaming utilizzando vari servizi AWS, come AWS Glue o AWS Lambda. Durante lo streaming dei dati direttamente in un database di destinazione, potresti avere opzioni limitate per l’elaborazione e l’analisi dei dati.<\/li>\n\n\n\n
- Costo: l’utilizzo di Kinesis Data Streams pu\u00f2 comportare costi aggiuntivi per l’elaborazione e l’archiviazione dei dati in streaming, nonch\u00e9 eventuali servizi AWS associati utilizzati per l’elaborazione e l’analisi. Lo streaming di dati direttamente a un database di destinazione potrebbe non comportare costi aggiuntivi, ma potrebbe essere necessario considerare il costo del ridimensionamento del database per gestire l’aumento del traffico.<\/li>\n<\/ol>\n\n\n\n
Nel complesso, entrambi gli approcci presentano vantaggi e svantaggi e la scelta migliore dipende dal caso d’uso e dai requisiti specifici. <\/p>\n\n\n\n
In questo articolo esploreremo la possibilit\u00e0 di elaborare eventi di inserimento\/aggiornamento\/eliminazione real-time con l’aiuto di Amazon Kinesis Data Streams.<\/p>\n\n\n\n
Setup di una soluzione di streaming di eventi DML su AWS<\/h2>\n\n\n\n
Creiamo un proof of concept per testare la soluzione di streaming CDC con DMS e Kinesis Data Streams. L’idea \u00e8 avere un processo automatizzato che ci offra un modo semplice per replicare le modifiche che si verificano su un database di origine su uno o pi\u00f9 motori di destinazione<\/strong>. <\/p>\n\n\n\n
Questo \u00e8 un diagramma di ci\u00f2 che costruiremo:<\/p>\n\n\n\n
<\/p>\n\n\n
\n![\"\"](\"https:\/\/blog.besharp.it\/wp-content\/uploads\/2023\/04\/image3-1024x576.png\")
<\/figure><\/div>\n\n\n<\/p>\n\n\n\n
L\u2019ingestion<\/h3>\n\n\n\n
La prima cosa che dobbiamo fare, se vogliamo abilitare CDC, \u00e8 configurare il nostro database di origine<\/strong> per rendere disponibili tutte le informazioni necessarie al DMS per catturare nuovi eventi. Per molti engine, questo significa eseguire una serie di query che sono ben descritte nella documentazione ufficiale di AWS<\/a>. <\/p>\n\n\n\n
Dopo aver configurato il database di origine, creiamo il nostro Kinesis Data Stream<\/strong>. <\/p>\n\n\n\n
Questo passaggio \u00e8 piuttosto semplice; per richiedere la creazione sono richiesti pochi parametri. In particolare, dobbiamo solo decidere quale sar\u00e0 la modalit\u00e0 di scaling del nostro data stream:<\/p>\n\n\n\n
- \n
- Scegliendo l’on-demand delegheremo le operazioni di scaling ad AWS.<\/li>\n\n\n\n
- Scegliendo \u201cprovisioned\u201d sar\u00e0 necessario fornire il numero di shard<\/strong> (ovvero il throughput di lettura e scrittura) che rappresenta la dimensione del nostro stream.<\/li>\n<\/ol>\n\n\n\n
Nel mio caso ho scelto l’opzione on-demand. Tieni a mente il concetto di sharding, torner\u00e0 pi\u00f9 avanti in questo articolo.<\/p>\n\n\n\n
Ora che abbiamo configurato i sistemi di origine e di destinazione, dobbiamo creare su AWS DMS l’istanza e gli endpoint<\/strong>, che sono fondamentalmente un insieme di configurazioni che il servizio utilizza per interagire con i vari sistemi.<\/p>\n\n\n\n
La configurazione di un endpoint DMS \u00e8 davvero semplice: prima devi scegliere se stai creando un endpoint di origine o di destinazione, quindi specifichi il tipo di engine a cui l’endpoint \u00e8 connesso e, infine, a seconda dell\u2019engine selezionato, devi fornire alcuni parametri che consentono di configurare la connessione. <\/p>\n\n\n\n
Ecco un esempio del form di creazione per l’endpoint Kinesis Data Stream:<\/p>\n\n\n\n
<\/p>\n\n\n
\n![\"\"](\"https:\/\/blog.besharp.it\/wp-content\/uploads\/2023\/04\/image4.png\")
<\/figure><\/div>\n\n\n<\/p>\n\n\n\n
AWS DMS richiede un ruolo IAM per poter interagire con Kinesis. Questo ruolo dovrebbe avere almeno queste autorizzazioni:<\/p>\n\n\n\n
{\n\t\"Version\": \"2012-10-17\",\n\t\"Statement\": [\n \t\t{\n \t\t \t\"Action\": [\n \t\t\t \t\"kinesis:PutRecord\",\n \t\t\t \t\"kinesis:PutRecords\",\n \t\t\t \t\"kinesis:DescribeStream\"\n \t\t\t],\n \t\t\t\"Resource\": [\n \t\t\t\t\"<your delivery stream arn>\"\n \t\t\t],\n\t\t \t\"Effect\": \"Allow\"\n \t\t}\n\t]\n}<\/code><\/pre>\n\n\n\nOra l’ultima risorsa da creare<\/strong> sulla console AWS DMS \u00e8 il task effettivo che si occuper\u00e0 di copiare i dati dalla nostra origine a Kinesis<\/strong>. <\/p>\n\n\n\n
Scegli l’istanza di replica DMS in cui desideri creare il tuo task, seleziona gli endpoint creati in precedenza e configura il tipo di migrazione che desideri eseguire: puoi avere una migrazione che acquisisce uno snapshot dei dati archiviati sul motore di origine, oppure \u00e8 possibile abilitare la Change Data Capture in modo che i nuovi eventi vengano replicati automaticamente nel motore di destinazione. Oppure entrambe le cose.<\/p>\n\n\n\n
I replication task hanno tonnellate di parametri di configurazione che puoi modificare per aumentare l’efficienza, la stabilit\u00e0 e la velocit\u00e0, ma non \u00e8 questo l\u2019articolo in cui andremo ad approfondirli. Per questa POC non \u00e8 stato necessario cambiare nulla e tutti i parametri sono stati lasciati al loro valore di default.<\/p>\n\n\n\n
La creazione dell’attivit\u00e0 richieder\u00e0 alcuni minuti. Nel frattempo possiamo concentrarci sulla creazione delle risorse per…<\/p>\n\n\n\n
L\u2019elaborazione<\/h3>\n\n\n\n
Nel diagramma dell’architettura ho inserito AWS Glue come servizio di elaborazione. AWS Glue si integra nativamente con molti data warehouse e d\u00e0 la possibilit\u00e0 di elaborare grandi dataset grazie a Spark. Inoltre, i Glue Job possono essere configurati in modalit\u00e0 streaming, il che significa che sono sempre attivi ed elaborano i dati man mano che arrivano.<\/p>\n\n\n\n
Qui puoi trovare un piccolo frammento di codice che pu\u00f2 essere una buona base di partenza per la creazione del job:<\/p>\n\n\n\n
<\/p>\n\n\n
\n![\"\"](\"https:\/\/blog.besharp.it\/wp-content\/uploads\/2023\/04\/image2-944x1024.png\")
<\/figure><\/div>\n\n\n<\/p>\n\n\n\n
Puoi copiare il codice dalla GitHub gist<\/a>.<\/p>\n\n\n\n
Questo codice crea sostanzialmente un collegamento tra il Glue Job e un Data Frame che ha come sorgente Kinesis Data Stream. Questo data frame verr\u00e0 aggiornato ogni 100 secondi e ogni sua nuova versione verr\u00e0 passata alla funzione process_batch<\/em>. Questa funzione si occupa dell\u2019elaborazione dei nuovi dati.<\/p>\n\n\n\n
Durante la creazione del Kinesis Data Frame, possiamo fornire una struttura dei dati in ingresso. Questo schema deve corrispondere al formato dei dati che DMS ci fornisce, che \u00e8 un JSON che contiene due chiavi:<\/p>\n\n\n\n
- \n
- data, un altro JSON che contiene i valori dei record creati\/aggiornati\/eliminati<\/li>\n\n\n\n
- metadata, sempre un JSON che contiene informazioni relative all\u2019evento come lo schema e il nome della tabella da cui \u00e8 scaturito l\u2019evento, la data in cui si \u00e8 verificato, …<\/li>\n<\/ul>\n\n\n\n
Come puoi vedere, ho fornito solo uno schema \u201cstrutturato\u201d per la parte dei metadati. Questo perch\u00e9 non possiamo conoscere il formato della chiave “data” prima di conoscere il nome dello schema e della tabella.<\/p>\n\n\n\n
Dopo aver avviato il nostro nuovo Glue job, dovremmo essere in grado di vedere alcuni log su CloudWatch simili a questi:<\/p>\n\n\n\n
<\/p>\n\n\n
\n![\"\"](\"https:\/\/blog.besharp.it\/wp-content\/uploads\/2023\/04\/image1-1024x375.png\")
<\/figure><\/div>\n\n\n<\/p>\n\n\n\n
Infine, volevo salvare gli eventi su S3 cos\u00ec come provengono da DMS, in maniera da poter decidere di tornare indietro e rielaborare tutto fino a un certo punto nel tempo. Fortunatamente disponiamo gi\u00e0 del nostro Data Stream su Kinesis e possiamo collegarvi pi\u00f9 consumer, dunque possiamo facilmente creare un Kinesis Firehose Delivery Stream per aggregare gli eventi e scaricarli su un bucket S3.<\/p>\n\n\n\n
Possibili criticit\u00e0<\/h3>\n\n\n\n
Quando abbiamo provato per la prima volta questa soluzione, ci siamo imbattuti in un problema di prestazioni legato alla scalabilit\u00e0 del nostro Data Stream: come abbiamo discusso in precedenza, Kinesis utilizza un concetto di shard<\/strong> come unit\u00e0 di misura dello scaling. Quando il producer produce un nuovo evento, deve fornire lo shard in cui deve andare l’evento o utilizzare un ID casuale per far decidere a Kinesis.<\/p>\n\n\n\n
DMS utilizza sempre lo stesso valore.<\/p>\n\n\n\n
In questo modo, utilizza sempre lo stesso shard, quindi anche avendo configurato la modalit\u00e0 di scaling del data stream come on-demand, non vi sar\u00e0 un\u2019effettiva scalabilit\u00e0 della soluzione a causa di DMS.<\/p>\n\n\n\n