Er zijn veel manieren om te overwegen hoe u met tenants in uw oplossing kunt werken. Uw keuze voor benadering is belangrijk afhankelijk van of en hoe u resources deelt tussen uw tenants. Intuïtief wilt u misschien voorkomen dat u resources deelt, maar deze benadering wordt snel duur wanneer uw bedrijf wordt geschaald en u meer tenants onboardt.
Wanneer u rekening houdt met de verschillende modellen van multitenancy, is het handig om eerst rekening te houden met de wijze waarop u tenants definieert voor uw organisatie, wat uw bedrijfsfactoren zijn en hoe u van plan bent om uw oplossing te schalen. Dit artikel bevat richtlijnen om technische besluitvormers te helpen de tenancymodellen en hun compromissen te evalueren.
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 diensten? 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 (teams of afdelingen) hebben en of ze aanwezig zijn in meerdere landen/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. Over het algemeen heeft één tenant 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 deze typen tenants:
- Als uw tenants individuele personen of gezinnen zijn, moet u zich mogelijk zorgen maken over de manier waarop u persoonsgegevens verwerkt en over de wetgeving inzake gegevenssoevereine 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 beschikbaarheid van services.
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. U moet vragen als volgt overwegen:
- Wat zijn uw zakelijke doelstellingen?
- Accepteren uw klanten alle vormen van multitenancy? Hoe beïnvloedt elk multitenancymodel uw nalevingsvereisten of de nalevingsvereisten van uw klanten?
- 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 dat u SLA's hebt waarnaar u streeft?
Als u verwacht dat uw bedrijf wordt geschaald naar een groot aantal klanten, is het belangrijk om een gedeelde infrastructuur te implementeren. Anders moet u een grote en groeiende vloot resource-exemplaren 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 wat tenant betekent voor uw specifieke oplossing en 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 u echter blijft groeien, zult u merken dat u uw oplossing of enkele onderdelen ervan moet dupliceren om te kunnen schalen naar de nieuwe vraag van de klant. Dit betekent dat u moet bepalen hoe u specifieke klanten toewijst aan specifieke exemplaren van uw oplossing. U kunt klanten willekeurig of geografisch toewijzen, of door één exemplaar in te vullen en vervolgens een andere instantie te starten (bin-verpakking). U moet echter waarschijnlijk een record bijhouden van uw klanten en welke infrastructuur hun gegevens en toepassingen beschikbaar zijn, zodat u hun verkeer naar de juiste infrastructuur kunt routeren. In dit voorbeeld kunt u elke klant vertegenwoordigen als een afzonderlijke tenant en vervolgens de gebruikers toewijzen aan de implementatie die hun gegevens bevat. U hebt een een-op-veel-toewijzing tussen tenants en implementaties en u kunt tenants naar eigen goeddunken verplaatsen tussen implementaties.
Denk daarentegen aan een bedrijf dat cloudsoftware voor juridische bedrijven maakt. Uw klanten willen mogelijk hun eigen toegewezen infrastructuur hebben 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 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 u tenants met hun eigen toegewezen implementaties hebt, hebben ze hun eigen infrastructuur, dus het kan minder belangrijk zijn voor uw code om te weten dat deze werkt in 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 hier wordt weergegeven:
Zie Toewijzingsaanvragen voor tenants voor meer informatie.
Isolatie van tenants
Een van de grootste overwegingen in het ontwerp van een architectuur met meerdere tenants is het isolatieniveau dat elke tenant nodig heeft. Isolatie kan verschillende dingen betekenen:
- Met éé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 situaties kan het zelfs betekenen dat u een afzonderlijke fysieke infrastructuur implementeert met behulp van toegewezen hosts.
In plaats van te denken aan isolatie als een discrete eigenschap, moet u erover nadenken als een continuum. U kunt onderdelen van uw architectuur implementeren die meer 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:
Het isolatieniveau is van invloed op veel aspecten van uw architectuur, waaronder de volgende:
- Beveiliging. Als u infrastructuur deelt tussen meerdere tenants, moet u er met name op letten 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. Gedeelde infrastructuur kan door meerdere tenants worden gebruikt, zodat deze goedkoper is.
- Prestaties. Als u de infrastructuur deelt, kunnen de prestaties van uw systeem afnemen naarmate meer klanten deze gebruiken, omdat de resources mogelijk sneller worden verbruikt. Prestatieproblemen kunnen worden verergerd door tenants met ongebruikelijke gebruikspatronen.
- Betrouwbaarheid. Als u één set gedeelde infrastructuur gebruikt, kan een probleem met één onderdeel leiden tot een storing voor al uw tenants.
- Reactiesnelheid voor de behoeften van afzonderlijke tenants. 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, waarbij al uw tenants toegang hebben 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 overwegen om verschillende isolatieniveaus voor elke laag te gebruiken. U moet uw beslissing baseren op wat er wordt gedeeld en wat is geïsoleerd op veel overwegingen, 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 dit voorbeeld:
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 (IaC) 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 aanpak is dat gegevens voor elke tenant geïsoleerd zijn, wat het risico op onbedoelde lekkage vermindert. Deze beveiliging kan belangrijk zijn voor sommige klanten die een hoge overhead voor naleving van regelgeving hebben. Bovendien zijn tenants waarschijnlijk niet van invloed op de systeemprestaties van elkaar, een probleem dat ook wel het probleem met lawaaierige buren wordt genoemd. 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 bepaalde infrastructuurkosten zijn vereist, vereisen 100 tenants waarschijnlijk 100 keer die kosten. Daarnaast is doorlopend onderhoud (zoals het toepassen van nieuwe configuratie- of software-updates) waarschijnlijk tijdrovend. 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. Zorg er ook voor dat u wilt plannen hoe u gegevens in meerdere implementaties kunt doorzoeken en bewerken.
Volledig multitenant-implementaties
In het tegenovergestelde extreme geval kunt u een volledig multitenant-implementatie overwegen, waarbij 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:
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 tussen twee afzonderlijke implementaties te migreren.
Risico 's:
Zorg ervoor dat u gegevens voor elke tenant scheidt en geen gegevens over tenants lekken. Mogelijk moet u shardinggegevens beheren. Daarnaast moet u zich misschien zorgen maken over 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 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.
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. U kunt overwegen om een pool met meerdere exemplaren van uw resources (bijvoorbeeld meerdere AKS-clusters of opslagaccounts) te implementeren om een quotumlimiet voor resources te voorkomen. 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 hiervoor kunnen niet-lineair toenemen. Als u bijvoorbeeld één gedeelde database hebt, kunt u, wanneer u op zeer grote schaal wordt uitgevoerd, 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 overwegen om uw tenants verticaal te partitioneren door deze aanpak 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 in multitenant-infrastructuren, maar implementeer 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 met name 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:
Voordelen: omdat u nog steeds een deel van uw infrastructuur deelt, kunt u enkele van de kostenvoordelen verkrijgen van het gebruik van gedeelde multitenant-implementaties. U kunt goedkopere gedeelde resources implementeren voor bepaalde klanten, zoals klanten die uw service evalueren met een proefversie. U kunt klanten zelfs een hoger tarief factureren om een implementatie met één tenant te gebruiken, zodat u enkele van uw kosten kunt herstellen.
Risico's: Uw codebase moet worden ontworpen ter ondersteuning van implementaties met meerdere tenants en implementaties met één tenant. 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 ook overwegen om uw implementaties horizontaal te 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 voor elke tenant implementeren, zoals wordt weergegeven in dit diagram:
Voordelen: horizontaal gepartitioneerde implementaties kunnen u helpen bij het beperken van een probleem met ruis: als u vaststelt dat de meeste belasting op uw systeem wordt veroorzaakt door specifieke onderdelen, 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, 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: 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 eventuele ruiseffecten 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.
Medewerkers
Dit artikel wordt onderhouden door Microsoft. De tekst is oorspronkelijk geschreven door de volgende Inzenders.
Hoofdauteur:
- John Downs | Principal Software Engineer
Andere Inzenders:
- Chad Kittel | Principal Software Engineer
- Paulo Salvatori | Principal Customer Engineer, FastTrack voor Azure
- Arsen Vladimirskiy | Principal Customer Engineer, FastTrack voor Azure
Als u niet-openbare LinkedIn-profielen wilt zien, meldt u zich aan bij LinkedIn.
Volgende stappen
Houd rekening met de levenscyclus van uw tenants