Tenancymodellen voor een multitenant-oplossing

Er zijn veel manieren om te overwegen hoe u met tenants in uw oplossing kunt werken. Uw benadering is afhankelijk van of en hoe u resources deelt tussen uw tenants. Intuïtief wil je misschien vermijden dat je resources deelt, maar deze aanpak wordt snel duurder naarmate je bedrijf groeit en je meer gebruikers onboardt.

Wanneer u rekening houdt met de verschillende modellen van multitenancy, is het handig om eerst na te denken over hoe u tenants voor uw organisatie definieert, wat uw bedrijfsfactoren zijn en hoe u van plan bent om uw oplossing te schalen. Dit artikel bevat richtlijnen om technische besluitvormers te helpen bij het evalueren van tenancymodellen en hun afwegingen.

Een tenant definiëren

U moet eerst een tenant voor uw organisatie definiëren. Bedenk wie uw klant is of wie uw diensten ontvangt. Er zijn twee algemene modellen:

• Business to business (B2B): Als uw klanten andere organisaties zijn, wijst u uw tenants waarschijnlijk toe aan die klanten. Overweeg echter of uw klanten afdelingen hebben, zoals teams of afdelingen, en of ze een aanwezigheid hebben in meerdere landen of regio's. Mogelijk moet u één klant toewijzen aan meerdere tenants als er verschillende vereisten zijn voor deze subgroepen. Op dezelfde manier wil een klant mogelijk twee exemplaren van uw service onderhouden, zodat ze hun ontwikkel- en productieomgevingen van elkaar kunnen scheiden. Een enkele tenant heeft doorgaans meerdere gebruikers. Alle werknemers van de klant zijn bijvoorbeeld gebruikers binnen één tenant.

• Business to consumer (B2C): Als uw klanten consumenten zijn, is het vaak ingewikkelder om klanten, tenants en gebruikers te relateren. In sommige scenario's kan elke consument een afzonderlijke tenant zijn. Overweeg echter of uw oplossing kan worden gebruikt door gezinnen, groepen vrienden, clubs, verenigingen of andere groepen die mogelijk toegang nodig hebben tot hun gegevens en deze samen moeten beheren. Een muziekstreamingservice ondersteunt bijvoorbeeld zowel individuele gebruikers als families en kan elk van deze accounttypen anders behandelen wanneer deze worden gescheiden in tenants.

Uw definitie van de tenant is van invloed op een aantal dingen die u moet overwegen of benadrukken wanneer u uw oplossing ontwerpt. Denk bijvoorbeeld aan de volgende typen tenants:

• Als uw tenants individuele personen of gezinnen zijn, moet u mogelijk overwegen hoe u persoonsgegevens verwerkt en over de wetten voor gegevenssoevereine in elke jurisdictie die u dient.

• Als uw tenants bedrijven zijn, moet u mogelijk rekening houden met de vereisten van uw klanten voor naleving van regelgeving en de isolatie van hun gegevens. Zorg ervoor dat u voldoet aan een opgegeven serviceniveaudoelstelling (SLO), zoals uptime of servicebeschikbaarheid.

Bepalen welk model u wilt gebruiken

Het selecteren van een tenancymodel is niet alleen een technische beslissing. Het is ook een commerciële beslissing. U moet rekening houden met de volgende vragen:

• Bedrijfsdoelstellingen: Overweeg of het verlagen van de kosten voor elke tenant of het maximaliseren van de tenantervaring beter aansluit bij strategische doelen.

• Naleving: Overweeg of uw klanten alle vormen van multitenancy accepteren. Hoe heeft elk multitenancymodel invloed op uw nalevingsvereisten of de nalevingsvereisten van uw klanten?

• Schaal: Overweeg of een oplossing met één tenant kan worden geschaald naar uw toekomstige groeiambities.

• Automatisering: Houd rekening met de grootte van uw operationele team en hoeveel van uw infrastructuurbeheer u kunt automatiseren.

• Service level agreements (SLA's): Overweeg of uw klanten verwachten dat u aan SLA's voldoet of dat u SLO's hebt die u nastreeft.

Als u verwacht dat uw bedrijf wordt geschaald naar een groot aantal klanten, is het belangrijk om een gedeelde infrastructuur te implementeren. Als alternatief moet u een grote en groeiende vloot aan resource-instanties onderhouden. Het implementeren van afzonderlijke Azure-resources voor elke klant is waarschijnlijk onhoudbaar, tenzij u een toegewezen abonnement voor elke tenant inricht en gebruikt. Wanneer u hetzelfde Azure-abonnement deelt voor meerdere tenants, kunnen azure-resourcequota en -limieten van toepassing zijn en kunnen de operationele kosten voor het implementeren en opnieuw configureren van deze resources toenemen met elke nieuwe klant.

Als u echter verwacht dat uw bedrijf slechts een paar klanten heeft, kunt u overwegen om resources met één tenant te gebruiken die zijn toegewezen aan elke klant. Als de isolatievereisten van uw klanten hoog zijn, is een infrastructuurbenadering met één tenant mogelijk ook geschikt, ook al is dit duurder.

Tenants en implementaties

Vervolgens moet u bepalen of u onderscheid moet maken tussen logische tenants en implementaties.

Denk bijvoorbeeld aan een streamingservice voor muziek. In eerste instantie kunt u een oplossing bouwen die eenvoudig duizenden of zelfs tienduizenden gebruikers kan verwerken. Naarmate uw organisatie echter blijft groeien, kunt u merken dat u uw oplossing of een aantal onderdelen ervan moet dupliceren om te schalen naar de nieuwe vraag van de klant. Als u deze taak wilt uitvoeren, moet u bepalen hoe u specifieke klanten toewijst aan specifieke exemplaren van uw oplossing. U kunt klanten willekeurig, geografisch of door een instantie volledig te vullen en vervolgens een andere instantie starten, ook wel bin packing genoemd. U moet echter waarschijnlijk een record bijhouden van uw klanten en de infrastructuur waar hun gegevens en toepassingen zich bevinden, zodat u hun verkeer naar de juiste locatie kunt routeren. In dit voorbeeld kunt u elke klant vertegenwoordigen als een afzonderlijke tenant en gebruikers toewijzen aan de implementatie die hun gegevens bevat. Deze benadering maakt een een-op-veel-relatie tussen tenants en implementaties, en u kunt tenants naar eigen goeddunken tussen implementaties verplaatsen.

Denk daarentegen aan een bedrijf dat cloudsoftware voor juridische bedrijven maakt. Uw klanten willen mogelijk hun eigen toegewezen infrastructuur hebben om te voldoen aan wettelijke vereisten. Daarom moet u vanaf het begin voorbereid zijn op het implementeren en beheren van veel verschillende exemplaren van uw oplossing. In dit voorbeeld bevat een implementatie altijd één tenant en wordt een tenant toegewezen aan een eigen toegewezen implementatie.

Een belangrijk verschil tussen tenants en implementaties is hoe isolatie wordt afgedwongen. Wanneer meerdere tenants één implementatie (een set infrastructuur) delen, vertrouwt u doorgaans op uw toepassingscode en een tenant-id die zich in een database bevindt om de gegevens van elke tenant gescheiden te houden. Wanneer tenants hun eigen toegewezen implementaties hebben, hebben ze hun eigen infrastructuur, dus het kan minder belangrijk zijn voor uw code om rekening te houden met een multitenant-omgeving.

Implementaties worden soms supertenants of stempels genoemd.

Wanneer u een aanvraag voor een specifieke tenant ontvangt, moet u deze toewijzen aan de implementatie die de gegevens van die tenant bevat, zoals wordt weergegeven in het volgende diagram:

Het diagram is onderverdeeld in drie hoofdsecties, tenants, uw oplossing en tenant-id en implementatie-id. Pijlen wijzen van tenants A, B, C en D naar een vak met het label tenant mapping in de oplossingssectie. Deze sectie bevat ook een webserver en database voor implementatie 1 en implementatie 2. Een andere pijl wijst vanuit het toewijzingsvak van de tenant naar de sectie met de tenant- en implementatie-id's. Tenants A en B hebben een implementatie-id van 1, en tenants C en D hebben implementatie-id's van 2.

Zie Toewijzingsaanvragen aan tenants voor meer informatie.

Isolatie van tenants

Een van de grootste overwegingen in het ontwerp van multitenant-architectuur is het isolatieniveau dat elke tenant nodig heeft. Isolatie kan verwijzen naar de volgende configuraties:

• Eén gedeelde infrastructuur met afzonderlijke exemplaren van uw toepassing en afzonderlijke databases voor elke tenant.

• Delen van enkele algemene resources, maar andere resources gescheiden houden voor elke tenant.

• Gegevens bewaren in een afzonderlijke fysieke infrastructuur. In de cloud is voor deze configuratie mogelijk afzonderlijke Azure-resources vereist voor elke tenant. In extreme scenario's kan het zelfs vereisen dat u een afzonderlijke fysieke infrastructuur implementeert met behulp van toegewezen hosts.

In plaats van isolatie als een discrete eigenschap te bekijken, kunt u het beschouwen als een spectrum. U kunt onderdelen van uw architectuur implementeren die geïsoleerder of minder geïsoleerd zijn dan andere onderdelen in dezelfde architectuur, afhankelijk van uw vereisten. In het volgende diagram ziet u een continuum van isolatie:

In het diagram ziet u een pijl van volledig geïsoleerd (niets gedeeld) tot volledig gedeeld (alles gedeeld). Aan de volledig geïsoleerde zijde bevatten blauwe vakken afzonderlijke berekeningen, afzonderlijke databases, afzonderlijke netwerken en afzonderlijke domeinnamen. In het midden van de pijl bevatten groene vakken gedeelde rekenkracht, gedeelde netwerken en gedeelde domeinnamen. Een blauw vak bevat afzonderlijke databases. Aan de volledig gedeelde zijde bevatten groene vakken gedeelde rekenkracht, gedeelde database, gedeelde netwerken en gedeelde domeinnamen.

Het isolatieniveau is van invloed op veel aspecten van uw architectuur:

• Veiligheid: Als u de infrastructuur tussen meerdere tenants deelt, moet u ervoor zorgen dat u geen toegang hebt tot gegevens van de ene tenant wanneer u antwoorden naar een andere tenant retourneert. U hebt een sterke basis nodig voor uw identiteitsstrategie en u moet rekening houden met zowel tenant- als gebruikersidentiteit in uw autorisatieproces.

• Kosten: Meerdere tenants kunnen gebruikmaken van gedeelde infrastructuur, dus het is goedkoper.

• Voorstelling: Als u de infrastructuur deelt, kunnen de prestaties van uw systeem afnemen naarmate meer klanten deze gebruiken, omdat de resources mogelijk sneller worden verbruikt. Tenants met ongebruikelijke gebruikspatronen kunnen prestatieproblemen verergeren.

• Betrouwbaarheid: Als u één set gedeelde infrastructuur gebruikt, kan een probleem met één onderdeel leiden tot een storing voor al uw tenants.

• Reactietijd voor afzonderlijke tenantbehoeften: Wanneer u infrastructuur implementeert die is toegewezen aan één tenant, kunt u de configuratie voor de resources mogelijk aanpassen aan de vereisten van die specifieke tenant. U kunt deze mogelijkheid zelfs overwegen in uw prijsmodel, zodat klanten meer kunnen betalen voor geïsoleerde implementaties.

Uw oplossingsarchitectuur kan invloed hebben op uw beschikbare opties voor isolatie. Denk bijvoorbeeld aan een oplossingsarchitectuur met drie lagen:

• Uw gebruikersinterfacelaag kan een gedeelde web-app met meerdere tenants zijn. Al uw tenants hebben toegang tot één hostnaam.

• De middelste laag kan een gedeelde toepassingslaag zijn met gedeelde berichtenwachtrijen.

• Uw gegevenslaag kan geïsoleerde databases, tabellen of blobcontainers zijn.

U kunt voor elke laag verschillende isolatieniveaus gebruiken. U moet uw beslissing baseren op wat u wilt delen en wat u wilt isoleren op verschillende factoren, waaronder kosten, complexiteit, de vereisten van uw klanten en het aantal resources dat u kunt implementeren voordat u Azure-quota en -limieten bereikt.

Algemene tenancymodellen

Nadat u uw vereisten hebt vastgesteld, evalueert u deze op basis van enkele algemene tenancymodellen en bijbehorende implementatiepatronen.

Geautomatiseerde implementaties met één tenant

In een geautomatiseerd implementatiemodel met één tenant implementeert u een toegewezen set infrastructuur voor elke tenant, zoals wordt weergegeven in het volgende voorbeeld:

Het diagram is onderverdeeld in drie secties, één voor tenant A, één voor tenant B en één voor tenant C. Een pijl wijst van tenant A naar een vak met het label Implementatie A. Dat vak bevat een webserver voor tenant A. Een andere pijl wijst van Tenant B naar een vak met het label Implementatie B. Dat vak bevat een webserver voor tenant B. Een andere pijl wijst van Tenant C naar een vak met het label Implementatie C. Dat vak bevat een webserver voor tenant C.

Uw toepassing is verantwoordelijk voor het initiëren en coördineren van de implementatie van de resources van elke tenant. Normaal gesproken gebruiken oplossingen die dit model gebruiken infrastructuur als code of de Azure Resource Manager-API's uitgebreid. U kunt deze benadering gebruiken wanneer u volledig afzonderlijke infrastructuren moet inrichten voor elk van uw klanten. Overweeg het patroon Implementatiestempels te gebruiken wanneer u uw implementatie plant.

Voordelen: Een belangrijk voordeel van deze benadering is dat gegevens voor elke tenant geïsoleerd zijn, waardoor het risico op onbedoelde lekkage wordt verminderd. Deze beveiliging kan belangrijk zijn voor klanten met een hoge overhead op het gebied van naleving van regelgeving. Tenants zijn ook waarschijnlijk niet van invloed op de systeemprestaties van elkaar, ook wel bekend als het probleem met lawaaierige buren . Updates en wijzigingen kunnen geleidelijk worden geïmplementeerd in tenants, wat de kans op een systeembrede storing vermindert.

Risico 's: Als u deze benadering gebruikt, is de kostenefficiëntie laag omdat u geen infrastructuur deelt tussen uw tenants. Als voor één tenant een specifieke infrastructuurkosten zijn vereist, vereisen 100 tenants waarschijnlijk 100 keer die kosten. Bovendien kan doorlopend onderhoud, zoals het toepassen van nieuwe configuratie- of software-updates, tijdrovend zijn. Overweeg het automatiseren van uw operationele processen en overweeg wijzigingen geleidelijk toe te passen via uw omgevingen. U moet ook andere implementatiebewerkingen overwegen, zoals rapportage en analyses in uw hele vloot. Plan hoe u gegevens kunt opvragen en bewerken in meerdere implementaties.

Volledig multitenant-implementaties

Bij het tegenovergestelde extreem kunt u een volledig multitenant-implementatie overwegen waarin alle onderdelen worden gedeeld. U hebt slechts één set infrastructuur om te implementeren en onderhouden, en alle tenants gebruiken deze, zoals wordt weergegeven in het volgende diagram:

In dit diagram wijzen pijlen van vakken met het label Tenant A, Tenant B en Tenant C naar een vak dat is gelabeld als gedeelde resources. Dit vak bevat een webserver voor tenants A, B en C.

Voordelen: Dit model is aantrekkelijk omdat het gebruik van een oplossing met gedeelde onderdelen goedkoper is dan het gebruik van afzonderlijke resources voor elke tenant. Zelfs als u hogere lagen of SKU's van resources moet implementeren om rekening te houden met de verhoogde belasting, zijn de totale implementatiekosten vaak nog steeds lager dan de kosten van een set resources met één tenant. Als een gebruiker of tenant de gegevens naar een andere tenant moet verplaatsen, kunt u mogelijk tenant-id's en sleutels bijwerken en hoeft u mogelijk geen gegevens te migreren tussen twee afzonderlijke implementaties.

risico's:

• Zorg ervoor dat u gegevens voor elke tenant scheidt en geen gegevens over tenants lekken. Mogelijk moet u shardinggegevens beheren. Mogelijk moet u ook rekening houden met de effecten die afzonderlijke tenants op het algehele systeem kunnen hebben. Als een grote tenant bijvoorbeeld probeert een zware query of bewerking uit te voeren, kan dit van invloed zijn op andere tenants.

• Bepaal hoe u uw Azure-kosten kunt bijhouden en koppelen aan tenants, als deze informatie belangrijk voor u is.

• U kunt het onderhoud vereenvoudigen door één implementatie te gebruiken, omdat u slechts één set resources hoeft bij te werken. Het is echter ook vaak riskanter omdat wijzigingen van invloed kunnen zijn op uw hele klantenbestand.

• Mogelijk moet u ook schalen overwegen. Het is waarschijnlijker dat u de schaallimieten voor Azure-resources bereikt wanneer u een gedeelde set infrastructuur hebt. Als u bijvoorbeeld een opslagaccount gebruikt als onderdeel van uw oplossing, kan het aantal aanvragen voor dat opslagaccount de limiet bereiken van wat het opslagaccount kan verwerken. Om te voorkomen dat u een quotumlimiet voor resources bereikt, kunt u een groep met meerdere exemplaren van uw resources implementeren, zoals meerdere AKS-clusters of opslagaccounts. U kunt zelfs overwegen om uw tenants te distribueren over resources die u in meerdere Azure-abonnementen implementeert.

• Er is waarschijnlijk een limiet voor hoe ver u één implementatie kunt schalen en de kosten voor schalen kunnen niet-lineair toenemen. Als u bijvoorbeeld één gedeelde database hebt die u op grote schaal uitvoert, kunt u de doorvoer uitputten en moet u steeds meer betalen voor een hogere doorvoer om uw vraag bij te houden.

Verticaal gepartitioneerde implementaties

U hoeft geen van de extremen van deze schalen te kiezen. In plaats daarvan kunt u uw tenants verticaal partitioneren door de volgende methode uit te voeren:

• Gebruik een combinatie van implementaties met één tenant en meerdere tenants. U hebt bijvoorbeeld de meeste gegevens- en toepassingslagen van uw klanten op multitenant-infrastructuren, maar u implementeert infrastructuren met één tenant voor klanten die hogere prestaties of gegevensisolatie nodig hebben.

• Implementeer meerdere exemplaren van uw oplossing geografisch en wijs elke tenant toe aan een specifieke implementatie. Deze aanpak is effectief wanneer u tenants in verschillende geografische gebieden hebt.

Hier volgt een voorbeeld van een gedeelde implementatie voor sommige tenants en een implementatie met één tenant voor een andere:

In dit diagram wijzen pijlen van Tenant A en Tenant B naar een vak met het label Deployment 1. Dat vak bevat een webserver voor tenants A en B. Een andere pijl wijst van Tenant C naar een vak met het label Deployment 2. Die kast bevat een webserver voor Tenant C.

Voordelen: Omdat u nog steeds een deel van uw infrastructuur deelt, kunt u enkele van de kostenvoordelen krijgen van het gebruik van gedeelde implementaties met meerdere tenants. U kunt goedkopere gedeelde resources implementeren voor specifieke klanten, zoals klanten die uw service evalueren met behulp van een proefversie. U kunt klanten zelfs een hoger tarief in rekening brengen om een implementatie met één tenant te gebruiken, zodat u enkele van uw kosten kunt herstellen.

Risico 's: Uw codebasis moet zijn ontworpen om implementaties met meerdere tenants en implementaties met één tenant te ondersteunen. Als u van plan bent om migratie tussen implementaties toe te staan, moet u overwegen hoe u klanten migreert van een implementatie met meerdere tenants naar hun eigen implementatie met één tenant. U moet ook weten welke van uw tenants zich in elke implementatie bevinden, zodat u informatie over systeemproblemen of upgrades kunt doorgeven aan de relevante klanten.

Horizontaal gepartitioneerde implementaties

U kunt uw implementaties ook horizontaal partitioneren. In een horizontale implementatie hebt u een aantal gedeelde onderdelen, maar andere onderdelen onderhouden met implementaties met één tenant. U kunt bijvoorbeeld één toepassingslaag bouwen en vervolgens afzonderlijke databases implementeren voor elke tenant, zoals wordt weergegeven in dit diagram:

In dit diagram wijzen pijlen van vakken met het label Tenant A, Tenant B en Tenant C naar een vak dat een webserver bevat die tenants A, B en C delen.

Voordelen: Horizontaal gepartitioneerde implementaties kunnen u helpen bij het beperken van een probleem met ruis. Als u aangeeft dat specifieke onderdelen de meeste belasting van uw systeem veroorzaken, kunt u afzonderlijke onderdelen voor elke tenant implementeren. Uw databases kunnen bijvoorbeeld de meeste belasting van uw systeem absorberen omdat de querybelasting hoog is. Als één tenant een groot aantal aanvragen naar uw oplossing verzendt, blijven de prestaties van een database mogelijk negatief beïnvloed, maar blijven de databases en gedeelde onderdelen van andere tenants, zoals de toepassingslaag, ongewijzigd.

Risico 's: Met een horizontaal gepartitioneerde implementatie moet u nog steeds rekening houden met de geautomatiseerde implementatie en het beheer van uw onderdelen, met name de onderdelen die door één tenant worden gebruikt.

Uw isolatiemodel testen

Ongeacht het isolatiemodel dat u kiest, moet u uw oplossing testen om te controleren of de gegevens van de ene tenant niet per ongeluk naar een andere worden gelekt en dat de resultaten van lawaaierige buren acceptabel zijn. Overweeg om Azure Chaos Studio te gebruiken om opzettelijk fouten te introduceren die echte storingen simuleren en de tolerantie van uw oplossing controleren, zelfs wanneer onderdelen defect zijn.

Bijdragers

Microsoft onderhoudt dit artikel. De volgende inzenders hebben dit artikel geschreven.

Hoofdauteur:

• John Downs | Principal Software Engineer, Azure Patterns & Practices

Andere Inzenders:

• Chad Kittel | Principal Software Engineer, Azure Patterns & Practices
• Paulo Salvatori | Principal Customer Engineer, FastTrack voor Azure
• Arsen Vladimirskiy | Hoofdklantingenieur, FastTrack voor Azure

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

Volgende stap

Houd rekening met de levenscyclus van uw tenants.