Lambda siseosad - 2. osa: süveneb

AWS Lambda Runtime teekide uurimine

Foto autor Jim Beaudoin

Serverita arendus on lihtsalt parim. Topeltklõps, laadige oma kood üles ja oletegi valmis, eks? Enamikul inimestel on selle üle hea meel jätta. Kui te pole enamik inimesi ja soovite Lambdaga tutvuda, on see artikkel just teile.

Eelmises artiklis saime kesta Lambda konteinerisse, laadisime alla Lambda käituskeskkonna ja avastasime selle komponendid:

  • bootstrap.py - meie käitleja mähisev python-kood.
  • awslambda / runtime.so - pythoniga ühilduv jagatud objekt bootstrap.py kasutab seda, tõepoolest, kõige jaoks.
  • liblambda * .so - runtime.so kasutab omakorda muid jagatud objekte. Keskendume liblambdaruntime.so, mis vastutab raske tõstmise eest Lambda loogika haldamisel.

Samuti oli meil lõbus jama bootstrap.py-ga. Seekord kerime varrukad üles ja sukeldame Lambda käituskeskkonna binaarraamatukogudesse. Uurime Lambda arveldussüsteemi ja (spoileri märguanne) on tore lõbutseda Lambda aegumistega.

„Oh kohti, kuhu lähed! Seal on lõbus teha! Seal on punkte, mida tuleb lüüa. Seal on mänge, mida tuleb võita. ”- dr Seuss. Foto autor: Joshua Earle

Teekide uurimine

Raamatukogud (liblambda * .so) on komponeeritud sümbolitega, nii et te saate raamatukogude kohta palju õppida, kui lähete üle sümbolite nimedele. Samuti paljastab runtime.soor neid funktsioone palju, neid importides ja mähkides, nii et Pythoni skript (meie puhul bootstrap.py) saab mõnda neist kasutada. Kui mugav!

Osaliste funktsioonide loend saidilt liblambdaruntime.so lahtivõtmine. Jumal tänatud sümbolite eest.

Üks asi, mida ma tegelikult tahtsin kontrollida, oli Lambda arveldussüsteemi kulisside taga ning funktsioonide nimesid vaadates oli mul mõned katsed, mida tahtsin proovida. Kuid kõigepealt - räägime natuke Lambda arveldusest.

Lambda arveldus

Lambdal on ajapõhine hinnakujundusmudel ja ilma kõiki üksikasju uurimata on selle sisu põhiline, mida kauem teie Lambda käitamiseks kulub, seda rohkem maksate. Lambda kutsumisel saate hõlpsalt märgata selle algust ja lõppu CloudWatchi logides, samuti selle kestust ja arvelduse kestust.

CloudWatch logib Lambda jaoks. Näete nii Lambda kestust kui ka arve esitamise kestust

Siiski on keerulisem stsenaarium. Mõelge järgmisele Lambdale:

Tavalise käigu korral peaks selle Lambda kestus olema väike (arvete kestus peaks peaaegu alati olema 100 ms). Mis saab aga esimesel kutsumisel? Või külmkäivitusel (kui moodul reimporditakse)?

Lambda logib külma alguse korral. Kestus on palju suurem kui tavaline kutsumine

Empiirilised testid näitavad, et esimese Lambda kutsumise kestus (või külmkäivitus) sisaldab initsialiseerimise kestust. Kuid ma tahtsin kontrollida, kuidas Lambda seda rakendab.

Teekide importimine

Bootstrap.py-s on binaarsest raamatukogust imporditud järgmiste funktsioonide kõned:

  • lambda_runtime.recept_start () või lambda_runtime.recept_invoke () - kui uus päästik on vastu võetud.
  • lambda_runtime.report_done () - alati, kui Lambda tehakse

Nüüd võib olla sobiv aeg anda rohkem üksikasju viilutaja kohta, millele ma eelmises artiklis viitasin. Viilutaja on komponent Lambdas, mille ülesandeks on tööaja eraldamine konteineril töötavatele erinevatele kasutajatele Lambdadele. Need funktsioonid saadavad viilutusele (ja teistele Lambda halduskomponentidele) teate, kui Lambda hukkamised on tehtud, või saavad teavet äsja algatatud täitmiste kohta.

Nii et pärast lambda_runtime kõnede tuvastamist ja teadmist, mis on viilutaja, oli midagi, mida ma lihtsalt pidin proovima: importisin käitusajakogu ja lõbutsin seda! (need katsed on sellised, kuidas ma viilutil asju leidsin, enamasti lahti võtmist ja mõningaid katse-eksituse vorme lugedes). Katse, mida tahan teiega jagada, on ka esimene, mida proovisin: helistades lambda_runtime.report_done () oma Lambda seest. See on kood, mida kasutasin:

Üllatav oli see, et selle näite esitamisel peatus mu kood alles pärast „Alguse” printimist. Siis, kui ma oma lambda uuesti sisse lülitasin, jätkas see selle täitmist täpselt sealt, kus me pooleli jäime - ja trükiti "Pärast esimest korda tehtud"! (Lisasin une, sest mõnikord õnnestus mu Lambdal üks “print” tõmmata, enne kui viilutaja selle peatas). See juhtus ikka ja jälle, kuni Lambda hukkamine lõppes.

Pilvevaatluse logid Lambda täitmiseks. Pange tähele, et meil on sama Lambda jaoks mitu päringu ID-d!

Nii tegi see minu jaoks selgeks - viilutaja arveldab meile nii kaua, kuni meie Lambda saab protsessori aega. See tähendab, et meie arvelduse kestus koosneb kahest osast:

  1. Mooduli initsialiseerimise aeg (ainult esimesel kutsumisel / külmkäivitusel)
  2. Meie tegelik funktsiooni kestus

Lambda ajalõppude vältimine

Lisaks sellele, et see avastus on väga lahe, on sellel ka praktilist (noh… praktiline, mis on vaatajale silma jäänud, kuid see on kindlasti huvitav) kasutamist: Lambda ajalõppude käsitlemist! Mõelge järgmisele Lambdale:

Lülitasin korra Lambda välja ja see peatus joonel 13. Siis ootasin natuke aega ja vallandasin selle uuesti. Tulemuseks oli see, et kontekstiobjekti meetodi tagastamise aeg oli 0, kuid Lambda ei aegunud! Lambda aegumine lähtestati, kuna see on erinev kutse ja nüüd oleme oma Lambda aegumistähtaja (ja muidugi ka meie AWS-i arve) kahekordistanud! Kasulik näide näiteks võib olla silmus, mis töötleb paljusid kirjeid ja mõnikord aegub. Nüüd saame kontrollida, kas läheneb aegumine, ja kui see on nii, helistage lambda_runtime.report_done () ja oodake järgmist päästikut, et kiirendada täitmine täpselt seal, kus peatusime!

Pilvevaatluse logi Lambda kutsest. Järelejäänud aeg: 0

Teine asi, mis juhtus minuga selle teema kallal töötades, on see, et AWS suudab selle käitumise põhjal pakkuda reaalset funktsiooni, kus kasutaja saab peatada oma Lambda ja jätkata samast asukohast järgmisel kutsel. See võib olla kasulik mitte ainult märkimisväärse hulga andmete töötlemiseks ja keset ajalõppude käsitlemist. Teiseks kasutusjuhtumiks võib olla näiteks Lambda peatamine, oodates kallist IO / mõnda muud ülesande tulemust, selle asemel, et tasuda Lambda ooteaja eest! Kas nad teevad seda? Ei tea. Kas see on ülilahe? Defo.

Sellel kõigel on siiski negatiivne külg. Kuna see on hämmastav viis, ebaõnnestuvad järgmised kaks järgmist Lambda kutset Amazoni sisemise veaga. Olen kindel, et selle probleemi saab ka väikese vaevaga lahendada, kuid praegu oli see minu jaoks piisavalt hea.

Järeldus

Oleme AWS Lambda sisemiste kohta palju teada saanud. Uurisime käituskeskkonnas asuvaid binaarraamatukogusid ja Lambda arveldussüsteemi. Samuti importisime Lambda käitusajakogu ja kasutasime seda ajalõppude käsitlemiseks! Kuid AWS-ilt ja teistelt müüjatelt on veel palju avastada. Kui ootate, ootan järgmisi väljakutseid - andke mulle sellest teada!

Olen värskendanud ka avatud lähtekoodiga raamatukogu, mis sisaldab erinevaid läbi viidud katseid. Loodetavasti leiate sellest kasuliku!

Siin Epsagonis töötame välja serveriteta rakenduste jaoks kohandatud jälgimisriista. Kas kasutate serverita ja olete huvitatud rohkem kuulda? Külastage meie veebisaiti!