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?
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 eerste 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 tegens 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 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.
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 internetapplicaties is vertrouwen en een slecht imago zal de dienst geen goed doen. Andere bedreiging is dat 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 dat 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 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 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.
Henri of kan ik beter Mr. Mc-Cloud zeggen 🙂
Alle gekheid op een stokje. Leuk en gemakkelijk leesbaar artikel.
“Ieder voordeel heb zijn nadeel” zo als Cruyff ooit eens wijs sprak.
Dat geldt ook voor Scale up en Scale Out. Minder beheer en minder licentiekosten. Al hangt dat laatste natuurlijk wel af van de hardware specificaties. Als je alles samenvoegt tot 1 DB, heb je daar vaak meer resources en rekenkracht voor nodig. En juist op DB gebied is de meeste software gelicenseerd op CPU of erger nog op CORE. Maar daar tegen over staat weer minder flexibiliteit. Een centrale DB is lastiger te patchen, updaten aan te passen etc. etc. Tevens kan het ook de achilleshiel van je omgeving worden. Valt je DB heb je echt een uitdaging. Maar dit is dan weer goed af te vangen door een cluster of DR omgeving op te zetten.
Er zijn dus meerdere wegen die naar Rome leiden. Ik ben zelf voorstander van een mix / best of bothworlds. Een beetje van jezelf en Maggi dus.
Henri,
Het ‘multi-tenant’ maken op de datalaag is vaak al simpel op te lossen door een prefix te gebruiken. Een truc die ook gebruikt wordt – tenminste ik doe dat wel – met populaire Open Source Content Management Systemen als Joomla/Drupal e.d. Op die manier heb ik voor hetzelfde geld een productie- en acceptatiesysteem online met maar 1 database;-)
Schaalbaarheid is natuurlijk een heel ander hoofdstuk zoals ik al aanhaalde in mijn laatste opinie. Scale out van de datalaag is vaak niet zo eenvoudig omdat je dan rekening moet houden met allerlei factoren zoals je zelf al deels aangeeft. Juist hier kiezen de verschillende en bekende Cloud providers ieder een andere oplossing. En omdat de duivel hier in de details zit is migratie niet altijd zo eenvoudig als je denkt. Zeker niet als bij ontwerp van de service cq. applicaties geen rekening gehouden is met de non-functionele eisen.
Ewout, Ruud, dank voor de reacties.
Ruud, Licenties zijn inderdaad een parameter in de overweging, vandaar dat nieuwe bedrijven, of bedrijven die opnieuw een oplossing bedenken niet snel meer voor bijvoorbeeld Oracle zullen kiezen.
En uiteraard mixen is goed, als je maar oppast dat je geen vleesch nog visch oplossing wordt die uiteindelijke de nadelen pakt en niet profiteert van de voordelen (een fout die je vaak ziek omdat bedrijven voor standaard software kiezen en daarop maatwerk gaan bouwen, een vreselijke keuze).
Ewout, prefix of sharding / paritioning is inderdaad een mogelijkheid en je toepassing test/ontwikkel/productie die je noemt als voorbeeld een nice take-away.
Goed nadenken over de toekomst is belangrijk bij strategische keuzes zoals deze. Als je weet wat je maximale scope is (in grootte en functionaliteit) kun je al goed een beslissing maken.
Punt is wel dat bij Scale-Out je serieus moet investeren in automatisering, kun of wil je dat niet dan is er een scale-up indicatie.
Het onderwerp van het artikel en m.n. scale in/- out is super interessant, alleen al vanuit juridische oogpunt (data-scheiding) en beveiliging.
Als semi-leek techniek zie ik graag de voordelen van de scale-out oplossing. Echter, mijn stemming is wat minder euforisch als ik kijk naar de uitvoerbaarheid in relatie tot kosten, onderhoud, geografische redenen etc. (tevens beperkingen korte termijn).
Ik denk dat op lange termijn (aangenomen dat techniek niet stilstaat) nieuwere ontwikkelingen zullen onstaan en zo de beperkingen nagenoeg teniet zullen doen.
Voor nu zou ik voor het gemak, beheersbaarheid, overzicht en investering etc. kiezen voor de scale-in oplossing met huidige techniek.
Duidelijk verhaal Henri!
Nog even een paar puntjes die je aanstipt versterken:
Multitenancy moet in je data model zitten. Doe dat nu gewoon, je krijgt er geen spijt van. Je kan altijd nog overwegen om de verschillende tenants verschillende hardware te geven. Integendeel, datamodellen later multitenant maken is een enorm gedoe. Zie de complexiteit van WordPress MU.
Als je honderden of nog meer tenants hebt, wil het er bij niet in dat je tot in in lengte der dagen die allemaal eigen hardware wilt geven. En elke database instance kost al gauw een paar honderd Megabyte geheugen, ook al heeft die niet veel gebruik.
Dan nog upgrades en updates. Ik denk dat je meer in het multitenant datamodel kan stoppen dan je verwacht. Het is in veel gevallen mogelijk om meerdere versies van de applicatie vanuit een enkele DB te leveren. Youtube en Flickr kunnen dat ook.
Een extra veld kan geen probleem zijn, en een veld dat langer wordt ook niet.
Tenslotte automatisering. Wil je een echte cloud provider zijn dan zul je tenminste de ambitie moeten hebben om je database instances vanuit een configutatie bestandje te genereren en te booten, inclusief automatische restore van een aan te geven lijstje van tenants.
Dank Pradiep voor je reactie. Overigens is “voor het gemakt” een gevaarlijk argument 😉
Peter, dank voor je inzichtvolle toevoegingen en voorbeelden. In mijn artikel praat ik wel vanuit het perspectief van relationele databases, de voorbeelden van Flickr en Youtube gelden denk ik vooral voor No-SQL, niettemin interessant.
En uiteraard, automatisering is de sleutel bij schaal.