{"id":37937,"date":"2019-10-31T22:20:41","date_gmt":"2019-10-31T19:20:41","guid":{"rendered":"https:\/\/prohoster.info\/blog\/detalnyj-razbor-aws-lambda\/"},"modified":"2019-10-31T22:20:41","modified_gmt":"2019-10-31T19:20:41","slug":"detalnyj-razbor-aws-lambda","status":"publish","type":"post","link":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/detalnyj-razbor-aws-lambda","title":{"rendered":"Die gedetailleerde analyse van AWS Lambda","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

De vertaling van het artikel is speciaal voorbereid voor studenten van de cursus \u00abCloud Services\u00bb<\/a><\/noindex>. Wil je je in deze richting ontwikkelen? Bekijk dan de masterclass van Yegor Zuev (TeamLead bij InBit) \u00abAWS EC2 Service\u00bb<\/a><\/noindex> en sluit je aan bij de volgende cursusgroep: start op 26 september. <\/em><\/p>\n

<\/p>\n

\"Die<\/p>\n

<\/p>\n

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.<\/a><\/noindex><\/p>\n

<\/p>\n

AWS Lambda<\/h2>\n

<\/p>\n

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.<\/p>\n

<\/p>\n

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.<\/p>\n

<\/p>\n

Wanneer overstappen naar Lambda?<\/h2>\n

<\/p>\n

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.<\/p>\n

<\/p>\n

Lambda is ideaal voor het cre\u00ebren 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 \u2014 iedereen kan iets geschikts kiezen, rekening houdend met het beoogde doel.<\/p>\n

<\/p>\n

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.<\/p>\n

<\/p>\n

Hier kunnen servicegerichte acties worden gecre\u00eberd 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.<\/p>\n

<\/p>\n

Dus, als u niet wilt bezig zijn met het toewijzen en beheren van rekenresources \u2014 probeer dan AWS Lambda; als u geen zware, resource-intensieve berekeningen nodig hebt \u2014 probeer ook AWS Lambda; als uw code periodiek wordt uitgevoerd \u2014 dat klopt, u zou AWS Lambda moeten proberen.<\/p>\n

<\/p>\n

Beveiliging<\/h2>\n

<\/p>\n

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.<\/p>\n

<\/p>\n

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 \u2014 van het besturingssysteem van de host en het virtualisatieniveau tot de fysieke beveiliging van de infrastructuur. <\/p>\n

<\/p>\n

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.<\/p>\n

<\/p>\n

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\u00efmplementeerd.<\/p>\n

<\/p>\n

\"Die<\/p>\n

<\/p>\n

Het model van gedeelde verantwoordelijkheid dat van toepassing is op AWS Lambda<\/em><\/p>\n

<\/p>\n

De Lambda-runtime<\/h3>\n

<\/p>\n

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.<\/p>\n

<\/p>\n

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.<\/p>\n

<\/p>\n

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.<\/p>\n

<\/p>\n

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.<\/p>\n

<\/p>\n

Hoe werkt dit allemaal en hoe zal de service jouw functies uitvoeren?<\/strong><\/p>\n

<\/p>\n

Elke functie draait in \u00e9\u00e9n of meer toegewezen omgevingen, die slechts bestaan gedurende de levenscyclus van deze functie en daarna worden vernietigd. In elke omgeving wordt er slechts \u00e9\u00e9n 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.<\/p>\n

<\/p>\n

\"Die<\/p>\n

<\/p>\n

Isolatiemodel in AWS Lambda<\/em><\/p>\n

<\/p>\n

De isolatie van runtimes wordt gerealiseerd met behulp van verschillende mechanismen. Op het hoogste niveau bevat elke omgeving aparte kopie\u00ebn van de volgende componenten:<\/p>\n

<\/p>\n