În ziua de azi, din ce în ce mai multe proiecte software aleg să se folosească de platforme publice de cloud. Fie că vorbim de Azure, AWS sau Google Cloud, impactul serviciilor oferite de aceste platforme poate schimba fundamental modul în care sistemele software sunt concepute și folosite. În ceea ce urmează, vom exemplifica acest aspect plecând de la un scenariu întâlnit într-unul dintre proiectele noastre.
Odată cu migrarea în AWS a unui produs existent, bazat pe o arhitectură de micro servicii clasică, găzduit și operat într-un centru de date local, am avut și cerința suplimentară de a stoca și agrega cererile utilizatorilor de căutare a unor puncte de interes, localizate pe hartă - restaurante, hoteluri, benzinării sau alte astfel de obiective. Aceste date urmau să fie folosite ulterior la construirea unui istoric personalizat și prioritizat în funcție de numărul cereri pentru anumite locații sau tipuri de obiective de interes pentru fiecare utilizator în parte.
Destul de frecvent, în proiecte care se bazează pe REST APIs, implementate prin micro servicii, întâlnim situații în care datele stocate recurent în baze de date RDBMS necesită o prelucrare ulterioară înainte de a fi returnate către front-end. Acesta era și cazul nostru, însă această abordare tradițională poate implica și anumite dezavantaje, precum:
Construirea de interogări care să satisfacă cerințele de performanță chiar și la volume mari de date, dat fiind că într-un sistem productiv, volumul de date poate crește exponențial ;
Gestionarea comportamentului micro serviciilor în producție - load balancing, autoscaling, monitorizare;
Așa că, deși implementarea unei astfel de soluții nu presupune un grad de complexitate prea mare, operarea aplicației productive vine cu oarecare dificultăți și costuri adiționale.
Cu această migrare ne-am propus de asemenea să ne folosim de tehnologiile oferite de platforma cloud pentru a simplifica operarea produsului. Pentru noi, AWS DynamoDB și funcțiile lambda s-au dovedit a fi o abordare mai eficientă.
Mecanismul de Change Data Control (CDC) oferit de DynamoDB creează automat evenimente care capturează schimbările survenite pe fiecare înregistrare din tabela DynamoDB asociată, fie că este vorba de introducerea unei înregistrări noi, modificarea sau ștergerea unei înregistrări existente. Aceste evenimente pot fi publicate automat pe un DynamoDB stream, sau pe un Kinesis stream; chiar mai mult, evenimentele pot fi publicate pe ambele streamuri în paralel.
Așa că pentru a stoca interacțiunile utilizatorilor ne-am folosit de o tabelă DynamoDB definită astfel:
Partition key: customer_id
Sort key: last_interaction_time
Fiecare acțiune a unui utilizator, odată stocată în această tabelă, va genera un eveniment în DynamoDB stream, unde un subscriber configurat în prealabil va invoca o funcție lambda ce implementează mecanismul de agregare și stochează datele finale agregate într-o altă tabelă DynamoDB.
Partition key: customer_id
Sort key: action_string_hash
Această soluție de tip serverless a simplificat considerabil gestionarea aplicației în producție. Spre deosebire de RDBMS-urile tradiționale, AWS DynamoDB este un produs 'fully managed' de către AWS, iar din punct de vedere al performanței, prin eliminarea nevoii de interogări complexe datorită implementării logicii de agregare într-o funcție lambda, extragerea datelor din tabela finală a devenit extrem de rapidă.
DynamoDB și funcțiile lambda vor scala automat în momentul creșterii semnificative a traficului, fără să trebuiască să gestionăm explicit nimic legat de load balancing sau autoscaling. Totuși, există o limitare (throttling) din motive de cost, aceasta este dată de capacitatea de scriere sau citire rezervată - Read Capacity Units și Write Capacity Units definite pentru conexiunea aplicației la instanța de DynamoDB. În momentul depășirii acestei limitări, apelurile suplimentare vor fi respinse, rezultând în final în erori HTTP 429 (Too many requests) către aplicație.
Fiecare tabelă DynamoDB poate avea configurat, de asemenea, un TTL ('time to live') pentru înregistrările stocate; prin urmare, acestea vor fi șterse automat la expirarea acestui time to live, fără costuri adiționale și fără să fie necesară implementarea explicită a unui mecanism de ștergere a datelor.
Dar un potențial dezavantaj al acestei soluții este faptul că posibile nevoi de analiză ale datelor ulterioare nu vor putea fi satisfăcute; o soluție de stocare key-value store precum DynamoDB nefiind prea flexibilă în ceea ce privește construirea de rapoarte și analize ale datelor. Totuși, această limitare este compensată de posibilitatea de a exporta datele în S3 sau chiar de a activa în paralel transmiterea evenimentelor de Change Data Control pe un Kinesis stream, de unde pot fi analizate cu Amazon Athena sau propagate într-o bază de date specializată pentru nevoi de analiză a datelor, cum ar fi Amazon Redshift.
AWS DynamoDB și evenimentele de Change Data Control nu reprezintă în niciun caz o soluție universală pentru orice tip de problemă de genul celei întâlnite de noi, însă cu siguranță această abordare merită luată în considerare, din moment ce poate aduce avantaje importante care se pot dovedi decisive în alegerea soluției potrivite.
de Ovidiu Mățan
