Cât de rapid este "destul de rapid"? În lumea serverless, unde fiecare milisecundă se poate traduce în costuri generate, optimizarea funcțiilor AWS Lambda devine o provocare tentantă. De unde putem totuși trage linia între eficiență și efort inutil? Cât de mult putem întinde raportul cost-performanță, până nu mai este benefic?
Ultimii ani au însemnat o tranziție în ceea ce privește arhitecturile sistemelor de zi cu zi. Migrarea continuă de la monolit către micro servicii a dus la crearea paradigmei FaaS (eng. Function as a Service). Aceasta vine cu beneficii de costuri, performanță, flexibilitate, oferind soluții pentru scrierea și executarea funcțiilor independente în medii create la cerere. Astfel, taxarea apare dinamic, doar în momentul folosirii resurselor, iar timpul și nevoia de gestionare a memoriei și mediului de rulare trece de la dezvoltator, la furnizorul de Cloud (Google, Microsoft, Amazon).
Deși vin cu o multitudine de soluții și beneficii, funcțiile serverless aduc cu sine o serie de provocări și limitări în runtime: cold starturile cauzate de inițierea instanței, încărcarea codului și a dependințelor, precum și overheadul introducerii mediilor de execuție (ex. în cazul Java și JVM). Dimensiunea executabilelor, frameworkurile utilizate, operațiile I/E sau asincrone afectează direct timpul de răspuns și comportamentul acestora.
Migrarea codului în Cloud introduce fenomenul de "cold start" (inițializarea mediului de execuție, ce adaugă latență, dar nu și costuri) și "warm start" (reutilizarea mediului pentru o execuție mai rapidă). O funcție des utilizată în producție poate nu experimentează frecvent cold starturi, însă acest lucru se schimbă în mediile de dezvoltare, unde accesul funcțiilor nu este la fel de frecvent. Optimizarea funcțiilor și frecvenței de invocare pot reduce impactul cold starturilor semnificativ.
În funcție de limbajul de scriere și compilatorul folosit pentru funcții influențează direct posibilitățile de îmbunătățire. Vom discuta în acest articol funcții lambda din AWS, scrise în NodeJS și Java. Există metode specifice cât și comune de eficientizare a execuției, precum creșterea memoriei alocate, utilizarea unui număr redus de librarii și dependințe, cât și folosirea contextului funcției lambda pentru stocarea variabilelor de inițializare.
Sursa - https://aws.amazon.com/blogs/compute/operating-lambda-performance-optimization-part-1/
Un prim pas esențial pentru optimizarea performanței unei funcții lambda constă în creșterea memoriei (în special CPU) alocate acesteia. Această ajustare sporește resursele de procesare asociate, având un impact direct asupra timpului de execuție.
Vom analiza diverse metode de optimizare a unei funcții lambda scrise în TypeScript, compilate în NodeJS 20, care generează un fișier PDF pe baza a 50 de utilizatori dintr-o bază de date DynamoDB. Compilând codul, vom examina modul în care memoria alocată influențează timpul de execuție în 25 invocări diferite al funcției (fără sa ținem cont de cold start).
Figura 1
Un aspect esențial de evidențiat în aceasta situație este costul final. În contextul AWS, funcțiile Lambda sunt influențate de doi factori principali: memoria alocată și durata execuției. Există adesea o percepție greșită conform căreia alocarea unei cantități mari de memorie implică automat costuri mai ridicate, ceea ce face această soluție neviabilă. Totuși, această idee este eronată, cel puțin până la un anumit punct. Creșterea memoriei poate reduce semnificativ timpul de execuție al funcției Lambda, ceea ce, în anumite cazuri, poate duce la scăderea costurilor totale. După cum am menționat anterior, această abordare funcționează doar în limite rezonabile. Dincolo de un anumit prag, o memorie suplimentară nu mai aduce îmbunătățiri semnificative ale performanței. Prin urmare, cheia constă în identificarea unui echilibru optim.
Tabel - Metode de eficientizare specifice limbajelor
De exemplu, în Figura 1 este ilustrată o funcție Lambda rulată de 24 (ignorăm cold startul) de ori, utilizând configurații diferite de memorie. Deși memoria a fost mărită de patru ori (de la 512MB la 2048MB), timpul de execuție s-a redus de peste patru ori. Astfel, pentru un cost similar, sau chiar mai mic, obținem o funcție de patru ori mai eficientă. Putem merge și mai departe. Creștem memoria funcției la 8192MB, chiar la 10240MB. Deși este un salt de patru, respectiv cinci ori mai mare, observăm că îmbunătățirile aduse funcției ca timp de rulare nu sunt proporționale, însă costurile au crescut semnificativ. Cu atât mai mult, diferența între cele două praguri este aproape neglijabilă.
Figura 2
Așadar, creșterea memoriei alocate poate îmbunătăți timpul de răspuns pentru funcțiile Lambda până într-un anumit punct, în care raportul costuri-performanță nu mai este rentabil, iar îmbunătățirile devin marginale. În funcție de contextul proiectului și cerințele acestuia, poate exista necesitatea unor timpi de răspuns mai reduși.
Putem identifica astfel metode suplimentare de optimizare. De exemplu, utilizarea esbuild (bundler rapid și eficient, ce compilează codul doar cu metodele folosite și necesare) reduce timpul de rulare, dar și de încărcare al funcției. Vom rula următoarea comandă pentru compilare:
esbuild ./ --entry-names=[dir]/index --bundle
--minify --platform=node -- target=node20 --outdir=dist .În plus, evitarea inițializării repetate a variabilelor prin folosirea contextului funcției poate contribui la reducerea timpului de execuție. Aceste aspecte pot fi observate mai clar în graficul anterior (Figura 2), în care cold startul este direct influențat de dimensiunea codului final compilat.
Figura 3
Pentru a optimiza timpii de rulare ai funcțiilor Lambda, am eliminat dependințele inutile din codul compilat final, păstrând doar cele strict necesare.
Un pas adițional în această direcție constă în modificarea codului sursă, pentru a preveni reinițializarea memoriei între invocările succesive ale funcției. De exemplu, în cazul inițializării unei conexiuni la baza de date, a variabilelor utilizate pentru accesul la Parameter Store, sau a altor resurse dinamice, aceasta poate fi extrasă în afara funcției handler, permițând reutilizarea acestora între execuții. După cum se observă în Figura 3, această abordare reduce timpul de execuție pentru rulările consecutive ale aceluiași cod, contribuind astfel la scăderea timpului total taxat.
Optimizarea funcțiilor Lambda nu doar că reduce costurile și timpii de execuție, dar contribuie și la o utilizare mai eficientă a resurselor disponibile. Alegerea soluțiilor potrivite trebuie să fie ghidată de cerințele specifice ale aplicației, asigurând în același timp un echilibru între performanță și costuri.
Design and human touch
Joi, 19 Iunie, ora 18:00
msg systems Romania
Facebook Meetup StreamEvent YouTubede Ovidiu Mățan
de Ovidiu Mățan
