Tenancymodellen die moeten worden gebruikt voor een multitenant-oplossing

Er zijn veel verschillende manieren waarop u een oplossing kunt ontwerpen voor multitenanting. Deze beslissing gaat voornamelijk over of en hoe u resources deelt tussen uw tenants. Intuïtief wilt u misschien voorkomen dat u resources deelt, maar dit wordt al snel duur naarmate uw bedrijf wordt geschaald en naarmate u meer en meer tenants onboardt.

Het is handig om na te denken over de verschillende modellen van multitenancy, door eerst te begrijpen hoe u tenants definieert voor uw specifieke organisatie, welke zakelijke drijfveren u hebt en hoe u van plan bent om uw oplossing te schalen.

Een tenant definiëren

Eerst moet u een tenant voor uw organisatie definiëren. Bedenk wie uw klant is. Met andere woorden, aan wie levert u uw services? Er zijn twee algemene modellen:

• Business-to-business (B2B). Als uw klanten andere organisaties zijn, bent u waarschijnlijk van mening dat uw tenants die klanten zijn. Bedenk echter of uw klanten afdelingen (teams of afdelingen) hebben of dat ze in meerdere landen aanwezig zijn. Mogelijk moet u overwegen om één klant toe te passen 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 de ontwikkel- en productieomgevingen van elkaar gescheiden blijven. Over het algemeen heeft één tenant meerdere gebruikers. Alle werknemers van uw klant zijn bijvoorbeeld gebruikers binnen dezelfde tenant.
• Business-to-consumer (B2C). Als uw klanten consumenten zijn, is het vaak gecompliceerder om klanten, tenants en gebruikers met elkaar in verband te brengen. In sommige scenario's kan elke consument een eigen tenant zijn. Bedenk echter of uw oplossing kan worden gebruikt door families, groepen vrienden, advocaten, verbanden of andere groeperingen die mogelijk hun gegevens samen moeten openen en beheren. Een muziekstreamingservice ondersteunt bijvoorbeeld zowel afzonderlijke gebruikers als families, en kan elk van deze accounttypen op een andere manier behandelen als het gaat om het scheiden ervan in tenants.

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

• Als uw tenants afzonderlijke personen of families zijn, moet u zich mogelijk met name zorgen maken over de manier waarop u persoonsgegevens verwerkt en de wetgeving op het gebied van gegevenssoevereiniteit binnen 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, de isolatie van hun gegevens en ervoor zorgen dat u voldoet aan een opgegeven serviceniveaudoelstelling (SLO), zoals uptime of servicebeschikbaarheid.

Hoe bepaalt u welk model u wilt gebruiken?

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

• Wat zijn uw zakelijke doelstellingen?
• Accepteren uw klanten alle vormen van multitenancy? Wat is de invloed van elk multitenancymodel op uw nalevingsvereisten of op de nalevingsvereisten van uw klant?
• Wordt een oplossing met één tenant geschaald naar uw toekomstige groeiambities?
• Hoe groot is uw operationele team en hoeveel van uw infrastructuurbeheer kunt u automatiseren?
• Verwachten uw klanten dat u voldoet aan service level agreements (SLA's) of hebt u SLO's die u wilt?

Als u verwacht dat uw bedrijf wordt geschaald naar een groot aantal klanten, is het zeer belangrijk om een gedeelde infrastructuur te implementeren. Anders moet u een groot en steeds groter wordend aantal exemplaren onderhouden. Het implementeren van afzonderlijke Azure-resources voor elke klant is waarschijnlijk onbereikbaar, tenzij u per tenant een toegewezen abonnement inrichten en gebruiken. Wanneer u hetzelfde Azure-abonnement deelt voor meerdere tenants, kunnen azure-resourcequota en -limieten worden toegepast en worden de operationele kosten voor het implementeren en opnieuw configureren van deze resources bij elke nieuwe klant hoger.

Als u daarentegen verwacht dat uw bedrijf slechts enkele klanten zal hebben, is het wellicht de moeite waard om resources met één tenant te hebben die zijn toegewezen aan elke klant. En als de isolatievereisten van uw klanten hoog zijn, is een infrastructuur met één tenant mogelijk geschikt.

Logische en fysieke tenants

Vervolgens moet u bepalen wat een tenant betekent voor uw specifieke oplossing en of u onderscheid moet maken tussen logische en fysieke tenants.

Neem bijvoorbeeld een muziekstreamingservice. In eerste instantie kunt u een oplossing bouwen die eenvoudig kan omgaan met duizenden (of zelfs tienduizenden) gebruikers. Als u echter blijft groeien, kan het voorkomen dat u uw oplossing of een aantal onderdelen ervan moet dupliceren om te kunnen schalen naar de vraag van uw nieuwe klant. Dit betekent dat u moet bedenken hoe u specifieke klanten kunt toewijzen aan specifieke exemplaren van uw oplossing. U kunt dit willekeurig of geografisch doen, of door één instantie in te vullen en vervolgens over te lekkage naar een andere instantie. U moet echter waarschijnlijk een record bij houden van de klanten die u hebt en op welke infrastructuur hun gegevens en toepassingen beschikbaar zijn, zodat u hun verkeer naar de juiste infrastructuur kunt doorsleoveren. In dit voorbeeld kunt u elke gebruiker weergeven als een afzonderlijke logische tenant en de gebruikers vervolgens toe te kennen aan fysieke tenants die staan voor de verschillende exemplaren die u hebt geïmplementeerd. U hebt een een-op-veel-toewijzing tussen logische en fysieke tenants en u kunt logische tenants naar eigen goed inzicht verplaatsen tussen fysieke tenants.

Neem daarentegen een bedrijf dat cloudsoftware bouwt voor juridische ondernemingen. Uw klanten staan mogelijk voor hun eigen toegewezen infrastructuur om hun nalevingsstandaarden te handhaven. Daarom moet u vanaf het begin voorbereid zijn op het implementeren en beheren van veel verschillende exemplaren van uw oplossing. In dit voorbeeld is een logische en fysieke tenant hetzelfde.

Een belangrijk verschil tussen logische en fysieke tenants is hoe isolatie wordt afgedwongen. Wanneer meerdere logische tenants één set infrastructuur delen, vertrouwt u doorgaans op uw toepassingscode en een tenant-id in een database, om de gegevens van elke tenant gescheiden te houden. Wanneer u fysieke tenants hebt, hebben ze hun eigen infrastructuur. Het is dus mogelijk minder belangrijk dat uw code zich ervan bewust is dat deze in een omgeving met meerdere tenants werkt.

Soms worden fysieke tenants aangeduid als implementaties, supertenants of stempels. In de rest van dit document gebruiken we de termen implementaties en fysieke implementaties om verwarring tussen logische en fysieke tenants te voorkomen.

Wanneer u een aanvraag voor een specifieke logische tenant ontvangt, moet u deze aan de fysieke implementatie die de gegevens van die tenant bevat, zoals hieronder wordt geïllustreerd:

Isolatie van tenants

Een van de grootste overwegingen bij het ontwerpen van een multitenant-architectuur is het isolatieniveau dat elke tenant nodig heeft. Isolatie kan verschillende dingen betekenen:

• Een enkele set gedeelde infrastructuur, met afzonderlijke exemplaren van uw toepassing en afzonderlijke databases voor elke tenant.
• Delen van een aantal algemene resources, terwijl andere resources voor elke tenant gescheiden blijven.
• Het bewaren van gegevens in een afzonderlijke fysieke infrastructuur. In de cloud zijn hiervoor mogelijk afzonderlijke Azure-resources voor elke tenant vereist, of kan het zelfs betekenen dat er letterlijk een afzonderlijke fysieke infrastructuur wordt geïmplementeerd met behulp van toegewezen hosts.

In plaats van isolatie te zien als een discrete eigenschap, moet u isolatie zien als een continuum. Afhankelijk van uw vereisten kunt u onderdelen van uw architectuur implementeren die meer of minder geïsoleerd zijn dan andere onderdelen in dezelfde architectuur. In het volgende diagram wordt een continuum van isolatie gedemonstreerd:

Het isolatieniveau is van invloed op veel aspecten van uw architectuur, waaronder de volgende:

• Veiligheid. Als u infrastructuur deelt tussen meerdere tenants, moet u er vooral voor zorgen dat u geen toegang krijgt 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 de tenant- als de gebruikersidentiteit binnen uw autorisatieproces.
• Kosten. Gedeelde infrastructuur kan worden gebruikt door meerdere tenants, zodat deze goedkoper is.
• Prestaties. Als u een infrastructuur deelt, kunnen de prestaties van uw systeem minder worden naarmate meer klanten deze gebruiken, omdat de resources mogelijk sneller worden verbruikt.
• Betrouwbaarheid. Als u één set gedeelde infrastructuur gebruikt, kan een probleem met de onderdelen van één tenant leiden tot een storing voor iedereen.
• Reactiesnelheid op de behoeften van afzonderlijke tenants. Wanneer u een infrastructuur implementeert die is toegewezen aan één tenant, kunt u mogelijk de configuratie voor de resources afstemmen op de vereisten van die specifieke tenant. U kunt dit zelfs overwegen in uw prijsmodel, waarbij u klanten in staat stelt meer te betalen voor geïsoleerde implementaties.

Uw oplossingsarchitectuur kan van invloed zijn op de opties die u voor isolatie beschikbaar hebt. Laten we bijvoorbeeld eens kijken naar een voorbeeld van een oplossingsarchitectuur met drie lagen:

• Uw gebruikersinterfacelaag kan een gedeelde web-app met meerdere tenants zijn en al uw tenants hebben toegang tot één hostnaam.
• Uw middelste laag kan een gedeelde toepassingslaag zijn, met gedeelde berichtenwachtrijen.
• Uw gegevenslaag kan geïsoleerde databases, tabellen of blobcontainers zijn.

U kunt overwegen om verschillende isolatieniveaus op elke laag te combineren en te koppelen. Uw beslissing over wat wordt gedeeld en wat geïsoleerd is, is gebaseerd op veel overwegingen, waaronder kosten, complexiteit, de vereisten van uw klanten en het aantal resources dat u kunt implementeren voordat u de Azure-quota en -limieten bereikt.

Algemene tenancymodellen

Wanneer u uw vereisten hebt vastgesteld, evalueert u deze op enkele algemene tenancymodellen en -patronen.

Geautomatiseerde implementaties met één tenant

In een geautomatiseerd implementatiemodel met één tenant implementeert u een toegewezen set infrastructuur voor elke tenant, zoals wordt geïllustreerd in dit voorbeeld:

Uw toepassing is verantwoordelijk voor het initiëren en coördineren van de implementatie van de resources van elke tenant. Normaal gesproken maken oplossingen die zijn gebouwd met behulp van dit model intensief gebruik van IaC (infrastructure as code) of de Azure Resource Manager API's. U kunt deze methode gebruiken wanneer u volledig afzonderlijke infrastructuren voor elk van uw klanten moet inrichten. Houd rekening met het patroon Implementatiestempels bij het plannen van uw implementatie.

Voordelen: Een belangrijk voordeel van deze benadering is dat gegevens voor elke tenant worden geïsoleerd, waardoor het risico op onbedoeld lekken wordt verkleind. Dit kan belangrijk zijn voor sommige klanten met hoge overhead voor naleving van regelgeving. Bovendien zullen tenants waarschijnlijk geen invloed hebben op de systeemprestaties van elkaar, ook wel het ruisprobleem genoemd. Updates en wijzigingen kunnen progressief worden uitgerold in tenants, waardoor de kans op een systeembrede storing wordt verkleind.

Risico's: Uw kostenefficiëntie is laag, omdat u de infrastructuur niet deelt tussen uw tenants. Als voor één tenant een bepaald bedrag aan infrastructuur moet worden besteed, is het waarschijnlijk dat 100 tenants 100 keer zoveel kosten in uitgaven nodig hebben. Daarnaast is doorlopend onderhoud (zoals het toepassen van nieuwe configuratie- of software-updates) waarschijnlijk tijdrovend. Overweeg uw operationele processen te automatiseren en overweeg wijzigingen progressief toe te passen via uw omgevingen. U moet ook rekening houden met andere bewerkingen voor meerdere implementaties, zoals rapportage en analyse in uw hele estate. Zorg er ook voor dat u van plan bent hoe u gegevens kunt opvragen en bewerken in meerdere implementaties.

Volledig multitenant-implementaties

Aan de andere kant kunt u een volledig multitenant-implementatie overwegen, waarbij alle onderdelen worden gedeeld. U hebt slechts één set infrastructuur die moet worden geïmplementeerd en onderhouden en alle tenants gebruiken deze, zoals wordt geïllustreerd in het volgende diagram:

Voordelen: Dit model is aantrekkelijk vanwege de lagere kosten voor het gebruik van een oplossing met gedeelde onderdelen. Zelfs als u hogere lagen of SKU's van resources moet implementeren, is het nog vaak het geval dat de totale implementatiekosten lager zijn dan een set resources met één tenant. Als een gebruiker of tenant zijn gegevens naar een andere logische tenant moet verplaatsen, hoeft u bovendien geen gegevens te migreren tussen twee afzonderlijke implementaties.

Risico 's:

• Zorg ervoor dat u gegevens scheidt voor elke tenant en dat er geen gegevens tussen tenants worden gelekt. Mogelijk moet u de sharding van uw gegevens zelf beheren. Daarnaast moet u zich mogelijk zorgen maken over de effecten die afzonderlijke tenants op het algehele systeem kunnen hebben. Als bijvoorbeeld één grote tenant een zware query of bewerking probeert uit te voeren, heeft dit dan invloed op andere tenants?

• Bepaal hoe u uw Azure-kosten bij houdt en koppelt aan tenants,als dit belangrijk voor u is. Onderhoud kan eenvoudiger zijn met één implementatie, 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.

• Schaal kan ook een factor zijn om rekening mee te houden. De kans is groter 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, naarmate de schaal toeneemt, de limiet bereiken van wat het opslagaccount kan verwerken. Om te voorkomen dat u een resourcequotumlimiet bereikt, kunt u overwegen om meerdere exemplaren van uw resources te implementeren (bijvoorbeeld meerdere AKS-clusters of opslagaccounts), of u kunt zelfs overwegen om uw tenants te distribueren over resources die u hebt geïmplementeerd in meerdere Azure-abonnementen.

• Er is waarschijnlijk een limiet voor hoe ver u één implementatie kunt schalen en de kosten van dit proces kunnen niet-lineair toenemen. Als u bijvoorbeeld één gedeelde database hebt en u op zeer grote schaal wordt uitgevoerd, is de doorvoer mogelijk uitgeput en moet u steeds meer betalen voor een hogere doorvoer om aan uw vraag te kunnen blijven voldoen.

Verticaal gepartitiede implementaties

U hoeft zich niet aan de uitersten van deze schalen te zitten. In plaats daarvan kunt u overwegen om uw tenants verticaal te partitioneren met de volgende stappen:

• Gebruik een combinatie van implementaties met één tenant en meerdere tenants. U hebt bijvoorbeeld de meeste gegevens- en toepassingslagen van uw klanten in multitenant-infrastructuren, maar u kunt infrastructuren met één tenant implementeren voor klanten die betere prestaties of gegevensisolatie nodig hebben.
• Implementeer geografisch meerdere exemplaren van uw oplossing en maak elke tenant vast aan een specifieke implementatie. Dit is met name effectief wanneer u tenants in verschillende geografische gebieden hebt.

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

Voordelen: Omdat u nog steeds infrastructuur deelt, kunt u nog steeds profiteren van enkele van de kostenvoordelen van gedeelde multitenant-implementaties. U kunt goedkopere, gedeelde resources implementeren voor bepaalde klanten, zoals degenen die uw service proberen met een proefversie. U kunt zelfs klanten een hoger tarief in rekening brengen voor een implementatie met één tenant, waardoor een deel van uw kosten worden losgekoppeld.

Risico's: Uw codebasis moet waarschijnlijk worden ontworpen om implementaties met zowel meerdere tenants als implementaties met één tenant te ondersteunen. Als u migratie tussen infrastructuren wilt toestaan, moet u overwegen hoe u klanten migreert van een multitenant-implementatie naar hun eigen implementatie met één tenant. U moet ook een duidelijk inzicht hebben in welke van uw logische tenants zich in welke sets van fysieke infrastructuur, zodat u informatie over systeemproblemen of upgrades aan de relevante klanten kunt communiceren.

Horizontaal gepartitiese implementaties

U kunt ook overwegen om uw implementaties horizontaal te partitioneren. Dit betekent dat u een aantal gedeelde onderdelen hebt, terwijl u andere onderdelen onderhoudt met implementaties met één tenant. U kunt bijvoorbeeld één toepassingslaag bouwen en vervolgens afzonderlijke databases voor elke tenant implementeren, zoals wordt weergegeven in deze afbeelding:

Voordelen: Horizontaal gepartities kunnen u helpen een probleem met ruis te verhelpen, als u hebt vastgesteld dat de meeste belasting van uw systeem wordt veroorzaakt door specifieke onderdelen die u afzonderlijk voor elke tenant kunt implementeren. Uw databases kunnen bijvoorbeeld het grootste deel van de belasting van uw systeem opnemen, omdat de querybelasting hoog is. Als één tenant een groot aantal aanvragen naar uw oplossing verzendt, kunnen de prestaties van een database negatief worden beïnvloed, maar blijven de databases van andere tenants (en gedeelde onderdelen, zoals de toepassingslaag) ongewijzigd.

Risico's: Bij een horizontaal gepartitiese 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.

Volgende stappen

Houd rekening met de levenscyclus van uw tenants.