Tech Talk: een serverlessarchitectuur bouwen in AWS met samenwerkende Lambda-functies (deel 1)
Functions as a Service (FaaS) maakt deel uit van het X-as-a-service-model. Daarbij wordt het beheer van een platform (PaaS), infrastructuur (IaaS) of software (SaaS) aan een cloudprovider overgelaten. Bedrijven kunnen zich zo op hun bedrijfslogica concentreren en hun overheadkosten verlagen.
Het idee achter FaaS: u schrijft code voor eenvoudige taken en de cloudprovider regelt de rest. Wat 'eenvoudig' betekent, is natuurlijk subjectief. De provider legt dan ook grenzen op aan wat uw code mag doen. Ze mag in principe niet te veel geheugen gebruiken en niet onbeperkt blijven draaien.
FaaS heeft tegenover code uitvoeren op een virtuele machine de volgende voordelen:
U hoeft geen infrastructuur te beheren. Dat is op zich al een groot voordeel.
Gebeurtenissen activeren de code, wat softwareontwikkeling eenvoudiger maakt.
Bij een activiteitspiek schaalt de code automatisch op en worden functies waar nodig parallel uitgevoerd.
De cloudprovider rekent aan wat u gebruikt. De prijs bestaat uit twee delen: de uitvoeringstijd van uw functie en de hoeveelheid geheugen die u toewijst. Er zijn geen extra kosten voor licenties, systeembeheer, onderhoud of ondersteuning.
Deze eigenschappen maken FaaS erg geschikt voor taken waarbij de werklast schommelt, bijvoorbeeld piektaken die kort veel middelen nodig hebben. Moet uw code 24/7 draaien of zijn er maar korte stilstandtijden, dan is FaaS niet de beste keuze. Voor eenvoudige taken die slechts af en toe moeten draaien, is het wel geschikt. Met serverless computing hoeft u geen onderbenutte infrastructuur te onderhouden en te betalen. Dat bespaart kopzorgen en geld.
De toepassing met AWS
Bij Agilytic werkten we onlangs aan een project waarin we een serverless architectuur bouwden met onder meer Lambda Functions van Amazon Web Services (AWS), in AWS-termen FaaS. Het doel was documenten verzamelen en op basis van hun inhoud classificeren, met technieken van optische tekenherkenning tot tekstsamenvatting. Onlangs publiceerden we ook een artikel over Function App van Azure voor oplossingen met een intensieve werklast.
Voor onze proof of concept kozen we Lambda-functies die elk een deeltaak uitvoeren en samenwerken met S3-opslag en een databank. AWS koppelt de Lambda's na elkaar: elke functie gebruikt de output van de vorige voor haar eigen taak. In dit artikel delen we enkele inzichten over de orkestratie van Lambda-functies.
We gaan ervan uit dat u al weet hoe u Lambda-functies maakt en IAM-rollen en -policies beheert. Om concreet te blijven, vereenvoudigen we onze architectuur en koppelen we enkele Lambda-functies, waarbij elke functie de output van de vorige nodig heeft voor haar specifieke taak.
We gebruiken de AWS-console om de onderwerpen te illustreren. Voor de klant rolden we de volledige architectuur uit als Infrastructure as Code met terraform. De console maakt automatisch rollen aan en kent tot op zekere hoogte rechten toe. Dat helpt om snel uit te rollen, maar is minder goed voor de beveiliging. Daarop gaan we in in deel 2 van dit artikel.
Functieorkestratie met AWS
Figuur 1: overzicht van de Lambda-functie
U hebt de code voor uw eerste Lambda-functie en wilt die activeren, bijvoorbeeld voor een test of om uw pipeline te starten. Hoe begint u? We starten bij de basis en gaan uit van een test. Open eerst in de AWS-console het functieoverzicht van uw Lambda. Dat ziet er ongeveer uit zoals figuur 1.
In die figuur is de testknop geel gemarkeerd. Daarmee maakt u een aangepaste gebeurtenis om uw functie te activeren. Eenvoudig. Heeft uw code een gebeurtenis nodig met de sleutel 'file' en de waarde 'path', dan schrijft u dat in het testfragment, zoals in figuur 2. Verwacht uw code een gebeurtenis van een andere AWS-dienst? Geen zorgen: er zijn veel sjablonen om uit te kiezen.
Figuur 2: testgebeurtenis
Na de test kunt u in de logs zien of de aanroep van uw Lambda-functie geslaagd is. Zo niet, dan wijzen de logs naar de eerste fout en kunt u beginnen met debuggen.
Dit artikel gaat echter niet over Lambda's debuggen, maar over ze met elkaar laten communiceren. Wat is er hier gebeurd? Kort gezegd heeft AWS de JSON uit uw test doorgegeven aan het argument event van de functie lambda_handler in figuur 1 (blauw gemarkeerd). Zo activeren gebeurtenissen een Lambda-functie.
De les is duidelijk: u start een Lambda door er een correct geformatteerde JSON-gebeurtenis aan door te geven. De runtime zet de JSON automatisch om in een object dat uw code begrijpt.
Een Lambda-functie automatisch activeren
AWS biedt dus een eenvoudige manier om een serverless functie handmatig te starten. Maar in hoeveel toepassingen kunt u telkens naar de AWS-console gaan om uw pipeline met een handmatige trigger in het juiste formaat te starten? Vaak wilt u taken automatisch starten, doorgaans in een van deze twee situaties:
Een Lambda op vaste tijdstippen activeren.
Een Lambda activeren als reactie op iets dat in de cloud is gebeurd.
De ingenieurs van AWS hebben daaraan gedacht. Ze maakten het mogelijk dat bepaalde AWS-diensten gebeurtenissen naar uw Lambda-functies sturen. Om een Lambda periodiek te activeren, stelt u in de AWS-console onder 'events' een AWS Cloudwatch-regel in (ja, dat woord komt erg vaak terug in dit artikel). Kies uw Lambda als doel van die gebeurtenis, zoals in figuur 3.
Figuur 3: een periodieke gebeurtenis instellen
Voor de andere toepassingen is er een centralere aanpak. Op de configuratiepagina van uw Lambda in de AWS-console (figuur 4) kiest u de dienst die uw Lambda moet activeren en volgt u de instructies om de gebeurtenis in te stellen. Op het moment van schrijven zijn er 16 AWS-diensten en veel meer partnerdiensten beschikbaar. Controleer altijd het gebeurtenissjabloon om de juiste code te schrijven! U vindt die sjablonen in het geel gemarkeerde deel van figuur 1.
Een tweede Lambda vanuit de eerste activeren met AWS
Prima! U weet nu hoe u een Lambda-functie periodiek of door een gebeurtenis activeert. Maar hoe start u een tweede functie? Kan een Lambda wel een andere Lambda activeren?
Als u opnieuw op de knop 'Add trigger' in figuur 4 klikt, ziet u nergens AWS Lambda staan. Maar geen nood! De mensen bij clouddiensten zoals AWS zijn slim. Het is moeilijk om een situatie te bedenken waarmee ze nog geen rekening hielden. Of we het eens zijn met hun ontwerpkeuzes, is een ander verhaal, voor een ander artikel.
Als uw eerste Lambda bijvoorbeeld elke dag om twaalf uur draait, kunt u de tweede elke dag om 12:20 laten draaien.
Hopelijk moest u glimlachen, want dan begreep u de grap. Zo niet, bekijk dan het grootste probleem met die aanpak. Er zijn er meerdere, maar we bespreken ze niet allemaal. Hoe krijgt de tweede Lambda in dit scenario de informatie die de eerste heeft verwerkt?
U kunt die informatie misschien in een databank of tussentijdse opslag bewaren en de tweede functie ze automatisch laten ophalen. Maar dat maakt uw code complexer en vergroot de kans op fouten en hogere facturen. Beter is het om de tussenstap weg te laten en de gebeurtenis rechtstreeks uit de instructie return in de functie lambda_handler van figuur 1 te halen, uiteraard met de juiste informatie in de JSON. Zo communiceert een Lambda tenslotte met een andere.
Een andere Lambda aanroepen met AWS
De eerste mogelijkheid om twee Lambda's rechtstreeks te laten communiceren, is de AWS Software Development Kit gebruiken. Voor Python heet die boto3 en kunt u daarmee vanuit uw code AWS-middelen beheren en gebruiken. In de documentatie ziet u hoe u een client voor Lambda-beheer opzet en de methode invoke gebruikt om een andere Lambda te activeren.
import boto3, json
client = boto3.client(‘lambda’)
client.invoke(FunctionName='ListenerLambda', InvocationType='Event', Payload=json.dumps({‘file’: ‘path’}))
Vergeet niet in de documentatie na te gaan wat de verschillende opties betekenen en welke andere opties bestaan! In dit codefragment sturen we een gebeurtenis met de sleutel 'file' en de waarde 'path' naar onze luisterfunctie, toepasselijk 'ListenerLambda' genoemd. Het aanroeptype 'Event' betekent dat de luisterende Lambda asynchroon wordt geactiveerd: we wachten niet op het antwoord voordat we de code verder uitvoeren.
Deze eenvoudige oplossing werkt, maar is niet altijd, of beter gezegd zelden, een goede keuze. Stel ter illustratie dat onze Lambda's zo presteren:
De eerste functie voert een eenvoudige taak uit en verwerkt 1.000 taken per seconde.
De tweede functie voert een veel zwaardere taak uit en verwerkt 1 taak per seconde.
Dat zijn de ingrediënten voor een bottleneck. In vijf seconden kunnen we 5.000 taken naar de tweede functie sturen, terwijl die er maar 5 verwerkt. Erger nog: één Lambda kan maximaal 1.000 taken tegelijk uitvoeren, de zogeheten concurrency. Wat is er dan gebeurd met de bijna 4.000 andere taken?
Die zijn verdwenen! Dat is natuurlijk niet goed. Gebruik de SDK in het algemeen alleen om een Lambda-functie asynchroon aan te roepen als u 100% zeker weet dat de volgende taak altijd sneller is dan de vorige. Bij een synchrone aanroep speelt dit niet: de code wacht tot de aanroep is afgerond. U betaalt dan wel voor die wachttijd.
Conclusie
We toonden de eerste stappen om met Lambda-functies van AWS een efficiënte serverless architectuur in de cloud te bouwen. In deel 2 van dit Tech talk-artikel leggen we uit hoe SQS, Step Functions en een beperkte set rechten de basis vormen voor een robuuste en veilige architectuur. We bespreken ook hoe u de juiste oplossing voor uw organisatie opzet.