{"id":5773,"date":"2023-04-14T09:00:00","date_gmt":"2023-04-14T07:00:00","guid":{"rendered":"https:\/\/blog.besharp.it\/?p=5773"},"modified":"2023-04-13T16:29:11","modified_gmt":"2023-04-13T14:29:11","slug":"come-trasmettere-in-maniera-efficiente-eventi-dml-su-aws","status":"publish","type":"post","link":"https:\/\/blog.besharp.it\/it\/come-trasmettere-in-maniera-efficiente-eventi-dml-su-aws\/","title":{"rendered":"Come trasmettere in maniera efficiente eventi DML su AWS"},"content":{"rendered":"\n
In passato, molti workload disponevano di un proprio database grande e monolitico, a cui non solo l’applicazione, ma anche gli strumenti di reporting e il supporto tecnico si collegavano per eseguire query. <\/p>\n\n\n\n
Sebbene questo sia vero ancora oggi, le aziende si stanno sempre pi\u00f9 muovendo verso l’archiviazione delle singole informazioni su pi\u00f9 data source e server. Una buona prassi prevede che solo l’applicazione principale sia in grado di accedere al database, gli strumenti di reporting utilizzino i dati archiviati su un’istanza separata e il monitoraggio e l’analisi dei dati siano eseguiti aggregando i dati provenienti da fonti diverse.<\/p>\n\n\n\n
Per far ci\u00f2, abbiamo bisogno di trasmettere le modifiche che si verificano sul nostro database verso una o pi\u00f9 destinazioni. Oggi daremo un’occhiata a come farlo su AWS.<\/p>\n\n\n\n
AWS Database Migration Service (DMS)<\/strong> \u00e8 un potente strumento per la migrazione dei dati tra varie piattaforme di database. Una delle caratteristiche distintive di AWS DMS \u00e8 la sua funzionalit\u00e0 Change Data Capture (CDC), che consente lo streaming in tempo reale delle modifiche apportate a un database di origine verso un database di destinazione<\/strong>.<\/p>\n\n\n\n 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 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 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 <\/p>\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 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 <\/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 Ora 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 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 <\/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 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 <\/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 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\n
Setup di una soluzione di streaming di eventi DML su AWS<\/h2>\n\n\n\n
<\/figure><\/div>\n\n\n
L\u2019ingestion<\/h3>\n\n\n\n
\n
<\/figure><\/div>\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\n
L\u2019elaborazione<\/h3>\n\n\n\n
<\/figure><\/div>\n\n\n
\n
<\/figure><\/div>\n\n\n
Possibili criticit\u00e0<\/h3>\n\n\n\n