Lambda Internals - Časť 2: Prejdeme hlbšie

Preskúmanie knižníc runtime AWS Lambda

Foto: Jim Beaudoin

Vývoj bez serverov je jednoducho najlepší. Dvakrát kliknite, nahrajte svoj kód a máte hotovo, však? Väčšina ľudí je viac než šťastná, že to nechajú. Ak nie ste väčšina ľudí a hľadáte nejaký prieskum Lambda, tento článok je určený len vám.

V predchádzajúcom článku sme dostali shell do Lambda kontajnera, stiahli sme Lambda runtime prostredie a objavili jeho komponenty:

  • bootstrap.py - pythonový kód baliaci náš handler.
  • awslambda / runtime.so - zdieľaný objekt kompatibilný s pythonom bootstrap.py ho používa na takmer všetko.
  • liblambda * .so - runtime.so potom používa iné zdieľané objekty. Zameriame sa na liblambdaruntime.so, ktorý má na starosti ťažkú ​​správu logiky Lambda.

Tiež sme sa pobavili pri posielaní správ pomocou bootstrap.py. Tentoraz sa chystáme zhrnúť rukávy a ponoriť sa do binárnych knižníc runtime prostredia Lambda. Preskúmame Lambdov fakturačný systém a (upozornenie spojlera) sa zabavíme s Lambda timeoutmi.

Preskúmanie knižníc

Knižnice (liblambda * .so) sú skompilované so symbolmi, takže o knižniciach sa môžete veľa dozvedieť len tak, že prejdete na názvy symbolov. Runtime.so tiež odhaľuje množstvo týchto funkcií ich importom a zabalením, takže skript Python (v našom prípade bootstrap.py) môže niektoré z nich použiť. Aké pohodlné!

Zoznam čiastkových funkcií z demontáže liblambdaruntime.so. Ďakujem bohu za symboly.

Jednou z vecí, ktoré som si spočiatku chcela vyskúšať, boli pozadie Lambdovho fakturačného systému, a keď som sa pozrel na názvy funkcií, vykonal som niekoľko experimentov, ktoré som chcel vyskúšať. Najprv však povedzme niečo o fakturácii Lambda.

Lambda fakturácia

Lambda má cenový model založený na čase a bez toho, aby sa zaoberali všetkými podrobnosťami, podstatou toho je, čím dlhšie trvá spustenie Lambdy, tým viac zaplatíte. Pri vyvolaní Lambdy si môžete ľahko všimnúť jej začiatok a koniec v protokoloch CloudWatch, ako aj jej trvanie a fakturované trvanie.

Protokoly CloudWatch pre Lambdu. Môžete vidieť trvanie Lambdy aj fakturované trvanie

Existuje však zložitejší scenár. Zvážte nasledujúce Lambda:

Pri typickom behu by malo byť trvanie tohto Lambda malé (fakturované by malo byť takmer vždy 100 ms). Čo sa však stane pri prvom vyvolaní? Alebo pri studenom štarte (kde sa modul opätovne importuje)?

Lambda sa prihlási, keď nastane studený štart. Trvanie je omnoho dlhšie ako pri normálnom vyvolaní

Empirické testy ukazujú, že trvanie prvého vyvolania Lambda (alebo studený štart) obsahuje trvanie inicializácie. Chcel som však skontrolovať, ako to Lambda implementuje.

Importovanie knižníc

V bootstrap.py existujú volania na nasledujúce funkcie, importované z binárnych knižníc:

  • lambda_runtime.receive_start () alebo lambda_runtime.receive_invoke () - po prijatí nového spúšťača.
  • lambda_runtime.report_done () - vždy, keď sa skončí Lambda

Teraz by mohol byť vhodný čas na poskytnutie podrobnejších informácií o krájači, o ktorom som hovoril v predchádzajúcom článku. Krájač je komponent v Lambde, ktorý má na starosti prideľovanie runtime rôznym používateľom Lambdas, bežiacim na kontajneri. Tieto funkcie pošlú upozornenie krájačovi (a iným komponentom správy Lambda), keď sa vykonajú Lambda spustenia alebo dostanú informácie o novo iniciovaných vykonaniach.

Takže keď sme identifikovali hovory z lambda_runtime a vedeli sme, čo je krájač, niečo, čo som len HAD skúsil: importovať runtime knižnicu a baviť sa s ňou! (tieto experimenty sú to, ako som zistil veci na krájači, väčšinou čítaním demontáže a pokusov a omylov). Test, ktorý s vami chcem zdieľať, je tiež prvý, o ktorý som sa pokúsil: volanie lambda_runtime.report_done () zvnútra mojej Lambdy. Toto je kód, ktorý som použil:

Prekvapujúce bolo, že pri spustení tohto príkladu sa môj kód zastavil len po tlači „Začiatok“. Potom, keď som znova spustil svoju Lambdu, obnovil jej vykonávanie presne od miesta, kde sme prestali - a vytlačil text „Po prvom dokončení“! (Pridal som spánok, pretože niekedy sa mojej Lambde podarilo vytiahnuť jednu „tlač“ skôr, ako ju krájač pozastavil). Stalo sa to znova a znova, až kým Lambda poprava neskončila.

Protokoly cloudwatch pre vykonanie Lambda. Všimnite si, že pre tú istú Lambdu máme niekoľko ID žiadostí!

Takže to pre mňa bolo definitívne - krájač nám účtuje tak dlho, kým naša Lambda získa čas na CPU. To znamená, že naše fakturované trvanie sa skladá z dvoch častí:

  1. Čas inicializácie modulu (iba pri prvom vyvolaní / studenom štarte)
  2. Naše skutočné trvanie funkcie

Vyhýbanie sa Lambda Timeoutom

Okrem toho, že je veľmi cool, má tento objav praktický (no ... praktický je v oku pozorovateľa, ale je to určite zaujímavé) použitie: zvládnutie Lambda timeoutov! Zvážte nasledujúce Lambda:

Raz som spustil Lambdu a zastavil sa na riadku 13. Potom som chvíľu čakal a znova ho spustil. Výsledkom bolo, že zostávajúci čas vrátenia metódy kontextu objektu bol 0, ale Lambda nevypršal časový limit! Časový limit Lambdy bol resetovaný, pretože ide o inú výzvu, a teraz sme zdvojnásobili časový limit našej Lambdy (a samozrejme náš účet AWS)! Užitočným prípadom môže byť napríklad slučka, ktorá spracúva veľa záznamov a niekedy vyprší čas. Teraz môžeme skontrolovať, či sa blížime k vypršaniu časového limitu, a ak áno, zavolajte lambda_runtime.report_done () a počkajte, kým ďalší spúšťač vyzdvihne spustenie z miesta, kde sme sa pozastavili!

Protokol Cloudwatch z vyvolania Lambda. Zostávajúci čas: 0

Ďalšou vecou, ​​ktorá sa mi pri práci na tomto probléme vyskytla, je, že AWS môže na základe tohto správania dodať skutočnú vlastnosť, kde používateľ môže pozastaviť svoju Lambdu a pokračovať v tom istom mieste vo svojej nasledujúcej výzve. Môže to byť užitočné nielen pri spracovaní značného množstva údajov a pri riešení časových limitov uprostred. Ďalším prípadom použitia môže byť napríklad pozastavenie prevádzky zariadenia Lambda pri čakaní na drahý výsledok IO / iné výsledky úlohy namiesto zaplatenia času nečinnosti vašej Lambdy! Urobia to? Neviem. Je to super? Defoe.

To však má jednu nevýhodu. Pretože je to hackerský spôsob, ďalšie dve nasledujúce vyvolania Lambdy zlyhajú s amazonskou internou chybou. Som si istý, že tento problém sa dá vyriešiť aj s trochou úsilia, ale pre mňa to bolo dosť dobré.

záver

Dozvedeli sme sa veľa o vnútorných intervaloch AWS Lambda. Preskúmali sme binárne knižnice v runtime prostredí a v fakturačnom systéme Lambda. Tiež sme importovali runtime knižnicu Lambda a použili sme ju na vypršanie časového limitu! Stále je však čo objavovať, a to aj na AWS a na ďalších predajcoch. Tešíme sa na ďalšie výzvy, ak máte nejaké otázky - dajte mi vedieť!

Aktualizoval som tiež otvorenú zdrojovú knižnicu obsahujúcu rôzne experimenty, ktoré som vykonal. Dúfam, že to bude užitočné!

Tu v Epsagone vyvíjame monitorovací nástroj šitý na mieru pre aplikácie bez serverov. Používate server bez servera a máte záujem dozvedieť sa viac? Navštívte našu webovú stránku!