Parhaat käytännöt AWS Lambda -säiliön uudelleenkäyttöön

Lämpimien aloitusten optimointi kytkettäessä AWS Lambda muihin palveluihin

AWS Lambda tarjoaa suuren skaalautuvuuden johtuen palvelimettomasta ja valtiottomasta, mikä mahdollistaa monien lambda-toimintojen kopioiden syntymisen heti (kuten tässä kuvataan). Kun kirjoitat sovelluskoodia, haluat kuitenkin saada pääsyn joihinkin tilallisiin tietoihin. Tämä tarkoittaa yhteyden muodostamista tietovarastoon, kuten RDS-ilmentymään tai S3: een. Yhteyden muodostaminen muihin palveluihin AWS Lambdasta lisää kuitenkin aikaa toimintokoodillesi. Korkeasta skaalautuvuudesta voi olla myös sivuvaikutuksia, kuten RDS-ilmentymään sallittujen yhteyksien enimmäismäärän saavuttaminen. Yksi vaihtoehto tämän torjumiseksi on käyttää säiliön uudelleenkäyttöä AWS Lambdassa yhteyden säilyttämiseksi ja lambdan käyttöajan vähentämiseksi.

Tässä on hyödyllisiä kaavioita, jotka selittävät lambdapyynnön elinkaaren.

Seuraavat tapahtuvat kylmäkäynnistyksen aikana, kun toimintosi käynnistetään ensimmäistä kertaa tai toimettomuuden jälkeen:

  • Koodi ja riippuvuudet ladataan.
  • Uusi kontti käynnistetään.
  • Ajonaikainen käynnistysstrategia.

Viimeinen toimenpide on käynnistää koodi, joka tapahtuu aina, kun lambda-toiminto käynnistetään. Jos säilytyslaitetta käytetään uudelleen myöhemmin lambda-toiminnon käynnistämiseen, voimme hypätä eteenpäin koodin aloittamiseen. Tätä kutsutaan lämpimäksi alkuksi, ja tämän voimme optimoida muodostaessamme yhteyden muihin palveluihin määrittelemällä yhteyden käsittelijän menetelmän ulkopuolelle.

Yhdistäminen muihin Lambdan AWS-palveluihin

Esimerkki: Yhdistä RDS-ilmentymään, täältä hankitut AWS-kuvakkeet

Meillä on yleinen ja yleinen esimerkki suoritettaviksi - haluamme muodostaa yhteyden konttiresurssiin hakeaksesi rikastustietoja. Tässä esimerkissä JSON-hyötykuorma toimitetaan tunnuksella ja Lambda-toiminto muodostaa yhteyden RDS-esiintymään, joka käyttää PostgreSQL: tä, löytääkseen vastaavan tunnuksen nimen, jotta voimme palauttaa rikastetun hyötykuorman. Koska lambda-toiminto on yhteydessä RDS: ään, joka asuu VPC: ssä, lambda-toiminnon on nyt myös oltava yksityisessä aliverkossa. Tämä lisää pari askelta kylmäkäynnistykseen - VPC-joustava verkkoliitäntä (ENI) on liitettävä (kuten Jeremy Dalyn blogissa mainittiin, tämä lisää aikaa kylmäkäynnistyksiin).

Huomaa: Voisimme välttää VPC: n käyttöä, jos käyttäisimme avain- / arvovarastoa DynamoDB: n kanssa RDS: n sijasta.

Käsittelen yli kaksi ratkaisua tähän tehtävään, ensimmäinen on ”naiivi” ratkaisuni, kun taas toinen ratkaisu optimoi lämpimät aloitusajat käyttämällä yhteyttä uudelleen myöhempiin kutsutuksiin. Sitten vertaamme kunkin ratkaisun suorituskykyä.

Vaihtoehto 1 - Yhdistä RDS: ään käsittelijän sisällä

Tämä koodiesimerkki osoittaa, kuinka voin lähestyä naiivisti tätä tehtävää - tietokantayhteys on käsittelijän menetelmän sisällä. Tunnuksen nimen hakemiseksi ennen hyötykuorman palauttamista on yksinkertainen valintakysely, joka sisältää nyt nimen.

Katsotaanpa, kuinka tämä vaihtoehto toimii pienen testin aikana, kun purskeessa on 2000 kutsua, joiden samanaikaisuus on 20. Pienin kesto on 18 ms keskimäärin 51 ms ja hiukan yli 1 sekunti (kylmäkäynnistyksen kesto).

Lambdan kesto

Seuraava kaavio osoittaa, että tietokantaan on enintään kahdeksan yhteyttä.

Yhteysten lukumäärä RDS-tietokantaan 5 minuutin ikkunassa.

Vaihtoehto 2 - Käytä globaalia yhteyttä

Toinen vaihtoehto on määritellä yhteys globaaliksi käsittelijän menetelmän ulkopuolelle. Sitten lisäämme käsittelijän sisällä tarkistuksen, onko yhteys olemassa, ja yhdistämme vain, jos sitä ei ole. Tämä tarkoittaa, että yhteys muodostetaan vain kerran konttia kohti. Yhteyden asettaminen ehdollisella paikallaan tarkoittaa, että meidän ei tarvitse muodostaa yhteyttä, ellei koodilogiikka sitä vaadi.

Emme enää sulje yhteyttä tietokantaan, joten yhteys pysyy toiminnon myöhempää kutsumista varten. Yhteyden uudelleenkäyttö vähentää merkittävästi lämpimän käynnistyksen kestoja - keskimääräinen kesto on noin 3 kertaa nopeampi ja minimi on 1 ms eikä 18 ms.

Lambdan kesto

Yhdistäminen RDS-ilmentymään on aikaa vievä tehtävä, ja että jokaisessa kutsussa ei tarvitse muodostaa yhteyttä, se on hyödyllinen suorituskyvylle. Kun muodostat yhteyden tietokantaan yksinkertaista tietokantakyselyä varten, saavutamme enintään 20 tietokantayhteyden määrää, joka vastaa samanaikaisuuden tasoa (teimme 20 samanaikaista kutsutusta x 100 kertaa). Kun kutsujen purske loppuu, yhteydet vähitellen sulkeutuvat.

Nyt kun AWS on lisännyt lambda-kestovaraa 15 minuuttiin, tämä tarkoittaa, että tietokantayhteydet saattavat kestää pidempään ja saatat olla vaarassa saavuttaa RDS max -yhteysnumero. Oletusarvon mukaiset max-yhteydet voidaan korvata RDS-parametriryhmäasetuksissa, vaikkakin yhteyksien enimmäismäärän lisääminen voi aiheuttaa ongelmia muistin allokoinnissa. Pienempien esiintymien max_yhteysarvojen oletusarvo voi olla alle 100. Muista nämä rajoitukset ja lisää sovelluslogiikka vain muodostaaksesi yhteys tietokantaan tarvittaessa.

Globaalin yhteyden käyttäminen muissa tehtävissä

Lambda liitetään S3: een

Yleinen tehtävä, joka meidän on ehkä tehtävä Lambdan kanssa, on käyttää tilallisia tietoja S3: lta. Alla oleva koodinpätkä on AWS: n toimittama Python Lambda -toiminnon suunnitelma - johon voit navigoida kirjautumalla sisään AWS-konsoliin ja napsauttamalla tätä. Koodissa voi nähdä, että S3-asiakas on määritelty täysin käsittelijän ulkopuolelle, kun säilö alustetaan, kun taas RDS-esimerkille globaali yhteys asetettiin käsittelijän sisälle. Molemmat lähestymistavat asettavat globaalit muuttujat, joiden avulla ne ovat käytettävissä myöhempiin kutsutuksiin.

s3-get-object lambda -piirroskoodinpätkä https://console.aws.amazon.com/lambda/home?region=us-east-1#/create/new?bp=s3-get-object-python

Ympäristömuuttujien salauksen purkaminen

Lambda-konsoli antaa sinulle mahdollisuuden salata ympäristömuuttujat ylimääräisen turvallisuuden takaamiseksi. Seuraava koodinpätkä on AWS: n tarjoama Java-esimerkki auttajakomentosarjasta ympäristömuuttujien salauksen purkamiseksi Lambda-toiminnosta. Voit navigoida koodinpätkään seuraamalla tätä opetusohjelmaa (erityisesti vaihetta 6). Koska DECRYPTED_KEY on määritelty luokan globaaliksi, decryptKey () -toimintoa ja logiikkaa kutsutaan vain kerran lambda-säilöä kohden. Siksi näemme huomattavan parannuksen lämpimän käynnistyksen kestoissa.

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

Globaalien muuttujien käyttö muissa FaaS-ratkaisuissa

Tätä lähestymistapaa ei voida eristää AWS Lambdan suhteen. Globaalin yhteyden käyttötapaa voidaan soveltaa myös muiden pilvipalvelujen tarjoajien palvelimettomiin toimintoihin. Google Cloud Functions -vinkit ja -vinkit -sivu antaa hyvän selityksen ei-laiskoille muuttujille (kun muuttuja alustetaan aina käsittelymenetelmän ulkopuolelle) verrattuna laiskoihin muuttujiin (globaali muuttuja asetetaan vain tarvittaessa) globaaleihin muuttujiin.

Muut parhaat käytännöt

Tässä on joitain muita parhaita käytäntöjä, jotka pitää mielessä.

Testaus

FaaS: n käyttö helpottaa mikropalveluarkkitehtuurin saamista. Ja pienten, erillisten toimintojen käyttäminen on käsi kädessä tehokkaan yksikkötestauksen kanssa. Yksikkötestien auttamiseksi:

  • Muista jättää testiriippuvuudet ulkopuolelle lambda-paketista.
  • Erota logiikka pois käsittelymenetelmästä, kuten tekisit ohjelman päämenetelmän kanssa.

Riippuvuudet ja paketin koko

Asennuspaketin koon pienentäminen tarkoittaa, että koodin lataus on nopeampaa alustettaessa ja parantaa siten kylmäkäynnistysaikoja. Poista käyttämättömät kirjastot ja kuollut koodi vähentääksesi käyttöönoton ZIP-tiedoston kokoa. AWS SDK tarjotaan Python- ja JavaScript-ajoille, joten niitä ei tarvitse sisällyttää käyttöönottopakettiin.

Jos Node.js on ensisijainen Lambda-ajonaika, voit käyttää minimointia ja ugglification vähentääksesi toimintokoodiasi ja minimoidaksesi käyttöönottopaketin koon. Joitakin, mutta ei kaikkia, minimoinnin ja ugglifikaation näkökohtia voidaan soveltaa muihin ajoihin, esim. et voi poistaa tyhjää tilaa python-koodista, mutta voit poistaa kommentteja ja lyhentää muuttujien nimiä.

Muistin asettaminen

Kokeile löytääksesi optimaalisen muistimäärän Lambda-toiminnolle. Maksat muistin varauksesta, joten muistin kaksinkertaistaminen tarkoittaa, että joudut maksamaan kaksinkertaisen millisekunnissa; mutta laskentakapasiteetti kasvaa allokoidun muistin kanssa, joten se voisi potentiaalisesti lyhentää ajoajan alle puoleen siitä, mikä se oli. On jo olemassa joitain hyödyllisiä työkaluja, kuten tämän, optimaalisen muistiasetuksen valitsemiseksi.

Lopuksi ...

Yksi asia on harkittava, onko yhteyden uudelleenkäyttömenetelmän soveltaminen välttämätöntä. Jos lambda-toimintoasi käytetään vain harvoin, kuten kerran päivässä, et hyöty siitä, että optimoit lämpimät käynnit. Suorituskyvyn optimoinnin ja koodisi luettavuuden välillä on usein kompromissi - termi “ugglification” puhuu puolestaan! Lisäksi globaalien muuttujien lisääminen koodiin käyttämään uudelleen yhteyksiä muihin palveluihin voi mahdollisesti vaikeuttaa koodisi jäljittämistä. Kaksi kysymystä tulee mieleen:

  • Ymmärtääkö uusi joukkueen jäsen koodisi?
  • Pystytkö sinä ja tiimisi debugoimaan koodin tulevaisuudessa?

Mutta on todennäköistä, että olet valinnut Lambdan sen mittakaavasta ja haluat korkean suorituskyvyn ja alhaiset kustannukset, joten löydä tasapaino, joka sopii joukkueesi tarpeisiin.

Nämä mielipiteet ovat kirjoittajan mielipiteitä. Ellei tässä viestissä toisin mainita, Capital One ei ole sidoksissa mihinkään mainittuihin yrityksiin eikä sitä ole hyväksytty. Kaikki käytetyt tavaramerkit ja muut immateriaalioikeudet ovat omistajiensa omistamia. Tämä artikkeli on © 2019 Capital One.