Serverless Architecture
volgende stap voor database-architectuur?
Door Guido Vandecasteele.
Data analist, consultant.
In de wereld van databases is de serverless architectuur is een relatief recente ontwikkeling. Kijkende naar de evolutie van databases kunnen er grofweg drie verschillende fases worden onderscheiden – on premises, cloudgebaseerd en nu serverless. Ondanks zoals de naam doet vermoeden, zijn er bij serverless nog steeds servers aanwezig, maar wat houdt dit nu precies in en welke voor- en nadelen zitten er aan verbonden?
Eerst een korte terugblik. In eerste instantie werden databases grotendeels beheerd on-premises, met toegewijde servers die de databases hostten. Dit vereiste veel investering in ruimte, koeling, server-hardware, onderhoud en personeel om ze te beheren maar had als voordeel dat alles in eigen beheer was.
Met de opkomst van de cloud en sneller internet werden databases beschikbaar als cloudservices. Gebruikers konden databases op afstand dynamisch gaan huren afhankelijk van hun behoefte, meestal bij derde partijen zoals Amazon en Google. Wel moesten ze nog steeds de database-instanties beheren. Een server kon nog steeds voor problemen zorgen als deze vol liep door onvoldoende opslag.
Wat ons brengt naar de nieuwste iteratie – serverless. Zoals ik al eerder benoemde, zijn er bij serverless nog steeds servers aanwezig, maar deze worden nu op een hoger abstractieniveau van de gebruiker af geplaatst. In vergelijking met standaard cloud-servers zitten er op fundamenteel niveau ook een aantal belangrijke verschillen in.
Als CoolProfs houden wij deze nieuwe ontwikkeling nauw in de gaten. Voor Cool Monitor, onze alomvattende monitoring-oplossing voor logs en metrieken van applicaties en infrastructuur, maken wij gebruik van Elastic (NoSQL-gebaseerd). Momenteel biedt Elastic een traditionele cloud-oplossing, maar heeft aangekondigd binnenkort een serverless oplossing te gaan aanbieden. Aan de hand van dit voorbeeld zullen we verder in gaan op de serverless architectuur.
Laten we eerst kijken naar de traditionele cloud-oplossing van Elastic en daarna hoe de serverless variant hiervan verschilt.
Als data in het Elastic systeem komt, wordt het in delen (‘shards’) opgedeeld, geïndexeerd en gerepliceerd. Nu wordt data eerst door de primary shard (Hot Primary) geïndexeerd en wordt een transaction log gecreëerd, wat veel rekenkracht vereist. De replica’s (Hot Replica) hiervan moeten dit indexeerwerk óók uitvoeren, en hebben dus ook compute capaciteit nodig. Dit vermenigvuldigt de hoeveelheid compute capaciteit die nodig is met de hoeveelheid kopieën die je opslaat. Elke node handelt indexeer- en zoek-functionaliteit af. Dit betekent deze de juiste grootte moeten hebben om hun piekbelasting aan te kunnen.
Om een balans te vinden tussen snelheid en kosten, maakt Elastic gebruik van data tiers en index lifecycle management. Op de snelste servers (Hot) wordt bijvoorbeeld de nieuwste data geplaats en na een bepaalde periode wordt deze data naar een iets langzamere server (Cold, Frozen) verplaatst, ervan uitgaande dat data waarde langzaam verliest naarmate deze ouder wordt.
Momenteel heeft Elastic een traditionele cloud-oplossing voor hun cloud-gebaseerde Elastic Cloud waarbij gebruikers specifieke servercapaciteit bij Elastic huren voor hun Hot, Cold en Frozen opslag. Stel je wilt nu meer opslag in de Hot data tier, ben je genoodzaakt om ook automatisch meer werkgeheugen en CPU-kracht af te nemen, terwijl dit niet altijd nodig is.
Daarnaast zijn er meer nadelen aan verbonden – het is een complex systeem, waarbij de servers allemaal de juiste grootte moeten hebben, er moet worden nagedacht hoe lang data wordt opgeslagen in iedere tier, er is sprake van de verplaatsing van grote hoeveelheden data tussen nodes, wat ook kosten met zich kan meebrengen en overbelasting van een server kan de stabiliteit van het systeem in gevaar brengen.
Als we nu kijken naar de nieuwe serverless architectuur vallen gelijk een aantal zaken op. In plaats van meerdere tiers aan data-opslag worden deze nu in één centrale object store thuisgebracht. Volgens Elastic zal deze worden thuisgebracht in Amazon S3. Deze neemt vervolgens ook automatisch de taken van replicatie en het verzorgen van nodes op zich, wat dus in theorie leidt tot minder complexiteit en werk aan de kant van de eindgebruiker. Die hoeft niet meer na te denken over de grootte en duur van de verschillende data tiers.
Daarnaast is er ook te zien dat er nu ook aparte machines voor indexering en voor zoeken zijn. Die machines nemen de compute-capaciteit op zich, terwijl de opslag puur voor opslag is. Deze ontkoppeling van compute en storage is een van dé belangrijke verandering binnen serverless en biedt vele voordelen.
Ten eerste hoeft de indexering hoeft maar één keer te gebeuren in plaats van meerdere keren. Daarnaast ben je veel flexibeler in het op- en afschalen van systemen. Waar je eerst automatisch meer RAM en CPU moest afnemen voor meer opslag, kan je nu de opslag verhogen zonder dat dit invloed heeft op RAM en CPU capaciteit. In theorie is het nu zelfs mogelijk om de compute-kant; het indexeren en zoeken, geheel uit te schakelen als deze niet nodig zijn. Als laatste kan de opslag grootte nu automatisch mee schalen met het gebruik.
Voor de implementatie van Elastic zijn er wel kanttekeningen bij te zetten. Het bijhouden van de transaction log (nodig om zeker te zijn dat data niet verloren gaat) wordt nu binnen één machine thuisgebracht. Maar als deze omvalt zou dat voor problemen kunnen zorgen. Daarnaast introduceert deze opzet ook in grote mate afhankelijkheid van Amazon AWS.
In theorie zou serverless voor CoolProfs een aantal grote voordelen bieden voor de implementatie van Cool Monitor; minder complexiteit doordat er niet over data tiers en het beheer van nodes hoeft worden nagedacht, zorgt voor minder beheerwerk en daardoor een algeheel robuuster systeem. Ook is deze opzet meer lichtgewicht, waardoor in theorie snel meerdere kleinere systemen kunnen worden opgezet.
Echter zijn wij wel benieuwd hoe de performance van een object store in S3 zich vergelijkt met de oude data tiers en uiteindelijk natuurlijk de kosten die eraan gebonden zijn. Ook zouden wij graag zien dat object stores buiten AWS tot de mogelijkheden behoren.
Of voor jouw organisatie een serverless architectuur de volgende stap is, zal van vele factoren afhangen. De uiteindelijk implementatie van serverless verschilt ook van systeem tot systeem. In dit geval is Elastic als voorbeeld genomen, maar de voordelen van de ontkoppeling van compute van opslag zullen ook voor andere systemen gelden. Bij CoolProfs zijn wij ieder geval positief benieuwd naar wat deze technologie voor ons zal brengen.
Guido Vandecasteele, CoolProfs Consultant
