Översättningen av artikeln förbereddes speciellt för kursens studenter . Intresserad av att utvecklas i denna riktning? Se mästarklassen av Egor Zuev (TeamLead på InBit) och gå med i nästa kursgrupp: startar den 26 september.
Fler människor migrerar till AWS Lambda för skalbarhet, prestanda, besparingar och förmågan att hantera miljontals eller till och med biljoner förfrågningar per månad. För att göra detta behöver du inte hantera infrastrukturen som tjänsten körs på. Och automatisk skalning låter dig betjäna tusentals samtidiga förfrågningar per sekund. Jag tror att AWS Lambda med rätta kan kallas en av de mest populära AWS-tjänsterna.
AWS Lambda
AWS Lambda är en händelsedriven serverlös datortjänst som låter dig köra kod utan att tillhandahålla eller hantera servrar och utöka andra AWS-tjänster med hjälp av anpassad logik. Lambda svarar automatiskt på olika händelser (kallade triggers), såsom HTTP-förfrågningar via Amazon API Gateway, ändringar av data i Amazon S3-buckets eller Amazon DynamoDB-tabeller; eller så kan du köra din kod genom API-anrop med AWS SDK och tillståndsövergångar i AWS Step Functions.
Lambda kör kod på en mycket tillgänglig datorinfrastruktur och är fullt ansvarig för att administrera den underliggande plattformen, inklusive underhåll av server och operativsystem, resursförsörjning, automatisk skalning, kodövervakning och loggning. Det vill säga, du behöver bara ladda upp din kod och konfigurera hur och när den ska köras. Tjänsten kommer i sin tur att ta hand om lanseringen och säkerställa hög tillgänglighet för din applikation.
När ska man byta till Lambda?
AWS Lambda är en bekväm datorplattform som är lämplig för en mängd olika användningsfall, så länge som språket och körtiden för din kod stöds av tjänsten. Om du vill fokusera på din kod och affärslogik samtidigt som du outsourcar serverunderhåll, provisionering och skalning till en rimlig kostnad, är AWS Lambda definitivt rätt väg att gå.
Lambda är idealiskt för att skapa programmeringsgränssnitt, och när det används i kombination med API Gateway kan du minska kostnaderna avsevärt och komma ut på marknaden snabbare. Det finns olika sätt att använda Lambda-funktioner och alternativ för att organisera en serverlös arkitektur – alla kan välja något som passar utifrån sitt mål.
Lambda låter dig utföra ett brett utbud av uppgifter. Tack vare CloudWatch-stödet kan du alltså skapa uppskjutna uppgifter och automatisera individuella processer. Det finns inga begränsningar för tjänstens art och intensitet (minnesförbrukning och tid beaktas), och ingenting hindrar dig från att systematiskt arbeta på en fullfjädrad mikrotjänst baserad på Lambda.
Här kan du skapa serviceinriktade åtgärder som inte körs kontinuerligt. Ett typiskt exempel är bildskalning. Även i fallet med distribuerade system förblir Lambda-funktioner relevanta.
Så om du inte vill ta itu med allokering och hantering av datorresurser, prova AWS Lambda; om du inte behöver tunga, resurskrävande beräkningar, prova även AWS Lambda; om din kod körs med jämna mellanrum, det stämmer, bör du prova AWS Lambda.
Безопасность
Än så länge finns det inga klagomål på säkerheten. Å andra sidan, eftersom många av de interna processerna och implementeringsfunktionerna i denna modell är dolda för användaren av den AWS Lambda-hanterade runtime-miljön, blir vissa allmänt accepterade regler för molnsäkerhet irrelevanta.
Liksom de flesta AWS-tjänster tillhandahålls Lambda på en delad säkerhet och efterlevnadsbasis mellan AWS och kunden. Denna princip minskar den operativa bördan för klienten, eftersom AWS tar på sig uppgifterna att underhålla, administrera och övervaka tjänstekomponenter - från värdoperativsystemet och virtualiseringslagret till den fysiska säkerheten för infrastrukturtillgångar.
När det gäller AWS Lambda, är AWS ansvarig för att hantera den underliggande infrastrukturen, tillhörande underliggande tjänster, operativsystem och applikationsplattform. Medan klienten ansvarar för säkerheten för sin kod, lagrar konfidentiell data, kontrollerar åtkomsten till den, såväl som till Lambda-tjänsten och resurserna (Identity and Access Management, IAM), inklusive inom gränserna för de funktioner som används.
Diagrammet nedan visar modellen för delat ansvar som den gäller för AWS Lambda. AWS ansvar är orange och kundansvar är blått. Som du kan se tar AWS mer ansvar för applikationerna som distribueras på tjänsten.
Modell för delat ansvar Gäller AWS Lambda
Lambda körtid
Den största fördelen med Lambda är att genom att utföra en funktion för din räkning allokerar tjänsten själv de nödvändiga resurserna. Du kan undvika att slösa tid och kraft på systemadministration och fokusera på affärslogik och kodning.
Lambdatjänsten är uppdelad i två plan. Det första är kontrollplanet. Enligt Wikipedia är kontrollplanet den del av nätverket som ansvarar för att transportera signaltrafik och routing. Det är den primära komponenten som fattar globala beslut om provisionering, service och distribution av arbetsbelastningar. Dessutom fungerar kontrollplanet som lösningsleverantörens nätverkstopologi, ansvarig för dirigering och hantering av trafik.
Det andra planet är dataplanet. Det har liksom kontrollplanet sina egna uppgifter. Kontrollplanet tillhandahåller API:er för att hantera funktioner (CreateFunction, UpdateFunctionCode) och styr hur Lambda kommunicerar med andra AWS-tjänster. Dataplanet styr Invoke API, som kör Lambda-funktioner. Efter att en funktion har anropats allokerar eller väljer styrplanet en befintlig körtidsmiljö som är förberedd för den funktionen och exekverar sedan koden i den.
AWS Lambda stöder en mängd olika programmeringsspråk, inklusive Java 8, Python 3.7, Go, NodeJS 8, .NET Core 2 och andra, genom sina respektive runtime-miljöer. AWS uppdaterar dem regelbundet, distribuerar säkerhetskorrigeringar och utför andra underhållsaktiviteter i dessa miljöer. Lambda tillåter dig att använda andra språk också, förutsatt att du implementerar lämplig körtid själv. Och då måste du ta hand om dess underhåll, inklusive övervaka dess säkerhet.
Hur fungerar det hela och hur kommer tjänsten att utföra dina funktioner?
Varje funktion körs i en eller flera dedikerade miljöer, som endast existerar under hela den funktionsperioden och sedan förstörs. Varje miljö gör bara ett anrop åt gången, men det återanvänds om det finns flera seriella anrop till samma funktion. Alla runtime-miljöer körs på virtuella maskiner med hårdvaruvirtualisering – så kallade microVMs. Varje microVM tilldelas ett specifikt AWS-konto och kan återanvändas av miljöer för att utföra olika funktioner inom det kontot. MicroVMs är paketerade i byggstenar av Lambda Workers hårdvaruplattform, som ägs och drivs av AWS. Samma körtid kan inte användas av olika funktioner, och mikroVM:er är inte heller unika för olika AWS-konton.
AWS Lambda isoleringsmodell
Isolering av körtidsmiljöer implementeras med hjälp av flera mekanismer. På översta nivån i varje miljö finns separata kopior av följande komponenter:
- Funktionskod
- Alla lambdalager som valts för funktionen
- Funktionsexekveringsmiljö
- Minimalt användarutrymme baserat på Amazon Linux
Följande mekanismer används för att isolera olika exekveringsmiljöer:
- cgroups - begränsa åtkomst till CPU, minne, lagring och nätverksresurser för varje runtime-miljö;
- namnområden - gruppering av process-ID, användar-ID, nätverksgränssnitt och andra resurser som hanteras av Linux-kärnan. Varje körning körs i sitt eget namnutrymme;
- seccomp-bpf - begränsar systemanropen som kan användas under körningen;
- iptables och routing-tabeller - isolering av exekveringsmiljöer från varandra;
- chroot - ger begränsad åtkomst till det underliggande filsystemet.
I kombination med AWS patenterade isoleringstekniker säkerställer dessa mekanismer tillförlitlig körtidsseparation. Miljöer isolerade på detta sätt kan inte komma åt eller ändra data från andra miljöer.
Även om flera körtider av samma AWS-konto kan köras på en enda microVM, kan mikroVM inte under några omständigheter delas mellan olika AWS-konton. AWS Lambda använder bara två mekanismer för att isolera mikroVM:er: EC2-instanser och Firecracker. Gästisolering i Lambda baserat på EC2-instanser har funnits sedan 2015. Firecracker är en ny hypervisor med öppen källkod speciellt designad av AWS för serverlösa arbetsbelastningar och introducerades 2018. Den fysiska hårdvaran som kör microVM:er delas mellan arbetsbelastningar över olika konton.
Spara miljöer och processtillstånd
Även om Lambda-körtider är unika för olika funktioner, kan de anropa samma funktion upprepade gånger, vilket innebär att körtiden kan överleva i flera timmar innan den förstörs.
Varje Lambda-runtime har också ett skrivbart filsystem som är tillgängligt via /tmp-katalogen. Dess innehåll kan inte nås från andra körtider. När det gäller beständighet i processtillstånd, finns filer skrivna till /tmp under hela livscykeln för runtime-miljön. Detta gör att resultaten av flera samtal kan ackumuleras, vilket är särskilt användbart för dyra operationer som att ladda maskininlärningsmodeller.
Samtalsdataöverföring
Invoke API kan användas i två lägen: händelseläge och begäran-svarsläge. I händelseläge läggs samtalet till i en kö för senare exekvering. I begäran-svar-läge anropas funktionen omedelbart med den angivna nyttolasten, varefter svaret returneras. I båda fallen körs funktionen i en Lambdamiljö, men med olika lastvägar.
Under förfrågningssvarssamtal flödar nyttolasten från ett API-anrop för begäranden (API Caller), såsom AWS API Gateway eller AWS SDK, till lastbalanseraren och sedan till Lambda-anropstjänsten (Invoke Service). Den senare bestämmer den lämpliga miljön för att utföra funktionen och skickar nyttolasten dit för att slutföra anropet. Lastbalanseraren tar emot TLS-skyddad trafik över Internet. Trafiken inom Lambda-tjänsten – efter lastbalanseraren – passerar genom en intern VPC i en specifik AWS-region.
AWS Lambda-samtalsbearbetningsmodell: Begäran-svarsläge
Händelsesamtal kan ringas direkt eller läggas till i en kö. I vissa fall implementeras kön med Amazon SQS (Amazon Simple Queue Service), som skickar samtal till Lambda-samtalsuppfyllelsetjänsten genom en intern pollerprocess. Den överförda trafiken är skyddad av TLS, och det finns ingen ytterligare kryptering av data som lagras i Amazon SQS.
Händelseanrop ger inga svar – Lambda-arbetaren ignorerar helt enkelt all svarsinformation. Händelsebaserade samtal från Amazon S3, Amazon SNS, CloudWatch och andra källor behandlas av Lambda i händelseläge. Samtal från Amazon Kinesis- och DynamoDB-strömmar, SQS-köer, Application Load Balancer och API Gateway-anrop behandlas på ett begäran-svar-sätt.
övervakning
Du kan övervaka och granska Lambda-funktioner med hjälp av en mängd olika AWS-mekanismer och tjänster, inklusive följande.
amazoncloudwatch
Samlar in olika statistik såsom antalet förfrågningar, varaktigheten för förfrågningar och antalet förfrågningar som misslyckades.
Amazon CloudTrail
Låter dig logga, kontinuerligt övervaka och underhålla kontoaktivitetsinformation som är kopplad till din AWS-infrastruktur. Du kommer att ha en fullständig historik över åtgärder som utförts med AWS Management Console, AWS SDK, kommandoradsverktyg och andra AWS-tjänster.
AWS röntgen
Ger fullständig insyn i alla stadier av begärandebehandlingen i din ansökan baserat på en karta över dess interna komponenter. Låter dig analysera applikationer under utveckling och i produktionsmiljöer.
AWS -konfigur
Du kommer att kunna spåra ändringar av Lambda-funktionskonfiguration (inklusive radering) och körtider, taggar, hanterarnamn, kodstorlek, minnestilldelning, timeoutinställningar och samtidighetsinställningar, såväl som Lambda IAM-exekveringsroll, subnät och säkerhetsgruppbindningar .
Slutsats
AWS Lambda erbjuder en kraftfull uppsättning verktyg för att bygga säkra och skalbara applikationer. Många av säkerhets- och efterlevnadsmetoderna i AWS Lambda är desamma som i andra AWS-tjänster, även om det finns undantag. Från och med mars 2019 är Lambda kompatibel med SOC 1, SOC 2, SOC 3, PCI DSS, Health Insurance Portability and Accountability Act (HIPAA) och andra bestämmelser. Så när du funderar på att implementera din nästa applikation, överväg AWS Lambda-tjänsten - den kan passa bäst för din uppgift.
Källa: will.com