De vertaling van het artikel is speciaal gemaakt voor de studenten van de cursus . Interesse om je in deze richting te ontwikkelen? Bekijk de masterclass van Egor Zuev (TeamLead bij InBit) en sluit je aan bij de volgende cursusgroep: start op 26 september.
Steeds meer mensen migreren naar AWS Lambda vanwege de schaalbaarheid, prestaties, besparingen en de mogelijkheid om miljoenen of zelfs biljoenen verzoeken per maand af te handelen. Hiervoor hoeft u de infrastructuur waarop de dienst draait niet te beheren. En dankzij automatisch schalen kunt u duizenden gelijktijdige verzoeken per seconde verwerken. Ik denk dat AWS Lambda met recht een van de populairste AWS-diensten genoemd mag worden.
AWS Lambda
AWS Lambda is een gebeurtenisgestuurde serverloze computerservice waarmee u code kunt uitvoeren zonder servers in te richten of te beheren, en andere AWS-services kunt uitbreiden met behulp van aangepaste logica. Lambda reageert automatisch op verschillende gebeurtenissen (triggers genoemd), zoals HTTP-verzoeken via Amazon API Gateway, wijzigingen in gegevens in Amazon S3-buckets of Amazon DynamoDB-tabellen; of u kunt uw code uitvoeren via API-aanroepen met behulp van de AWS SDK en statusovergangen in AWS Step Functions.
Lambda voert code uit op een zeer beschikbare computerinfrastructuur en is volledig verantwoordelijk voor het beheer van het onderliggende platform, inclusief server- en besturingssysteemonderhoud, resourcevoorziening, automatische schaling, codemonitoring en logboekregistratie. Dat wil zeggen, u hoeft alleen maar uw code te uploaden en te configureren hoe en wanneer deze moet worden uitgevoerd. De dienst zorgt op zijn beurt voor de lancering ervan en zorgt voor een hoge beschikbaarheid van uw applicatie.
Wanneer overstappen op Lambda?
AWS Lambda is een handig computerplatform dat geschikt is voor verschillende gebruiksscenario's, zolang de taal en runtime van uw code door de service worden ondersteund. Als u zich wilt concentreren op uw code en bedrijfslogica en tegelijkertijd serveronderhoud, provisioning en schaling wilt uitbesteden tegen een redelijke prijs, dan is AWS Lambda absoluut de juiste keuze.
Lambda is ideaal voor het maken van programmeerinterfaces, en bij gebruik in combinatie met API Gateway kunt u de kosten aanzienlijk verlagen en sneller op de markt komen. Er zijn verschillende manieren om Lambda-functies en opties te gebruiken voor het organiseren van een serverloze architectuur - iedereen kan iets geschikts kiezen op basis van zijn doel.
Met Lambda kunt u een breed scala aan taken uitvoeren. Zo kunt u dankzij de ondersteuning van CloudWatch uitgestelde taken creëren en individuele processen automatiseren. Er zijn geen beperkingen aan de aard en intensiteit van het gebruik van de dienst (er wordt rekening gehouden met geheugenverbruik en tijd), en niets belet je om systematisch te werken aan een volwaardige microservice op basis van Lambda.
Hier kunt u servicegerichte acties aanmaken die niet continu lopen. Een typisch voorbeeld is het schalen van afbeeldingen. Zelfs in het geval van gedistribueerde systemen blijven Lambda-functies relevant.
Dus als je geen zin hebt in het toewijzen en beheren van computerbronnen, probeer dan AWS Lambda; als je geen zware, resource-intensieve berekeningen nodig hebt, probeer dan ook AWS Lambda; als uw code periodiek wordt uitgevoerd, klopt dat, u moet AWS Lambda proberen.
veiligheid
Over de veiligheid zijn er tot nu toe geen klachten. Aan de andere kant, omdat veel van de interne processen en implementatiekenmerken van dit model verborgen zijn voor de gebruiker van de door AWS Lambda beheerde runtime-omgeving, worden sommige algemeen aanvaarde regels voor cloudbeveiliging irrelevant.
Zoals de meeste AWS-diensten wordt Lambda geleverd op basis van gedeelde beveiliging en compliance tussen AWS en de klant. Dit principe vermindert de operationele lasten voor de klant, omdat AWS de taken op zich neemt van het onderhouden, beheren en monitoren van servicecomponenten - van het hostbesturingssysteem en de virtualisatielaag tot de fysieke beveiliging van infrastructuuractiva.
Specifiek gesproken over AWS Lambda: AWS is verantwoordelijk voor het beheer van de onderliggende infrastructuur, de bijbehorende onderliggende services, het besturingssysteem en het applicatieplatform. Terwijl de klant verantwoordelijk is voor de veiligheid van zijn code, het opslaan van vertrouwelijke gegevens, het controleren van de toegang daartoe, evenals tot de dienst en middelen van Lambda (Identity and Access Management, IAM), ook binnen de grenzen van de gebruikte functies.
Het onderstaande diagram toont het gedeelde verantwoordelijkheidsmodel zoals dit van toepassing is op AWS Lambda. AWS-verantwoordelijkheid is oranje en klantverantwoordelijkheid is blauw. Zoals u kunt zien, neemt AWS meer verantwoordelijkheid voor de applicaties die op de service worden ingezet.
Model voor gedeelde verantwoordelijkheid van toepassing op AWS Lambda
Lambda-looptijd
Het belangrijkste voordeel van Lambda is dat door namens u een functie uit te voeren, de dienst zelf de benodigde middelen toewijst. U kunt voorkomen dat u tijd en moeite verspilt aan systeembeheer en u kunt zich concentreren op bedrijfslogica en codering.
De Lambda-service is verdeeld in twee vlakken. De eerste is het besturingsvlak. Volgens Wikipedia is het controlevlak het deel van het netwerk dat verantwoordelijk is voor het transporteren van signaalverkeer en routering. Het is het primaire onderdeel dat mondiale beslissingen neemt over het inrichten, onderhouden en distribueren van werklasten. Bovendien fungeert het besturingsvlak als de netwerktopologie van de oplossingsprovider en is verantwoordelijk voor het routeren en beheren van verkeer.
Het tweede vlak is het datavlak. Het heeft, net als het besturingsvlak, zijn eigen taken. Het besturingsvlak biedt API's voor het beheren van functies (CreateFunction, UpdateFunctionCode) en bepaalt hoe Lambda communiceert met andere AWS-services. Het datavlak bestuurt de Invoke API, die Lambda-functies uitvoert. Nadat een functie is aangeroepen, wijst of selecteert het besturingsvlak een bestaande runtime-omgeving die vooraf is voorbereid voor die functie, en voert vervolgens de code daarin uit.
AWS Lambda ondersteunt een verscheidenheid aan programmeertalen, waaronder Java 8, Python 3.7, Go, NodeJS 8, .NET Core 2 en andere, via hun respectievelijke runtime-omgevingen. AWS werkt deze regelmatig bij, distribueert beveiligingspatches en voert andere onderhoudsactiviteiten uit op deze omgevingen. Met Lambda kun je ook andere talen gebruiken, op voorwaarde dat je zelf de juiste runtime implementeert. En dan moet u voor het onderhoud ervan zorgen, inclusief het toezicht op de veiligheid ervan.
Hoe werkt het allemaal en hoe zal de dienst uw functies vervullen?
Elke functie draait in een of meer specifieke omgevingen, die slechts bestaan gedurende de levensduur van die functie en vervolgens worden vernietigd. Elke omgeving voert slechts één oproep tegelijk uit, maar deze wordt hergebruikt als er meerdere seriële oproepen naar dezelfde functie zijn. Alle runtime-omgevingen draaien op virtuele machines met hardwarevirtualisatie - zogenaamde microVM's. Elke microVM wordt toegewezen aan een specifiek AWS-account en kan door omgevingen worden hergebruikt om verschillende functies binnen dat account uit te voeren. MicroVM’s zijn verpakt in bouwstenen van het Lambda Worker-hardwareplatform, dat eigendom is van en beheerd wordt door AWS. Dezelfde runtime kan niet door verschillende functies worden gebruikt, en microVM’s zijn ook niet uniek voor verschillende AWS-accounts.
AWS Lambda-isolatiemodel
Isolatie van runtime-omgevingen wordt geïmplementeerd met behulp van verschillende mechanismen. Op het hoogste niveau van elke omgeving bevinden zich afzonderlijke kopieën van de volgende componenten:
- Functiecode
- Alle Lambda-lagen die voor de functie zijn geselecteerd
- Functie-uitvoeringsomgeving
- Minimale gebruikersruimte gebaseerd op Amazon Linux
De volgende mechanismen worden gebruikt om verschillende uitvoeringsomgevingen te isoleren:
- cgroups - beperk de toegang tot CPU, geheugen, opslag en netwerkbronnen voor elke runtime-omgeving;
- naamruimten - groepering van proces-ID's, gebruikers-ID's, netwerkinterfaces en andere bronnen die worden beheerd door de Linux-kernel. Elke runtime draait in zijn eigen naamruimte;
- seccomp-bpf - beperkt de systeemaanroepen die tijdens runtime kunnen worden gebruikt;
- iptables en routeringstabellen - isolatie van uitvoeringsomgevingen van elkaar;
- chroot - biedt beperkte toegang tot het onderliggende bestandssysteem.
Gecombineerd met de eigen isolatietechnologieën van AWS zorgen deze mechanismen voor een betrouwbare runtime-scheiding. Op deze manier geïsoleerde omgevingen hebben geen toegang tot gegevens uit andere omgevingen en kunnen deze ook niet wijzigen.
Hoewel meerdere runtimes van hetzelfde AWS-account op één microVM kunnen draaien, mogen microVM's onder geen enkele omstandigheid worden gedeeld tussen verschillende AWS-accounts. AWS Lambda gebruikt slechts twee mechanismen om microVM’s te isoleren: EC2-instanties en Firecracker. Gastisolatie in Lambda op basis van EC2-instanties bestaat al sinds 2015. Firecracker is een nieuwe open source hypervisor die speciaal door AWS is ontworpen voor serverloze workloads en geïntroduceerd in 2018. De fysieke hardware waarop microVM's worden uitgevoerd, wordt gedeeld tussen workloads over verschillende accounts.
Omgevingen en processtatussen opslaan
Hoewel Lambda-runtimes uniek zijn voor verschillende functies, kunnen ze dezelfde functie herhaaldelijk aanroepen, wat betekent dat de runtime enkele uren kan overleven voordat deze wordt vernietigd.
Elke Lambda-runtime heeft ook een beschrijfbaar bestandssysteem dat toegankelijk is via de map /tmp. De inhoud ervan is niet toegankelijk vanuit andere runtimes. Wat de persistentie van de processtatus betreft, bestaan bestanden die naar /tmp zijn geschreven gedurende de gehele levenscyclus van de runtime-omgeving. Hierdoor kunnen de resultaten van meerdere oproepen worden verzameld, wat vooral handig is voor dure bewerkingen zoals het laden van machine learning-modellen.
Gegevensoverdracht bellen
De Invoke API kan in twee modi worden gebruikt: gebeurtenismodus en verzoek-antwoordmodus. In de gebeurtenismodus wordt de oproep toegevoegd aan een wachtrij voor latere uitvoering. In de request-response-modus wordt de functie onmiddellijk aangeroepen met de opgegeven payload, waarna het antwoord wordt geretourneerd. In beide gevallen draait de functie in een Lambda-omgeving, maar met verschillende payload-paden.
Tijdens request-response-aanroepen stroomt de payload van een API voor het verwerken van verzoeken (API Caller), zoals AWS API Gateway of AWS SDK, naar de load balancer en vervolgens naar de Lambda-aanroepservice (Invoke Service). Deze laatste bepaalt de juiste omgeving voor het uitvoeren van de functie en geeft de payload daar door om de oproep te voltooien. De load balancer ontvangt TLS-beveiligd verkeer via internet. Verkeer binnen de Lambda-service (na de load balancer) loopt via een interne VPC in een specifieke AWS-regio.
AWS Lambda-oproepverwerkingsmodel: verzoek-antwoordmodus
Gebeurtenisoproepen kunnen onmiddellijk worden gedaan of aan een wachtrij worden toegevoegd. In sommige gevallen wordt de wachtrij geïmplementeerd met behulp van Amazon SQS (Amazon Simple Queue Service), die oproepen doorgeeft aan de Lambda-oproepafhandelingsservice via een intern pollerproces. Het verzonden verkeer wordt beschermd door TLS en er is geen extra versleuteling van gegevens die zijn opgeslagen in Amazon SQS.
Gebeurtenisoproepen retourneren geen antwoorden: de Lambda Worker negeert eenvoudigweg alle antwoordinformatie. Op gebeurtenissen gebaseerde oproepen van Amazon S3, Amazon SNS, CloudWatch en andere bronnen worden door Lambda verwerkt in de gebeurtenismodus. Aanroepen van Amazon Kinesis- en DynamoDB-streams, SQS-wachtrijen, Application Load Balancer en API Gateway-aanroepen worden op verzoek-antwoord-manier verwerkt.
controle
U kunt Lambda-functies monitoren en auditen met behulp van een verscheidenheid aan AWS-mechanismen en -services, waaronder de volgende.
Amazon Cloud Watch
Verzamelt verschillende statistieken, zoals het aantal verzoeken, de duur van de verzoeken en het aantal mislukte verzoeken.
Amazon CloudTrail
Hiermee kunt u accountactiviteitsinformatie die verband houdt met uw AWS-infrastructuur registreren, continu monitoren en onderhouden. U beschikt over een volledige geschiedenis van acties die zijn uitgevoerd met behulp van de AWS Management Console, AWS SDK, opdrachtregelhulpmiddelen en andere AWS-services.
AWS-röntgenfoto
Biedt volledig inzicht in alle stadia van de aanvraagverwerking in uw applicatie op basis van een kaart van de interne componenten. Hiermee kunt u applicaties analyseren tijdens de ontwikkeling en in productieomgevingen.
AWS-configuratie
U kunt wijzigingen in de Lambda-functieconfiguratie (inclusief verwijdering) en runtimes, tags, handlernamen, codegrootte, geheugentoewijzing, time-outinstellingen en gelijktijdigheidsinstellingen volgen, evenals de Lambda IAM-uitvoeringsrol, subnetten en beveiligingsgroepbindingen .
Conclusie
AWS Lambda biedt een krachtige set tools voor het bouwen van veilige en schaalbare applicaties. Veel van de beveiligings- en compliancepraktijken in AWS Lambda zijn hetzelfde als in andere AWS-services, hoewel er uitzonderingen zijn. Vanaf maart 2019 voldoet Lambda aan de naleving van SOC 1, SOC 2, SOC 3, PCI DSS, Health Insurance Portability and Accountability Act (HIPAA) en andere regelgeving. Dus als u overweegt uw volgende applicatie te implementeren, overweeg dan de AWS Lambda-service; deze past wellicht het beste bij uw taak.
Bron: www.habr.com