Oversættelsen af artiklen er udarbejdet specifikt til kursets studerende . Interesseret i at udvikle dig i denne retning? Se mesterklassen af Egor Zuev (TeamLead hos InBit) og kom med i næste kursusgruppe: starter 26. september.
Flere mennesker migrerer til AWS Lambda for skalerbarhed, ydeevne, besparelser og evnen til at håndtere millioner eller endda billioner af anmodninger om måneden. For at gøre dette behøver du ikke at administrere den infrastruktur, som tjenesten kører på. Og autoskalering giver dig mulighed for at betjene tusindvis af samtidige anmodninger i sekundet. Jeg tror, at AWS Lambda med rette kan kaldes en af de mest populære AWS-tjenester.
AWS Lambda
AWS Lambda er en hændelsesdrevet serverløs computertjeneste, der giver dig mulighed for at køre kode uden at klargøre eller administrere servere og udvide andre AWS-tjenester ved hjælp af tilpasset logik. Lambda reagerer automatisk på forskellige hændelser (kaldet triggere), såsom HTTP-anmodninger gennem Amazon API Gateway, ændringer af data i Amazon S3-buckets eller Amazon DynamoDB-tabeller; eller du kan køre din kode gennem API-kald ved hjælp af AWS SDK og tilstandsovergange i AWS Step Functions.
Lambda kører kode på en meget tilgængelig computerinfrastruktur og er fuldt ansvarlig for at administrere den underliggende platform, herunder server- og operativsystemvedligeholdelse, ressourceforsyning, automatisk skalering, kodeovervågning og logning. Det vil sige, du skal blot uploade din kode og konfigurere hvordan og hvornår den skal udføres. Til gengæld vil tjenesten tage sig af sin lancering og sikre høj tilgængelighed af din applikation.
Hvornår skal man skifte til Lambda?
AWS Lambda er en bekvem computerplatform, der er velegnet til en række forskellige brugssager, så længe sproget og kørselstiden for din kode understøttes af tjenesten. Hvis du vil fokusere på din kode og forretningslogik, mens du outsourcer servervedligeholdelse, provisionering og skalering til en rimelig pris, er AWS Lambda bestemt vejen at gå.
Lambda er ideel til at skabe programmeringsgrænseflader, og når det bruges sammen med API Gateway, kan du reducere omkostningerne betydeligt og komme hurtigere på markedet. Der er forskellige måder at bruge Lambda-funktioner og muligheder for at organisere en serverløs arkitektur - alle kan vælge noget passende ud fra deres mål.
Lambda giver dig mulighed for at udføre en lang række opgaver. Takket være CloudWatch-support kan du således oprette udskudte opgaver og automatisere individuelle processer. Der er ingen begrænsninger på arten og intensiteten af brugen af tjenesten (hukommelsesforbrug og tid er taget i betragtning), og intet forhindrer dig i systematisk at arbejde på en fuldgyldig mikroservice baseret på Lambda.
Her kan du lave serviceorienterede handlinger, der ikke kører kontinuerligt. Et typisk eksempel er billedskalering. Selv i tilfælde af distribuerede systemer forbliver Lambda-funktioner relevante.
Så hvis du ikke ønsker at beskæftige dig med at allokere og administrere computerressourcer, så prøv AWS Lambda; hvis du ikke har brug for tunge, ressourcekrævende beregninger, så prøv også AWS Lambda; hvis din kode kører periodisk, det er rigtigt, bør du prøve AWS Lambda.
Безопасность
Indtil videre er der ingen klager over sikkerheden. På den anden side, da mange af de interne processer og implementeringsfunktioner i denne model er skjult for brugeren af det AWS Lambda-styrede runtime-miljø, bliver nogle generelt accepterede regler for cloud-sikkerhed irrelevante.
Som de fleste AWS-tjenester leveres Lambda på en delt sikkerheds- og compliancebasis mellem AWS og kunden. Dette princip reducerer den operationelle byrde på klienten, da AWS påtager sig opgaverne med at vedligeholde, administrere og overvåge servicekomponenter - fra værtsoperativsystemet og virtualiseringslaget til den fysiske sikkerhed af infrastrukturaktiver.
Specifikt taler om AWS Lambda, AWS er ansvarlig for at administrere den underliggende infrastruktur, tilhørende underliggende tjenester, operativsystem og applikationsplatform. Mens klienten er ansvarlig for sikkerheden af sin kode, lagring af fortrolige data, kontrol af adgangen til den, samt til Lambda-tjenesten og ressourcer (Identity and Access Management, IAM), herunder inden for grænserne af de anvendte funktioner.
Diagrammet nedenfor viser modellen med delt ansvar, som den gælder for AWS Lambda. AWS-ansvar er orange, og kundeansvar er blåt. Som du kan se, tager AWS mere ansvar for de applikationer, der er installeret på tjenesten.
Delt ansvarsmodel Gælder for AWS Lambda
Lambda køretid
Den største fordel ved Lambda er, at ved at udføre en funktion på dine vegne, tildeler tjenesten selv de nødvendige ressourcer. Du kan undgå at spilde tid og kræfter på systemadministration og fokusere på forretningslogik og kodning.
Lambda-tjenesten er opdelt i to fly. Den første er kontrolplanet. Ifølge Wikipedia er kontrolflyet den del af netværket, der er ansvarlig for transport af signaltrafik og routing. Det er den primære komponent, der træffer globale beslutninger om klargøring, servicering og distribution af arbejdsbelastninger. Derudover fungerer kontrolplanet som løsningsudbyderens netværkstopologi, ansvarlig for routing og styring af trafik.
Det andet plan er dataplanet. Det har ligesom kontrolflyet sine egne opgaver. Kontrolplanet giver API'er til styring af funktioner (CreateFunction, UpdateFunctionCode) og styrer, hvordan Lambda kommunikerer med andre AWS-tjenester. Dataplanet styrer Invoke API, som kører Lambda-funktioner. Efter at en funktion er kaldt, allokerer eller vælger kontrolplanet et eksisterende runtime-miljø, der er forberedt på den pågældende funktion, og udfører derefter koden i det.
AWS Lambda understøtter en række programmeringssprog, herunder Java 8, Python 3.7, Go, NodeJS 8, .NET Core 2 og andre, gennem deres respektive runtime-miljøer. AWS opdaterer dem regelmæssigt, distribuerer sikkerhedsrettelser og udfører andre vedligeholdelsesaktiviteter på disse miljøer. Lambda giver dig mulighed for også at bruge andre sprog, forudsat at du selv implementerer den passende runtime. Og så skal du sørge for dens vedligeholdelse, herunder overvågning af dens sikkerhed.
Hvordan fungerer det hele, og hvordan vil tjenesten udføre dine funktioner?
Hver funktion kører i et eller flere dedikerede miljøer, som kun eksisterer i denne funktions levetid og derefter ødelægges. Hvert miljø foretager kun ét opkald ad gangen, men det genbruges, hvis der er flere serielle opkald til den samme funktion. Alle runtime-miljøer kører på virtuelle maskiner med hardwarevirtualisering – såkaldte microVM'er. Hver microVM er tildelt en specifik AWS-konto og kan genbruges af miljøer til at udføre forskellige funktioner på den konto. MicroVM'er er pakket ind i byggeklodser af Lambda Worker hardwareplatformen, som ejes og drives af AWS. Den samme runtime kan ikke bruges af forskellige funktioner, og microVM'er er heller ikke unikke for forskellige AWS-konti.
AWS Lambda isolationsmodel
Isolering af runtime-miljøer implementeres ved hjælp af flere mekanismer. På øverste niveau i hvert miljø er der separate kopier af følgende komponenter:
- Funktionskode
- Eventuelle lambdalag valgt til funktionen
- Funktionsudførelsesmiljø
- Minimal brugerplads baseret på Amazon Linux
Følgende mekanismer bruges til at isolere forskellige eksekveringsmiljøer:
- cgroups - begrænse adgangen til CPU, hukommelse, lager og netværksressourcer for hvert runtime miljø;
- navnerum - gruppering af proces-id'er, bruger-id'er, netværksgrænseflader og andre ressourcer, der administreres af Linux-kernen. Hver runtime kører i sit eget navneområde;
- seccomp-bpf - begrænser de systemkald, der kan bruges i kørselstiden;
- iptables og routing-tabeller - isolering af eksekveringsmiljøer fra hinanden;
- chroot - giver begrænset adgang til det underliggende filsystem.
Kombineret med AWS proprietære isolationsteknologier sikrer disse mekanismer pålidelig runtime-separation. Miljøer, der er isoleret på denne måde, kan ikke få adgang til eller ændre data fra andre miljøer.
Selvom flere runtimes af den samme AWS-konto kan køre på en enkelt microVM, kan mikroVM'er under ingen omstændigheder deles mellem forskellige AWS-konti. AWS Lambda bruger kun to mekanismer til at isolere microVM'er: EC2-instanser og Firecracker. Gæsteisolation i Lambda baseret på EC2-forekomster har eksisteret siden 2015. Firecracker er en ny open source hypervisor specielt designet af AWS til serverløse arbejdsbelastninger og introduceret i 2018. Den fysiske hardware, der kører microVM'er, deles mellem arbejdsbelastninger på tværs af forskellige konti.
Lagring af miljøer og procestilstande
Selvom Lambda-kørselstider er unikke for forskellige funktioner, kan de kalde den samme funktion gentagne gange, hvilket betyder, at køretiden kan overleve i flere timer, før den bliver ødelagt.
Hver Lambda-runtime har også et skrivbart filsystem, der er tilgængeligt via /tmp-mappen. Dens indhold kan ikke tilgås fra andre kørselstider. Hvad angår procestilstandspersistens, eksisterer filer skrevet til /tmp for hele livscyklussen af runtime-miljøet. Dette gør det muligt at akkumulere resultaterne af flere opkald, hvilket især er nyttigt til dyre operationer, såsom indlæsning af maskinlæringsmodeller.
Opkaldsdataoverførsel
Invoke API kan bruges i to tilstande: hændelsestilstand og anmodning-svar-tilstand. I hændelsestilstand føjes opkaldet til en kø til senere udførelse. I anmodning-svar-tilstand kaldes funktionen øjeblikkeligt med den leverede nyttelast, hvorefter svaret returneres. I begge tilfælde kører funktionen i et Lambda-miljø, men med forskellige nyttelastveje.
Under anmodningssvar-opkald flyder nyttelasten fra en anmodningsbehandlings-API (API Caller), såsom AWS API Gateway eller AWS SDK, til belastningsbalanceren og derefter til Lambda-opkaldstjenesten (Invoke Service). Sidstnævnte bestemmer det passende miljø til at udføre funktionen og sender nyttelasten dertil for at fuldføre opkaldet. Loadbalanceren modtager TLS-beskyttet trafik over internettet. Trafik inden for Lambda-tjenesten – efter belastningsbalanceren – passerer gennem en intern VPC i en specifik AWS-region.
AWS Lambda Call Processing Model: Request-Response Mode
Eventopkald kan foretages med det samme eller tilføjes til en kø. I nogle tilfælde implementeres køen ved hjælp af Amazon SQS (Amazon Simple Queue Service), som videresender opkald til Lambda-opkaldsudførelsestjenesten gennem en intern poller-proces. Den transmitterede trafik er beskyttet af TLS, og der er ingen yderligere kryptering af data gemt i Amazon SQS.
Hændelseskald returnerer ikke svar - Lambda-arbejderen ignorerer simpelthen enhver svarinformation. Hændelsesbaserede opkald fra Amazon S3, Amazon SNS, CloudWatch og andre kilder behandles af Lambda i hændelsestilstand. Opkald fra Amazon Kinesis- og DynamoDB-streams, SQS-køer, Application Load Balancer og API Gateway-opkald behandles på en anmodning-svar-måde.
overvågning
Du kan overvåge og revidere Lambda-funktioner ved hjælp af en række AWS-mekanismer og -tjenester, herunder følgende.
amazoncloudwatch
Indsamler forskellige statistikker såsom antallet af anmodninger, varigheden af anmodninger og antallet af anmodninger, der mislykkedes.
Amazon CloudTrail
Giver dig mulighed for at logge, løbende overvåge og vedligeholde oplysninger om kontoaktivitet forbundet med din AWS-infrastruktur. Du vil have en komplet historie over handlinger udført ved hjælp af AWS Management Console, AWS SDK, kommandolinjeværktøjer og andre AWS-tjenester.
AWS røntgen
Giver komplet synlighed i alle faser af anmodningsbehandling i din ansøgning baseret på et kort over dens interne komponenter. Giver dig mulighed for at analysere applikationer under udvikling og i produktionsmiljøer.
AWS-konfig
Du vil være i stand til at spore ændringer af Lambda-funktionskonfiguration (inklusive sletning) og kørselstider, tags, handlernavne, kodestørrelse, hukommelsestildeling, timeout-indstillinger og samtidighedsindstillinger samt Lambda IAM-udførelsesrolle, undernet og sikkerhedsgruppebindinger .
Konklusion
AWS Lambda tilbyder et kraftfuldt sæt værktøjer til at bygge sikre og skalerbare applikationer. Mange af praksisserne for sikkerhed og overholdelse i AWS Lambda er de samme som i andre AWS-tjenester, selvom der er undtagelser. Fra marts 2019 er Lambda i overensstemmelse med SOC 1, SOC 2, SOC 3, PCI DSS, Health Insurance Portability and Accountability Act (HIPAA) og andre regler. Så når du overvejer at implementere din næste applikation, så overvej AWS Lambda-tjenesten – den passer måske bedst til din opgave.
Kilde: www.habr.com