Översättningen av artikeln är särskilt utarbetad för studenter i kursen Är du intresserad av att utvecklas inom detta område? Titta på masterclass med Egor Zuev (TeamLead på InBit) och gå med i den närmaste kursgruppen: start 26 september.
Allt fler människor väljer AWS Lambda för dess skalbarhet, prestanda, kostnadseffektivitet och möjlighet att hantera miljontals och till och med triljoner förfrågningar per månad. För detta behöver man inte hantera den infrastruktur som tjänsten körs på. Automatiserad skalning gör det möjligt att betjäna tusentals samtidiga förfrågningar per sekund. Jag tycker att AWS Lambda med rätta kan kallas en av de mest eftertraktade tjänsterna på AWS.
AWS Lambda
AWS Lambda är en händelsestyrd serverlös beräkningstjänst som gör det möjligt att köra kod utan att allokera eller administrera servrar, och komplettera andra AWS-tjänster baserat på användarlogik. Lambda reagerar automatiskt på olika händelser (så kallade triggers), till exempel på HTTP-förfrågningar via Amazon API Gateway, ändringar av data i Amazon S3-funktioner eller Amazon DynamoDB-tabeller; eller så kan man köra sin kod via API-anrop, använda AWS SDK och övergångar mellan tillstånd i AWS Step Functions.
Lambda kör koden på en högav tillgänglig beräkningsinfrastruktur och ansvarar helt för administrationen av den underliggande plattformen, inklusive serverunderhåll och operativsystem, resursallokering, automatisk skalning, kodövervakning och loggning. Det vill säga, du behöver bara ladda upp din kod och ställa in hur och när den ska köras. Tjänsten tar hand om att köra den och säkerställer hög tillgänglighet för din applikation.
När ska man övergå till Lambda?
AWS Lambda är en bekväm beräkningsplattform som är lämplig för många tillämpningsscenarier, naturligtvis förutsatt att språket och körmiljön för din kod stöds av tjänsten. Om du vill fokusera på koden och affärslogiken, och överlåta serverhantering, resursallokering och skalning till en extern leverantör till rimliga kostnader, bör du definitivt övergå till AWS Lambda.
Lambda är perfekt för att skapa programgränssnitt, och om tjänsten används tillsammans med API Gateway kan man betydligt minska kostnaderna och snabbare nå marknaden. Det finns olika sätt att använda Lambda-funktioner och alternativ för att organisera serverlös arkitektur — alla kan välja något som passar med hänsyn till målet.
Lambda möjliggör ett brett spektrum av uppgifter. Tack vare stödet för CloudWatch kan man skapa schemalagda uppgifter och automatisera specifika processer. Det finns inga begränsningar för typen eller intensiteten av tjänstanvändning (endast minnesanvändning och tid räknas), och inget hindrar dig från att systematiskt arbeta på en komplett mikrotjänst baserad på Lambda.
Här kan man skapa tjänsteorienterade åtgärder som inte körs kontinuerligt. Ett typiskt exempel är omvandling av bilder. Även i distribuerade system förlorar Lambda-funktioner inte sin relevans.
Så om du inte vill ägna tid åt att allokera och administrera datorkällor — prova AWS Lambda; om du inte behöver tunga, resurskrävande beräkningar — prova även AWS Lambda; om din kod körs periodiskt — konsistent, då bör du prova AWS Lambda.
Säkerhet
Hittills har det inte funnits några klagomål om säkerheten. Å andra sidan, eftersom många interna processer och detaljer i implementeringen av denna modell döljs från användaren av den hanterade AWS Lambda-miljön, förlorar vissa allmänt accepterade regler för molnsäkerhet sin relevans.
Som de flesta AWS-tjänster tillhandahålls Lambda enligt principen om delat ansvar mellan AWS och kunden när det gäller säkerhet och efterlevnad av regler. Denna princip minskar den operativa bördan för kunden, eftersom AWS tar sitt ansvar för underhåll, administration och övervakning av komponenterna i tjänsten — från operativsystemet för värden och virtualiseringsnivån till den fysiska säkerheten för infrastrukturobjekt.
När det gäller AWS Lambda ansvarar AWS för att hantera den underliggande infrastrukturen, relaterade grundläggande tjänster, operativsystemet och applikationsplattformen. Samtidigt har kunden ansvaret för säkerheten av sin kod, lagring av känslig information, åtkomstkontroll till dessa samt till tjänsten och resurserna i Lambda (Identity and Access Management, IAM), även inom de använda funktionerna.
Nedan visas en modell för delat ansvar som gäller för AWS Lambda. AWS:s ansvarsområde är markerat i orange, medan kundens ansvar är markerat i blått. Som du kan se, tar AWS på sig större ansvar för applikationer som distribueras på tjänsten.
Modellen för delat ansvar som gäller för AWS Lambda
Lambda-körmiljö
Den största fördelen med Lambda är att tjänsten själv tilldelar de resurser som behövs när den kör en funktion å dina vägnar. Du behöver inte slösa tid och energi på att administrera system och kan fokusera på affärslogik och kodskrivande.
Lambda-tjänsten är uppdelad i två plan. Det första är kontrollplanet. Enligt Wikipedia är kontrollplanet (control plane) den del av nätverket som ansvarar för transport av signaltrafik och routing. Det är den viktigaste komponenten som fattar globala beslut om tilldelning, underhåll och distribution av arbetsbelastningar. Dessutom fungerar kontrollplanet som nätverksarkitekturen för tjänsteleverantören och ansvarar för rutingen och hanteringen av trafik.
Det andra planet är dataplanet. Likt kontrollplanet har det sina egna uppgifter. Kontrollplanet tillhandahåller API:er för att hantera funktioner (CreateFunction, UpdateFunctionCode) och kontrollerar interaktionen mellan Lambda och andra AWS-tjänster. Data planet hanterar API-anrop (Invoke API), som utlöser Lambda-funktioner. Efter att en funktion har anropats tilldelar kontrollplanet antingen en ny eller väljer en befintlig, förberedd körmiljö för denna funktion och utför sedan koden i den.
AWS Lambda stöder många programmeringsspråk, inklusive Java 8, Python 3.7, Go, NodeJS 8, .NET Core 2 och andra genom de motsvarande körmiljöerna. AWS uppdaterar dem regelbundet, distribuerar säkerhetsfixar och utför andra underhållsåtgärder för dessa miljöer. Lambda tillåter användning av andra språk, förutsatt att du själv implementerar den nödvändiga körmiljön. Då måste du också sköta underhållet av den, inklusive säkerhetsaspekter.
Hur fungerar allt detta och hur kommer tjänsten att utföra dina funktioner?
Varje funktion körs i en eller flera dedikerade miljöer som bara existerar under livscykeln för den funktionen och förstörs därefter. I varje miljö körs endast ett anrop åt gången, men den används igen om det sker flera sekventiella anrop till samma funktion. Alla körmiljöer körs på virtuella maskiner med hårdvaruvirtualisering – de så kallade microVM. Varje microVM tilldelas ett specifikt AWS-konto och kan återanvändas av miljöer för att köra olika funktioner i det kontot. MicroVM:s är packade i strukturella block av Lambda Worker-hårdvaruplattformen som ägs och förvaltas av AWS. Samma körmiljö kan inte användas av olika funktioner, precis som microVM:s är unika för olika AWS-konton.
Isoleringsmodellen i AWS Lambda
Isoleringen av körmiljöerna implementeras med hjälp av flera mekanismer. På den högsta nivån finns separata kopior av följande komponenter i varje miljö:
- Funktionens kod
- Eventuella Lambda-lager som valts för funktionen
- Funktionens körmiljö
- Minimalt användarutrymme baserat på Amazon Linux
För att isolera olika körmiljöer tillämpas följande mekanismer:
- cgroups – begränsning av tillgång till resurser som CPU, minne, lagringsbandbredd och nätverk för varje körmiljö;
- namespaces – gruppering av process-ID:n, användar-ID:n, nätverksgränssnitt och andra resurser som hanteras av Linux-kärnan. Varje körmiljö arbetar i sitt eget namnrymd;
- seccomp-bpf – begränsning av systemanrop som kan göras i körmiljön;
- iptables och routingtabeller – isolering av körmiljöerna från varandra;
- chroot — tillhandahållande av begränsad åtkomst till underliggande filsystem.
I kombination med proprietära isoleringstekniker från AWS garanterar de nämnda mekanismerna en säker separation av körmiljöer. Isolerade miljöer kan inte få åtkomst till data från andra miljöer eller ändra dem.
Även om flera körmiljöer för ett AWS-konto kan köras på samma microVM, får microVM under inga omständigheter delas av olika AWS-konton. För isolering av microVM i AWS Lambda används endast två mekanismer: EC2-instans och Firecracker. Gästisolering (guest isolation) i Lambda baserat på EC2-instanser har använts sedan 2015. Firecracker är en ny öppen källkodshypervisor, speciellt designad av AWS för serverlösa arbetsbelastningar och lanserades 2018. Den fysiska utrustningen där microVM körs delas av arbetsbelastningar från olika konton.
Bevarande av miljöer och processstatusar
Även om körmiljöerna för Lambda är unika för olika funktioner, kan samma funktion återsändas, det vill säga att körmiljön kan existera i flera timmar innan den förstörs.
I varje Lambda-körmiljö finns också ett skrivbart filsystem tillgängligt via katalogen /tmp. Dess innehåll kan inte nås från andra körmiljöer. När det gäller bevarande av processstatusar finns de filer som skrivits till /tmp kvar under hela körmiljöns livscykel. Detta möjliggör ackumulering av resultat från flera anrop, vilket är särskilt användbart för kostsamma operationer som inläsning av maskininlärningsmodeller.
Överföring av anropsdata
Invoke API-gränssnittet kan aktiveras i två lägen: händelseläge och förfrågnings-svarläge. I händelseläge läggs anropet i kö för senare utförande. I förfrågnings-svarläget anropas funktionen omedelbart med den angivna nyttolasten, varefter ett svar returneras. I båda fallen körs funktionen i Lambda-miljön, men med olika sätt att hantera nyttolasten.
Vid anrop av typen "request-response" mottas nyttolasten från API:et för anropshantering (API Caller), som AWS API Gateway eller AWS SDK, i lastbalanseraren och vidare till Lambda-anropsservicen (Invoke Service). Denna bestämmer lämplig miljö för att köra funktionen och skickar nyttolasten dit för att slutföra anropet. Lastbalanseraren får trafik med TLS-skydd över Internet. Trafiken inom Lambda-tjänsten — efter lastbalanseraren — passerar genom det interna VPC i en specifik AWS-region.
Modellen för AWS Lambda-anrop: "request-response"-läge
Händelsebaserade anrop kan utföras omedelbart eller läggas i kö. I vissa fall implementeras kön med hjälp av Amazon SQS (Amazon Simple Queue Service), vilket överför anrop till Lambda-anropsservicen via en intern poller. Den överförda trafiken är skyddad med TLS, medan någon ytterligare kryptering av data som lagras i Amazon SQS inte tillhandahålls.
Händelsebaserade anrop returnerar inga svar — all svarsinformation ignoreras helt av Lambda Worker. Anrop från källor som Amazon S3, Amazon SNS, CloudWatch och andra behandlas av Lambda-tjänsten i händelseläge. Anrop från Amazon Kinesis-flöden och DynamoDB, SQS-köanrop, applikationens lastbalanserare och API Gateway behandlas i "request-response"-läge.
Övervakning
Du kan övervaka och granska Lambda-funktioner med hjälp av olika mekanismer och AWS-tjänster, inklusive följande.
Amazon CloudWatch
Samlar in olika statistiska data, som antal anrop, varaktighet för anrop och antalet anrop som avslutats med fel.
Amazon CloudTrail
Möjliggör loggning, kontinuerlig övervakning och bevarande av information om aktiviteter i ditt konto kopplat till din AWS-infrastruktur. Du får en fullständig tidslinje av åtgärder som utförts via AWS Management Console, AWS SDK, kommandoradsverktyg och andra AWS-tjänster.
AWS X-Ray
Ger fullständig insyn i alla steg i anropsbehandlingen i din applikation baserat på en karta över dess interna komponenter. Gör det möjligt att analysera applikationer under utveckling och i produktionsmiljö.
AWS Config
Du kan spåra ändringar i konfigurationen av Lambda-funktioner (inklusive deras borttagning), körmiljöer, taggar, funktionsnamn, kodstorlek, minnesallokering, tidsinställningar och parallelliseringsalternativ, samt IAM-roll för Lambda-exekvering, delnät och säkerhetsgruppsbindningar.
Slutsats
AWS Lambda erbjuder ett kraftfullt verktygssats för att bygga säkra och skalbara applikationer. Många metoder för säkerhet och efterlevnad inom AWS Lambda är desamma som de som används i andra AWS-tjänster, även om det finns undantag. Från och med mars 2019 uppfyller Lambda kraven enligt SOC 1, SOC 2, SOC 3, PCI DSS, den amerikanska lagen om kontinuitet och ansvar för medicinsk försäkring (HIPAA) samt andra normer. Därför, när du överväger att implementera en ny applikation, överväg AWS Lambda – det kan vara den bästa lösningen för ditt behov.
Källa: habr.com
