De vertaling van het artikel is speciaal voorbereid voor studenten van de cursus . Wil je je in deze richting ontwikkelen? Bekijk dan de masterclass van Yegor Zuev (TeamLead bij InBit) en sluit je aan bij de volgende cursusgroep: start op 26 september.
Steeds meer mensen stappen over naar AWS Lambda vanwege de schaalbaarheid, prestaties, besparingen en de mogelijkheid om miljoenen en zelfs triljoenen verzoeken per maand te verwerken. Hiervoor is er geen noodzaak om de infrastructuur van de service te beheren. Autoscaling maakt het mogelijk om duizenden gelijktijdige verzoeken per seconde te bedienen. Ik denk dat je AWS Lambda met recht een van de meest gewilde services van AWS kunt noemen.
AWS Lambda
AWS Lambda is een event-driven serverless computing service die het mogelijk maakt om code uit te voeren zonder servers toe te wijzen en te beheren, en die andere AWS-services aanvult op basis van gebruikelijke logica. Lambda reageert automatisch op verschillende gebeurtenissen (de zogenaamde triggers), bijvoorbeeld op HTTP-verzoeken via Amazon API Gateway, wijziging van gegevens in Amazon S3-emmers of Amazon DynamoDB-tabellen; of je kunt je code starten via API-aanroepen met behulp van AWS SDK en overgangen tussen staten in AWS Step Functions.
Lambda voert code uit op een hoog beschikbare compute-infrastructuur en is volledig verantwoordelijk voor het beheer van de onderliggende platform, inclusief server- en besturingssysteemonderhoud, resource-allocatie, autoscaling, code-monitoring en logging. Dit betekent dat je alleen je code hoeft te uploaden en in te stellen hoe en wanneer deze moet worden uitgevoerd. De service zorgt in ruil daarvoor voor de uitvoering en garandeert de hoge beschikbaarheid van je applicatie.
Wanneer overstappen naar Lambda?
AWS Lambda is een handige rekenplatform, geschikt voor tal van toepassingsscenario's, mits de taal en runtime-omgeving van je code door de service worden ondersteund. Als je je wilt concentreren op de code en de bedrijfslogica, en het onderhoud van servers, resource-allocatie en schaalvergroting wilt uitbesteden aan een externe leverancier tegen een eerlijke prijs, is het zeker de moeite waard om over te stappen op AWS Lambda.
Lambda is ideaal voor het creëren van applicatie-interfaces, en door de service samen met API Gateway te gebruiken, kunnen de kosten aanzienlijk worden verlaagd en kan sneller op de markt worden gekomen. Er zijn verschillende manieren om Lambda-functies te gebruiken en opties voor het organiseren van serverloze architecturen — iedereen kan iets geschikts kiezen, rekening houdend met het beoogde doel.
Lambda maakt een breed scala aan taken mogelijk. Dankzij de ondersteuning van CloudWatch kunnen uitgestelde taken worden gemaakt en afzonderlijke processen worden geautomatiseerd. Er zijn geen beperkingen qua aard en intensiteit van het gebruik van de service (geheugengebruik en tijd worden in aanmerking genomen), en niets weerhoudt u ervan om gestaag te werken aan een volledige microservice op basis van Lambda.
Hier kunnen servicegerichte acties worden gecreëerd die niet continu worden uitgevoerd. Een typisch voorbeeld is het schalen van afbeeldingen. Zelfs in het geval van gedistribueerde systemen verliezen Lambda-functies hun relevantie niet.
Dus, als u niet wilt bezig zijn met het toewijzen en beheren van rekenresources — probeer dan AWS Lambda; als u geen zware, resource-intensieve berekeningen nodig hebt — probeer ook AWS Lambda; als uw code periodiek wordt uitgevoerd — dat klopt, u zou AWS Lambda moeten proberen.
Beveiliging
Tot nu toe zijn er geen klachten over de beveiliging. Aan de andere kant, omdat veel interne processen en de implementatiekenmerken van dit model voor de gebruiker van de beheerde AWS Lambda-omgeving verborgen zijn, verliezen sommige algemeen aanvaarde regels voor cloudbeveiliging hun relevantie.
Zoals de meeste AWS-diensten, wordt Lambda aangeboden volgens het principe van gedeelde verantwoordelijkheid van AWS en de klant met betrekking tot beveiliging en naleving van regelgeving. Dit principe vermindert de operationele belasting van de klant, aangezien AWS zich bezighoudt met het onderhoud, het beheer en de controle van de servicecomponenten — van het besturingssysteem van de host en het virtualisatieniveau tot de fysieke beveiliging van de infrastructuur.
Als we het specifiek over AWS Lambda hebben, dan beheert AWS de onderliggende infrastructuur, de bijbehorende basisdiensten, het besturingssysteem en het applicatieplatform. Terwijl de klant verantwoordelijk is voor de beveiliging van zijn code, het opslaan van gevoelige gegevens, de controle van de toegang tot deze gegevens, evenals tot de Lambda-service en -middelen (Identity and Access Management, IAM), inclusief binnen de gebruikte functies.
In het onderstaande schema wordt het model van gedeelde verantwoordelijkheid weergegeven, dat van toepassing is op AWS Lambda. Het verantwoordelijkheidsgebied van AWS is in het oranje weergegeven, terwijl de verantwoordelijkheid van de klant in het blauw is. Zoals je kunt zien, neemt AWS meer verantwoordelijkheid voor de applicaties die op de service zijn geïmplementeerd.
Het model van gedeelde verantwoordelijkheid dat van toepassing is op AWS Lambda
De Lambda-runtime
Het belangrijkste voordeel van Lambda is dat de service de benodigde middelen zelf toewijst terwijl het jouw functie uitvoert. Je kunt je tijd en inspanning besparen die normaal aan systeembeheer zou worden besteed en je richten op de bedrijfslogica en het schrijven van code.
De Lambda-service is verdeeld in twee vlakken. Het eerste is het beheervlak. Volgens Wikipedia is het beheervlak (control plane) het deel van het netwerk dat verantwoordelijk is voor het transport van signaleringverkeer en routing. Het is de hoofdcomponent die wereldwijde beslissingen neemt over het toewijzen, onderhouden en distribueren van werklasten. Bovendien fungeert het beheervlak als de netwerktopologie van de oplossingleverancier, die verantwoordelijk is voor het routeren en beheren van verkeer.
Het tweede vlak is het datavlak. Dit vlak, net als het beheervlak, heeft zijn eigen taken. Het beheervlak biedt een API voor het beheren van functies (CreateFunction, UpdateFunctionCode) en controleert de interactie van Lambda met andere AWS-diensten. Het datavlak beheert de API-aanroepen (Invoke API), die Lambda-functies aanroepen. Na de aanroep van de functie wijst het beheervlak een bestaande runtime toe of kiest een bestaande, vooraf voorbereide runtime voor deze functie en voert vervolgens de code daarin uit.
AWS Lambda ondersteunt meerdere programmeertalen, waaronder Java 8, Python 3.7, Go, NodeJS 8, .NET Core 2 en andere via de bijbehorende runtimes. AWS werkt ze regelmatig bij, distribueert beveiligingspatches en voert andere onderhoudsoperaties uit op deze runtimes. Lambda laat ook andere talen toe, op voorwaarde dat je zelf de bijbehorende runtime implementeert. Dan ben jij verantwoordelijk voor het onderhoud, inclusief de beveiliging.
Hoe werkt dit allemaal en hoe zal de service jouw functies uitvoeren?
Elke functie draait in één of meer toegewezen omgevingen, die slechts bestaan gedurende de levenscyclus van deze functie en daarna worden vernietigd. In elke omgeving wordt er slechts één oproep tegelijk uitgevoerd, maar deze wordt hergebruikt als er meerdere opeenvolgende oproepen van dezelfde functie zijn. Alle runtimes draaien op virtuele machines met hardwarevirtualisatie - de zogenaamde microVM's. Elke microVM wordt toegewezen aan een specifieke AWS-account en kan meerdere keren worden gebruikt door omgevingen om verschillende functies in deze account uit te voeren. MicroVM's zijn verpakt in de hardwareplatformstructuren van Lambda Worker, die eigendom zijn van en beheerd worden door AWS. Dezelfde runtime kan niet door verschillende functies worden gebruikt, net zoals microVM's uniek zijn voor verschillende AWS-accounts.
Isolatiemodel in AWS Lambda
De isolatie van runtimes wordt gerealiseerd met behulp van verschillende mechanismen. Op het hoogste niveau bevat elke omgeving aparte kopieën van de volgende componenten:
- Functiecoded
- Alle Lambda-lagen die voor de functie zijn gekozen
- Functieruntime
- Minimale gebruikersruimte op basis van Amazon Linux
Voor de isolatie van verschillende runtimes worden de volgende mechanismen toegepast:
- cgroups - beperking van de toegang tot CPU, geheugen, schijfcapaciteit en netwerk voor elke runtime;
- namespaces - groepering van proces-ID's, gebruikers-ID's, netwerkinterfaces en andere middelen die door de Linux-kernel worden beheerd. Elke runtime werkt in zijn eigen naamruimte;
- seccomp-bpf - beperking van systeemoproepen die in de runtime kunnen worden gebruikt;
- iptables en routing tables - isolatie van runtimes van elkaar;
- chroot — het bieden van beperkte toegang tot het onderliggende bestandssysteem.
In combinatie met de eigen technologieën voor isolatie van AWS garanderen de genoemde mechanismen een betrouwbare scheiding van uitvoeringsomgevingen. Dergelijke geïsoleerde omgevingen kunnen geen toegang krijgen tot de gegevens van andere omgevingen en deze niet wijzigen.
Hoewel meerdere uitvoeringsomgevingen van één AWS-account op dezelfde microVM kunnen draaien, kunnen microVM's onder geen enkele omstandigheden worden gedeeld door verschillende AWS-accounts. Voor de isolatie van microVM's in AWS Lambda worden slechts twee mechanismen gebruikt: EC2-instanties en Firecracker. Gastisolatie in Lambda op basis van EC2-instanties wordt sinds 2015 toegepast. Firecracker is een nieuwe open-source hypervisor die speciaal door AWS is ontwikkeld voor serverloze werkbelastingen en in 2018 is geïntroduceerd. De fysieke hardware waarop microVM's worden uitgevoerd, wordt gedeeld door werkbelastingen van verschillende accounts.
Het opslaan van omgevingen en processtatussen
Hoewel de uitvoeringsomgevingen van Lambda uniek zijn voor verschillende functies, kan dezelfde functie meerdere keren worden aangeroepen, wat betekent dat de uitvoeringsomgeving meerdere uren kan bestaan voordat deze wordt vernietigd.
In elke uitvoeringsomgeving van Lambda is er ook een schrijfbare bestandssysteem beschikbaar via de map /tmp. De inhoud ervan kan niet worden benaderd vanuit andere uitvoeringsomgevingen. Wat betreft het opslaan van processtatussen, bestaan de bestanden die in /tmp zijn geschreven gedurende de hele levenscyclus van de uitvoeringsomgeving. Hierdoor is het mogelijk om de resultaten van meerdere aanroepen te accumuleren, wat vooral nuttig is voor kostbare operaties zoals het laden van machine learning-modellen.
Het doorgeven van aanroepgegevens
De Invoke API-interface kan in twee modi worden gebruikt: in evenementmodus en in 'request-response'-modus. In evenementmodus wordt de aanroep in de wachtrij geplaatst voor latere uitvoering. In 'request-response'-modus wordt de functie onmiddellijk aangeroepen met de gegeven payload, waarna een antwoord wordt teruggegeven. In beide gevallen wordt de functie uitgevoerd in de Lambda-omgeving, maar met verschillende paden voor de payload.
Tijdens verzoek-responsaanroepen komt de payload van de API die verzoeken verwerkt (API Caller), zoals AWS API Gateway of AWS SDK, in de load balancer en vervolgens in de Lambda-uitvoeringsservice (Invoke Service). Laatstgenoemde bepaalt de juiste omgeving voor de uitvoering van de functie en geeft de payload door om de aanroep te voltooien. De load balancer ontvangt verkeer met TLS-beveiliging via het internet. Verkeer binnen de Lambda-service, na de load balancer, doorgaat via de interne VPC in een specifieke AWS-regio.
Verwerkingsmodel voor AWS Lambda: verzoek-responsmodus
Event-gebaseerde aanroepen kunnen onmiddellijk worden uitgevoerd of in een wachtrij worden geplaatst. In sommige gevallen wordt de wachtrij geïmplementeerd met behulp van de service Amazon SQS (Amazon Simple Queue Service), die aanroepen naar de Lambda-uitvoeringsservice doorgeeft via een intern pollingproces. Het doorgegeven verkeer is TLS-beveiligd, terwijl er geen extra gegevensversleuteling is voor gegevens die in Amazon SQS worden opgeslagen.
Event-gebaseerde aanroepen retourneren geen antwoorden; alle antwoordinformatie van de Lambda Worker wordt simpelweg genegeerd. Aanroepen van eventbronnen zoals Amazon S3, Amazon SNS, CloudWatch en andere worden door de Lambda-service in eventmodus verwerkt. Aanroepen van Amazon Kinesis- en DynamoDB-stromen, SQS-wachtrij-aanroepen, applicatieload-balancer en API Gateway worden in verzoek-responsmodus verwerkt.
Monitoring
U kunt de functies van Lambda monitoren en auditeren met verschillende mechanismen en services van AWS, inclusief de volgende.
Amazon CloudWatch
Verzamelt verschillende statistieken, zoals het aantal verzoeken, de duur van verzoeken en het aantal verzoeken die zijn mislukt.
Amazon CloudTrail
Stelt u in staat om logboeken bij te houden, continue monitoring uit te voeren en informatie over activiteiten in uw account die verband houden met uw AWS-infrastructuur op te slaan. U heeft een volledige chronologie van acties die zijn uitgevoerd via de AWS Management Console, AWS SDK, commandoregeltools en andere AWS-services.
AWS X-Ray
Biedt volledige zichtbaarheid in alle fasen van de verzoekverwerking in uw applicatie op basis van een kaart van de interne componenten. Hiermee kunt u applicaties analyseren tijdens de ontwikkeling en in een productieomgeving.
AWS Config
U kunt de wijzigingen in de configuratie van Lambda-functies (inclusief hun verwijdering) en runtime, tags, handler-namen, codegrootte, geheugenverdeling, time-out instellingen en parallelle parameters, evenals de IAM-uitvoeringsrol van Lambda, subnets en beveiligingsgroepstoewijzingen volgen.
Conclusie
AWS Lambda biedt een krachtige set tools voor het bouwen van veilige en schaalbare toepassingen. Veel methoden voor veiligheid en compliance binnen AWS Lambda zijn vergelijkbaar met die in andere AWS-diensten, hoewel er uitzonderingen zijn. Sinds maart 2019 voldoet Lambda aan de eisen van SOC 1, SOC 2, SOC 3, PCI DSS, de Amerikaanse wet op de continuïteit en verantwoordingsplicht in de gezondheidszorg (HIPAA) en andere regelgeving. Dus als u nadenkt over het implementeren van een nieuwe toepassing, overweeg dan AWS Lambda – het zou wel eens perfect voor uw behoeften kunnen zijn.
Bron: habr.com
