Oversettelsen av artikkelen ble utarbeidet spesielt for studentene på kurset . Interessert i å utvikle seg i denne retningen? Se mesterklassen av Egor Zuev (TeamLead hos InBit) og bli med i neste kursgruppe: starter 26. september.
Flere mennesker migrerer til AWS Lambda for skalerbarhet, ytelse, besparelser og muligheten til å håndtere millioner eller til og med billioner av forespørsler per måned. For å gjøre dette trenger du ikke å administrere infrastrukturen som tjenesten kjører på. Og autoskalering lar deg betjene tusenvis av samtidige forespørsler per sekund. Jeg tror AWS Lambda med rette kan kalles en av de mest populære AWS-tjenestene.
AWS Lambda
AWS Lambda er en hendelsesdrevet serverløs databehandlingstjeneste som lar deg kjøre kode uten å klargjøre eller administrere servere og utvide andre AWS-tjenester ved hjelp av tilpasset logikk. Lambda reagerer automatisk på ulike hendelser (kalt triggere), for eksempel HTTP-forespørsler gjennom Amazon API Gateway, endringer i data i Amazon S3-bøtter eller Amazon DynamoDB-tabeller; eller du kan kjøre koden din gjennom API-kall ved å bruke AWS SDK og tilstandsoverganger i AWS Step Functions.
Lambda kjører kode på en svært tilgjengelig datainfrastruktur og er fullt ansvarlig for å administrere den underliggende plattformen, inkludert vedlikehold av server og operativsystem, ressursforsyning, automatisk skalering, kodeovervåking og logging. Det vil si, du trenger bare å laste opp koden din og konfigurere hvordan og når den skal kjøres. Tjenesten vil på sin side ta seg av lanseringen og sikre høy tilgjengelighet av applikasjonen din.
Når skal du bytte til Lambda?
AWS Lambda er en praktisk dataplattform som passer for en rekke brukstilfeller, så lenge språket og kjøretiden til koden din støttes av tjenesten. Hvis du ønsker å fokusere på koden og forretningslogikken din mens du outsourcer servervedlikehold, klargjøring og skalering til en rimelig pris, er AWS Lambda definitivt veien å gå.
Lambda er ideell for å lage programmeringsgrensesnitt, og når den brukes sammen med API Gateway, kan du redusere kostnadene betydelig og komme raskere ut på markedet. Det er forskjellige måter å bruke Lambda-funksjoner og alternativer for å organisere en serverløs arkitektur - alle kan velge noe som passer ut fra målet sitt.
Lambda lar deg utføre et bredt spekter av oppgaver. Dermed kan du, takket være CloudWatch-støtte, opprette utsatte oppgaver og automatisere individuelle prosesser. Det er ingen begrensninger på arten og intensiteten av bruken av tjenesten (minneforbruk og tid er tatt i betraktning), og ingenting hindrer deg i å systematisk jobbe med en fullverdig mikrotjeneste basert på Lambda.
Her kan du lage tjenesteorienterte handlinger som ikke kjører kontinuerlig. Et typisk eksempel er bildeskalering. Selv når det gjelder distribuerte systemer, forblir Lambda-funksjoner relevante.
Så hvis du ikke ønsker å håndtere tildeling og administrasjon av dataressurser, prøv AWS Lambda; hvis du ikke trenger tunge, ressurskrevende beregninger, prøv også AWS Lambda; hvis koden din kjører med jevne mellomrom, det er riktig, bør du prøve AWS Lambda.
Безопасность
Så langt er det ingen klager på sikkerheten. På den annen side, siden mange av de interne prosessene og implementeringsfunksjonene til denne modellen er skjult for brukeren av det AWS Lambda-administrerte kjøretidsmiljøet, blir noen generelt aksepterte regler for skysikkerhet irrelevante.
Som de fleste AWS-tjenester, leveres Lambda på en delt sikkerhet og samsvarsbasis mellom AWS og kunden. Dette prinsippet reduserer den operasjonelle byrden på klienten, siden AWS tar på seg oppgavene med å vedlikeholde, administrere og overvåke tjenestekomponenter – fra vertsoperativsystemet og virtualiseringslaget til den fysiske sikkerheten til infrastrukturressurser.
Når det gjelder AWS Lambda, er AWS ansvarlig for å administrere den underliggende infrastrukturen, tilhørende underliggende tjenester, operativsystem og applikasjonsplattform. Mens klienten er ansvarlig for sikkerheten til koden sin, lagrer konfidensielle data, kontrollerer tilgangen til den, samt til Lambda-tjenesten og ressursene (Identity and Access Management, IAM), inkludert innenfor grensene for funksjonene som brukes.
Diagrammet under viser delt ansvarsmodellen slik den gjelder for AWS Lambda. AWS-ansvar er oransje og kundeansvar er blått. Som du kan se, tar AWS mer ansvar for applikasjonene som er distribuert på tjenesten.
Delt ansvarsmodell Gjelder for AWS Lambda
Lambda kjøretid
Den største fordelen med Lambda er at ved å utføre en funksjon på dine vegne, tildeler tjenesten selv de nødvendige ressursene. Du kan unngå å kaste bort tid og krefter på systemadministrasjon og fokusere på forretningslogikk og koding.
Lambdatjenesten er delt inn i to fly. Den første er kontrollplanet. I følge Wikipedia er kontrollflyet den delen av nettverket som er ansvarlig for transport av signaltrafikk og ruting. Det er den primære komponenten som tar globale beslutninger om klargjøring, service og distribusjon av arbeidsbelastninger. I tillegg fungerer kontrollplanet som løsningsleverandørens nettverkstopologi, ansvarlig for ruting og styring av trafikk.
Det andre planet er dataplanet. Det har i likhet med kontrollflyet sine egne oppgaver. Kontrollplanet gir APIer for å administrere funksjoner (CreateFunction, UpdateFunctionCode) og kontrollerer hvordan Lambda kommuniserer med andre AWS-tjenester. Dataplanet styrer Invoke API, som kjører Lambda-funksjoner. Etter at en funksjon er kalt, tildeler eller velger kontrollplanet et eksisterende kjøretidsmiljø som er forhåndsforberedt for den funksjonen, og kjører deretter koden i den.
AWS Lambda støtter en rekke programmeringsspråk, inkludert Java 8, Python 3.7, Go, NodeJS 8, .NET Core 2 og andre, gjennom deres respektive kjøretidsmiljøer. AWS oppdaterer dem regelmessig, distribuerer sikkerhetsoppdateringer og utfører andre vedlikeholdsaktiviteter på disse miljøene. Lambda lar deg bruke andre språk også, forutsatt at du implementerer riktig kjøretid selv. Og så må du ta vare på vedlikeholdet, inkludert overvåking av sikkerheten.
Hvordan fungerer det hele og hvordan vil tjenesten utføre dine funksjoner?
Hver funksjon kjører i ett eller flere dedikerte miljøer, som bare eksisterer så lenge funksjonen varer og deretter blir ødelagt. Hvert miljø foretar kun ett anrop om gangen, men det gjenbrukes hvis det er flere serieanrop til samme funksjon. Alle runtime-miljøer kjører på virtuelle maskiner med maskinvarevirtualisering – såkalte microVM-er. Hver microVM er tilordnet en spesifikk AWS-konto og kan gjenbrukes av miljøer for å utføre forskjellige funksjoner innenfor den kontoen. MicroVM-er er pakket inn i byggeklossene til Lambda Worker-maskinvareplattformen, som eies og drives av AWS. Den samme kjøretiden kan ikke brukes av forskjellige funksjoner, og mikroVM-er er heller ikke unike for forskjellige AWS-kontoer.
AWS Lambda isolasjonsmodell
Isolering av kjøretidsmiljøer implementeres ved hjelp av flere mekanismer. På toppnivået i hvert miljø er det separate kopier av følgende komponenter:
- Funksjonskode
- Alle lambdalag valgt for funksjonen
- Funksjonsutførelsesmiljø
- Minimal brukerplass basert på Amazon Linux
Følgende mekanismer brukes til å isolere ulike utførelsesmiljøer:
- cgroups - begrense tilgangen til CPU, minne, lagring og nettverksressurser for hvert kjøretidsmiljø;
- navneområder - gruppering av prosess-IDer, bruker-IDer, nettverksgrensesnitt og andre ressurser administrert av Linux-kjernen. Hver kjøretid kjører i sitt eget navneområde;
- seccomp-bpf - begrenser systemanropene som kan brukes i kjøretiden;
- iptables og rutingtabeller - isolering av utførelsesmiljøer fra hverandre;
- chroot - gir begrenset tilgang til det underliggende filsystemet.
Kombinert med AWS proprietære isolasjonsteknologier, sikrer disse mekanismene pålitelig separasjon under kjøretid. Miljøer isolert på denne måten kan ikke få tilgang til eller endre data fra andre miljøer.
Selv om flere kjøretider for samme AWS-konto kan kjøres på en enkelt microVM, kan mikroVM-er under ingen omstendigheter deles mellom forskjellige AWS-kontoer. AWS Lambda bruker bare to mekanismer for å isolere mikroVM-er: EC2-forekomster og Firecracker. Gjesteisolasjon i Lambda basert på EC2-forekomster har eksistert siden 2015. Firecracker er en ny åpen kildekode-hypervisor spesielt designet av AWS for serverløse arbeidsbelastninger og introdusert i 2018. Den fysiske maskinvaren som kjører microVM-er deles mellom arbeidsbelastninger på tvers av forskjellige kontoer.
Lagre miljøer og prosesstilstander
Selv om Lambda-kjøringstider er unike for forskjellige funksjoner, kan de kalle den samme funksjonen gjentatte ganger, noe som betyr at kjøretiden kan overleve i flere timer før den blir ødelagt.
Hver Lambda-kjøretid har også et skrivbart filsystem som er tilgjengelig via /tmp-katalogen. Innholdet kan ikke nås fra andre kjøretider. Når det gjelder vedvarende prosesstilstand, eksisterer filer skrevet til /tmp for hele livssyklusen til kjøretidsmiljøet. Dette gjør at resultatene fra flere samtaler kan akkumuleres, noe som er spesielt nyttig for dyre operasjoner som lasting av maskinlæringsmodeller.
Samtaledataoverføring
Invoke API kan brukes i to moduser: hendelsesmodus og forespørsel-svar-modus. I hendelsesmodus legges anropet til en kø for senere utførelse. I forespørsel-svar-modus kalles funksjonen opp umiddelbart med den oppgitte nyttelasten, hvoretter svaret returneres. I begge tilfeller kjører funksjonen i et Lambda-miljø, men med forskjellige nyttelastbaner.
Under forespørsel-svar-anrop flyter nyttelasten fra en forespørselsbehandlings-API (API Caller), for eksempel AWS API Gateway eller AWS SDK, til lastbalanseren og deretter til Lambda-anropstjenesten (Invoke Service). Sistnevnte bestemmer et passende miljø for å utføre funksjonen og sender nyttelasten dit for å fullføre anropet. Lastbalanseren mottar TLS-beskyttet trafikk over Internett. Trafikk innenfor Lambda-tjenesten – etter lastbalanseren – går gjennom en intern VPC i en spesifikk AWS-region.
AWS Lambda Call Processing Model: Request-Response Mode
Eventanrop kan foretas umiddelbart eller legges til i en kø. I noen tilfeller implementeres køen ved hjelp av Amazon SQS (Amazon Simple Queue Service), som sender anrop til Lambda-anropsoppfyllingstjenesten gjennom en intern pollerprosess. Den overførte trafikken er beskyttet av TLS, og det er ingen ekstra kryptering av data som er lagret i Amazon SQS.
Hendelsesanrop gir ikke svar – Lambda-arbeideren ignorerer ganske enkelt all responsinformasjon. Hendelsesbaserte anrop fra Amazon S3, Amazon SNS, CloudWatch og andre kilder behandles av Lambda i hendelsesmodus. Anrop fra Amazon Kinesis- og DynamoDB-strømmer, SQS-køer, Application Load Balancer og API-gateway-anrop behandles på en forespørsel-svar-måte.
overvåking
Du kan overvåke og revidere Lambda-funksjoner ved å bruke en rekke AWS-mekanismer og tjenester, inkludert følgende.
Amazon CloudWatch
Samler inn ulike statistikker som antall forespørsler, varigheten av forespørsler og antall forespørsler som mislyktes.
Amazon CloudTrail
Lar deg logge, kontinuerlig overvåke og vedlikeholde kontoaktivitetsinformasjon knyttet til AWS-infrastrukturen din. Du vil ha en fullstendig historikk over handlinger utført ved hjelp av AWS Management Console, AWS SDK, kommandolinjeverktøy og andre AWS-tjenester.
AWS røntgen
Gir fullstendig innsyn i alle stadier av forespørselsbehandlingen i søknaden din basert på et kart over dens interne komponenter. Lar deg analysere applikasjoner under utvikling og i produksjonsmiljøer.
AWS-konfig
Du vil kunne spore endringer i konfigurasjon av Lambda-funksjonen (inkludert sletting) og kjøretider, tagger, behandlernavn, kodestørrelse, minneallokering, tidsavbruddsinnstillinger og samtidighetsinnstillinger, samt Lambda IAM-utførelsesrolle, subnetting og sikkerhetsgruppebindinger .
Konklusjon
AWS Lambda tilbyr et kraftig sett med verktøy for å bygge sikre og skalerbare applikasjoner. Mange av praksisene for sikkerhet og samsvar i AWS Lambda er de samme som i andre AWS-tjenester, selv om det finnes unntak. Fra mars 2019 er Lambda i samsvar med SOC 1, SOC 2, SOC 3, PCI DSS, Health Insurance Portability and Accountability Act (HIPAA) og andre forskrifter. Så når du tenker på å implementere din neste applikasjon, bør du vurdere AWS Lambda-tjenesten - den kan være den beste egnet for oppgaven din.
Kilde: www.habr.com