Architectuurmethoden voor opslag en gegevens in multitenant-oplossingen

  • Artikel
  • 16 minuten om te lezen

Bij het plannen van opslag- of gegevensonderdelen voor meerdere tenants moet u een benadering kiezen voor het delen of isoleren van de gegevens van uw tenants. Gegevens worden vaak beschouwd als het meest waardevolle onderdeel van een oplossing, omdat deze de waardevolle bedrijfsinformatie van uw of uw klanten vertegenwoordigen. Het is dus belangrijk om de aanpak die u gebruikt voor het beheren van gegevens in een multitenant-omgeving zorgvuldig te plannen. Op deze pagina bieden we richtlijnen over de belangrijkste overwegingen en vereisten die u moet overwegen bij het kiezen van een benadering voor het opslaan van gegevens in een multitenant-systeem. Vervolgens wordt een aantal algemene patronen voor het toepassen van multitenancy op opslag- en gegevensservices en een aantal antipatronen om te voorkomen. Ten slotte bieden we gerichte richtlijnen voor een aantal specifieke situaties.

Belangrijke overwegingen en vereisten

Het is belangrijk om rekening te houden met de benaderingen die u gebruikt voor opslag- en gegevensservices vanuit een aantal perspectieven, die ongeveer zijn afgestemd op de pijlers van het Azure Well-Architected Framework.

Schalen

Wanneer u werkt met services die uw gegevens opslaan, moet u rekening houden met het aantal tenants dat u hebt en het volume van de gegevens die u opgeslagen. Als u een klein aantal tenants (zoals vijf of minder) hebt en u kleine hoeveelheden gegevens voor elke tenant opslaat, is het waarschijnlijk een verspilde inspanning om een zeer schaalbare benadering voor gegevensopslag te plannen of om een volledig geautomatiseerde benadering te bouwen voor het beheren van uw gegevensbronnen. Naarmate u groeit, profiteert u steeds meer van een duidelijke strategie om uw gegevens- en opslagresources te schalen en automatisering toe te passen op hun beheer. Wanneer u 50 tenants of meer hebt, of als u van plan bent dat schaalniveau te bereiken, is het vooral belangrijk om uw gegevens- en opslagbenadering te ontwerpen, met schaal als een belangrijke overweging.

Houd rekening met de mate waarin u van plan bent te schalen en plan duidelijk de architectuur van uw gegevensopslag om aan dat schaalniveau te voldoen.

Voorspelbaarheid van prestaties

Multitenant-gegevens- en opslagservices zijn met name vatbaar voor het probleem met ruisende buren. Het is belangrijk om te overwegen of uw tenants van invloed kunnen zijn op elkaars prestaties. Hebben uw tenants bijvoorbeeld overlappende pieken in hun gebruikspatronen gedurende een bepaalde periode? Gebruiken al uw klanten uw oplossing elke dag op hetzelfde moment of worden aanvragen gelijkmatig verdeeld? Deze factoren zijn van invloed op het isolatieniveau dat u moet ontwerpen, de hoeveelheid resources die u moet inrichten en de mate waarin resources kunnen worden gedeeld tussen tenants.

Het is belangrijk om de resource en aanvraagquota van Azure als onderdeel van deze beslissing te overwegen. Stel bijvoorbeeld dat u één opslagaccount implementeert dat alle gegevens van uw tenants bevat. Als u een bepaald aantal opslagbewerkingen per seconde overschrijdt, worden Azure Storage aanvragen van uw toepassing afgewezen en worden al uw tenants beïnvloed. Dit wordt beperkingsgedrag genoemd. Het is belangrijk dat u controleert op beperkt aantal aanvragen. Zie Richtlijnen voor opnieuw proberen voor Azure-services voor meer informatie.

Gegevensisolatie

Bij het ontwerpen van een oplossing die multitenant-gegevensservices bevat, zijn er meestal verschillende opties en niveaus van gegevensisolatie, elk met hun eigen voordelen en afwegingen. Bijvoorbeeld:

  • Wanneer u Azure Cosmos DB, kunt u afzonderlijke containers voor elke tenant implementeren en kunt u databases en accounts delen tussen meerdere tenants. U kunt ook overwegen om verschillende databases of zelfs accounts voor elke tenant te implementeren, afhankelijk van het vereiste isolatieniveau.
  • Wanneer u Azure Storage blobgegevens gebruikt, kunt u afzonderlijke blobcontainers implementeren voor elke tenant of u kunt afzonderlijke opslagaccounts implementeren.
  • Wanneer u Azure SQL, kunt u afzonderlijke tabellen in gedeelde databases gebruiken of kunt u afzonderlijke databases of servers voor elke tenant implementeren.
  • In alle Azure-services kunt u overwegen resources te implementeren binnen één gedeeld Azure-abonnement, of u kunt meerdere Azure-abonnementen gebruiken, mogelijk zelfs één per tenant.

Er is geen enkele oplossing die voor elke situatie werkt. De optie die u kiest, is afhankelijk van een aantal factoren en de vereisten van uw tenants. Als uw tenants bijvoorbeeld moeten voldoen aan specifieke nalevings- of regelgevingsstandaarden, moet u mogelijk een hoger isolatieniveau toepassen. Op dezelfde manier hebt u mogelijk commerciële vereisten om de gegevens van uw klanten fysiek te isoleren, of moet u isolatie afdwingen om het probleem met ruis te voorkomen. Als tenants hun eigen versleutelingssleutels moeten gebruiken, hebben ze afzonderlijke back-up- en herstelbeleidsregels, of moeten hun gegevens worden opgeslagen op verschillende geografische locaties, moet u ze mogelijk isoleren van andere tenants of ze groeperen met tenants met vergelijkbare beleidsregels.

Complexiteit van de implementatie

Het is belangrijk om rekening te houden met de complexiteit van uw implementatie. Het is een goed idee om uw architectuur zo eenvoudig mogelijk te houden, terwijl u toch aan uw vereisten voldoet. Vermijd het inzetten van een architectuur die steeds complexer wordt naarmate u schaalt, of een architectuur die u niet over de resources of expertise beschikt om te ontwikkelen en te onderhouden.

Als uw oplossing niet hoeft te worden geschaald naar een groot aantal tenants, of als u zich geen zorgen maakt over prestaties of gegevensisolatie, is het beter om uw oplossing eenvoudig te houden en onnodige complexiteit te voorkomen.

Een specifiek probleem voor multitenant-gegevensoplossingen is het aanpassingsniveau dat u ondersteunt. Kan een tenant bijvoorbeeld uw gegevensmodel uitbreiden of aangepaste gegevensregels toepassen? Zorg ervoor dat u hiervoor vooraf ontwerpt. Vermijd het schalen of leveren van aangepaste infrastructuur voor afzonderlijke tenants, omdat u hierdoor niet meer kunt schalen, uw oplossing kunt testen en updates kunt implementeren. Overweeg in plaats daarvan het gebruik van functievlaggen en andere vormen van tenantconfiguratie.

Complexiteit van beheer en bewerkingen

Bedenk hoe u van plan bent om uw oplossing te gebruiken en hoe uw multitenancybenadering van invloed is op uw bewerkingen en processen. Bijvoorbeeld:

  • Overweeg beheerbewerkingen voor verschillende tenants, zoals normale onderhoudsactiviteiten. Als u meerdere accounts, servers of databases gebruikt, hoe initieert en bewaakt u dan de bewerkingen voor elke tenant?
  • Als u uw tenants bewaakt of meet, moet u overwegen hoe uw oplossing metrische gegevens rapporteert en of deze eenvoudig kunnen worden gekoppeld aan de tenant die de aanvraag heeft geactiveerd.
  • Rapportagegegevens van verschillende geïsoleerde tenants vereisen mogelijk dat elke tenant gegevens publiceert naar een gecentraliseerd datawarehouse, in plaats van query's uit te kunnen geven op elke database afzonderlijk en vervolgens de resultaten samen te brengen.
  • Als u een database gebruikt die een schema afdwingt, plan dan hoe u schema-updates in uw estate implementeert. Bedenk hoe uw toepassing weet welke schemaversie moet worden gebruikt voor de databasequery's van een specifieke tenant.
  • Houd rekening met de vereisten voor hoge beschikbaarheid van uw tenants (bijvoorbeeld uptime-serviceovereenkomsten of SLA's) en vereisten voor herstel na noodherstel (bijvoorbeeld hersteltijddoelen of RTO's, en herstelpuntdoelstellingen of RTO's). Als tenants andere verwachtingen hebben, kunt u dan voldoen aan de vereisten van elke tenant?
  • Hoe migreert u tenants als ze moeten worden verplaatst naar een ander type service, een andere implementatie of een andere regio?

Kosten

Over het algemeen geldt dat hoe hoger de dichtheid van tenants voor uw implementatie-infrastructuur is, hoe lager de kosten voor het inrichten van die infrastructuur. Gedeelde infrastructuur verhoogt echter de kans op problemen zoals het probleem Noisy Neighbor,dus overweeg de afwegingen zorgvuldig.

Benaderingen en patronen om rekening mee te houden

Verschillende ontwerppatronen uit de Azure Architecture Center zijn van belang voor meerdere opslag- en gegevensservices. U kunt ervoor kiezen om één patroon consistent te volgen. Of u kunt overwegen om patronen te combineren en te matchen. U kunt bijvoorbeeld een multitenant-database gebruiken voor de meeste tenants, maar zegels met één tenant implementeren voor tenants die meer betalen of die ongebruikelijke vereisten hebben. Op dezelfde manier is het vaak een goede gewoonte om te schalen met behulp van implementatiestempels, zelfs wanneer u een multitenant-database of shard-databases binnen een stempel gebruikt.

Patroon Implementatiestempels

Het patroon Implementatiestempels omvat het implementeren van een toegewezen infrastructuur voor een tenant of groep tenants. Een enkele zegel kan meerdere tenants bevatten of kan worden toegewezen aan één tenant.

Diagram met het patroon Implementatiestempels. Elke tenant heeft een eigen zegel met een database.

Wanneer u stempels met één tenant gebruikt, is het patroon Implementatiestempels doorgaans eenvoudig te implementeren, omdat elke zegel waarschijnlijk geen andere stempels heeft en er dus geen multitenancylogica of mogelijkheden hoeven te worden ingebouwd in de toepassingslaag. Wanneer elke tenant een eigen toegewezen zegel heeft, biedt dit patroon de hoogste mate van isolatie en vermindert het probleem met ruis. Het biedt ook de mogelijkheid voor tenants om te worden geconfigureerd of aangepast volgens hun eigen vereisten, zoals om zich te bevinden in een specifieke geopolitieke regio of om specifieke vereisten voor hoge beschikbaarheid te hebben.

Wanneer u multitenant stempels gebruikt, moeten andere patronen worden overwogen voor het beheren van multitenancy binnen de zegel, en het probleem Noisy Neighbor kan nog steeds van toepassing zijn. Met behulp van het patroon Implementatiestempels kunt u er echter voor zorgen dat u kunt blijven schalen naarmate uw oplossing groeit.

Het grootste probleem met het patroon Implementatiestempels, wanneer het wordt gebruikt om één tenant te bedienen, zijn meestal de kosten van de infrastructuur. Wanneer u stempels met één tenant gebruikt, moet elke zegel een eigen afzonderlijke set infrastructuur hebben, die niet wordt gedeeld met andere tenants. U moet er ook voor zorgen dat de resources die zijn geïmplementeerd voor een zegel voldoende zijn om te voldoen aan de piekbelasting voor de workload van die tenant. Zorg ervoor dat uw prijsmodel de implementatiekosten voor de infrastructuur van de tenant verschoven.

Stempels met één tenant werken vaak goed wanneer u een klein aantal tenants hebt. Naarmate het aantal tenants groeit, is het mogelijk, maar steeds moeilijker om een vloot van stempels te beheren ( zie dezecase study als voorbeeld). U kunt ook het patroon Implementatiestempels toepassen om een vloot van multitenant-zegels te maken, wat voordelen kan bieden voor het delen van resources en kosten.

Als u het patroon Implementatiestempels wilt implementeren, is het belangrijk om geautomatiseerde implementatiemethoden te gebruiken. Afhankelijk van uw implementatiestrategie kunt u overwegen om uw stempels binnen uw implementatiepijplijnen te beheren met behulp van declaratieve infrastructuur als code, zoals Bicep, ARM-sjablonen of Terraform-sjablonen. U kunt ook overwegen om aangepaste code te maken voor het implementeren en beheren van elke zegel, zoals met behulp van de Azure SDK's.

Gedeelde multitenant-databases en bestandsopslag

U kunt overwegen om een gedeelde multitenant-database, opslagaccount of bestandsdeling te implementeren en deze te delen in al uw tenants.

Diagram met één gedeelde multitenant-database voor de gegevens van alle tenants.

Deze aanpak biedt de hoogste dichtheid van tenants voor infrastructuur, zodat deze meestal tegen de laagste kosten van elke benadering aanbesteedt. Het vermindert ook vaak de beheeroverhead, omdat er één database of resource is om te beheren, back-up te maken en te beveiligen.

Wanneer u echter met een gedeelde infrastructuur werkt, zijn er verschillende overwegingen waar u rekening mee moet houden:

  • Wanneer u afhankelijk bent van één resource, moet u rekening houden met de ondersteunde schaal en limieten van die resource. Zo wordt de maximale grootte van één database of bestandsopslag, of de maximale doorvoerlimieten, uiteindelijk een harde blokkering als uw architectuur afhankelijk is van één database. Overweeg zorgvuldig de maximale schaal die u moet bereiken en vergelijk deze met uw huidige en toekomstige limieten voordat u dit patroon selecteert.
  • Het probleem met ruis kan een factor worden, met name als u tenants hebt die bezet zijn of hogere workloads genereren dan andere. Overweeg het patroon Beperking of het patroon Snelheidsbeperking toe te passen om deze effecten te beperken.
  • Mogelijk hebt u problemen met het bewaken van de activiteit en het meten van het verbruik voor één tenant. Sommige services, zoals Azure Cosmos DB, bieden rapportage over resourcegebruik voor elke aanvraag, zodat deze informatie kan worden bij houden om het verbruik voor elke tenant te meten. Andere services bieden niet hetzelfde detailniveau. De metrische gegevens van Azure Files voor bestandscapaciteit zijn bijvoorbeeld beschikbaar per bestands sharedimensie, alleen wanneer u Premium-shares gebruikt. De standard-laag biedt echter alleen de metrische gegevens op het niveau van het opslagaccount.
  • Tenants kunnen verschillende vereisten hebben voor beveiliging, back-up, beschikbaarheid of opslaglocatie. Als deze niet overeenkomen met de configuratie van uw enkele resource, kunt u deze mogelijk niet aan.
  • Wanneer u werkt met een relationele database of een andere situatie waarin het schema van de gegevens belangrijk is, is schemaaanpassing op tenantniveau moeilijk.

Patroon Sharding

Diagram met een shard-database. De ene database bevat de gegevens voor tenantS A en B en de andere database bevat de gegevens voor tenant C.

Het Sharding-patroon omvat het implementeren van meerdere afzonderlijke databases, ook wel shards genoemd, die gegevens van een of meer tenants bevatten. In tegenstelling tot implementatiestempels impliceren shards niet dat de hele infrastructuur wordt gedupliceerd. U kunt databases sharden zonder ook andere infrastructuur in uw oplossing te dupliceren of sharden.

Sharding is nauw gerelateerd aan partitionering en de termen worden vaak door elkaar gebruikt. Houd rekening met de richtlijnen voor horizontale, verticale en functionele gegevenspartities.

Het Sharding-patroon kan worden geschaald naar zeer grote aantallen tenants. Afhankelijk van uw workload kunt u bovendien mogelijk een high-density van tenants naar shards bereiken, zodat de kosten aantrekkelijk kunnen zijn. Het Sharding-patroon kan ook worden gebruikt voor het aanpakken van Azure-abonnement en servicequota, limieten en beperkingen.

Sommige gegevensopslag, zoals Azure Cosmos DB, bieden systeemeigen ondersteuning voor sharding of partitionering. Wanneer u met andere oplossingen werkt, zoals Azure SQL, kan het complexer zijn om een sharding-infrastructuur te bouwen en aanvragen voor een bepaalde tenant naar de juiste shard te routeeren.

Multitenant-app met toegewezen databases voor elke tenant

Een andere veelgebruikte benadering is het implementeren van één multitenant-toepassing, met toegewezen databases voor elke tenant.

Diagram met verschillende databases voor elke tenant.

In dit model worden de gegevens van elke tenant geïsoleerd van de andere en kunt u mogelijk een zekere mate van aanpassing voor elke tenant ondersteunen.

Omdat u toegewezen gegevensbronnen voor elke tenant inrichten, kunnen de kosten voor deze benadering hoger zijn dan gedeelde hostingmodellen. Azure biedt echter verschillende opties die u kunt overwegen om de kosten voor het hosten van afzonderlijke gegevensbronnen in meerdere tenants te delen. Als u bijvoorbeeld met Azure SQL, kunt u elastische pools overwegen. Voor Azure Cosmos DB kunt u doorvoer inrichten voor een database en wordt de doorvoer gedeeld tussen de containers in die database, hoewel deze benadering niet geschikt is wanneer u gegarandeerde prestaties voor elke container nodig hebt.

Omdat in deze benadering alleen de gegevensonderdelen afzonderlijk voor elke tenant worden geïmplementeerd, kunt u waarschijnlijk high-density bereiken voor de andere onderdelen in uw oplossing en de kosten van die onderdelen verlagen.

Het is belangrijk om geautomatiseerde implementatiemethoden te gebruiken bij het inrichten van databases voor elke tenant.

Geodes-patroon

Het Geode-patroon is specifiek ontworpen voor geografisch gedistribueerde oplossingen, waaronder multitenant-oplossingen. Het ondersteunt hoge belasting en hoge tolerantieniveaus. Wanneer u met het Geode-patroon werkt, moet de gegevenslaag in staat zijn om de gegevens te repliceren tussen geografische regio's en moet deze ondersteuning bieden voor schrijfgegevens in meerdere geografische regio's.

Diagram met het geodepatroon, met databases die zijn geïmplementeerd in meerdere regio's die met elkaar worden gesynchroniseerd.

Azure Cosmos DB biedt schrijf schrijfingen voor meerdere masters ter ondersteuning van dit patroon en Cassandra ondersteunt clusters met meerdere regio's. Andere gegevensservices kunnen dit patroon doorgaans niet ondersteunen, zonder aanzienlijke aanpassingen.

Antipatroon dat moet worden vermeden

Wanneer u werkt met multitenant-gegevensservices, is het belangrijk om situaties te voorkomen die uw mogelijkheid om te schalen belemmeren.

Voor relationele databases zijn dit onder andere:

  • Isolatie op basis van tabel. Als u binnen één database werkt, moet u het maken van afzonderlijke tabellen voor elke tenant vermijden. Een individuele database kan geen ondersteuning bieden voor zeer grote aantallen tenants wanneer u deze methode gebruikt en het wordt steeds moeilijker om gegevens op te vragen, te beheren en bij te werken. Overweeg in plaats daarvan om één set multitenant-tabellen met een kolom tenant-id te gebruiken. U kunt ook een van de hierboven beschreven patronen gebruiken om afzonderlijke databases voor elke tenant te implementeren.
  • Aanpassing van tenants op kolomniveau. Vermijd het toepassen van schema-updates die alleen van toepassing zijn op één tenant. Stel bijvoorbeeld dat u één multitenant-database hebt. Vermijd het toevoegen van een nieuwe kolom om te voldoen aan de vereisten van een specifieke tenant. Het kan acceptabel zijn voor een klein aantal aanpassingen, maar dit wordt snel onmanagebaar wanneer u een groot aantal aanpassingen moet overwegen. Overweeg in plaats daarvan uw gegevensmodel te herzien om aangepaste gegevens voor elke tenant in een toegewezen tabel bij te houden.
  • Handmatige schemawijzigingen. Voorkom dat u uw databaseschema handmatig bijwerkt, zelfs als u slechts één gedeelde database hebt. Het is eenvoudig om de updates die u hebt toegepast uit het overzicht te verliezen. Als u wilt uitschalen naar meer databases, is het lastig om het juiste schema te identificeren dat u wilt toepassen. Bouw in plaats daarvan een geautomatiseerde pijplijn om uw schemawijzigingen te implementeren en gebruik deze consistent. Houd de schemaversie bij die wordt gebruikt voor elke tenant in een toegewezen database of opzoektabel.
  • Versieafhankelijkheden. Voorkom dat uw toepassing afhankelijk is van één versie van uw databaseschema. Tijdens het schalen moet u mogelijk schema-updates op verschillende tijdstippen toepassen voor verschillende tenants. Zorg er in plaats daarvan voor dat uw toepassingsversie achterwaarts compatibel is met ten minste één schemaversie en voorkom destructieve schema-updates.

Databases

Er zijn enkele functies die nuttig kunnen zijn voor multitenancy. Deze zijn echter niet beschikbaar in alle databaseservices. Overweeg of u deze nodig hebt wanneer u besluit welke service u wilt gebruiken voor uw scenario:

  • Beveiliging op rijniveau kan beveiligingsisolatie bieden voor gegevens van specifieke tenants in een gedeelde multitenant-database. Deze functie is beschikbaar in Azure SQL en Postgres Flex, maar is niet beschikbaar in andere databases, zoals MySQL of Azure Cosmos DB.
  • Versleuteling op tenantniveau is mogelijk vereist ter ondersteuning van tenants die hun eigen versleutelingssleutels voor hun gegevens leveren. Deze functie is beschikbaar in Azure SQL als onderdeel van Always Encrypted. Cosmos DB biedt door de klant beheerde sleutels op accountniveau en ondersteunt ook Always Encrypted.
  • Resourcegroepering biedt de mogelijkheid om resources en kosten te delen tussen meerdere databases of containers. Deze functie is beschikbaar in de elastische pools en beheerde exemplaren van Azure SQL en in de databasedoorvoervan Azure Cosmos DB, hoewel elke optie beperkingen heeft waarmee u rekening moet houden.
  • Sharding en partitionering hebben in sommige services betere systeemeigen ondersteuning dan andere services. Deze functie is beschikbaar in Azure Cosmos DB, met behulp van de logische en fysieke partitioneringen in Postgres Hyperscale. Hoewel Azure SQL systeemeigen ondersteuning biedt voor sharding, biedt het sharding-hulpprogramma's ter ondersteuning van dit type architectuur.

Wanneer u werkt met relationele databases of andere op schema's gebaseerde databases, moet u bovendien overwegen waar het schema-upgradeproces moet worden geactiveerd wanneer u een aantal databases onderhoudt. In een klein aantal databases kunt u overwegen een implementatiepijplijn te gebruiken om schemawijzigingen te implementeren. Naarmate u groeit, is het mogelijk beter voor uw toepassingslaag om de schemaversie voor een specifieke database te detecteren en het upgradeproces te starten.

Bestands- en blobopslag

Denk na over de methode die u gebruikt om gegevens binnen een opslagaccount te isoleren. U kunt bijvoorbeeld afzonderlijke opslagaccounts implementeren voor elke tenant of u kunt opslagaccounts delen en afzonderlijke containers implementeren. U kunt ook gedeelde blobcontainers maken en vervolgens het blobpad gebruiken om gegevens voor elke tenant te scheiden. Overweeg limieten en quota voor Azure-abonnementenen plan uw groei zorgvuldig om ervoor te zorgen dat uw Azure-resources worden geschaald om uw toekomstige behoeften te ondersteunen.

Als u gedeelde containers gebruikt, moet u uw verificatie- en autorisatiestrategie zorgvuldig plannen om ervoor te zorgen dat tenants geen toegang hebben tot elkaars gegevens. Houd rekening met het valetsleutelpatroonwanneer u clients toegang geeft tot Azure Storage resources.

Kostentoewijzing

Denk na over hoe u het verbruik meet en kosten toekent aan tenantsvoor het gebruik van gedeelde gegevensservices. Waar mogelijk kunt u ingebouwde metrische gegevens gebruiken in plaats van uw eigen metrische gegevens te berekenen. Met een gedeelde infrastructuur wordt het echter moeilijk om telemetrie voor afzonderlijke tenants te splitsen. Aangepaste meting op toepassingsniveau moet worden overwogen.

Over het algemeen bieden cloudeigen services, zoals Azure Cosmos DB en Azure Blob Storage, gedetailleerdere metrische gegevens om het gebruik voor een specifieke tenant bij te houden en te modelleren. Zo biedt Azure Cosmos DB de verbruikte doorvoer voor elke aanvraag en elk antwoord.

Volgende stappen

Zie voor meer informatie over multitenancy en specifieke Azure-services: