Tenancypatronen voor SaaS-databases met meerdere tenants

VAN TOEPASSING OP: Azure SQL Database

In dit artikel worden de verschillende tenancymodellen beschreven die beschikbaar zijn voor een SaaS-toepassing met meerdere tenants.

Bij het ontwerpen van een SaaS-toepassing met meerdere tenants moet u zorgvuldig het tenancymodel kiezen dat het beste past bij de behoeften van uw toepassing. Een tenancymodel bepaalt hoe de gegevens van elke tenant worden toe te kennen aan de opslag. Uw gekozen tenancymodel is van invloed op het ontwerp en beheer van toepassingen. Het is soms duur om later over te schakelen naar een ander model.

A. SaaS-concepten en -terminologie

In het SaaS-model (Software as a Service) verkoopt uw bedrijf geen licenties aan uw software. In plaats daarvan maakt elke klant huurbetalingen aan uw bedrijf, waardoor elke klant een tenant van uw bedrijf wordt.

In het geval van betaalde huur ontvangt elke tenant toegang tot uw SaaS-toepassingsonderdelen en worden de gegevens opgeslagen in het SaaS-systeem.

De term tenancymodel verwijst naar de manier waarop de opgeslagen gegevens van tenants zijn georganiseerd:

  • Enkele tenancy:   In elke database worden gegevens van slechts één tenant opgeslagen.
  • Multi-tenancy:   Elke database slaat gegevens van meerdere afzonderlijke tenants op (met mechanismen om de privacy van gegevens te beschermen).
  • Hybride tenancymodellen zijn ook beschikbaar.

B. Het juiste tenancymodel kiezen

Over het algemeen heeft het tenancymodel geen invloed op de functie van een toepassing, maar dit is waarschijnlijk van invloed op andere aspecten van de algehele oplossing. De volgende criteria worden gebruikt om elk van de modellen te evalueren:

  • Schaalbaarheid:

    • Aantal tenants.
    • Opslag per tenant.
    • Opslag in aggregatie.
    • Werklast.
  • Isolatie van tenants:   Gegevensisolatie en -prestaties (of de workload van de ene tenant invloed heeft op andere tenants).

  • Kosten per tenant:   Databasekosten.

  • Complexiteit van ontwikkeling:

    • Wijzigingen in het schema.
    • Wijzigingen in query's (vereist door het patroon).
  • Operationele complexiteit:

    • Prestaties bewaken en beheren.
    • Schemabeheer.
    • Een tenant herstellen.
    • Herstel na noodgevallen.
  • Aanpassingsmogelijkheden:   Eenvoudige ondersteuning voor schemaaanpassingen die specifiek zijn voor tenants of tenantklassen.

De tenancydiscussie is gericht op de gegevenslaag. Houd echter even rekening met de toepassingslaag. De toepassingslaag wordt behandeld als een monolithische entiteit. Als u de toepassing opsplitst in veel kleine onderdelen, kan uw tenancymodelkeuze veranderen. U kunt sommige onderdelen anders behandelen dan andere met betrekking tot zowel de tenancy als de gebruikte opslagtechnologie of het gebruikte platform.

C. Zelfstandige app met één tenant met database met één tenant

Isolatie op toepassingsniveau

In dit model wordt de hele toepassing herhaaldelijk geïnstalleerd, eenmaal voor elke tenant. Elk exemplaar van de app is een zelfstandig exemplaar en communiceert dus nooit met een ander zelfstandig exemplaar. Elk exemplaar van de app heeft slechts één tenant en heeft daarom slechts één database nodig. De tenant heeft de database voor zichzelf.

Ontwerp van een zelfstandige app met precies één database met één tenant.

Elk app-exemplaar wordt geïnstalleerd in een afzonderlijke Azure-resourcegroep. De resourcegroep kan deel uitmaken van een abonnement dat eigendom is van de softwareleverancier of de tenant. In beide gevallen kan de leverancier de software voor de tenant beheren. Elk exemplaar van de toepassing is geconfigureerd om verbinding te maken met de bijbehorende database.

Elke tenantdatabase wordt geïmplementeerd als één database. Dit model biedt de grootste database-isolatie. Maar de isolatie vereist dat er voldoende resources worden toegewezen aan elke database om de piekbelastingen te verwerken. Hier is het belangrijk dat elastische pools niet kunnen worden gebruikt voor databases die zijn geïmplementeerd in verschillende resourcegroepen of voor verschillende abonnementen. Deze beperking maakt dit zelfstandige app-model met één tenant de duurste oplossing vanuit het oogpunt van databasekosten.

Leveranciersbeheer

De leverancier heeft toegang tot alle databases in alle zelfstandige app-exemplaren, zelfs als de app-exemplaren zijn geïnstalleerd in verschillende tenantabonnementen. De toegang wordt bereikt via SQL-verbindingen. Deze toegang tussen exemplaren kan de leverancier in staat stellen schemabeheer en query's tussen databases te centraliseren voor rapportage- of analysedoeleinden. Als dit soort gecentraliseerd beheer gewenst is, moet er een catalogus worden geïmplementeerd die tenant-id's toekent aan database-URI's. Azure SQL Database biedt een sharding-bibliotheek die samen wordt gebruikt om een catalogus te leveren. De sharding-bibliotheek heet formeel de Elastische database clientbibliotheek.

D. Multi-tenant-app met database-per-tenant

In dit volgende patroon wordt een toepassing met meerdere tenants met veel databases gebruikt, die allemaal databases met één tenant zijn. Er wordt een nieuwe database ingericht voor elke nieuwe tenant. De toepassingslaag wordt verticaal omhoog geschaald door meer resources per knooppunt toe te voegen. Of de app wordt horizontaal geschaald door meer knooppunten toe te voegen. De schaal is gebaseerd op de workload en is onafhankelijk van het aantal of de schaal van de afzonderlijke databases.

Ontwerp van een app met meerdere tenants met database-per-tenant.

Aanpassen voor een tenant

Net als bij het patroon van zelfstandige apps biedt het gebruik van databases met één tenant een sterke isolatie van de tenant. In elke app waarvan het model alleen databases met één tenant specificeert, kan het schema voor een bepaalde database worden aangepast en geoptimaliseerd voor de tenant. Deze aanpassing heeft geen invloed op andere tenants in de app. Misschien heeft een tenant meer gegevens nodig dan de basisgegevensvelden die alle tenants nodig hebben. Bovendien heeft het extra gegevensveld mogelijk een index nodig.

Met database-per-tenant is het eenvoudig om het schema voor een of meer afzonderlijke tenants aan te passen. De leverancier van de toepassing moet procedures ontwerpen om schemaaanpassingen zorgvuldig op schaal te beheren.

Pools voor Elastic Database

Wanneer databases in dezelfde resourcegroep worden geïmplementeerd, kunnen ze worden gegroepeerd in elastische pools. De pools bieden een rendabele manier om resources te delen in veel databases. Deze pooloptie is goedkoper dan te vereisen dat elke database groot genoeg is om de pieken in het gebruik aan te kunnen. Hoewel pooldatabases toegang tot resources delen, kunnen ze toch een hoge mate van prestatie-isolatie bereiken.

Ontwerp van een app met meerdere tenants met database-per-tenant, met behulp van een elastische pool.

Azure SQL Database biedt de hulpprogramma's die nodig zijn voor het configureren, bewaken en beheren van het delen. Zowel metrische gegevens op poolniveau als op databaseniveau zijn beschikbaar in de Azure Portal en via Azure Monitor logboeken. De metrische gegevens kunnen veel inzicht geven in zowel aggregatieprestaties als tenantspecifieke prestaties. Afzonderlijke databases kunnen worden verplaatst tussen pools om gereserveerde resources te bieden aan een specifieke tenant. Met deze hulpprogramma's kunt u goede prestaties op een rendabele manier garanderen.

Bewerkingen schalen voor database-per-tenant

Azure SQL Database bevat veel beheerfuncties die zijn ontworpen voor het beheren van grote aantallen databases op schaal, zoals meer dan 100.000 databases. Door deze functies is het database-per-tenant-patroon mogelijk.

Stel bijvoorbeeld dat een systeem een database met 1000 tenants als enige database heeft. De database kan 20 indexen hebben. Als het systeem wordt omgezet in 1000 databases met één tenant, neemt het aantal indexen toe tot 20.000. In Azure SQL Database onderdeel van Automatisch afstemmenzijn de functies voor automatisch indexeren standaard ingeschakeld. Automatisch indexeren beheert voor u alle 20.000 indexen en de lopende optimalisaties voor maken en neerzetten. Deze geautomatiseerde acties vinden plaats in een afzonderlijke database en worden niet gecoördineerd of beperkt door vergelijkbare acties in andere databases. Met automatische indexering worden indexen in een bezette database anders behandeld dan in een minder drukke database. Dit type aanpassing van indexbeheer zou niet praktisch zijn op database-per-tenant-schaal als deze enorme beheertaak handmatig moet worden uitgevoerd.

Andere beheerfuncties die goed kunnen worden geschaald, zijn onder andere:

  • Ingebouwde back-ups.
  • Hoge beschikbaarheid.
  • Versleuteling op schijf.
  • Telemetrie van prestaties.

Automation

De beheerbewerkingen kunnen worden gescript en aangeboden via een devops-model. De bewerkingen kunnen zelfs worden geautomatiseerd en zichtbaar worden gemaakt in de toepassing.

U kunt bijvoorbeeld het herstel van één tenant naar een eerder tijdstip automatiseren. Voor het herstel hoeft alleen de database met één tenant te worden hersteld waarin de tenant is opgeslagen. Deze herstelbewerking heeft geen invloed op andere tenants, wat bevestigt dat beheerbewerkingen op het fijn granulaire niveau van elke afzonderlijke tenant zijn.

E. Multi-tenant-app met databases met meerdere tenants

Een ander beschikbaar patroon is het opslaan van veel tenants in een database met meerdere tenants. Het exemplaar van de toepassing kan een groot aantal databases met meerdere tenants hebben. Het schema van een database met meerdere tenants moet een of meer tenant-id-kolommen hebben, zodat de gegevens van een bepaalde tenant selectief kunnen worden opgehaald. Daarnaast zijn voor het schema mogelijk enkele tabellen of kolommen vereist die alleen worden gebruikt door een subset van tenants. Statische code en referentiegegevens worden echter slechts één keer opgeslagen en worden gedeeld door alle tenants.

Isolatie van tenants wordt overgeslagen

Gegevens:   Een database met meerdere tenants verlaagt per se de isolatie van tenants. De gegevens van meerdere tenants worden samen opgeslagen in één database. Zorg er tijdens de ontwikkeling voor dat query's nooit gegevens van meer dan één tenant beschikbaar maken. SQL Database ondersteunt beveiliging op rijniveau,waarmee kan worden afgedwongen dat gegevens die worden geretourneerd door een query, worden beperkt tot één tenant.

Verwerking:   Een database met meerdere tenants deelt reken- en opslagresources in alle tenants. De database als geheel kan worden bewaakt om ervoor te zorgen dat deze op een aanvaardbare manier presteert. Het Azure-systeem heeft echter geen ingebouwde manier om het gebruik van deze resources door een afzonderlijke tenant te bewaken of beheren. Daarom heeft de database met meerdere tenants een verhoogd risico op ruis, waarbij de werkbelasting van één overactieve tenant van invloed is op de prestatie-ervaring van andere tenants in dezelfde database. Aanvullende bewaking op toepassingsniveau kan de prestaties op tenantniveau bewaken.

Lagere kosten

Over het algemeen hebben databases met meerdere tenants de laagste kosten per tenant. De resourcekosten voor een individuele database zijn lager dan voor een elastische pool van vergelijkbare grootte. Bovendien kunnen in scenario's waarin tenants slechts beperkte opslag nodig hebben, mogelijk miljoenen tenants worden opgeslagen in één database. Geen enkele elastische pool kan miljoenen databases bevatten. Een oplossing met 1000 databases per pool, met 1000 pools, kan echter de schaal van miljoenen bereiken, met het risico dat het onprakkig wordt om te beheren.

Twee variaties van een databasemodel met meerdere tenants worden in de volgende onderwerpen besproken, met het shard-model voor meerdere tenants het meest flexibele en schaalbare model.

F. App met meerdere tenants met één database met meerdere tenants

Het eenvoudigste databasepatroon voor meerdere tenants maakt gebruik van één database voor het hosten van gegevens voor alle tenants. Naarmate er meer tenants worden toegevoegd, wordt de database opgeschaald met meer opslag- en rekenresources. Dit omhoog schalen is mogelijk het enige wat u nodig hebt, hoewel er altijd een uiteindelijke schaallimiet is. Lang voordat deze limiet is bereikt, is de database echter onprakbaar om te beheren.

Beheerbewerkingen die zijn gericht op afzonderlijke tenants, zijn complexer om te implementeren in een database met meerdere tenants. En op schaal kunnen deze bewerkingen onacceptabel traag worden. Een voorbeeld is een herstel naar een bepaald tijdstip van de gegevens voor slechts één tenant.

G. App met meerdere tenants met shard-databases voor meerdere tenants

De meeste SaaS-toepassingen hebben toegang tot de gegevens van slechts één tenant tegelijk. Met dit toegangspatroon kunnen tenantgegevens worden gedistribueerd over meerdere databases of shards, waarbij alle gegevens voor één tenant in één shard zijn opgenomen. In combinatie met een multi-tenant-databasepatroon maakt een shard-model vrijwel onbeperkte schaal mogelijk.

Ontwerp van een app met meerdere tenants met shard-databases met meerdere tenants.

Shards beheren

Sharding voegt complexiteit toe aan zowel het ontwerp als operationeel beheer. Een catalogus is vereist voor het onderhouden van de toewijzing tussen tenants en databases. Daarnaast zijn beheerprocedures vereist voor het beheren van de shards en de tenantpopulatie. Procedures moeten bijvoorbeeld worden ontworpen om shards toe te voegen en te verwijderen, en om tenantgegevens tussen shards te verplaatsen. Eén manier om te schalen is door een nieuwe shard toe te voegen en deze te vullen met nieuwe tenants. Op andere momenten kunt u een dicht gevulde shard splitsen in twee minder dicht gevulde shards. Nadat verschillende tenants zijn verplaatst of stopgezet, kunt u verspreide shards samenvoegen. De samenvoeging zou leiden tot een rendabeler resourcegebruik. Tenants kunnen ook worden verplaatst tussen shards om workloads te verdelen.

SQL Database biedt een splits-/samenvoeghulpprogramma dat werkt in combinatie met de sharding-bibliotheek en de catalogusdatabase. De opgegeven app kan shards splitsen en samenvoegen en tenantgegevens verplaatsen tussen shards. De app onderhoudt ook de catalogus tijdens deze bewerkingen, en markeert de betrokken tenants als offline voordat ze worden verplaatst. Na de overstap werkt de app de catalogus opnieuw bij met de nieuwe toewijzing en markeert de tenant als weer online.

Kleinere databases kunnen gemakkelijker worden beheerd

Door tenants over meerdere databases te distribueren, resulteert de shard-oplossing voor meerdere tenants in kleinere databases die gemakkelijker kunnen worden beheerd. Het herstellen van een specifieke tenant naar een eerder tijdstip omvat nu bijvoorbeeld het herstellen van één kleinere database vanuit een back-up, in plaats van een grotere database die alle tenants bevat. De grootte van de database en het aantal tenants per database kunnen worden gekozen om de workload en de beheerinspanningen in balans te brengen.

Tenant-id in het schema

Afhankelijk van de gebruikte sharding-benadering kunnen er extra beperkingen worden opgelegd aan het databaseschema. De SQL Database toepassing voor splitsen/samenvoegen vereist dat het schema de shardingsleutel bevat. Dit is doorgaans de tenant-id. De tenant-id is het belangrijkste element in de primaire sleutel van alle shard-tabellen. Met de tenant-id kan de toepassing voor splitsen/samenvoegen snel gegevens zoeken en verplaatsen die zijn gekoppeld aan een specifieke tenant.

Elastische pool voor shards

Shard-databases met meerdere tenants kunnen worden geplaatst in elastische pools. Over het algemeen is het hebben van veel databases met één tenant in een pool net zo kostenefficiënt als veel tenants in een paar databases met meerdere tenants. Databases met meerdere tenants zijn voordelig als er een groot aantal relatief inactieve tenants is.

H. Hybride shard-databasemodel met meerdere tenants

In het hybride model hebben alle databases de tenant-id in hun schema. De databases kunnen allemaal meer dan één tenant opslaan en de databases kunnen worden geshard. In schema opzicht zijn het dus allemaal databases met meerdere tenants. Maar in de praktijk bevatten sommige van deze databases slechts één tenant. Het aantal tenants dat is opgeslagen in een bepaalde database heeft echter geen invloed op het databaseschema.

Tenants verplaatsen

U kunt een bepaalde tenant op elk moment verplaatsen naar een eigen database met meerdere tenants. En u kunt op elk moment van gedachten veranderen en de tenant terug verplaatsen naar een database die meerdere tenants bevat. U kunt ook een tenant toewijzen aan een nieuwe database met één tenant wanneer u de nieuwe database inrichten.

Het hybride model komt goed tot zijn uiting wanneer er grote verschillen zijn tussen de resourcebehoeften van identificeerbare groepen tenants. Stel bijvoorbeeld dat tenants die deelnemen aan een gratis proefversie niet hetzelfde hoge prestatieniveau hebben als tenants die zich abonneren. Het beleid kan zijn dat tenants in de gratis proeffase worden opgeslagen in een database met meerdere tenants die wordt gedeeld tussen alle tenants van de gratis proefversie. Wanneer een tenant voor een gratis proefversie zich abonneert op de Basic-servicelaag, kan de tenant worden verplaatst naar een andere database met meerdere tenants die mogelijk minder tenants heeft. Een abonnee die voor de Premium-servicelaag betaalt, kan worden verplaatst naar een eigen nieuwe database met één tenant.

Pools

In dit hybride model kunnen de databases met één tenant voor abonneeten tenants in resourcegroepen worden geplaatst om de databasekosten per tenant te verlagen. Dit wordt ook gedaan in het database-per-tenant-model.

I. Vergelijking van tenancymodellen

De volgende tabel bevat een overzicht van de verschillen tussen de belangrijkste tenancymodellen.

Meting Zelfstandige app Database per tenant Sharded multi-tenant
Schalen Normaal
1-100s
Zeer hoog
1-100.000
Onbeperkt
1-1.000.000
Isolatie van tenants Zeer hoog Hoog Laag; met uitzondering van één tenant (alleen in een MT-database).
Databasekosten per tenant Hoog; is een grootte voor pieken. Laag; gebruikte pools. Laagste, voor kleine tenants in MT-DB's.
Prestatiebewaking en -beheer Alleen per tenant Aggregatie + per tenant Aggregatie; hoewel alleen per tenant is voor singles.
Complexiteit van ontwikkeling Beperkt Beperkt Gemiddeld; vanwege sharding.
Operationele complexiteit Laag-hoog. Afzonderlijk eenvoudig, complex op schaal. Laag-gemiddeld. Patronen gaan in op complexiteit op schaal. Laag-hoog. Het beheer van afzonderlijke tenants is complex.
 

Volgende stappen