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.
Wanneer u een SaaS-toepassing met meerdere tenants ontwerpt, 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 heeft invloed op het ontwerp en beheer van toepassingen. Later overschakelen naar een ander model 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 zijn geordend:
- Eén tenant: elke database slaat gegevens op van slechts één tenant.
- Meerdere tenants: 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 heeft dit waarschijnlijk 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.
Aanpasbaarheid: 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 onderverdeelt, kan uw keuze voor het tenancymodel veranderen. U kunt sommige onderdelen anders behandelen dan andere met betrekking tot zowel tenancy als de 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, 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.
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 aan elke database worden toegewezen om de piekbelastingen af te handelen. 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 tussen 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 toe wijst aan database-URI's. Azure SQL Database biedt een sharding-bibliotheek die samen wordt gebruikt om een catalogus te bieden. De sharding-bibliotheek heet formeel de clientbibliotheek voor elastic database.
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 werkbelasting en is onafhankelijk van het aantal of de schaal van de afzonderlijke databases.
Aanpassen voor een tenant
Net als het zelfstandige app-patroon biedt het gebruik van databases met één tenant een sterke tenantisolatie. In elke app waarvan het model alleen databases met één tenant opgeeft, 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 mogelijk gegevens nodig die verder gaan dan de basisgegevensvelden die alle tenants nodig hebben. Verder 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 op schaal zorgvuldig te beheren.
Elastische pools
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 het vereisen dat elke database groot genoeg is om tegemoet te komen aan de pieken in het gebruik. Hoewel pooldatabases toegang hebben tot resources, kunnen ze nog steeds een hoge mate van prestatie-isolatie bereiken.
Azure SQL Database biedt de hulpprogramma's die nodig zijn om het delen te configureren, bewaken en beheren. Prestatiegegevens op poolniveau en databaseniveau zijn beschikbaar in 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 aan een specifieke tenant te bieden. Met deze hulpprogramma's kunt u op een kosteneffectieve manier goede prestaties garanderen.
Schaal van bewerkingen 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 patroon database-per-tenant plausibel.
Stel dat een systeem een database van 1000 tenants heeft als enige database. 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 als onderdeel van Automatisch afstemmen zijn de functies voor automatisch indexeren standaard ingeschakeld. Automatische indexering beheert voor u alle 20.000 indexen en hun doorlopende optimalisaties voor maken en verwijderen. Deze geautomatiseerde acties vinden plaats in een afzonderlijke database en ze worden niet gecoördineerd of beperkt door vergelijkbare 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 kunnen worden geschaald, zijn onder andere:
- Ingebouwde back-ups.
- Hoge beschikbaarheid.
- Versleuteling op schijf.
- Telemetrie van prestaties.
Automatisering
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, waarmee wordt bevestigd dat beheerbewerkingen zich op het gedetailleerde niveau van elke afzonderlijke tenant bevinden.
E. App met meerdere tenants 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 is het mogelijk dat het schema enkele tabellen of kolommen vereist 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. Daarom heeft de database met meerdere tenants een verhoogd risico dat er lawaaierige buren optreden, 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
Over het algemeen hebben databases met meerdere tenants de laagste kosten per tenant. 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 bereiken van miljoenen die het risico lopen onhandig te worden om te beheren.
Twee variaties van een databasemodel met meerdere tenants worden in de volgende onderwerpen besproken, waarbij het shard-model met meerdere tenants het meest flexibel en schaalbaar is.
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. 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 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 elke tenant zich in één shard bevinden. In combinatie met een databasepatroon met meerdere tenants kan een shard-model bijna onbeperkt worden geschaald.
Shards beheren
Sharding voegt complexiteit toe aan zowel het ontwerp als het operationele beheer. Er is een catalogus 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 deze te vullen met nieuwe tenants. Op andere momenten kunt u een dichtbevolkte shard splitsen in twee minder dichtbevolkte shards. Nadat verschillende tenants zijn verplaatst of stopgezet, kunt u shards samenvoegen die shards parseren. De samenvoeging zou resulteren in rendabeler resourcegebruik. Tenants kunnen ook worden verplaatst tussen shards om workloads te verdelen.
SQL Database biedt een hulpprogramma voor splitsen/samenvoegen dat in combinatie met de sharding-bibliotheek en de catalogusdatabase werkt. De opgegeven app kan shards splitsen en samenvoegen en kan tenantgegevens tussen shards verplaatsen. De app onderhoudt ook de catalogus tijdens deze bewerkingen, waarbij de betrokken tenants als offline worden gemarkeerd 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 kunnen worden beheerd
Door tenants over meerdere databases te distribueren, resulteert de shardoplossing voor meerdere tenants in kleinere databases die eenvoudiger 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. De SQL Database-toepassing voor splitsen/samenvoegen 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 shardtabellen. 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 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 meerdere tenants opslaan en de databases kunnen worden gehard. 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 zijn opgeslagen in een bepaalde database heeft 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 tenants die zich abonneren. Het beleid kan zijn dat tenants in de gratis proefversiefase worden opgeslagen in een database met meerdere tenants die wordt gedeeld door 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 hebben. Een abonnee die betaalt voor de Premium-servicelaag, kan worden verplaatst naar een eigen nieuwe database met één tenant.
Groepen
In dit hybride model kunnen de databases met één tenant voor tenants van abonnees 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 |
|---|---|---|---|
| Schaal | Gemiddeld 1-100s |
Zeer hoog 1-100.000s |
Onbeperkt 1-1.000.000s |
| Tenantisolatie | Zeer hoog | Hoog | Lage; met uitzondering van één tenant (alleen in een MT-database). |
| Databasekosten per tenant | Hoge; is grootte voor pieken. | Lage; gebruikte pools. | Laagste, voor kleine tenants in MT DB's. |
| Prestatiebewaking en -beheer | Alleen per tenant | Aggregaat + per tenant | Statistische; hoewel dit slechts per tenant geldt voor singles. |
| Complexiteit van ontwikkeling | Laag | Laag | Medium; vanwege sharding. |
| Operationele complexiteit | Laag/hoog. Individueel eenvoudig, complex op schaal. | Laag/middelgroot. Patronen hebben betrekking op complexiteit op schaal. | Laag/hoog. Individueel tenantbeheer is complex. |