Najbolji postupci za ponovnu upotrebu spremnika lambda AWS

Optimizacija toplih pokreta prilikom spajanja AWS Lambda na ostale usluge

AWS Lambda pruža veliku skalabilnost zahvaljujući tome što je bez servera i bez stanja stanja, omogućujući tako da se mnoge kopije lambda funkcije odmah rode (kako je ovdje opisano). Međutim, prilikom pisanja prijavnog koda vjerojatno ćete htjeti pristup nekim državnim podacima. To znači povezivanje s podatkovnom prodavaonicom poput RDS instance ili S3. Međutim, povezivanje s drugim uslugama AWS Lambda dodaje vrijeme vašem funkcijskom kodu. Moguće su i nuspojave od velike skalabilnosti, poput postizanja maksimalnog broja dopuštenih veza na RDS instancu. Jedna od mogućnosti da se tome suprotstavi je korištenje ponovne upotrebe spremnika u AWS Lambda kako bi se nastavila veza i smanjilo vrijeme rada lambde.

Ovdje su neki korisni dijagrami za objašnjenje životnog ciklusa zahtjeva lambda.

Sljedeće se događa tijekom hladnog pokretanja, kada se vaša funkcija prvi put poziva ili nakon razdoblja neaktivnosti:

  • Kôd i ovisnosti se preuzimaju.
  • Pokrenut je novi spremnik.
  • Runtime se pokreće.

Završna radnja je pokretanje koda, što se događa svaki put kada se aktivira lambda funkcija. Ako se spremnik ponovno upotrebljava za naknadni poziv lambda funkcije, možemo preskočiti na početak pokretanja koda. To se naziva topli početak i to je korak koji možemo optimizirati prilikom povezivanja s drugim uslugama definiranjem veze izvan opsega metode manipulatora.

Spajanje na druge AWS usluge tvrtke Lambda

Primjer: Spajanje na RDS instancu, AWS ikone dobivene odavde

Imamo osnovni i uobičajeni primjer kroz koji se krećemo - želimo se povezati s resursom spremnika kako bismo preuzeli podatke o obogaćivanju. U ovom primjeru, JSON korisni teret dolazi s ID-om i Lambda funkcija se povezuje na RDS instancu koja izvodi PostgreSQL kako bi pronašla odgovarajuće ime ID-a kako bismo mogli vratiti obogaćeni korisni teret. Budući da se lambda funkcija povezuje s RDS-om koji živi u VPC-u, lambda funkcija sada treba živjeti i u privatnoj podmreži. To dodaje nekoliko koraka hladnom startu - treba priključiti VPC elastično mrežno sučelje (ENI) (kao što je spomenuto u blogu Jeremyja Dalya, ovo dodaje vrijeme vašim hladnim startovima).

Napomena: mogli bismo izbjeći upotrebu VPC-a ako bismo umjesto RDS-a koristili pohranu ključa / vrijednosti s DynamoDB-om.

Prelazit ću preko dva rješenja ovog zadatka, prvo je moje 'naivno' rješenje, dok drugo rješenje optimizira za topla vremena početka korištenjem veze za naknadne prizive. Zatim ćemo usporediti izvedbu svakog rješenja.

Opcija 1 - Spajanje na RDS unutar alata za upravljanje

Ovaj primjer koda pokazuje kako se naivno mogu pristupiti ovom zadatku - veza s bazom podataka nalazi se unutar metode obrađivača. Postoji jednostavan odabir upita za dohvaćanje imena ID-a prije povratka korisnog tereta koji sada uključuje i ime.

Pogledajmo kako funkcionira ova opcija tijekom malog testa s pragom 2000 poziva s istodobnošću od 20. Minimalno trajanje je 18 ms s prosječno 51 ms i malo više od 1 sekunde (trajanje hladnog starta).

Trajanje lambda

Grafikon u nastavku pokazuje da postoji najveći broj osam veza s bazom podataka.

Broj veza s RDS bazom podataka u prozoru od 5 minuta.

Opcija 2 - Koristite globalnu vezu

Druga je mogućnost definirati vezu kao globalnu izvan metode obrade. Zatim unutar alata za obradu dodajemo ček da vidimo postoji li veza i povežemo se samo ako nema. To znači da se veza vrši samo jednom po spremniku. Postavljanje veze na ovaj način s uvjetnim mjestom znači da ne trebamo uspostavljati vezu ako to logika koda ne zahtijeva.

Više ne zatvaramo vezu s bazom podataka, tako da veza ostaje za naknadno pozivanje funkcije. Ponovna upotreba veze značajno smanjuje trajanje toplog pokretanja - prosječno trajanje je približno 3 puta brže, a minimalno 1 ms, a ne 18 ms.

Lambda Durations

Povezivanje s RDS instancom dugotrajan je zadatak, a ne mora se povezivati ​​za svaki poziv korisno za performanse. Prilikom povezivanja s bazom podataka pomoću jednostavnog upita baze podataka postižemo maksimalni broj veza baze podataka 20, što odgovara razini istodobnosti (napravili smo 20 istodobnih poziva 100 puta). Kad prestaje praćenje poziva, veze se postupno zatvaraju.

Sada kada je AWS povećao lambda trajanje dopuštenja na 15 minuta, to znači da bi veze s bazama podataka mogle trajati duže i mogli biste biti u opasnosti da dosegnete maksimalni broj RDS veza. Zadane maks. Veze mogu se prebrisati u postavkama grupe parametara RDS, iako bi povećavanje maksimalnog broja veza moglo rezultirati problemima s dodjelom memorije. Manje instance mogu imati zadanu vrijednost max_connections manju od 100. Pripazite na ta ograničenja i dodajte samo logiku aplikacije da biste se povezali s bazom podataka kada je to potrebno.

Korištenje globalne veze za druge zadatke

Lambda se povezuje na S3

Čest zadatak koji bismo možda trebali obaviti s Lambdom je pristup državnim podacima iz S3. Isječak koda ispod je AWS-ov nacrt Python Lambda Function - do kojeg se možete kretati tako da se prijavite na AWS konzolu i kliknete ovdje. U kodu možete vidjeti da je klijent S3 u potpunosti definiran izvan obrađivača kad se spremnik inicijalizira, dok je za primjer RDS-a postavljena globalna veza unutar alata. Oba pristupa će postaviti globalne varijable koje će im biti dostupne za naknadne prizive.

isječak koda s nacrtom kôda s3-get-object lambda https://console.aws.amazon.com/lambda/home?region=us-east-1#/create/new?bp=s3-get-object-python

Dešifriranje varijabli okruženja

Lambda konzola pruža vam mogućnost šifriranja vaših varijabli okoline radi dodatne sigurnosti. Sljedeći isječak koda AWS je pružio Java primjer pomoćne skripte za dešifriranje varijabli okoline iz funkcije Lambda. Možete se kretati do isječka koda slijedeći ovaj vodič (posebno korak 6). Budući da je DECRYPTED_KEY definirana kao globalna klasa, funkcija i logika decryptKey () poziva se samo jednom po lambda spremniku. Stoga ćemo vidjeti značajno poboljšanje u trajanju toplog starta.

https://console.aws.amazon.com/lambda/home?region=us-east-1#/functions i https://docs.aws.amazon.com/lambda/latest/dg/tutorial-env_console.html

Korištenje globalnih varijabli u drugim FaaS rješenjima

Ovaj pristup nije izoliran od AWS Lambda. Način korištenja globalne veze može se primijeniti i na funkcije bez poslužitelja drugih pružatelja usluga oblaka. Stranica savjeta i trikova Google Cloud Functions daje dobro objašnjenje ne-lijenih varijabli (kada se varijabla uvijek inicijalizira izvan metode obrađivača) nasuprot lijenim varijablama (globalna se varijabla postavlja samo kad je potrebno) globalnim varijablama.

Ostale najbolje prakse

Evo još nekoliko najboljih praksi kojih treba imati na umu.

Testiranje

Upotreba FaaS-a olakšava arhitekturu mikroservisa. A posjedovanje malih, diskretnih dijelova funkcionalnosti ide ruku pod ruku s učinkovitim testiranjem jedinica. Za pomoć testovima jedinice:

  • Ne zaboravite da iz paketa lambda izuzmete testne ovisnosti.
  • Logiku odvojite od metode obrađivača, kao što biste učinili s glavnom metodom programa.

Ovisnosti i veličina paketa

Smanjenje veličine paketa za implementaciju znači da će preuzimanje koda biti brže kod inicijalizacije, a time i poboljšati vaša hladna vremena. Uklonite neiskorištene biblioteke i mrtvi kôd da biste smanjili veličinu ZIP datoteke za implementaciju. AWS SDK predviđen je za Python i JavaScript vrijeme izvođenja, tako da ih nema potrebe uključuju u svoj paket za implementaciju.

Ako je Node.js vaše preferirano vrijeme rada Lambda, možete primijeniti modifikaciju i uglifikaciju kako biste smanjili veličinu funkcijskog koda i umanjili veličinu paketa za implementaciju. Neki, ali ne svi aspekti minimiziranja i uglifikacije, mogu se primijeniti na druge vremenske uvjete, npr. ne možete ukloniti bijeli prostor iz python koda, ali možete ukloniti komentare i skratiti imena varijabli.

Postavljanje memorije

Eksperimentirajte kako biste pronašli optimalnu količinu memorije za Lambda funkciju. Plaćate dodjelu memorije, tako da udvostručenje memorije znači da morate platiti dvostruko po milisekundi; ali računski kapacitet povećava se s dodijeljenom memorijom tako da potencijalno vrijeme rada može smanjiti na manje od polovice onoga što je bilo. Već postoje neki korisni alati za odabir optimalne postavke memorije za vas, poput ove.

Zaključiti…

Treba uzeti u obzir da li je primjena metode ponovne upotrebe veze potrebna. Ako se vaša lambda funkcija priziva samo rijetko, poput jednom dnevno, tada nećete imati koristi od optimizacije za tople pokrete. Često se radi o kompromisu između optimiziranja performansi u odnosu na čitljivost vašeg koda - izraz "uglifikacija" govori sam za sebe! Osim toga, dodavanje globalnih varijabli vašem kôdu za ponovnu upotrebu veza s drugim uslugama može potencijalno otežati vaš kôd. Dva mi padaju na pamet:

  • Hoće li novi član tima razumjeti vaš kod?
  • Hoćete li i vi i vaš tim moći ublažiti pogrešku u kodu u budućnosti?

No vjerovatno je da ste odabrali Lambdu za njezinu mjeru i želite visoke performanse i niske troškove, pa pronađite balans koji odgovara potrebama vašeg tima.

Ova mišljenja su mišljenja autora. Ako u ovom postu nije drugačije navedeno, Capital One nije povezana, niti ga podržava bilo koja od navedenih tvrtki. Svi zaštićeni znakovi i ostala intelektualna svojstva koja se koriste ili prikazuju vlasništvo su njihovih vlasnika. Ovaj je članak © 2019 Capital One.