Delen via

Architectuurbenaderingen voor compute in multitenant-oplossingen

De meeste cloudoplossingen bestaan uit rekenresources. Deze resources kunnen bestaan uit web- en applicatielagen, batchprocessors, geplande taken of gespecialiseerde resources zoals GPU's en high-performance computing. Multitenant-oplossingen profiteren vaak van gedeelde rekenresources omdat een hogere dichtheid van tenants voor elke infrastructuur operationele kosten verlaagt en het beheer vereenvoudigt. U moet rekening houden met de isolatievereisten en de gevolgen van een gedeelde infrastructuur.

Dit artikel bevat richtlijnen over cruciale overwegingen en vereisten voor oplossingsarchitecten die rekening moeten houden bij het plannen van een multitenant-rekenlaag. Deze richtlijnen omvatten veelvoorkomende patronen voor het toepassen van multitenancy op rekenservices en antipatroonten om te voorkomen.

Belangrijke overwegingen en vereisten

Zowel multitenancy als het isolatiemodel dat u kiest, is van invloed op de schaal, prestaties, statusbeheer en beveiliging van uw rekenresources. In de volgende secties worden belangrijke beslissingen besproken die u moet nemen wanneer u een multitenant-rekenoplossing plant.

Schaal

Systemen moeten adequaat presteren naarmate de vraag verandert. Naarmate het aantal tenants en verkeer toeneemt, moet u mogelijk uw resources schalen om aan de groeiende vraag te voldoen en acceptabele prestaties te behouden. Op dezelfde manier moet u, wanneer het aantal actieve gebruikers of de hoeveelheid verkeer afneemt, automatisch de rekencapaciteit verlagen om de kosten te verlagen. U moet echter elke onderbreking voor gebruikers minimaliseren wanneer u de capaciteit aanpast.

Als u toegewezen resources voor elke tenant implementeert, hebt u de flexibiliteit om de resources van elke tenant onafhankelijk te schalen. In een oplossing waarbij rekenresources worden gedeeld tussen meerdere tenants, kunnen alle tenants profiteren van de toegenomen capaciteit door deze resources te schalen. Echter, alle tenants hebben er last van wanneer de schaal onvoldoende is om hun totale belasting te dragen. Zie Noisy Neighbor antipatroon voor meer informatie.

Wanneer u cloudoplossingen bouwt, kunt u kiezen of u horizontaal of verticaal wilt schalen. In een multitenant-oplossing met een toenemend aantal tenants biedt horizontale schaalvergroting doorgaans meer flexibiliteit en een hoger plafond voor de algehele schaal.

Prestatieproblemen blijven vaak onopgemerkt totdat een toepassing wordt geladen. U kunt een volledig beheerde service, zoals Azure Load Testing, gebruiken om te leren hoe uw toepassing werkt onder stress.

Schaaltriggers

Ongeacht de benadering die u gebruikt om te schalen, moet u doorgaans de triggers plannen die ervoor zorgen dat uw onderdelen worden geschaald. Wanneer u gedeelde onderdelen hebt, moet u rekening houden met de workloadpatronen van elke tenant om ervoor te zorgen dat uw ingerichte capaciteit voldoet aan de totale vereiste vraag. Met deze aanpak voorkomt u conflicten tussen resources en vermindert u de kans dat tenants het probleem met lawaaierige buren ondervinden. Mogelijk kunt u uw schaalcapaciteit ook plannen door rekening te houden met het aantal tenants. Als u bijvoorbeeld de resources meet die u gebruikt voor de service van 100 tenants, kunt u naarmate u meer tenants onboardt, schalen zodat uw resources verdubbelen voor elke extra 100 tenants.

Staat

Rekenresources kunnen staatloos zijn of stateful zijn. Staatloze onderdelen onderhouden geen gegevens tussen aanvragen. Vanuit het oogpunt van schaalbaarheid zijn staatloze onderdelen vaak eenvoudig uit te schalen, omdat u snel nieuwe werkrollen, exemplaren of knooppunten kunt toevoegen. Stateless onderdelen kunnen ook onmiddellijk beginnen met het verwerken van aanvragen. Als uw architectuur ondersteuning biedt voor het opnieuw toewijzen van exemplaren, kunt u ook instanties van de ene tenant opnieuw toewijzen aan een andere tenant.

Stateful resources kunnen verder worden onderverdeeld op basis van het type status dat ze onderhouden. Permanente status is gegevens die permanent moeten worden opgeslagen. Vermijd in cloudoplossingen het opslaan van een permanente status in uw rekenlaag. Gebruik in plaats daarvan opslagservices zoals databases of opslagaccounts. Tijdelijke status is gegevens die tijdelijk worden opgeslagen. Het omvat alleen-lezen geheugenopslag en de opslag van tijdelijke bestanden op lokale schijven.

Tijdelijke status is vaak handig om de prestaties van uw toepassingslaag te verbeteren door het aantal aanvragen naar back-endopslagservices te verminderen. Wanneer u bijvoorbeeld een in-memory cache gebruikt, kunt u mogelijk leesaanvragen verwerken zonder verbinding te maken met een database en zonder een intensieve query uit te voeren die u onlangs hebt uitgevoerd toen u een andere aanvraag hebt gedaan.

In latentiegevoelige toepassingen kunnen de kosten van cachehydrateren aanzienlijk worden. Een multitenant-oplossing kan dit probleem verergeren als voor elke tenant verschillende gegevens in de cache moeten worden opgeslagen. Om dit probleem te verhelpen, passen sommige oplossingen sessieaffiniteit toe. Deze aanpak zorgt ervoor dat hetzelfde rekenwerkknooppunt alle aanvragen voor een specifieke gebruiker of tenant verwerkt. Sessieaffiniteit kan de mogelijkheid van de toepassingslaag verbeteren om de cache effectief te gebruiken. Sessieaffiniteit maakt het schalen en het verdelen van verkeer echter ook ingewikkeld voor werkrollen. Houd dit zorgvuldig in overweging. Voor veel toepassingen is sessieaffiniteit niet vereist.

Het is ook mogelijk om gegevens op te slaan in externe caches, zoals Azure Cache voor Redis. Externe caches zijn geoptimaliseerd voor het ophalen van gegevens met lage latentie, terwijl de status van de rekenresources wordt geïsoleerd, zodat ze afzonderlijk kunnen worden geschaald en beheerd. In veel oplossingen kunt u met externe caches de prestaties van toepassingen verbeteren, terwijl u de rekenlaag staatloos houdt.

Belangrijk

Vermijd het lekken van gegevens tussen tenants wanneer u caches in het geheugen of andere onderdelen gebruikt die de status behouden. U kunt bijvoorbeeld een tenant-id toewijzen aan alle cachesleutels om ervoor te zorgen dat gegevens voor elke tenant worden gescheiden.

Isolatie

Wanneer u een multitenant-rekenlaag ontwerpt, hebt u verschillende opties voor tenantisolatie. U kunt gedeelde rekenresources implementeren voor alle tenants, toegewezen rekenresources voor afzonderlijke tenants of een semi-geïsoleerde benadering die tussen deze extremen valt. Elke optie heeft compromissen. Als u wilt bepalen welke optie het beste bij uw oplossing past, moet u rekening houden met uw vereisten voor isolatie.

Het kan zijn dat u zich bezig houdt met de logische isolatie van tenants en het scheiden van de beheerverantwoordelijkheden of beleidsregels die op elke tenant worden toegepast. U moet mogelijk afzonderlijke resourceconfiguraties implementeren voor specifieke tenants, zoals het implementeren van een specifieke VM-SKU (virtuele machine) voor de workload van een tenant.

Afhankelijk van het isolatiemodel dat u kiest, moet u ervoor zorgen dat tenantgegevens op de juiste wijze worden geïsoleerd, zelfs als er fouten of storingen optreden in onderdelen. Overweeg het gebruik van Azure Chaos Studio in uw reguliere geautomatiseerde testproces om fouten te introduceren die echte storingen simuleren. Met deze test kunt u controleren of uw oplossing de juiste tenantisolatie onderhoudt en blijft onder druk functioneren.

Benaderingen en patronen om rekening mee te houden

Automatisch schalen

Azure Compute-services bieden verschillende mogelijkheden voor het schalen van workloads. Veel rekenservices ondersteunen automatisch schalen. Hiervoor moet u bepalen wanneer u de schaal wilt aanpassen en minimum- en maximumschaalniveaus wilt instellen. De specifieke schaalopties zijn afhankelijk van de rekenservices die u gebruikt. Zie de volgende voorbeeldservices of onderdelen:

Patroon voor implementatiestempels

Zie Architectuurbenaderingen voor een multitenant-oplossing voor meer informatie over hoe u het patroon Implementatiestempels kunt gebruiken om een multitenant-oplossing te ondersteunen.

Patroon voor rekenresourceconsolidatie

Het Compute Resource Consolidation patroon stelt u in staat een hogere dichtheid van gebruikers binnen de computere-infrastructuur te realiseren door de onderliggende rekenresources te delen. Door rekenresources te delen, kunt u de directe kosten van deze resources verlagen. Ook zijn uw beheerkosten vaak lager omdat er minder onderdelen zijn om te beheren.

Consolidatie van rekenresources verhoogt echter de kans op het probleem van de luidruchtige buur. De workload van elke tenant kan een onevenredige hoeveelheid rekencapaciteit verbruiken die beschikbaar is. U kunt dit risico vaak beperken door ervoor te zorgen dat u uw oplossing op de juiste manier schaalt en door besturingselementen zoals quota en API-limieten toe te passen om tenants te voorkomen die meer verbruiken dan hun evenredige aandeel van de capaciteit.

Dit patroon wordt op verschillende manieren bereikt, afhankelijk van de rekenservice die u gebruikt. Zie de volgende voorbeeldservices of onderdelen:

  • App Service en Azure Functions: Implementeer gedeelde App Service-plannen, die de infrastructuur van de hostingserver vertegenwoordigen.

  • Container Apps:Gedeelde omgevingen implementeren.

  • AKS: Implementeer gedeelde pods met een multitenancybewuste toepassing.

  • VM's: Implementeer één set virtuele machines voor gebruik door alle huurders.

Toegewezen rekenresources voor elke tenant

U kunt ook toegewezen rekenresources implementeren voor elke tenant. Toegewezen resources beperken het risico van het probleem van luidruchtige buren door ervoor te zorgen dat de rekenresources voor elke tenant worden geïsoleerd van de andere tenants. Hiermee kunt u ook een afzonderlijke configuratie implementeren voor de resources van elke tenant op basis van hun vereisten. Voor toegewezen resources worden echter doorgaans hogere kosten in rekening gebracht omdat u een lagere dichtheid van tenants voor resources hebt.

Afhankelijk van de Azure-rekenservices die u gebruikt, moet u mogelijk verschillende toegewezen resources implementeren:

  • App Service en Azure Functions: Implementeer afzonderlijke App Service-plannen voor elke tenant.

  • Container Apps: Implementeer afzonderlijke omgevingen voor elke tenant.

  • AKS: Implementeer toegewezen clusters voor elke tenant.

  • Vms: Implementeer toegewezen VM's voor elke tenant.

Isolatie op fysiek hostniveau kan ook worden geboden door tenant-VM's uit te voeren op toegewezen Azure-hosts, die een volledige fysieke server reserveren voor één klant. Deze benadering is echter meestal duurder dan het gebruik van gedeelde hosts.

Semi-geïsoleerde rekenresources

Bij semi-geïsoleerde benaderingen moet u aspecten van de oplossing in een geïsoleerde configuratie implementeren terwijl u de andere onderdelen deelt.

Wanneer u App Service en Azure Functions gebruikt, kunt u afzonderlijke toepassingen implementeren voor elke tenant en de toepassingen hosten op gedeelde App Service-abonnementen. Deze aanpak vermindert de kosten van uw rekenlaag, omdat App Service-abonnementen de factureringseenheid vertegenwoordigen. Hiermee kunt u ook afzonderlijke configuratie en beleidsregels toepassen op elke toepassing. Deze benadering introduceert echter het risico van het probleem met lawaaierige buren.

U kunt Container Apps gebruiken om meerdere toepassingen te implementeren in een gedeelde omgeving en vervolgens Dapr en andere hulpprogramma's gebruiken om elke toepassing afzonderlijk te configureren.

AKS en Kubernetes bieden meer mogelijkheden voor multitenancy:

  • Tenantspecifieke naamruimten die logische isolatie van tenantspecifieke resources kunnen bieden, die worden geïmplementeerd in gedeelde clusters en knooppuntgroepen.

  • Tenantspecifieke knooppunten of knooppuntgroepen in een gedeeld cluster.

  • Tenantspecifieke pods die mogelijk gebruikmaken van dezelfde knooppuntgroep.

U kunt AKS ook gebruiken om governance op podniveau toe te passen om het probleem met lawaaierige buren te beperken. Zie Aanbevolen procedures voor toepassingsontwikkelaars voor het beheren van resources in AKS voor meer informatie.

Het is ook belangrijk om rekening te houden met gedeelde onderdelen in een Kubernetes-cluster en hoe multitenancy van invloed kan zijn op deze onderdelen. De Kubernetes-API-server is bijvoorbeeld een gedeelde service die in het hele cluster wordt gebruikt. Zelfs als u tenantspecifieke knooppuntgroepen opgeeft om de toepassingsworkloads van de tenants te isoleren, kan de API-server problemen ondervinden door een groot aantal verzoeken vanuit de tenants.

Antipatronen om te vermijden

Luidruchtige buurman anti-patroon

Wanneer u onderdelen implementeert die tenants delen, is het probleem met een luidruchtige buur een potentieel risico. Zorg ervoor dat u resourcebeheer en bewaking opneemt om het risico te beperken dat de activiteit van andere tenants van invloed is op de rekenworkload van een tenant.

Gegevenslekken tussen tenants

Rekenlagen kunnen worden onderworpen aan gegevenslekken tussen tenants als ze niet goed worden verwerkt. Dit risico is meestal niet iets wat u moet overwegen wanneer u een multitenant-service op Azure gebruikt, omdat Microsoft beveiliging biedt op de platformlaag. Wanneer u echter uw eigen multitenant-toepassing ontwikkelt, kunt u overwegen of gedeelde resources, zoals lokale schijfcaches, RAM en externe caches, mogelijk gegevens bevatten die een andere tenant per ongeluk kan bekijken of wijzigen.

Antipatroon overbelaste front-end

Als u het antipatroon Bezet-front-end wilt voorkomen, moet u ervoor zorgen dat uw front-endlaag niet het meeste werk doet dat andere onderdelen of lagen van uw architectuur kunnen verwerken. Deze antipatroon is vooral belangrijk wanneer u gedeelde front-ends voor een multitenant-oplossing maakt, omdat een drukke front-end de ervaring voor alle tenants verslechtert.

In plaats daarvan kunt u overwegen asynchrone verwerking te gebruiken met behulp van wachtrijen of andere berichtenservices. Met deze aanpak kunt u ook kwaliteit van servicecontroles toepassen voor verschillende tenants op basis van hun vereisten. Alle tenants kunnen bijvoorbeeld een gemeenschappelijke front-endlaag delen, maar tenants die betalen voor een hoger serviceniveau kunnen een grotere set exclusieve resources hebben om het werk van hun wachtrijberichten te verwerken.

Inelastisch of onvoldoende schaalbaarheid

Multitenant-oplossingen zijn vaak onderhevig aan piekende schaalveranderingen. Gedeelde onderdelen zijn zeer gevoelig voor dit probleem omdat het bereik voor burst hoger is en het effect groter is wanneer u meer tenants hebt met verschillende gebruikspatronen.

Zorg ervoor dat u profiteert van de elasticiteit en schaal van de cloud. Overweeg of u horizontaal of verticaal schalen moet gebruiken en automatisch schalen moet gebruiken om pieken in de belasting automatisch te verwerken. Test uw oplossing om te begrijpen hoe deze werkt onder verschillende belastingsniveaus. Zorg ervoor dat u de verwachte belasting in de productie en uw verwachte groei opneemt. U kunt een volledig beheerde service, zoals belastingtests, gebruiken om te leren hoe uw toepassing werkt onder stress.

Geen antipatroon voor opslaan in cache

Het antipatroon zonder caching is wanneer de prestaties van uw oplossing verslechteren, omdat de toepassingslaag herhaaldelijk aanvragen doet of gegevens opnieuw berekent die opnieuw gebruikt kunnen worden bij aanvragen. Als u gegevens hebt die kunnen worden gedeeld tussen tenants of tussen gebruikers binnen één tenant, is het waarschijnlijk de moeite waard om deze in de cache op te slaan om de belasting van uw back-end of databaselaag te verminderen.

Onnodige statefulheid

De implicatie van het Geen caching-antipatroon is dat u ook moet voorkomen dat onnodige toestand in uw rekenlaag wordt opgeslagen. Wees expliciet over waar u de status onderhoudt en waarom. Stateful front-end- of applicatielagen kunnen uw vermogen om te schalen verminderen. Stateful compute-lagen vereisen doorgaans ook sessieaffiniteit, waardoor u minder effectief taken kunt verdelen over werkrollen of knooppunten.

Houd rekening met de afwegingen voor elk deel van de status dat u in uw rekenlaag onderhoudt en of dit van invloed is op uw vermogen om te schalen of te groeien naarmate de workloadpatronen van uw tenants veranderen. U kunt ook de status opslaan in een externe cache, zoals Azure Cache voor Redis.

Medewerkers

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

Hoofdauteurs:

  • Dixit Arora | Senior klanttechnicus, FastTrack voor Azure
  • John Downs | Hoofd Software Ingenieur

Andere inzenders:

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

Volgende stappen

Bekijk servicespecifieke richtlijnen voor uw rekenservices: