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 toegewezen aan de opslag. Uw keuze voor tenancymodel is van invloed op het ontwerp en beheer van toepassingen. Overschakelen naar een ander model later is soms kostbaar.

A. SaaS-concepten en -terminologie

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

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

Het tenancymodel van de term verwijst naar de wijze waarop de opgeslagen gegevens van tenants worden georganiseerd:

  • Eén tenancy: In elke database worden gegevens van slechts één tenant opgeslagen.
  • Multitenancy: Elke database slaat gegevens op van meerdere afzonderlijke tenants (met mechanismen om gegevensprivacy te beschermen).
  • Er zijn ook hybride tenancymodellen beschikbaar.

B. Het juiste tenancymodel kiezen

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

  • Schaalbaarheid:

    • Aantal tenants.
    • Opslag per tenant.
    • Opslag in aggregaties.
    • Werklast.
  • Tenantisolatie: Gegevensisolatie en prestaties (of de workload van één tenant van invloed is op andere tenants).

  • Kosten per tenant: Databasekosten.

  • Complexiteit van ontwikkeling:

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

    • Prestaties bewaken en beheren.
    • Schemabeheer.
    • Een tenant herstellen.
    • Herstel na noodgevallen.
  • Customizability: Het gemak van het ondersteunen van schemaaanpassingen die specifiek zijn voor tenants of tenantklassen.

De tenancydiscussie is gericht op de gegevenslaag . Maar overweeg even de toepassingslaag . De toepassingslaag wordt behandeld als een monolithische entiteit. Als u de toepassing in veel kleine onderdelen splitst, kan uw keuze voor het tenancymodel veranderen. U kunt sommige onderdelen anders behandelen dan andere met betrekking tot zowel 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, één keer voor elke tenant. Elk exemplaar van de app is een zelfstandig exemplaar, dus deze communiceert 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 allemaal op zichzelf.

Ontwerp van 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 toepassingsexemplaren 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. Voor de isolatie moeten echter 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 perspectief van de totale 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 voor meerdere databases te centraliseren voor rapportage- of analysedoeleinden. Als dit type gecentraliseerd beheer gewenst is, moet er een catalogus worden geïmplementeerd die tenant-id's toegeeft aan database-URI's. Azure SQL Database biedt een sharding-bibliotheek die samen wordt gebruikt om een catalogus te leveren. De sharding-bibliotheek wordt formeel de clientbibliotheek voor elastische databases genoemd.

D. App met meerdere tenants met database-per-tenant

Dit volgende patroon maakt gebruik van een toepassing met meerdere tenants met veel databases, allemaal databases met één tenant. Er wordt een nieuwe database ingericht voor elke nieuwe tenant. De toepassingslaag wordt verticaal opgeschaald door meer resources per knooppunt toe te voegen. Of de app wordt horizontaal uitgeschaald door meer knooppunten toe te voegen. De schaalaanpassing is gebaseerd op de workload en is onafhankelijk van het aantal of de schaal van de afzonderlijke databases.

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

Aanpassen voor een tenant

Net als het zelfstandige app-patroon biedt het gebruik van databases met één tenant sterke tenantisolatie. 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 gegevens nodig dan de basisgegevensvelden die alle tenants nodig hebben. Verder heeft het extra gegevensveld mogelijk een index nodig.

Met database-per-tenant is het aanpassen van het schema voor een of meer afzonderlijke tenants eenvoudig te bereiken. De leverancier van de toepassing moet procedures ontwerpen om schemaaanpassingen op schaal zorgvuldig 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 dat elke database groot genoeg moet zijn om te voldoen aan de pieken in het gebruik dat deze ondervindt. Hoewel pooldatabases toegang tot resources delen, kunnen ze nog steeds een hoge mate van prestatie-isolatie bereiken.

Ontwerp van 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. Prestatiegegevens op pool- en databaseniveau zijn beschikbaar in de Azure Portal en via Azure Monitor-logboeken. De metrische gegevens kunnen uitstekend inzicht geven in zowel statistische 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 op een kosteneffectieve manier goede prestaties garanderen.

Bewerkingen schalen voor database-per-tenant

Azure SQL Database heeft veel beheerfuncties die zijn ontworpen om grote aantallen databases op schaal te beheren, zoals meer dan 100.000 databases. Deze functies maken het database-per-tenantpatroon plausibel.

Stel dat een systeem een database met 1000 tenants heeft als enige database. De database heeft mogelijk 20 indexen. Als het systeem wordt geconverteerd naar 1000 databases met één tenant, neemt de hoeveelheid indexen toe tot 20.000. In Azure SQL Database als onderdeel van Automatisch afstemmen zijn de functies voor automatisch indexeren standaard ingeschakeld. Automatische indexering beheert voor u alle 20.000 indexen en de bijbehorende lopende optimalisaties voor maken en verwijderen. Deze geautomatiseerde acties vinden plaats in een afzonderlijke database en ze worden niet gecoördineerd of beperkt door soortgelijke acties in andere databases. Automatische indexering behandelt indexen anders in een drukke database dan in een minder drukke database. Dit type aanpassing van indexbeheer zou onpraktisch zijn op de schaal van de database per tenant als deze enorme beheertaak handmatig moest worden uitgevoerd.

Andere beheerfuncties die goed worden geschaald, zijn onder andere:

  • Ingebouwde back-ups.
  • Hoge beschikbaarheid.
  • Versleuteling op schijf.
  • Prestatietelemetrie.

Automation

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

U kunt bijvoorbeeld het herstel van één tenant naar een eerder tijdstip automatiseren. Het herstel hoeft alleen de database met één tenant te herstellen waarin de tenant wordt opgeslagen. Deze herstelbewerking heeft geen invloed op andere tenants, waardoor wordt bevestigd dat beheerbewerkingen zich op het gedetailleerde niveau van elke afzonderlijke tenant bevinden.

E. Multitenant-app met databases met meerdere tenants

Een ander beschikbaar patroon is het opslaan van veel tenants in een database met meerdere tenants. Het toepassingsexemplaren kunnen een willekeurig aantal databases met meerdere tenants hebben. Het schema van een database met meerdere tenants moet een of meer kolommen met tenant-id's hebben, zodat de gegevens van een bepaalde tenant selectief kunnen worden opgehaald. Verder vereist het schema mogelijk enkele tabellen of kolommen die worden gebruikt door slechts een subset van tenants. Statische code en referentiegegevens worden echter slechts eenmaal opgeslagen en worden gedeeld door alle tenants.

Tenantisolatie wordt opgeofferd

Gegevens: Een database met meerdere tenants offert noodzakelijkerwijs tenantisolatie op. De gegevens van meerdere tenants worden samen opgeslagen in één database. Zorg er tijdens de ontwikkeling voor dat query's nooit gegevens uit meer dan één tenant beschikbaar maken. SQL Database biedt ondersteuning voor beveiliging op rijniveau, waarmee kan worden afgedwongen dat gegevens die worden geretourneerd vanuit 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 acceptabel presteert. Het Azure-systeem heeft echter geen ingebouwde manier om het gebruik van deze resources door een afzonderlijke tenant te bewaken of te beheren. De database met meerdere tenants heeft daarom een verhoogd risico op het tegenkomen van lawaaierige buren, waarbij de workload van een 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

In het algemeen hebben databases met meerdere tenants de laagste kosten per tenant. De resourcekosten voor één database zijn lager dan voor een elastische pool met een equivalent formaat. Voor scenario's waarin tenants slechts beperkte opslag nodig hebben, kunnen mogelijk miljoenen tenants worden opgeslagen in één database. Geen elastische pool kan miljoenen databases bevatten. Een oplossing met 1000 databases per pool, met 1000 pools, kan echter de schaal van miljoenen bereiken die het risico lopen om onhandig te worden om te beheren.

Twee variaties van een databasemodel met meerdere tenants worden in de volgende onderwerpen besproken, waarbij het sharded multitenant-model het meest flexibel en schaalbaar is.

F. Multitenant-app met één database met meerdere tenants

Het eenvoudigste databasepatroon met meerdere tenants maakt gebruik van één database om gegevens voor alle tenants te hosten. Naarmate er meer tenants worden toegevoegd, wordt de database omhoog geschaald met meer opslag- en rekenresources. Deze schaal omhoog kan alles zijn wat nodig is, hoewel er altijd een ultieme schaallimiet is. Lang voordat deze limiet is bereikt, wordt de database echter onhandig 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 hiervan is een herstel naar een bepaald tijdstip van de gegevens voor slechts één tenant.

G. Multitenant-app met shard-databases met 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 zich in één shard bevinden. In combinatie met een databasepatroon met meerdere tenants kunt u met een shard-model bijna onbeperkt schalen.

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

Shards beheren

Sharding voegt complexiteit toe aan zowel het ontwerp als het operationele 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 zijn ontworpen om shards toe te voegen en te verwijderen en om tenantgegevens tussen shards te verplaatsen. Een manier om te schalen is door een nieuwe shard toe te voegen en te vullen met nieuwe tenants. Op andere momenten kunt u een dichtbevolkte shard splitsen in twee minder dichtbevolkte shards. Nadat meerdere tenants zijn verplaatst of stopgezet, kunt u sparse gevulde shards samenvoegen. De samenvoeging zou leiden tot een rendabeler resourcegebruik. Tenants kunnen ook worden verplaatst tussen shards om werkbelastingen te verdelen.

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

Kleinere databases gemakkelijker te beheren

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

Tenant-id in het schema

Afhankelijk van de gebruikte shardingbenadering kunnen er extra beperkingen worden opgelegd aan het databaseschema. Voor de SQL Database toepassing splitsen/samenvoegen is vereist dat het schema de sharding-sleutel 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 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 het hebben van veel tenants in een paar databases met meerdere tenants. Databases met meerdere tenants zijn voordelig wanneer 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 het schema zijn ze dus allemaal databases met meerdere tenants. Maar in de praktijk bevatten sommige van deze databases slechts één tenant. De hoeveelheid tenants die in een bepaalde database zijn opgeslagen, heeft echter geen invloed op het databaseschema.

Tenants verplaatsen

U kunt een bepaalde tenant op elk gewenst moment verplaatsen naar een eigen database met meerdere tenants. En u kunt op elk gewenst moment van gedachten veranderen en de tenant weer 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 inricht.

Het hybride model schijnt wanneer er grote verschillen zijn tussen de resourcebehoeften van identificeerbare groepen tenants. Stel dat tenants die deelnemen aan een gratis proefversie, niet hetzelfde hoge prestatieniveau garanderen als het abonneren van tenants. Het beleid kan zijn dat tenants in de gratis proefversiefase worden opgeslagen in een database met meerdere tenants die worden gedeeld met alle tenants voor gratis proefversies. 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 betaalt voor de Premium-servicelaag, kan worden verplaatst naar een eigen nieuwe database met één tenant.

Pools

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

I. Tenancymodellen vergeleken

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

Meting Zelfstandige app Database per tenant Sharded multitenant
Schalen Normaal
1-100s
Zeer hoog
1-100.000s
Onbeperkt
1-1.000.000s
Isolatie van tenants Zeer hoog Hoog Laag; met uitzondering van één tenant (alleen in een MT-database).
Databasekosten per tenant Hoog; is grootte voor pieken. Laag; gebruikte pools. Laagste, voor kleine tenants in MT DB's.
Prestatiebewaking en -beheer Alleen per tenant Aggregeren + per tenant Aggregaat; hoewel dit slechts per tenant is voor singles.
Complexiteit van ontwikkeling Beperkt Beperkt Gemiddeld; vanwege sharding.
Operationele complexiteit Laag/hoog. Individueel eenvoudig, complex op schaal. Laag-normaal. Patronen hebben betrekking op complexiteit op schaal. Laag/hoog. Individueel tenantbeheer is complex.

Volgende stappen