Bij het ontwerpen van de database voor een cloud oplossing zijn een aantal vragen die steeds terugkomen:
> Hoe ga ik om met data van verschillende klanten?
> Hoe hou ik de database ook snel als de dienst populair wordt?
> Hoe hou ik de eigen TCO van de dienst zo laag mogelijk?
> Hoe ga ik zo slim mogelijk om met schaalbaarheid?
Wat betreft het opslaan van data van verschillende klanten is één van de belangrijkste vragen: Scale-up or scale-out?
Multi-tenant
Software voor cloud applicaties is van nature multi-tenant, ofwel, meerdere klanten maken gebruik van dezelfde dienst en leven dus naast elkaar op een dienst die je over het internet afneemt. Multitenancy speelt zich echter af op verschillende lagen en één daarvan is de database.
Bij het ontwikkelen van software diensten gaat een ontwerp vooraf. Vaak zullen deze diensten door verschillende klanten gebruikt worden, het ontwerp dient dus van de grond af aan multi-tenant te zijn. Over hoe je de architectuur voor zo’n omgeving inzet zijn de meningen verdeeld. De database staat vaak aan de basis van een ontwerp aangezien data de basis van veel (kantoor) applicaties vormt. Zo kom je al snel voor de volgende fundamentele keuze:
> maak voor iedere klant (tenant) een eigen database
> stop de data van alle klanten in één database
De 1e keuze kun je beargumenteren als niet multi-tenant. De dienst als geheel is echter wel multi-tenant en daar gaat het uiteindelijk om.
Alle data in één database stoppen is een vorm van opschalen (scale up), je maakt iets groter en zwaarder terwijl de database snel moet blijven. Voor iedere klant een database maken heet scale-out. Je houdt de database snel door de data te verspreiden. Er zijn diverse voors en tegen voor beide aanpakken, ik zal er een paar geven.
Scale up
Het voordeel van één database is dat het beheer en de schaalbaarheid in de basis goed te realiseren is, hoewel het ontwerp van het datamodel wat complexer is. Dit houdt ook de kostprijs laag. Ook het up to data houden van het model en het uitvoeren van upgrades is relatief eenvoudig omdat er maar één omgeving is. Nadelen zijn er echter ook. Upgraden kent geen uitzondering, alle klanten moeten in één keer over. Ook is de veiligheid lastiger te realiseren aangezien de data van klanten in dezelfde tabellen staan. Maar op termijn is de grootste uitdaging de schaalbaarheid. Wat als een miljoen klanten tegelijk data in de database stoppen en eruit halen? Wat als je klanten overal ter wereld zitten?
Scale out
Bij het maken van een database per klant begin ik bij de nadelen. Het beheren van duizenden databases is lastig. Je moet veel dingen zoals upgraden geautomatiseerd kunnen doen anders ben je exponentieel veel tijd kwijt voor het beheer. Als er zaken fout gaan, bijvoorbeeld in upgrades kan dit leiden tot een beheer nachtmerrie. Als je licenties moet betalen per database zullen deze dus ook leiden tot hogere kosten. Er zijn echter ook voordelen. Zo gebeurt het niet snel dat je data van andere klanten per ongelukt “lekt”. Ook het snel houden van een relatief kleine database is makkelijker dan van een grote database. Ook zijn er subtiele voordelen zoals een eenvoudige restore of disaster recovery. Daarnaast hoeven niet alle klanten direct mee te gaan in een update/upgrade. Maar zoals gezegd, beheer vergt veel automatisering anders zullen de kosten snel oplopen. Daarvoor krijg je wel in de basis oneindige schaalbaarheid terug. Ook heeft het voordelen als klanten over meerdere werelddelen verspreid zijn. Hoe dichter de data zich bij de klant bevindt, hoe makkelijker het is om de data snel te serveren.
Het is dus zaak van de te voren in te schatten wie je klanten zijn en hoeveel dat er kunnen worden. Scale up is tot een bepaald niveau goedkoper en sneller te realiseren. Scale out is de winnaar als het echt op grootte aankomt.
Wat zijn de uitdagingen bij multi-tenancy?
Wat gebeurt er als een database niet goed ontworpen is? Het ergste is imagoschade die kan ontstaan als er ontdekt wordt hoe je data in kunt zien van andere klanten. Veiligheid van data is dan ook van de hoogste prioriteit. Een grote belemmering van de adoptie van internet applicaties is vertrouwen en een slecht imago zal de dienst geen goed doen. Andere bedreigingen is als de dienst populair wordt en daarmee trager. Dit zag je bijvoorbeeld bij de onstuimige groei van Hyves en Twitter. Bij applicaties die door bedrijven gebruikt worden zie je vaak dat bedrijven niet altijd direct mee willen met de nieuwste functionaliteit en het faciliteren hierin is bijzonder lastig als alles in één database zit. Net als het herstellen van data als er iets fout is gegaan bij één klant. Als laatste is het beheren van de klant omgevingen een uitdaging, vooral als klanten bepaalde vormen van vrijheid krijgen om het datamodel flexibel in te richten.
Hybride
Wat voor de database geldt, gaat ook op voor andere onderdelen van het ontwerp, de rekenkracht, load balancers, cache, et cetera. In de regel is scale out vaker een betere keuze dan scale up.
Zelf heb ik een hekel aan het woord hybride omdat dit vaak voorgesteld wordt als het beste model voor cloud computing. In dit geval is het echter wel een woord wat snel een goed beeld schetst als het gaat om scale-up of scale-out. Ik zie namelijk in de basis geen belemmering om databases multi-tenant te ontwerpen, maar deze ook te dupliceren voor iedere klant. Ook hier begin ik weer met de nadelen; het ontwerp is bevat meer complexiteit en daarnaast moet je ook nog eens het beheer en automatisering inregelen voor de scale-out. Maar deze prijs is relatief laag en de voordelen zijn groot. Je kunt het nu voor kleine klanten aanbieden of voor een gratis model. Deze zitten in één database. Als één klant te groot wordt kan deze gemigreerd worden naar een eigen database. Krijgt een klant een dochterbedrijf of neemt deze een bedrijf over? Dan kan in diens database gewoon een tenant worden toegevoegd. Ook white labelen is nu relatief makkelijk te realiseren.
Take-aways
Dan heb ik nog twee take-aways voor het ontwerpen van multi-tenant datamodellen. De eerste is om bij elke veel tabellen bijvoorbeeld een veld toe voegen met bijvoorbeeld een naam als TenantId. Elke bevraging (query) gebruik je deze TenantId om zodoende nooit data te kunnen tonen van andere tenants. De tweede take-away is het gebruik van Global Unique IDentifiers (GUIDS). Gebruik als primaire sleutel voor elke tabel een GUID. Een GUID heeft bijvoorbeeld deze vorm : FD9EDB38-864D-49F2-A8AE-B6439AB3362D . Dat lijkt een verspilling van ruimte, maar besef dat een adres veld al meer tekens bevat. De voordelen van GUID’s zijn zeer krachtig. Google maar eens op deze GUID, je zult alleen dit artikel vinden. Het voordeel in multi-tenant omgevingen is dat je heel gemakkelijk data van een klant kunt verplaatsen naar een andere database. Een GUID is volstrekt uniek over alle database ter wereld heen.
Hoe dan ook, Als je ontwerpt voor schaal moet je ook ontwerpen op basis van automatisering anders slaat die schaal keihard in je gezicht terug.