Multitenancy en Azure Cosmos DB

Op deze pagina beschrijven we enkele van de functies van Azure Cosmos DB die handig zijn wanneer u met multitenant-systemen werkt. We koppelen ook een koppeling naar richtlijnen en voorbeelden voor het gebruik van Azure Cosmos DB in een multitenant-oplossing.

Functies van Azure Cosmos DB die ondersteuning bieden voor multitenancy

Partitionering

Met behulp van partities met uw Azure Cosmos DB-containers kunt u containers maken die worden gedeeld over meerdere tenants. Doorgaans gebruikt u de tenant-id als partitiesleutel, maar u kunt ook overwegen om meerdere partitiesleutels voor één tenant te gebruiken. Een goed geplande partitioneringsstrategie implementeert effectief het Sharding-patroon. Met grote containers verspreidt Azure Cosmos DB uw tenants over meerdere fysieke knooppunten om een hoge schaal te bereiken.

We raden u aan het gebruik van hiërarchische partitiesleutels te verkennen om de prestaties van uw multitenant-oplossing te verbeteren. Met hiërarchische partitiesleutels kunt u een partitiesleutel maken die meerdere waarden bevat. U kunt bijvoorbeeld een hiërarchische partitiesleutel gebruiken die de tenant-id bevat en het type gegevens dat u opslaat. Met deze methode kunt u schalen buiten de limiet voor logische partities van 20 GB per partitiesleutelwaarde.

Meer informatie:

Aanvraageenheden beheren

Het prijsmodel van Azure Cosmos DB is gebaseerd op het aantal aanvraageenheden per seconde dat u inricht of verbruikt. Een aanvraageenheid is een logische abstractie van de kosten van een databasebewerking of query. Normaal gesproken richt u een gedefinieerd aantal aanvraageenheden per seconde in voor uw workload. Dit wordt doorvoer genoemd. Azure Cosmos DB biedt verschillende opties voor het inrichten van doorvoer. In een omgeving met meerdere tenants is de selectie van invloed op de prestaties en prijs van uw Azure Cosmos DB-resources.

Eén tenancymodel voor Azure Cosmos DB omvat het implementeren van afzonderlijke containers voor elke tenant in een gedeelde database. Met Azure Cosmos DB kunt u aanvraageenheden inrichten voor een database en alle containers delen de aanvraageenheden. Als uw tenantworkloads doorgaans niet overlappen, kan deze aanpak helpen uw operationele kosten te verlagen. Deze benadering is echter vatbaar voor het probleem met Noisy Neighbor, omdat de container van één tenant mogelijk een onevenredige hoeveelheid van de gedeelde ingerichte aanvraageenheden verbruikt. Om dit probleem te verhelpen, moet u eerst de luidruchtige tenants identificeren. Vervolgens kunt u eventueel ingerichte doorvoer instellen voor een specifieke container. De andere containers in de database blijven hun doorvoer delen, maar de luidruchtige tenant verbruikt hun eigen toegewezen doorvoer.

Azure Cosmos DB biedt ook een serverloze laag, die geschikt is voor workloads met onregelmatig of onvoorspelbaar verkeer. Als alternatief kunt u met automatisch schalen beleidsregels configureren om de schaal van ingerichte doorvoer op te geven. Daarnaast kunt u profiteren van azure Cosmos DB-burstcapaciteit, waardoor het gebruik van uw ingerichte doorvoercapaciteit wordt gemaximaliseerd, wat anders beperkt zou zijn geweest. In een multitenant-oplossing kunt u al deze benaderingen combineren om verschillende typen tenants te ondersteunen.

Notitie

Zorg er bij het plannen van uw Azure Cosmos DB-configuratie voor dat u rekening houdt met de servicequota en -limieten.

Voor het bewaken en beheren van de kosten die aan elke tenant zijn gekoppeld, bevat elke bewerking met behulp van de Azure Cosmos DB-API de verbruikte aanvraageenheden. U kunt deze informatie gebruiken om de werkelijke aanvraageenheden die door elke tenant worden verbruikt, samen te voegen en te vergelijken. Vervolgens kunt u tenants identificeren met verschillende prestatiekenmerken.

Meer informatie:

Door klant beheerde sleutels

Voor sommige tenants is mogelijk het gebruik van hun eigen versleutelingssleutels vereist. Azure Cosmos DB biedt een door de klant beheerde sleutelfunctie. Deze functie wordt toegepast op het niveau van een Azure Cosmos DB-account, zodat tenants die hun eigen versleutelingssleutels nodig hebben, moeten worden geïmplementeerd met behulp van toegewezen Azure Cosmos DB-accounts.

Meer informatie:

Isolatiemodellen

Wanneer u werkt met een multitenant-systeem dat gebruikmaakt van Azure Cosmos DB, moet u een beslissing nemen over het isolatieniveau dat u wilt gebruiken. Business-to-business (B2B) verwijst naar verkopen aan een bedrijf. Business-to-consumer (B2C) verwijst naar het rechtstreeks verkopen aan een individuele klant die het product of de service gebruikt. Azure Cosmos DB ondersteunt verschillende isolatiemodellen:

Workload vereist Partitiesleutel per tenant Container per tenant (gedeelde doorvoer) Container per tenant (toegewezen doorvoer) Database per tenant Databaseaccount per tenant
Query's in tenants Eenvoudig (container fungeert als grens voor query's) Hard Hard Hard Hard
Tenantdichtheid Hoog (laagste kosten per tenant) Gemiddeld Laag Laag Laag
Verwijdering van tenantgegevens Hard Eenvoudig (container neerzetten wanneer de tenant vertrekt) Eenvoudig (container neerzetten wanneer de tenant vertrekt) Eenvoudig (database verwijderen wanneer de tenant vertrekt) Eenvoudig (database verwijderen wanneer de tenant vertrekt)
Beveiligingsisolatie voor gegevenstoegang Moet worden geïmplementeerd in de toepassing Container RBAC Container RBAC Database-RBAC RBAC
Geo-replicatie Geo-replicatie per tenant is niet mogelijk Tenants binnen databaseaccounts groeperen op basis van vereisten Tenants binnen databaseaccounts groeperen op basis van vereisten Tenants binnen databaseaccounts groeperen op basis van vereisten Tenants binnen databaseaccounts groeperen op basis van vereisten
Lawaaierige buurpreventie Geen Geen Ja Ja Ja
Latentie voor het maken van nieuwe tenants Direct Snel Snel Gemiddeld Langzaam
Voordelen van gegevensmodellering Geen colocatie van entiteit colocatie van entiteit Meerdere containers om tenantentiteiten te modelleren Meerdere containers en databases om tenants te modelleren
Encryptiesleutel Hetzelfde voor alle tenants Hetzelfde voor alle tenants Hetzelfde voor alle tenants Hetzelfde voor alle tenants Door de klant beheerde sleutel per tenant
Doorvoervereisten >0 RU's per tenant >100 RU's per tenant >100 RU's per tenant (met alleen automatisch schalen, anders >400 RU's per tenant) >400 RU's per tenant >400 RU's per tenant
Voorbeeld van use-case(s) B2C-apps Standaardaanbieding voor B2B-apps Premium-aanbieding voor B2B-apps Premium-aanbieding voor B2B-apps Premium-aanbieding voor B2B-apps

Partitiesleutel per tenant

Wanneer u één container voor meerdere tenants gebruikt, kunt u gebruikmaken van de ondersteuning voor partitionering van Azure Cosmos DB. Door afzonderlijke partitiesleutels voor elke tenant te gebruiken, kunt u eenvoudig een query uitvoeren op de gegevens voor één tenant. U kunt ook query's uitvoeren op meerdere tenants, zelfs als ze zich in afzonderlijke partities bevinden. Query's voor meerdere partities hebben echter een hogere aanvraageenheidkosten (RU) dan query's met één partitie.

Deze benadering werkt meestal goed wanneer de hoeveelheid gegevens die voor elke tenant is opgeslagen, klein is. Het kan een goede keuze zijn voor het bouwen van een prijsmodel met een gratis laag en voor B2C-oplossingen (business-to-consumer). Over het algemeen bereikt u met behulp van gedeelde containers de hoogste dichtheid van tenants en daarom de laagste prijs per tenant.

Het is belangrijk om rekening te houden met de doorvoer van uw container. Alle tenants delen de doorvoer van de container, zodat het probleem met ruis buurman prestatieproblemen kan veroorzaken als uw tenants hoge of overlappende workloads hebben. Dit probleem kan soms worden verholpen door subsets van tenants in verschillende containers te groeperen en ervoor te zorgen dat elke tenantgroep compatibele gebruikspatronen heeft. U kunt ook een hybride model met meerdere en één tenant overwegen. Groepeer kleinere tenants in gedeelde gepartitioneerde containers en geef grote klanten toegewezen containers. Er zijn ook functies die kunnen helpen bij het beheren van het probleem met lawaaierige buren bij het modelleren van de tenant per partitie, zoals het opnieuw toewijzen van doorvoer, burstcapaciteit en doorvoerbeheer in de Java SDK.

Het is ook belangrijk om rekening te houden met de hoeveelheid gegevens die u opslaat in elke logische partitie. Met Azure Cosmos DB kan elke logische partitie groeien tot 20 GB. Als u één tenant hebt die meer dan 20 GB aan gegevens moet opslaan, kunt u overwegen de gegevens over meerdere logische partities te spreiden. In plaats van één partitiesleutel te Contosohebben, kunt u de partitiesleutels bijvoorbeeld zout maken door meerdere partitiesleutels te maken voor een tenant, zoals Contoso1Contoso2, enzovoort. Wanneer u een query uitvoert op de gegevens voor een tenant, kunt u de WHERE IN component gebruiken om alle partitiesleutels te vinden. Hiërarchische partitiesleutels kunnen ook worden gebruikt ter ondersteuning van grote tenants, met opslag groter dan 20 GB, zonder dat u synthetische partitiesleutels of meerdere partitiesleutelwaarden per tenant hoeft te gebruiken.

Houd rekening met de operationele aspecten van uw oplossing en de verschillende fasen van de levenscyclus van de tenant. Wanneer een tenant bijvoorbeeld overgaat naar een toegewezen prijscategorie, moet u de gegevens waarschijnlijk verplaatsen naar een andere container. Wanneer de inrichting van een tenant ongedaan wordt gemaakt, moet u een verwijderquery uitvoeren op de container om de gegevens te verwijderen. Voor grote tenants kan deze query een aanzienlijke hoeveelheid doorvoer verbruiken terwijl deze wordt uitgevoerd.

Container per tenant

U kunt toegewezen containers inrichten voor elke tenant. Toegewezen containers werken goed wanneer de gegevens die u voor uw tenant opslaat, in één container kunnen worden gecombineerd. Dit model biedt betere prestatie-isolatie dan het bovenstaande model partition-key-per-tenant, en biedt ook meer isolatie van gegevenstoegang via Azure RBAC.

Wanneer u een container voor elke tenant gebruikt, kunt u overwegen om doorvoer met andere tenants te delen door doorvoer in te richten op databaseniveau. Houd rekening met de beperkingen en limieten rond het minimale aantal aanvraageenheden voor uw database en het maximum aantal containers in de database. Overweeg ook of uw tenants een gegarandeerd prestatieniveau vereisen en of ze vatbaar zijn voor het probleem noisy neighbor. Wanneer u doorvoer deelt op databaseniveau, moet de workload of opslag voor alle containers relatief uniform zijn. Anders hebt u mogelijk een probleem met ruis, als er een of meer grote tenants zijn. Plan indien nodig deze tenants te groeperen in verschillende databases die zijn gebaseerd op workloadpatronen.

U kunt ook toegewezen doorvoer inrichten voor elke container. Deze benadering werkt goed voor grotere tenants en voor tenants die risico lopen op het probleem met ruis. De basislijndoorvoer voor elke tenant is echter hoger, dus houd rekening met de minimale vereisten en kosteneffecten van dit model.

Als uw tenantgegevensmodel meer dan één entiteit vereist, zolang alle entiteiten dezelfde partitiesleutel kunnen delen, kunnen ze in dezelfde container worden geplaatst. Als het tenantgegevensmodel echter complexer is en entiteiten vereist die niet dezelfde partitiesleutel kunnen delen, kunt u de onderstaande modellen database-per-tenant of database-account-per-tenant overwegen. Bekijk ons artikel over het modelleren en partitioneren van gegevens in Azure Cosmos DB met behulp van een praktijkvoorbeeld voor meer richtlijnen.

Levenscyclusbeheer is over het algemeen eenvoudiger wanneer containers zijn toegewezen aan tenants. U kunt tenants eenvoudig verplaatsen tussen gedeelde en toegewezen doorvoermodellen en wanneer u de inrichting van een tenant ongedaan wilt maken, kunt u de container snel verwijderen.

Database per tenant

U kunt databases inrichten voor elke tenant, in hetzelfde databaseaccount. Net als het bovenstaande model container-per-tenant biedt dit model betere prestatie-isolatie dan het model partition-key-per-tenant en biedt het ook verbeterde isolatie van gegevenstoegang via Azure RBAC.

Net als het onderstaande account-per-tenantmodel biedt deze benadering het hoogste prestatie-isolatieniveau, maar biedt het de laagste tenantdichtheid. Deze optie is echter het beste wanneer elke tenant een ingewikkelder gegevensmodel vereist dan haalbaar is in het container-per-tenantmodel. Of u moet deze aanpak volgen wanneer het een vereiste is voor het snel maken van een nieuwe tenant en/of zonder overhead om tenantaccounts vooraf te maken. Het kan ook zo zijn dat het specifieke framework voor softwareontwikkeling dat wordt gebruikt, dat database-per-tenant het enige prestatie-isolatieniveau is dat in dat framework wordt herkend. Isolatie op entiteitsniveau (container) en colocatie van entiteiten worden doorgaans niet systeemeigen ondersteund in dergelijke frameworks.

Databaseaccount per tenant

Met Azure Cosmos DB kunt u afzonderlijke databaseaccounts inrichten voor elke tenant, wat het hoogste isolatieniveau biedt, maar de laagste dichtheid. Net als de bovenstaande container-per-tenant- en database-per-tenant-modellen biedt dit model een betere isolatie van prestaties dan het model voor partitiesleutels per tenant. Het biedt ook verbeterde isolatie van gegevenstoegangsbeveiliging via Azure RBAC. Daarnaast biedt dit model beveiligingsisolatie voor databaseversleuteling op tenantniveau via door de klant beheerde sleutels.

Eén databaseaccount is toegewezen aan een tenant, wat betekent dat ze niet onderhevig zijn aan het probleem met ruis. U kunt de locatie van het databaseaccount configureren volgens de vereisten van de tenant. U kunt ook de configuratie van Azure Cosmos DB-functies, zoals geo-replicatie en door de klant beheerde versleutelingssleutels, afstemmen op de vereisten van elke tenant. Wanneer u een toegewezen Azure Cosmos DB-account per tenant gebruikt, kunt u het maximum aantal Azure Cosmos DB-accounts per Azure-abonnement overwegen.

Als u dit model gebruikt, moet u overwegen hoe snel uw toepassing nieuwe tenants moet kunnen genereren. Het maken van accounts in Azure Cosmos DB kan enkele minuten duren, dus mogelijk moet u vooraf accounts maken. Als deze methode niet haalbaar is, kunt u het database-per-tenantmodel overwegen.

Als u tenants toestaat om te migreren van een gedeeld account naar een toegewezen Azure Cosmos DB-account, kunt u de migratiebenadering overwegen die u gebruikt om de gegevens van een tenant tussen de oude en nieuwe accounts te verplaatsen.

Hybride benaderingen

U kunt een combinatie van de bovenstaande benaderingen overwegen om aan de vereisten van verschillende tenants en uw prijsmodel te voldoen. Voorbeeld:

  • Richt alle klanten van de gratis proefversie in een gedeelde container in en gebruik de tenant-id of een synthetische sleutelpartitiesleutel.
  • Bied een betaalde Bronze-laag aan waarmee een toegewezen container per tenant wordt geïmplementeerd, maar met gedeelde doorvoer op een database.
  • Bied een hogere Silver-laag aan waarmee toegewezen doorvoer wordt ingericht voor de container van de tenant.
  • Bied de hoogste Gold-laag aan en geef een toegewezen databaseaccount voor de tenant op, zodat tenants ook de geografie voor hun implementatie kunnen selecteren.

Bijdragers

Dit artikel wordt onderhouden door Microsoft. De tekst is oorspronkelijk geschreven door de volgende Inzenders.

Belangrijkste auteurs:

  • Paul Burpo | Principal Customer Engineer, FastTrack voor Azure
  • John Downs | Principal Customer Engineer, FastTrack voor Azure

Andere Inzenders:

Als u niet-openbare LinkedIn-profielen wilt zien, meldt u zich aan bij LinkedIn.

Volgende stappen

Bekijk de opslag- en gegevensbenaderingen voor multitenancy.

Meer informatie over multitenancy en Azure Cosmos DB:

  • Azure Cosmos DB- en multitenant-systemen: een blogbericht waarin wordt besproken hoe u een multitenant-systeem bouwt dat gebruikmaakt van Azure Cosmos DB.
  • Multitenant-toepassingen met Azure Cosmos DB (video)
  • Een multitenant SaaS bouwen met Azure Cosmos DB en Azure (video): Een praktijkstudie over hoe Whally, een multitenant SaaS-opstartproces, een modern platform helemaal opnieuw heeft gebouwd op Azure Cosmos DB en Azure. Whally toont de ontwerp- en implementatiebeslissingen die ze hebben genomen met betrekking tot partitionering, gegevensmodellering, veilige multitenancy, prestaties, realtime streaming van wijzigingenfeed naar SignalR en meer. Al deze oplossingen maken gebruik van ASP.NET Core op Azure-app Services.

Raadpleeg enkele van onze andere architectuurscenario's voor Cosmos DB: