A legjobb gyakorlatok az AWS Lambda Container újrahasználatához

A meleg indítás optimalizálása az AWS Lambda más szolgáltatásokhoz történő csatlakoztatásakor

Az AWS Lambda magas skálázhatóságot biztosít, mivel kiszolgáló nélküli és állapot nélküli, és lehetővé teszi a lambda funkció sok példányának azonnali létrehozását (az itt leírtak szerint). Az alkalmazáskód írásakor valószínűleg hozzáférést igényel bizonyos állapotalapú adatokhoz. Ez azt jelenti, hogy csatlakozni kell egy adattárhoz, például RDS-példányhoz vagy S3-hoz. Az AWS Lambda szolgáltatásaihoz való csatlakozás azonban időt ad a funkciókódhoz. A nagy skálázhatóságnak lehetnek mellékhatásai is, például az RDS-példányhoz megengedett maximális szám elérése. Ennek egyik módja a konténer újrafelhasználása az AWS Lambda alkalmazásban a kapcsolat megőrzéséhez és a lambda futási idejének csökkentéséhez.

Van néhány hasznos diagram, amely magyarázza a lambda kérés életciklusát.

A következők fordulnak elő hidegindításkor, amikor első alkalommal vagy inaktivitási időszak után hívják be a funkciódat:

  • A kód és a függőségek letöltésre kerülnek.
  • Elindul egy új tároló.
  • A futási idő elindul.

Az utolsó lépés a kód elindítása, ami minden alkalommal megtörténik, amikor a lambda funkciót meghívják. Ha a tárolót újra felhasználják a lambda funkció későbbi behívására, akkor előre ugranunk a kód elindításához. Ezt meleg indításnak nevezzük, és ezt a lépést optimalizálhatjuk, amikor más szolgáltatásokhoz kapcsolódunk úgy, hogy a kapcsolatot meghatározjuk a kezelő módszer keretein kívül.

Csatlakozás más AWS szolgáltatásokhoz a Lambda-tól

Példa: Csatlakozás az RDS példányhoz, az AWS ikonok innen származnak

Van egy alapvető és közös példa a futtatásra - csatlakozni szeretnénk egy tároló erőforráshoz a dúsítási adatok letöltéséhez. Ebben a példában a JSON hasznos terhelés azonosítóval jár, és a Lambda függvény kapcsolódik egy RDS példányhoz, amely PostgreSQL-t futtat, hogy megtalálja az azonosító megfelelő nevét, így visszatéríthetjük a gazdagított hasznos terhelést. Mivel a lambda funkció kapcsolódik az RDS-hez, amely VPC-ben él, a lambda funkciónak most magánhálózatban is kell lennie. Ez pár lépést tesz a hidegindításhoz - csatlakoztatni kell egy VPC elasztikus hálózati interfészt (ENI) (amint azt Jeremy Daly blogjában említjük, ez időt ad a hidegindításokhoz).

Megjegyzés: elkerülhetjük a VPC használatát, ha kulcs- / értéktárolót használunk a DynamoDB-vel az RDS helyett.

Két feladaton megyek át ehhez a feladathoz, az első a „naiv” megoldásom, míg a második megoldás a meleg indulási időkre optimalizálja azáltal, hogy a kapcsolatot újra felhasználja a későbbi meghívásokhoz. Ezután összehasonlítjuk az egyes megoldások teljesítményét.

1. lehetőség - Csatlakozás az RDS-hez a kezelőn belül

Ez a kódpélda megmutatja, hogyan lehet naiv módon megközelíteni ezt a feladatot - az adatbázis-kapcsolat a kezelő módszerén belül van. Van egy egyszerű választási lekérdezés az azonosító nevének beolvasására, mielőtt visszatérne a hasznos teher, amely most a nevet is tartalmazza.

Lássuk, hogyan teljesít ez az opció egy kicsi teszt során, 2000 felhívással, 20 egyidejűleg. A minimális időtartam 18 ms, átlagosan 51 ms, és alig több mint 1 másodperc (a hidegindítás időtartama).

Lambda időtartam

Az alábbi grafikon azt mutatja, hogy az adatbázishoz legfeljebb nyolc kapcsolat lehetséges.

Csatlakozások száma az RDS adatbázishoz egy 5 perces ablakban.

2. lehetőség - Használjon globális kapcsolatot

A második lehetőség a kapcsolat meghatározása a kezelő módszer globális külső oldalán. Ezután a kezelő belsejébe ellenőrzést adunk, hogy megnézzük, létezik-e kapcsolat, és csak akkor csatlakozzunk, ha nincs. Ez azt jelenti, hogy a kapcsolat tárolókonként csak egyszer történik. A kapcsolat ilyen módon történő feltételével a helyben azt jelenti, hogy nem kell kapcsolatot létesítenünk, ha a kódlogika nem követeli meg.

Már nem zárjuk le az adatbázis-kapcsolatot, így a kapcsolat megmarad a funkció későbbi meghívására. A kapcsolat újbóli felhasználása jelentősen csökkenti a meleg indítás időtartamát - az átlagos időtartam körülbelül háromszor gyorsabb, a minimum pedig 1 ms, nem 18 ms.

Lambda tartamok

Az RDS-példányhoz történő csatlakozás időigényes feladat, és a teljesítményhez előnyös, ha nem kell minden egyes meghíváshoz csatlakozni. Amikor egy egyszerű adatbázis-lekérdezéshez kapcsolódunk az adatbázishoz, akkor az adatbázis-kapcsolatok maximális száma 20, amely megegyezik az egyidejűség szintjével (20 egyidejű hívást xx100-szor készítettünk). Amikor a hívások száma leáll, a kapcsolatok fokozatosan bezáródnak.

Most, hogy az AWS 15 percre növelte a lambda időtartam-korlátot, ez azt jelenti, hogy az adatbázis-kapcsolatok hosszabb ideig tarthatnak, és fennállhat annak veszélye, hogy eléri az RDS max kapcsolatok számát. Az alapértelmezett maximális kapcsolatok felülírhatók az RDS paramétercsoport beállításaiban, bár a kapcsolatok maximális számának növelése problémákat okozhat a memóriaelosztásban. A kisebb példányok alapértelmezett max_connections értéke kevesebb lehet, mint 100. Vigyázzon ezekre a korlátozásokra, és csak az alkalmazás logikáját adja hozzá az adatbázishoz való kapcsolódáshoz, ha szükséges.

Globális kapcsolat használata más feladatokhoz

Lambda csatlakoztatás az S3-hoz

Egy általános feladat, amelyet esetleg a Lambda-val kell elvégeznünk, az állapotalapú adatok elérése az S3-ból. Az alábbi kódrészlet egy AWS által biztosított Python Lambda Function tervrajz - amelyre belépve jelentkezzen be az AWS konzolba, és kattintson ide. A kódban láthatja, hogy az S3 ügyfél a kezelőn kívül teljesen definiálódik, amikor a tároló inicializálódik, míg az RDS példához a globális kapcsolatot a kezelőben állították be. Mindkét megközelítés beállítja a globális változókat, lehetővé téve számukra, hogy rendelkezésre álljanak a későbbi hívásokhoz.

s3-get-object lambda terv kódrészlet https://console.aws.amazon.com/lambda/home?region=us-east-1#/create/new?bp=s3-get-object-python

A környezeti változók visszafejtése

A lambda konzol lehetőséget ad a környezeti változók titkosítására a további biztonság érdekében. A következő kódrészlet AWS által biztosított Java példa egy segítő szkriptről a környezeti változók Lambda függvényből való visszafejtésére. Navigálhat a kódrészlethez az útmutató betartásával (különösen a 6. lépéssel). Mivel a DECRYPTED_KEY osztály globális, a decryptKey () függvényt és logikát lambda tárolónként csak egyszer hívják meg. Ezért a meleg indítás időtartama jelentősen javul.

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

Globális változók használata más FaaS megoldásokban

Ez a megközelítés nem különbözik az AWS Lambda-tól. A globális kapcsolat használatának módszere alkalmazható más felhőszolgáltatók kiszolgáló nélküli funkcióira is. A Google Cloud Functions tippek és trükkök oldal jó magyarázatot ad a nem lusta változókra (amikor a változó mindig a kezelő módszerén kívül inicializálódik), szemben a lusta változókkal (a globális változót csak akkor állítják be, ha szükséges) a globális változókat.

Egyéb bevált gyakorlatok

Itt van néhány további legjobb gyakorlat, amelyet szem előtt kell tartani.

Tesztelés

A FaaS használata megkönnyíti a mikroszolgáltatási architektúra kialakítását. És a kicsi, különálló funkcionalitás megléte kézhez jár a hatékony egységteszttel. Az egységteszt elősegítéséhez:

  • Ne felejtse el kizárni a tesztfüggőségeket a lambda csomagból.
  • Válasszon külön logikát a kezelő módszerétől, mint ahogyan egy program fő módszerével tenné.

Függőségek és a csomag mérete

A telepítési csomag méretének csökkentése azt jelenti, hogy az inicializáláskor a kód gyorsabban letölthető, és ezáltal javul a hidegindítási idő. Távolítsa el a nem használt könyvtárakat és az érvénytelen kódot a telepítési ZIP fájl méretének csökkentése érdekében. Az AWS SDK biztosított a Python és a JavaScript futási időkhöz, így nem kell ezeket belefoglalni a telepítési csomagba.

Ha a Node.js az Ön által előnyben részesített Lambda futásiideje, akkor a minifikációt és az uglifikációt alkalmazhatja a funkciókód méretének csökkentése és a telepítési csomag méretének minimalizálása érdekében. A finomítás és az uglifikáció néhány, de nem minden vonatkozása alkalmazható más futási időkre is, pl. nem távolíthat el szóközt a python-kódból, de eltávolíthatja a megjegyzéseket és lerövidítheti a változóneveket.

A memória beállítása

Kísérlet a Lambda Function optimális memóriamennyiségének megtalálására. Fizet a memóriaelosztásért, tehát a memória megduplázása azt jelenti, hogy milliszekundumban kétszer kell fizetnie; de a számítási kapacitás növekszik a kiosztott memóriával, így potenciálisan a futási idő kevesebb mint felére csökkenthető, mint az volt. Már létezik néhány hasznos eszköz az optimális memóriabeállítás kiválasztásához, például ez.

Következtetni…

Az egyik szempont, amelyet figyelembe kell venni, szükség van-e a kapcsolat újrafelhasználási módszer alkalmazására. Ha a lambda-funkcióra csak ritkán, például egyszer naponta, hívják, akkor nem lesz kedvező a meleg indítások optimalizálása. Gyakran van egy kompromisszum a teljesítmény optimalizálása és a kód olvashatósága között - az “uglification” kifejezés önmagáért beszél! Ezen túlmenően, ha a globális változókat hozzáadja a kódhoz, hogy újra felhasználja a kapcsolatokat más szolgáltatásokkal, akkor a kód nyomon követését megnehezítheti. Két kérdés jut eszembe:

  • Meg fogja érteni az új csapattag a kódot?
  • A jövőben Ön és csapata hibakeresést tud majd végezni?

De valószínű, hogy a Lambda-t választotta méretének megfelelően, és nagy teljesítményt és alacsony költségeket akar, tehát keresse meg a csapata igényeinek megfelelő egyensúlyt.

Ezek a vélemények a szerző véleményét tükrözik. Ha ebben a bejegyzésben másként nem szerepelnek, a Capital One nem áll kapcsolatban egyetlen kapcsolt társasággal sem, és azt sem hagyja jóvá. Minden használt vagy megjelenített védjegy és egyéb szellemi tulajdon a megfelelő tulajdonos tulajdonát képezi. Ez a cikk © 2019 Capital One.