Hello world
Mijn naam is Roland Jochems en ik ben al bijna 25 jaar werkzaam in de automatisering waarvan de laatste 20 jaar bij CIMSOLUTIONS. In deze tijd heb ik diverse keren te maken gehad met voorbeelden over hoe een techniek of een service te gebruiken is en steevast krijg je te maken met “hello world” achtige voorbeelden. Zo vriendelijk als “hello world” ook klinkt, zo naïef kan het zijn als men op basis van deze “hello world” voorbeelden beslist of een techniek of service ook gebruikt kan worden om de eigen “Real world” problemen op te lossen.
Ik ben al een tijdje, voor een goede klant van CIMSOLUTIONS bekend van kogellagers, als systems architect aan het werk aan een systeem voor het verwerken en analyseren van data gemeten aan kogellagers van treinen. De klant heeft gekozen om voor al hun klantgerichte applicaties gebruik te maken van Amazon Web Services.
AWS
Vanwege de keuze van de klant voor AWS is het aan mij om de data te verwerken in AWS en IoT. Een bijkomende eis van de klant was om zoveel als mogelijk gebruik te maken van “serverless”-“managed” services, in plaats van virtuele servers (Ec2) te gebruiken met daarop draaiende software. De reden is om de kosten van het beheer van virtuele machines zo klein mogelijk te houden. Een andere reden is dat het gebruik van managed services goedkoper zou zijn. Ik zeg met name “zou zijn” omdat dat dat niet altijd waar is en erg afhankelijk is van het gebruik van de service.
Om een idee te krijgen over wat voor een soort applicatie ik spreek:
- Stel je een trein voor waarbij bij alle wielen een sensor dicht bij het lager is gemonteerd die volledig zelfstandig metingen uitvoert en data uploadt op het moment dat het de sensor het beste uitkomt.
- Deze trein heeft bijvoorbeeld drie treinstellen elk 8 wielen verdeeld over 2 bogies per treinstel. Dat is voor die trein 24 sensoren.
- Verder heeft deze klant 16 treinen. Dat komt neer op een totaal van 348 sensoren.
- Deze sensoren sturen elke dag voordat de dienstregeling weer begint de data die een dag eerder was gemeten. Wat neer komt op gemiddeld 285 individuele meetwaardes per dag per sensor. Totaal 348 * 285 ≈ 99.000 records per dag voor deze individuele klant. Afgelopen januari hebben 2.586 sensoren samen gemiddeld 1.065.866 meetgegevens per dag gestuurd.
Architectuur
Ik ben in de AWS literatuur gedoken en ben naar de Re-Invent conferentie in Las Vegas geweest om daar een en ander te leren over AWS en hoe ik boven staande use-case het beste kan oplossen. Onderstaand een standard architectuur zoals je in AWS documentatie tegenkomt. Ik heb het plaatje wat vereenvoudigd.
De bovenstaande architectuur hadden we dus ook voor het verwerken van onze sensor data in gedachten.
Uitdaging 1: Alle “voorbeeld” en referentie applicaties die ik tot nu heb gezien, gaan uit van sensoren die een veelal een constante verbinding hebben en dan data sturen op het moment dat ze het meten of via een “edge” computing device doorsturen. Dit levert zelfs met 10k+ aantal sensoren geen problemen, omdat de verdeling van data over de dag redelijk is uitgesmeerd. Echter zoals ik in de use-case beschreef is het in ons geval zo dat de bulk van de data in een relatief korte periode gestuurd kan worden.
Kinesis is een streaming service die door middel van chards (betekent letterlijk scherf) de hoeveelheden data reguleert. Elke chard kan 1.000 records of 1MB per seconde verwerken. Het aantal chards dat je beschikbaar hebt, is configureerbaar en brengt kosten met zich mee.
Een chard wordt toegewezen via een key. Op deze manier kun je garanderen dat alle data via de zelfde chard wordt gestuurd en dus ook in dezelfde volgorde aankomt.
Waar we al snel tegenaan liepen is dat kinesis maar 1.000 records per seconde kan verwerken en als alle sensoren van 1 trein op hetzelfde moment data sturen, lopen we al snel tegen deze limiet aan.
Oplossing 1: Verhogen van het aantal chards om de piekbelasting aan te kunnen. Het nadeel is dat we na de piek betalen voor iets dat we niet gebruiken.
Oplossing 2: Opvangen van de piekbelasting door middel van S3 en SQS.
In plaats van de berichten in een keer naar kinesis te sturen, worden deze eerst naar S3 geschreven. Op het moment dat de sensor klaar is, wordt er een bericht op de queue gezet dat de sensor klaar is met sturen en dat de data verwerkt kan worden. De Data handler leest alle data van die desbetreffende sensor en bundelt de data om minder berichten per seconde te generen en stuurt deze naar kinesis.
S3 en SQS en Lambda zijn ook niet zonder kosten, maar dit kost nog altijd minder dan het verhogen van de chards om de piekbelasting op te kunnen vangen.
Dit project dat nog volop in ontwikkeling is, heeft al een aantal van deze hindernissen genomen waarbij een voorgestelde techniek toch niet precies dat deed wat je ervan verwachtte.
Ik zal in een volgende blog nog meer van dit soort “hello world vs real world” voorbeelden laten zien.
Roland Jochems
Systems Architect
