Tech talk: oplossingen met een intensieve werklast bouwen met Function App van Azure, verwachtingen en beperkingen
Bedrijven kiezen steeds vaker voor clouddiensten vanwege het gebruiksgemak en de flexibele kosten. U kunt het platform, de infrastructuur of zelfs de uitvoeringsomgeving eenvoudig aan uw cloudprovider overlaten. Die verschillende dienstenniveaus zijn populair geworden onder de namen PaaS, IaaS en FaaS.
Bedrijven kunnen zich zo op hun bedrijfslogica richten zonder zelf uitgebreide IT-capaciteit op te bouwen en te beheren. Dat helpt vooral start-ups om met hun cloudprovider snel naar de markt te gaan.
Bij Agilytic testen en implementeren we graag proofs of concept met opkomende technologieën die de technische beheerkosten op verschillende vlakken van een project verlagen. In dit artikel tonen we een experiment uit ons Azure-lab met Azure Function App. We probeerden een toepassing met een zware werklast te bouwen met nieuwe beheerde clouddiensten, om het technische beheer zo veel mogelijk te beperken. We wilden de technische grenzen qua functionaliteit en schaalbaarheid onderzoeken en de kosten vergelijken met klassieke cloudimplementaties.
In ons lab bekijken we een toepassing met een zware werklast die pdf-documenten analyseert. De analyse bestaat uit vier verwerkingsstappen, van optische tekenherkenning tot tekstclassificatie. Op één vCPU schatten we de gemiddelde verwerkingstijd voor de vier stappen samen op 1 minuut.
De architectuur van de Azure Function App
Bij IaaS zou de eerste gedachte zijn om virtuele machines en processen te starten die het werk uitvoeren. We kunnen horizontaal opschalen door meer VM's en processen toe te voegen. Het grootste nadeel is het bijkomende systeembeheer: het besturingssysteem, updates enzovoort. We moeten ook de toepassingsarchitectuur beheren en de workflow synchroniseren, zeker als die verdeeld is.
Het idee was om zo'n toepassing experimenteel op Platform as a Service (PaaS) te bouwen in plaats van op Infrastructure as a Service (IaaS). Met Azure Function App gaan we nog verder, naar Function as a Service (FaaS). Bij FaaS wordt het beheer zo veel mogelijk beperkt: we hoeven noch het platform, noch de toepassingsarchitectuur te beheren. We kunnen ons richten op de code die rechtstreeks waarde levert, met minder beheer en dus mogelijk lagere kosten. Zo'n keuze heeft ook nadelen, zoals afhankelijkheid van één leverancier. Dit experiment onderzoekt de technische voordelen en meerwaarde, niet de zakelijke voorkeuren.
We kozen voor de Azure Function App, waarbij elke functie-instantie één verwerkingsstap uitvoert. Azure Service Bus Queue verzorgt de communicatie tussen de stappen. Zo voegen we geen beheerlast toe. Alle documenten staan in blobopslag.
De workflow doorloopt de stappen achtereenvolgens via berichten in de Azure Service Bus Queue, die de belasting over de Function Apps helpt verdelen. Omdat Function Apps stateless zijn, zijn ze eenvoudig te verwerken, te verdelen en op te schalen. Wanneer een stap bijvoorbeeld een taak afrondt, gaat via de Service Bus een bericht naar de volgende stap om de verwerking voort te zetten.
De Azure-architectuur bestaat uit:
Function App - Voert onze code uit.
Service Bus Queue - Geeft de workflow achtereenvolgens door van de ene stap naar de andere.
DataLake storage - Slaat resultaten op.
Blob storage - Slaat documenten op.
De verschillende stappen zijn:
Dispatcher - Een zeer licht onderdeel dat de uit te voeren taken genereert.
Search & Download - Zoekt documenten in Azure-blobopslag en downloadt ze voor verwerking.
Text extract - Combineert Postscript-interpretatie en optische tekenherkenning om tekstgegevens uit de pdf te halen.
NLP - Natuurlijke taalverwerking om de geëxtraheerde tekst te classificeren.
De code achter de Azure Function App
Elke stap voert één specifieke taak uit. Dankzij de Azure Service Bus Queue krijgen we zonder extra inspanningen een At-Least-Once-aflevergarantie. Zo raken we uitvoeringen bij een fout niet kwijt. De Azure Function App laat u bedrijfslogica implementeren zonder rechtstreeks met de Service Bus Queue te communiceren. De Azure Function App verpakt uw bedrijfslogica namelijk in een eigen consumer-producerpatroon. Zo kunnen we ons op de bedrijfslogica richten zonder integratieproblemen te moeten oplossen. Azure onderhoudt en ondersteunt alles behalve onze bedrijfslogica. Dat is het belangrijkste voordeel van FaaS tegenover PaaS.
De configuratie van de Azure Function App is eenvoudig. U geeft het type invoer en uitvoer op, de namen van de wachtrijen en de naam van de omgevingsvariabele met de verbindingsreeks om veilig met de Service Bus te verbinden. Afhankelijk van het type invoer en uitvoer kunnen nog andere parameters nodig zijn.
{
"scriptFile": "__init__.py",
"bindings": [
{
"name": "msgIn",
"type": "serviceBusTrigger",
"direction": "in",
"queueName": "inputqueue",
"connection": "InputBusQueueConnectionString"
},
{
"name": "msgOut",
"type": "serviceBus",
"direction": "out",
"queueName": "outputqueue",
"connection": "OutputBusQueueConnectionString",
}
]
}import json
import business
import azure.functions as func
def main(msgIn: func.ServiceBusMessage, msgOut: func.Out[str]):
input_data = json.loads(msgIn.get_body())
output_data = business.process(input_data)
msgOut.set(json.dumps(output_data))
Zo eenvoudig is het. Onze code voor de bedrijfslogica blijft overdraagbaar, omdat die onafhankelijk is van de rest van de code. Met deze main-functie kunnen we zelf een serialisatiemethode kiezen. Later kunnen we de architectuur aanpassen en de Azure Function App door een andere dienst vervangen zonder onze bedrijfslogica opnieuw te implementeren of te herstructureren.
Deze architectuur is vergelijkbaar met wat Apache Storm kan bieden.
De voordelen
Deze architectuur biedt meerdere voordelen:
Realtime resultaten. Elk document wordt zo snel mogelijk verwerkt zonder extra technische kosten.
De volledige architectuur is fouttolerant en consistent. Als één Function App crasht, gaat de rest van de verwerking onafhankelijk door. Dankzij de Azure Service Bus Queue en de Peek-lock-modus wordt de mislukte verwerkingsstap opnieuw geprobeerd. Alleen de mislukte stap wordt herhaald, niet alle stappen.
De architectuur is tot op detailniveau schaalbaar. We kunnen een specifieke stap horizontaal opschalen als die de bottleneck vormt. Verderop zien we dat die schaalbaarheid ook grenzen heeft.
Er is helemaal geen bijkomend beheer nodig. Zowel de Azure Function App als de Azure Service Bus Queue zijn volledig beheerde diensten.
De beperkingen
Zoals we zagen, biedt de architectuur grote voordelen qua schaalbaarheid. Toch heeft de schaalbaarheid van de Azure Function App beperkingen. Met verschillende serviceplannen kunnen functies verticaal tot 4 cores opschalen. Dat kan onze verwerking vier keer sneller maken als we een multithreaded Azure Function App gebruiken. Helaas kunnen we in het Premium-serviceplan niet verder dan vier cores per functie-instantie.
De hier voorgestelde architectuur kan eenvoudig horizontaal opschalen omdat ze stateless is en de Service Bus Queue gebruikt. Toch geldt er ook een horizontale limiet: één Function App kan maximaal 100 instanties hebben in het Premium-serviceplan of 200 in het Consumption-plan. Dat geeft ons maximaal (100 × 4) 400 vCPU's per verwerkingsstap.
Als één document 1 minuut nodig heeft om alle stappen achtereenvolgens te doorlopen, halen we maximaal 400 documenten per minuut of 6,66/s.
De kosten
Als we minstens 6,66 documenten per seconde willen verwerken, hebben we 100 instanties met 4 vCPU's nodig in het Premium-serviceplan.
Op dit moment zou die opstelling ongeveer $185.759,74 per maand kosten. Een alternatief met uitsluitend VM's zou daarentegen slechts $31.220,69 per maand kosten.
Conclusie
Hoewel deze architectuur veel interessante voordelen biedt, mogen we de financiële kant niet negeren. We raden deze architectuur beslist niet aan voor zware werklasten, vooral vanwege de beperkingen in schaalbaarheid en de kosten. De Azure Function App richt zich oorspronkelijk op het ontwikkelen van een eenvoudig API-endpoint voor de rest van de Azure-infrastructuur. Dat past duidelijk niet bij de toepassing die we hier bespreken.
De Azure Function App blijft een goede oplossing voor een gebeurtenisgestuurde functie zonder grote hoeveelheid berekeningen per seconde. De hier voorgestelde architectuur blijft zinvol, maar kan beter met andere onderdelen worden geïmplementeerd, zoals Azure Container Instance. Voor het specifieke doel van dit artikel lijkt Azure Batch ons een veel betere keuze.