Gedetailleerde ontleding van AWS Lambda

Die vertaling van die artikel is spesifiek vir die studente van die kursus voorberei "Wolkdienste". Stel u belang om in hierdie rigting te ontwikkel? Kyk na die meesterklas deur Egor Zuev (TeamLead by InBit) "AWS EC2 diens" en sluit aan by die volgende kursusgroep: begin op 26 September.

Gedetailleerde ontleding van AWS Lambda

Meer mense migreer na AWS Lambda vir skaalbaarheid, werkverrigting, besparings en die vermoë om miljoene of selfs triljoene versoeke per maand te hanteer. Om dit te doen, hoef jy nie die infrastruktuur waarop die diens loop, te bestuur nie. En outomatiese skaal laat jou toe om duisende gelyktydige versoeke per sekonde te bedien. Ek dink AWS Lambda kan met reg een van die gewildste AWS-dienste genoem word.

AWS Lambda

AWS Lambda is 'n gebeurtenisgedrewe bedienerlose rekenaardiens wat jou toelaat om kode te laat loop sonder om bedieners te voorsien of te bestuur en ander AWS-dienste uit te brei deur gebruik te maak van pasgemaakte logika. Lambda reageer outomaties op verskeie gebeurtenisse (genoem snellers), soos HTTP-versoeke deur Amazon API Gateway, veranderinge aan data in Amazon S3-emmers of Amazon DynamoDB-tabelle; of jy kan jou kode deur API-oproepe laat loop deur die AWS SDK en staatsoorgange in AWS Step Functions te gebruik.

Lambda loop kode op 'n hoogs beskikbare rekenaarinfrastruktuur en is ten volle verantwoordelik vir die administrasie van die onderliggende platform, insluitend bediener- en bedryfstelselonderhoud, hulpbronvoorsiening, outo-skaal, kodemonitering en aanteken. Dit wil sê, jy hoef net jou kode op te laai en op te stel hoe en wanneer dit uitgevoer moet word. Op sy beurt sal die diens sorg vir die bekendstelling daarvan en hoë beskikbaarheid van u toepassing verseker.

Wanneer om oor te skakel na Lambda?

AWS Lambda is 'n gerieflike rekenaarplatform wat geskik is vir 'n verskeidenheid gebruiksgevalle, solank die taal en looptyd van jou kode deur die diens ondersteun word. As u op u kode en besigheidslogika wil fokus terwyl u bedieneronderhoud, voorsiening en skaal teen 'n redelike koste uitkontrakteer, is AWS Lambda beslis die pad om te gaan.

Lambda is ideaal vir die skep van programmeringskoppelvlakke, en wanneer dit saam met API Gateway gebruik word, kan u koste aansienlik verminder en vinniger op die mark kom. Daar is verskillende maniere om Lambda-funksies en opsies te gebruik om 'n bedienerlose argitektuur te organiseer - almal kan iets geskik kies op grond van hul doel.

Lambda laat jou toe om 'n wye verskeidenheid take uit te voer. Dus, danksy CloudWatch-ondersteuning, kan u uitgestelde take skep en individuele prosesse outomatiseer. Daar is geen beperkings op die aard en intensiteit van gebruik van die diens nie (geheueverbruik en tyd word in ag geneem), en niks verhinder jou om sistematies aan 'n volwaardige mikrodiens gebaseer op Lambda te werk nie.

Hier kan jy diensgerigte aksies skep wat nie deurlopend loop nie. 'n Tipiese voorbeeld is beeldskaal. Selfs in die geval van verspreide stelsels bly Lambda-funksies relevant.

Dus, as jy nie die toekenning en bestuur van rekenaarhulpbronne wil hanteer nie, probeer AWS Lambda; as jy nie swaar, hulpbron-intensiewe berekeninge nodig het nie, probeer ook AWS Lambda; as jou kode periodiek loop, dit is reg, jy moet AWS Lambda probeer.

sekuriteit

Tot dusver is daar geen klagtes oor veiligheid nie. Aan die ander kant, aangesien baie van die interne prosesse en implementeringskenmerke van hierdie model weggesteek is vir die gebruiker van die AWS Lambda-bestuurde runtime-omgewing, word sommige algemeen aanvaarde reëls van wolksekuriteit irrelevant.

Soos die meeste AWS-dienste, word Lambda verskaf op 'n gedeelde sekuriteit- en voldoeningsbasis tussen AWS en die kliënt. Hierdie beginsel verminder die operasionele las op die kliënt, aangesien AWS die take van die instandhouding, administrasie en monitering van dienskomponente oorneem – van die gasheerbedryfstelsel en die virtualisasielaag tot die fisiese sekuriteit van infrastruktuurbates.

Spesifiek oor AWS Lambda, AWS is verantwoordelik vir die bestuur van die onderliggende infrastruktuur, geassosieerde onderliggende dienste, bedryfstelsel en toepassingsplatform. Terwyl die kliënt verantwoordelik is vir die sekuriteit van sy kode, berging van vertroulike data, beheer van toegang daartoe, sowel as tot die Lambda-diens en hulpbronne (Identity and Access Management, IAM), insluitend binne die perke van die funksies wat gebruik word.

Die diagram hieronder toon die gedeelde verantwoordelikheidsmodel soos dit van toepassing is op AWS Lambda. AWS-verantwoordelikheid is oranje en klante-verantwoordelikheid is blou. Soos u kan sien, neem AWS meer verantwoordelikheid vir die toepassings wat op die diens ontplooi word.

Gedetailleerde ontleding van AWS Lambda

Gedeelde Verantwoordelikheidsmodel Van toepassing op AWS Lambda

Lambda looptyd

Die grootste voordeel van Lambda is dat deur 'n funksie namens jou te verrig, die diens self die nodige hulpbronne toeken. U kan vermy om tyd en moeite op stelseladministrasie te mors en fokus op besigheidslogika en kodering.

Die Lambda-diens word in twee vlakke verdeel. Die eerste is die beheervlak. Volgens Wikipedia is die beheervliegtuig die deel van die netwerk wat verantwoordelik is vir die vervoer van seinverkeer en roetes. Dit is die primêre komponent wat globale besluite neem oor voorsiening, diens en verspreiding van werkladings. Daarbenewens dien die beheervlak as die oplossingsverskaffer se netwerktopologie, verantwoordelik vir die roetering en bestuur van verkeer.

Die tweede vlak is die datavlak. Dit het, soos die beheervliegtuig, sy eie take. Die beheervlak verskaf API's vir die bestuur van funksies (CreateFunction, UpdateFunctionCode) en beheer hoe Lambda met ander AWS-dienste kommunikeer. Die datavlak beheer die Invoke API, wat Lambda-funksies uitvoer. Nadat 'n funksie opgeroep is, ken of kies die beheervlak 'n bestaande runtime-omgewing wat vooraf vir daardie funksie voorberei is, en voer dan die kode daarin uit.

AWS Lambda ondersteun 'n verskeidenheid programmeertale, insluitend Java 8, Python 3.7, Go, NodeJS 8, .NET Core 2, en ander, deur hul onderskeie looptyd-omgewings. AWS dateer hulle gereeld op, versprei sekuriteitskolle en voer ander instandhoudingsaktiwiteite op hierdie omgewings uit. Lambda laat jou toe om ook ander tale te gebruik, mits jy self die toepaslike looptyd implementeer. En dan sal jy moet sorg vir die instandhouding daarvan, insluitend die monitering van die veiligheid daarvan.

Hoe werk dit alles en hoe sal die diens jou funksies verrig?

Elke funksie loop in een of meer toegewyde omgewings, wat slegs vir die lewe van daardie funksie bestaan ​​en dan vernietig word. Elke omgewing maak net een oproep op 'n slag, maar dit word hergebruik as daar verskeie reeksoproepe na dieselfde funksie is. Alle runtime-omgewings loop op virtuele masjiene met hardeware-virtualisering - sogenaamde mikroVM's. Elke mikroVM word aan 'n spesifieke AWS-rekening toegewys en kan deur omgewings hergebruik word om verskillende funksies binne daardie rekening uit te voer. MikroVM's word verpak in boublokke van die Lambda Worker-hardewareplatform, wat deur AWS besit en bedryf word. Dieselfde looptyd kan nie deur verskillende funksies gebruik word nie, en mikroVM's is ook nie uniek aan verskillende AWS-rekeninge nie.

Gedetailleerde ontleding van AWS Lambda

AWS Lambda-isolasiemodel

Isolasie van runtime-omgewings word geïmplementeer deur verskeie meganismes te gebruik. Op die boonste vlak van elke omgewing is daar afsonderlike kopieë van die volgende komponente:

  • Funksie kode
  • Enige Lambda lae gekies vir die funksie
  • Funksie uitvoering omgewing
  • Minimale gebruikersspasie gebaseer op Amazon Linux

Die volgende meganismes word gebruik om verskillende uitvoeringsomgewings te isoleer:

  • cgroups - beperk toegang tot SVE, geheue, berging en netwerkhulpbronne vir elke runtime-omgewing;
  • naamruimtes - groepering proses ID's, gebruiker ID's, netwerk koppelvlakke en ander hulpbronne wat deur die Linux kern bestuur word. Elke looptyd loop in sy eie naamruimte;
  • seccomp-bpf - beperk die stelseloproepe wat in die looptyd gebruik kan word;
  • iptables en roeteringstabelle - isolasie van uitvoeringsomgewings van mekaar;
  • chroot - bied beperkte toegang tot die onderliggende lêerstelsel.

Gekombineer met AWS eie isolasie tegnologieë, verseker hierdie meganismes betroubare runtime skeiding. Omgewings wat op hierdie manier geïsoleer is, kan nie toegang tot data van ander omgewings verkry of dit verander nie.

Alhoewel verskeie looptye van dieselfde AWS-rekening op 'n enkele mikroVM kan loop, kan mikroVM's onder geen omstandighede tussen verskillende AWS-rekeninge gedeel word nie. AWS Lambda gebruik slegs twee meganismes om mikroVM's te isoleer: EC2-gevalle en Firecracker. Gaste-isolasie in Lambda gebaseer op EC2-gevalle bestaan ​​sedert 2015. Firecracker is 'n nuwe oopbron-hypervisor wat spesifiek deur AWS ontwerp is vir bedienerlose werkladings en in 2018 bekendgestel is. Die fisiese hardeware wat mikroVM's gebruik, word tussen werkladings oor verskillende rekeninge gedeel.

Stoor omgewings en prosestoestande

Alhoewel Lambda-looptye uniek is aan verskillende funksies, kan hulle dieselfde funksie herhaaldelik oproep, wat beteken dat die looptyd vir 'n paar uur kan oorleef voordat dit vernietig word.

Elke Lambda-looptyd het ook 'n skryfbare lêerstelsel wat toeganklik is deur die /tmp-gids. Die inhoud daarvan kan nie vanaf ander looptye verkry word nie. Wat prosestoestandvolharding betref, bestaan ​​lêers wat na /tmp geskryf is vir die hele lewensiklus van die looptydomgewing. Dit laat die resultate van veelvuldige oproepe toe om te versamel, wat veral nuttig is vir duur bedrywighede soos om masjienleermodelle te laai.

Bel data-oordrag

Die Invoke API kan in twee modusse gebruik word: gebeurtenismodus en versoek-responsmodus. In gebeurtenismodus word die oproep by 'n tou gevoeg vir latere uitvoering. In versoek-reaksie-modus word die funksie onmiddellik opgeroep met die verskafde loonvrag, waarna die antwoord teruggestuur word. In albei gevalle loop die funksie in 'n Lambda-omgewing, maar met verskillende loonvragpaaie.

Tydens versoek-reaksie-oproepe vloei die loonvrag vanaf 'n versoekverwerking API (API Caller), soos AWS API Gateway of AWS SDK, na die lasbalanseerder, en dan na die Lambda-oproepdiens (Invoke Service). Laasgenoemde bepaal die toepaslike omgewing vir die uitvoering van die funksie en stuur die loonvrag daarheen om die oproep te voltooi. Die lasbalanseerder ontvang TLS-beskermde verkeer oor die internet. Verkeer binne die Lambda-diens – ná die lasbalanseerder – gaan deur 'n interne VPC in 'n spesifieke AWS-streek.

Gedetailleerde ontleding van AWS Lambda

AWS Lambda-oproepverwerkingsmodel: Versoek-reaksie-modus

Gebeurtenisoproepe kan onmiddellik gemaak word of by 'n tou gevoeg word. In sommige gevalle word die tou geïmplementeer met behulp van Amazon SQS (Amazon Simple Queue Service), wat oproepe na die Lambda-oproepvervullingsdiens deur 'n interne pollerproses deurgee. Die oorgedrade verkeer word deur TLS beskerm, en daar is geen bykomende enkripsie van data wat in Amazon SQS gestoor word nie.

Gebeurtenisoproepe gee nie antwoorde nie - die Lambda-werker ignoreer eenvoudig enige reaksie-inligting. Gebeurtenisgebaseerde oproepe vanaf Amazon S3, Amazon SNS, CloudWatch en ander bronne word deur Lambda in gebeurtenismodus verwerk. Oproepe vanaf Amazon Kinesis- en DynamoDB-strome, SQS-rye, Application Load Balancer en API Gateway-oproepe word op 'n versoek-reaksie-wyse verwerk.

Monitering

Jy kan Lambda-funksies monitor en oudit deur 'n verskeidenheid AWS-meganismes en -dienste te gebruik, insluitend die volgende.

amazoncloudwatch
Versamel verskeie statistieke soos die aantal versoeke, die duur van versoeke en die aantal versoeke wat misluk het.

Amazon CloudTrail
Laat jou toe om rekeningaktiwiteitinligting wat met jou AWS-infrastruktuur geassosieer word, aan te teken, deurlopend te monitor en in stand te hou. Jy sal 'n volledige geskiedenis hê van aksies wat uitgevoer word met die AWS Management Console, AWS SDK, opdragreëlnutsgoed en ander AWS-dienste.

AWS X-straal
Bied volledige sigbaarheid in alle stadiums van versoekverwerking in jou aansoek gebaseer op 'n kaart van sy interne komponente. Laat jou toe om toepassings tydens ontwikkeling en in produksie-omgewings te ontleed.

AWS-konfigurasie
Jy sal veranderinge aan Lambda-funksiekonfigurasie (insluitend uitvee) en looptye, etikette, hanteerdername, kodegrootte, geheuetoewysing, uittelinstellings en gelyktydige instellings, sowel as Lambda IAM-uitvoeringsrol, subnetwerk en sekuriteitsgroepbindings kan naspoor. .

Gevolgtrekking

AWS Lambda bied 'n kragtige stel gereedskap vir die bou van veilige en skaalbare toepassings. Baie van die sekuriteit- en voldoeningspraktyke in AWS Lambda is dieselfde as in ander AWS-dienste, hoewel daar uitsonderings is. Vanaf Maart 2019 voldoen Lambda aan SOC 1, SOC 2, SOC 3, PCI DSS, Health Insurance Portability and Accountability Act (HIPAA) nakoming, en ander regulasies. So, wanneer jy daaraan dink om jou volgende toepassing te implementeer, oorweeg die AWS Lambda-diens – dit kan dalk die beste pas vir jou taak.

Bron: will.com

Voeg 'n opmerking