Oversættelsen er specielt udarbejdet til studerende på kurset . Er du interesseret i at udvikle dig inden for dette område? Se Eгор Зуевs masterclass (TeamLead i InBit). og tilmeld dig den nærmeste kursusgruppe: start den 26. september.
Flere og flere mennesker skifter til AWS Lambda på grund af skalerbarhed, ydeevne, omkostningsbesparelser og muligheden for at håndtere millioner og endda billioner af forespørgsler om måneden. Dette kræver ikke, at man administrerer den infrastruktur, som tjenesten kører på. Autoskalering gør det muligt at håndtere tusindvis af samtidige forespørgsler per sekund. Jeg mener, AWS Lambda kan med rette kaldes en af de mest eftertragtede tjenester på AWS.
AWS Lambda
AWS Lambda er en begivenhedsorienteret serverløs computing-tjeneste, der muliggør kørsel af kode uden tildeling og administration af servere og supplerer andre AWS-tjenester baseret på brugerdefineret logik. Lambda reagerer automatisk på forskellige begivenheder (de såkaldte triggere), for eksempel HTTP-anmodninger via Amazon API Gateway, ændring af data i Amazon S3-buckets eller Amazon DynamoDB-tabeller; eller du kan køre din kode via API-opkald ved hjælp af AWS SDK og overgange mellem tilstande i AWS Step Functions.
Lambda kører kode på en højtilgængelig computing-infrastruktur og håndterer fuldt ud administrationen af den underliggende platform, herunder vedligeholdelse af servere og operativsystem, tildeling af ressourcer, automatisk skalering, overvågning af kode og logning. Det vil sige, at du blot skal uploade din kode og indstille, hvordan og hvornår den skal køre. Tjenesten tager sig af at køre den og sikrer høj tilgængelighed for din applikation.
Hvornår skal man skifte til Lambda?
AWS Lambda er en praktisk computing-platform, der passer til mange anvendelsesscenarier, forudsat at sproget og runtime-miljøet for din kode understøttes af tjenesten. Hvis du vil fokusere på kode og forretningslogik og overlade servervedligeholdelse, ressourceallokering og skalering til en tredjepartsleverandør til en rimelig pris, bør du bestemt overveje at skifte til AWS Lambda.
Lambda er ideel til at skabe API'er, og ved at bruge tjenesten sammen med API Gateway kan man markant reducere omkostningerne og komme hurtigere på markedet. Der er forskellige måder at anvende Lambda-funktioner og organisere serverløse arkitekturer på – alle kan vælge noget, der passer til deres mål.
Lambda muliggør en bred vifte af opgaver. Takket være understøttelsen af CloudWatch kan du oprette planlagte opgaver og automatisere forskellige processer. Der er ingen begrænsninger for arten og intensiteten af brugen af tjenesten (huske på hukommelsesforbruget og tiden), og der er ingenting, der forhindrer dig i at arbejde metodisk på en fuldgyldig mikrotjeneste baseret på Lambda.
Her kan man skabe serviceorienterede handlinger, der ikke udføres konstant. Et typisk eksempel er billedskalering. Selv i tilfælde af distribuerede systemer mister Lambda-funktioner ikke deres relevans.
Så hvis du ikke ønsker at bruge tid på at tildele og administrere beregningsressourcer – 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 – så er du helt rigtig, du burde prøve AWS Lambda.
Sikkerhed
Indtil videre har der ikke været klager over sikkerheden. På den anden side, da mange interne processer og detaljer i denne model er skjult for brugere af AWS Lambda's administrerede runtime-miljø, mister nogle almindeligt anerkendte regler for cloud-sikkerhed relevans.
Som de fleste AWS-tjenester leveres Lambda under principperne for delt ansvar mellem AWS og kunden vedrørende sikkerhed og overholdelse af lovgivning. Dette princip reducerer kundens operationelle belastning, da AWS påtager sig opgaver med vedligeholdelse, administration og kontrol af servicens komponenter – fra operativsystemet på værten og virtualiseringsniveauet til den fysiske sikkerhed af infrastrukturens objekter.
Når vi taler specifikt om AWS Lambda, er AWS ansvarlig for at administrere den underliggende infrastruktur, de tilknyttede grundlæggende tjenester, operativsystemet og applikationsplatformen. Mens kunden er ansvarlig for sikkerheden af deres kode, opbevaring af følsomme data, adgangskontrol dertil samt til tjenesten og ressourcerne i Lambda (Identity and Access Management, IAM), herunder inden for de anvendte funktioner.
På diagrammet nedenfor er modellen for delt ansvar, der gælder for AWS Lambda, vist. AWS's ansvar er markeret med orange, mens kundens ansvar er i blå. Som du kan se, tager AWS sig af mere ansvar for applikationer, der implementeres på tjenesten.
Modellen for delt ansvar, der gælder for AWS Lambda
Lambda-runtime
Den primære fordel ved Lambda er, at tjenesten selv tildeler de nødvendige ressourcer, mens den udfører en funktion på dine vegne. Du kan spare tid og kræfter på systemadministration og fokusere på forretningslogik og kodning.
Lambda-tjenesten er delt op i to plan. Den første er kontrolplanen. Ifølge Wikipedia er kontrolplanen den del af netværket, der er ansvarlig for transport af signaltrafik og routning. Den er den primære komponent, der træffer globale beslutninger om tildeling, vedligeholdelse og distribution af arbejdsbelastning. Desuden fungerer kontrolplanen som netværksarkitektur for udbyderen, der er ansvarlig for routning og håndtering af trafik.
Den anden plan er dataplatsen. Den har, ligesom kontrolplanen, sine egne opgaver. Kontrolplanen leverer API'er til administration af funktioner (CreateFunction, UpdateFunctionCode) og kontrollerer interaktionen mellem Lambda og andre AWS-tjenester. Dataplatsen styrer API-anmodninger (Invoke API), der aktiverer Lambda-funktioner. Efter at funktionen er kaldt, tildeler kontrolplanen en ny eller vælger en eksisterende runtime, der er forberedt til denne funktion, og udfører derefter koden i den.
AWS Lambda understøtter mange programmeringssprog, herunder Java 8, Python 3.7, Go, NodeJS 8, .NET Core 2 og andre via de relevante runtime-miljøer. AWS opdaterer regelmæssigt disse, distribuerer sikkerhedsopdateringer og udfører andre vedligeholdelsesopgaver på disse miljøer. Lambda tillader brug af andre sprog, så længe du implementerer det relevante runtime-miljø selv. Og så vil du også være ansvarlig for at vedligeholde det, herunder overvåge sikkerheden.
Hvordan fungerer det hele, og hvordan vil tjenesten udføre dine funktioner?
Hver funktion kører i et eller flere dedikerede miljøer, der kun eksisterer i løbet af livscyklussen for denne funktion og derefter destrueres. I hvert miljø udføres der kun ét kald ad gangen, men det genbruges, hvis der opstår mange sekventielle kald af den samme funktion. Alle runtime-miljøer kører på virtuelle maskiner med hardwarevirtualisering — de såkaldte microVM. Hver microVM tildeles en specifik AWS-konto og kan genbruges af miljøer til at udføre forskellige funktioner i denne konto. MicroVM pakkes ind i de strukturelle enheder af hardwareplatformen Lambda Worker, som ejes og styres af AWS. Det samme runtime-miljø kan ikke bruges af forskellige funktioner, ligesom microVM er unikke for forskellige AWS-konti.
Isoleringsmodellen i AWS Lambda
Isolering af runtime-miljøer er implementeret ved hjælp af flere mekanismer. På det højeste niveau har hvert miljø separate kopier af følgende komponenter:
- Funktionskode
- Eventuelle Lambda-lag, der er valgt til funktionen
- Funktions runtime-miljø
- Minimum brugerrum baseret på Amazon Linux
Følgende mekanismer anvendes til isolering af forskellige runtime-miljøer:
- cgroups — begrænsning af adgang til CPU-ressourcer, hukommelse, båndbredde for lagring og netværk for hvert runtime-miljø;
- namespaces — gruppering af proces-ID'er, bruger-ID'er, netværksinterfaces og andre ressourcer, som Linux-kernen styrer. Hvert runtime-miljø kører i sit eget navnerum;
- seccomp-bpf — begrænsning af systemopkald, der kan anvendes i runtime-miljøet;
- iptables og routingtabel — isolering af runtime-miljøer fra hinanden;
- chroot — begrænsning af adgangen til det underliggende filsystem.
I kombination med AWS's proprietære isoleringsteknologier garanterer de nævnte mekanismer en sikker opdeling af kørselmiljøer. Isolerede miljøer kan ikke få adgang til data fra andre miljøer eller ændre dem.
Selvom flere kørselmiljøer fra én AWS-konto kan køre på én microVM, må microVM'er under ingen omstændigheder deles mellem forskellige AWS-konti. Der anvendes kun to mekanismer til isolering af microVM'er i AWS Lambda: EC2-instanser og Firecracker. Gæste-isoleringen i Lambda baseret på EC2-instanser har været i brug siden 2015. Firecracker er en ny open-source hypervisor, der er specielt designet til serverløse arbejdsbyrder og blev præsenteret i 2018. Det fysiske udstyr, hvorpå microVM'er kører, deles af arbejdsbyrder fra forskellige konti.
Bevaring af miljøer og processtatusser
Selvom kørselmiljøer i Lambda er unikke for forskellige funktioner, kan den samme funktion kaldes flere gange, hvilket betyder, at kørselmiljøet kan eksistere i flere timer, før det bliver ødelagt.
I hver Lambda-kørselmiljø er der også et skrivebart filsystem tilgængeligt via kataloget /tmp. Dets indhold kan ikke tilgås fra andre kørselmiljøer. Med hensyn til bevaring af processtatusser eksisterer de filer, der skrives i /tmp, gennem hele livscyklussen for kørselmiljøet. Dette gør det muligt at akkumulere resultaterne af flere kald, hvilket især er nyttigt for ressourcekrævende operationer, såsom indlæsning af maskinlæringsmodeller.
Overførsel af data ved opkald
Invoke API-grænsefladen kan aktiveres i to tilstande: i events-tilstand og i request-response-tilstand. I events-tilstand tilføjes opkaldet til en kø for senere udførelse. I request-response-tilstand kaldes funktionen straks med den angivne nyttelast, hvorefter et svar returneres. I begge tilfælde udføres funktionen i Lambda-miljøet, men med forskellige veje for nyttelasten.
Under type 'request-response' calls, the payload comes from a request processing API (API Caller), such as AWS API Gateway or AWS SDK, into the load balancer, and then to the Lambda function execution service (Invoke Service). The latter determines the appropriate environment to execute the function and passes the payload there to complete the call. The load balancer receives traffic with TLS protection over the Internet. Traffic within the Lambda service—after the load balancer—travels through an internal VPC in a specific AWS region.
AWS Lambda Call Processing Model: 'request-response' mode
Event-based calls can be executed immediately or queued. In some cases, the queue is implemented using Amazon SQS (Amazon Simple Queue Service), which passes the calls to the Lambda function execution service via an internal polling process. The transmitted traffic is protected by TLS, while no additional data encryption for information stored in Amazon SQS is provided.
Event calls do not return responses—the Lambda Worker simply ignores any response information. Calls based on events from Amazon S3, Amazon SNS, CloudWatch, and other sources are processed by Lambda in event mode. Calls from Amazon Kinesis streams and DynamoDB, SQS queue calls, application load balancer, and API Gateway are processed in 'request-response' mode.
Overvågning
You can monitor and audit Lambda functions using various AWS mechanisms and services, including the following.
Amazon CloudWatch
Collects various statistics such as the number of requests, the duration of request execution, and the number of requests that have failed.
Amazon CloudTrail
Allows logging, continuous monitoring, and storing activity information in your account related to your AWS infrastructure. You will have a complete timeline of actions performed using the AWS Management Console, AWS SDK, command-line tools, and other AWS services.
AWS X-Ray
Provides complete visibility into all stages of request processing in your application based on its internal component map. Allows for application analysis during development and in the production environment.
AWS Config
Du kan spore ændringer i konfigurationen af Lambda-funktioner (inklusive deres sletning) samt runtime, tags, handler-navne, kode størrelse, hukommelsesfordeling, timeout-indstillinger, og parallelisme parametre, såvel som IAM-execution rolle for Lambda, subnets, og sikkerhedsgrupper bindings.
Konklusion
AWS Lambda tilbyder et kraftfuldt sæt værktøjer til at opbygge sikre og skalerbare applikationer. Mange sikkerheds- og overholdelsesmetoder i AWS Lambda ligner dem, der anvendes i andre AWS-tjenester, selvom der er undtagelser. Pr. marts 2019 overholder Lambda kravene til SOC 1, SOC 2, SOC 3, PCI DSS, den amerikanske lov om medfør og ansvar for medicinsk forsikring (HIPAA) og andre regler. Derfor, når du overvejer implementeringen af en ny applikation, bør du overveje AWS Lambda — det kan være den perfekte løsning til dit behov.
Kilde: habr.com
