Delen via

Architectuurbenaderingen voor compute in multitenant-oplossingen

  • Artikel

De meeste cloudoplossingen bestaan uit rekenresources van een soort, zoals web- en toepassingslagen, batchprocessors, geplande taken en zelfs gespecialiseerde resources, zoals GPU's en HPC (High Performance Compute). Multitenant-oplossingen profiteren vaak van gedeelde rekenresources, omdat een hogere dichtheid van tenants naar infrastructuur de operationele kosten en het beheer vermindert. U moet rekening houden met de isolatievereisten en de gevolgen van een gedeelde infrastructuur.

Dit artikel bevat richtlijnen over de overwegingen en vereisten die essentieel zijn voor oplossingsarchitecten om rekening mee te houden bij het plannen van een multitenant-rekenlaag. Dit omvat enkele veelvoorkomende patronen voor het toepassen van multitenancy op rekenservices, samen met enkele antipatroonten om te voorkomen.

Belangrijke overwegingen en vereisten

Multitenancy en het isolatiemodel dat u selecteert, heeft invloed op het schalen, prestaties, statusbeheer en beveiliging van uw rekenresources. In deze sectie bekijken we enkele belangrijke beslissingen die u moet nemen wanneer u een multitenant-rekenoplossing plant.

Schaal

Systemen moeten adequaat presteren onder veranderende vraag. Naarmate het aantal tenants en de hoeveelheid verkeer toeneemt, moet u mogelijk de capaciteit van uw resources verhogen om het groeiende aantal tenants bij te houden en een acceptabel prestatiepercentage te behouden. Op dezelfde manier moet u, wanneer het aantal actieve gebruikers of de hoeveelheid verkeer afneemt, automatisch de rekencapaciteit verminderen om de kosten te verlagen, maar moet u de capaciteit met minimale gevolgen voor gebruikers verminderen.

Als u toegewezen resources voor elke tenant implementeert, hebt u de flexibiliteit om de resources van elke tenant onafhankelijk te schalen. In een oplossing waarin rekenresources worden gedeeld tussen meerdere tenants, als u deze resources schaalt, kunnen al deze tenants gebruikmaken van de nieuwe schaal. Ze zullen echter ook allemaal lijden wanneer de capaciteit onvoldoende is om hun totale belasting te dragen. Zie het probleem met lawaaierige burenvoor meer informatie.

Wanneer u cloudoplossingen bouwt, kunt u kiezen of u horizontaal of verticaal wilt schalen. In een multitenant-oplossing met een groeiend aantal huurders biedt horizontaal schalen u 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 gebruiken, zoals Azure Load Testing, om te leren hoe uw toepassing zich gedraagt onder stress.

Schaaltriggers

Welke methode u ook gebruikt om te schalen, doorgaans moet u de triggers plannen die ervoor zorgen dat uw onderdelen worden geschaald. Wanneer u gedeelde onderdelen hebt, moet u rekening houden met de werklastpatronen van elke tenant die van de resources gebruikmaken, om ervoor te zorgen dat uw ingerichte capaciteit kan voldoen aan de totale vereiste capaciteit en om de kans te minimaliseren dat een huurder het probleem van de Noisy Neighbor ervaart. 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, van plan zijn om te schalen zodat uw resources verdubbelen voor elke extra 100 tenants.

Staat

Rekenmiddelen kunnen staatlooszijn, of ze kunnen met toestandzijn. Staatloze onderdelen onderhouden geen gegevens tussen aanvragen. Vanuit een schaalbaarheidsperspectief zijn staatloze onderdelen vaak eenvoudig uit te schalen, omdat u snel nieuwe werknemers, exemplaren of knooppunten kunt toevoegen en ze direct kunnen beginnen met het verwerken van aanvragen. Als uw architectuur dit toestaat, kunt u ook instanties die aan één tenant zijn toegewezen, opnieuw gebruiken en toewijzen aan een andere tenant.

Stateful resources kunnen verder worden onderverdeeld op basis van het type status dat ze onderhouden. permanente status gegevens zijn die permanent moeten worden opgeslagen. In cloudoplossingen moet u voorkomen dat u een permanente status opslaat in uw rekenlaag. Gebruik in plaats daarvan opslagservices zoals databases of opslagaccounts. Overgangstoestand is gegevens die tijdelijk worden opgeslagen, inclusief alleen-lezen geheugencaches 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 voor back-endopslagservices te verminderen. Wanneer u bijvoorbeeld een cache in het geheugen 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 wanneer 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, gebruiken sommige oplossingen sessieaffiniteit om ervoor te zorgen dat alle aanvragen voor een specifieke gebruiker of tenant worden verwerkt door hetzelfde rekenwerkknooppunt. Hoewel sessieaffiniteit de mogelijkheid van de toepassingslaag kan verbeteren om de cache effectief te gebruiken, maakt het ook moeilijker om de schaal aan te passen en de belasting van verkeer over werknemers te verdelen. Dit compromis moet zorgvuldig worden overwogen. 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 geïsoleerd blijft van de rekenresources, 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 vaak veel opties om rekening mee te houden voor het isolatieniveau tussen tenants, waaronder het implementeren van gedeelde rekenresources, die door alle tenants moeten worden gebruikt, toegewezen rekenresources voor elke tenant of iets tussen deze extremen. Elke optie heeft zijn keerzijde. 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 virtuele-machine-SKU voor de workload van een tenant.

Ongeacht het isolatiemodel dat u selecteert, controleert u of uw tenantgegevens op de juiste wijze geïsoleerd blijven, zelfs wanneer onderdelen niet beschikbaar of defect zijn. Overweeg het gebruik van Azure Chaos Studio als onderdeel van uw reguliere geautomatiseerde testproces om opzettelijk fouten te introduceren die echte storingen simuleren en controleren of uw oplossing geen gegevens lekt tussen tenants en zelfs onder druk functioneert.

Benaderingen en patronen om rekening mee te houden

Automatisch schalen

Azure Compute-services bieden verschillende mogelijkheden om uw workloads te schalen. Veel rekenservices ondersteunen automatisch schalen. Hiervoor moet u rekening houden wanneer u moet schalen en uw minimale en maximale schaalniveaus. Welke specifieke opties beschikbaar zijn voor schalen, is afhankelijk van de rekenservices die u gebruikt. Zie de volgende voorbeeldservices:

Patroon voor implementatiestempels

Zie Overviewvoor meer informatie over hoe het Deployment Stamps-patroon kan worden gebruikt om een multitenant-oplossing te ondersteunen.

Patroon voor rekenresourceconsolidatie

Het patroon Consolidatie van rekenresources helpt u een hogere dichtheid van tenants op de computerinfrastructuur te bereiken door de onderliggende rekenresources te delen. Door rekenresources te delen, kunt u vaak de directe kosten van deze resources verlagen. Daarnaast zijn uw beheerkosten vaak lager omdat er minder onderdelen zijn om te beheren.

Consolidatie van computerbronnen verhoogt echter de kans op het probleem Noisy Neighbor. 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 te voorkomen dat tenants 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:

  • Azure App Service en Azure Functions: Implementeer gedeelde App Service-plannen, die de infrastructuur van de hostingserver vertegenwoordigen.
  • Azure Container Apps-: gedeelde omgevingen implementeren.
  • Azure Kubernetes Service (AKS): Gedeelde pods implementeren met een multitenancybewuste toepassing.
  • virtuele machines: implementeer één set virtuele machines die door alle huurders wordt gebruikt.

Toegewezen rekenresources per tenant

U kunt ook toegewezen rekenresources implementeren voor elke tenant. Geëigende middelen beperken het risico van het Luidruchtige Buurman probleemdoor ervoor te zorgen dat de rekenkrachtbronnen van elke huurder geïsoleerd blijven van de anderen. Hiermee kunt u ook een afzonderlijke configuratie implementeren voor de resources van elke tenant, op basis van hun vereisten. Toegewijde middelen hebben doorgaans hogere kosten, omdat je een lagere dichtheid van gebruikers per middel hebt.

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

  • Azure App Service en Azure Functions: Afzonderlijke App Service-plannen voor elke tenant implementeren.
  • Azure Container Apps: afzonderlijke omgevingen implementeren voor elke tenant.
  • Azure Kubernetes Service (AKS): Toegewezen clusters implementeren voor elke tenant.
  • virtuele machines: toegewezen virtuele machines implementeren voor elke tenant.

Semi-geïsoleerde rekenresources

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

Wanneer u met App Service en Azure Functions werkt, kunt u afzonderlijke toepassingen implementeren voor elke tenant en kunt u de toepassingen hosten op gedeelde App Service-plannen. 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 aanpak introduceert echter het risico van het Noisy Neighbor-probleem.

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

Azure Kubernetes Service (AKS) en Kubernetes bieden een verscheidenheid aan opties voor multitenancy, waaronder de volgende:

  • Tenantspecifieke naamruimten voor logische isolatie van tenantspecifieke resources, 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.

Met AKS kunt u ook podbeheer toepassen om het Noisy Neighbor-probleemte beperken. Zie Aanbevolen procedures voor toepassingsontwikkelaars voor het beheren van resources in Azure Kubernetes Service (AKS)voor meer informatie.

Het is ook belangrijk om rekening te houden met gedeelde onderdelen in een Kubernetes-cluster en hoe deze onderdelen mogelijk worden beïnvloed door multitenancy. 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 worden gedeeld tussen tenants, is het Noisy Neighbor-probleem een potentieel risico. Zorg ervoor dat u resourcebeheer en bewaking opneemt om het risico te beperken dat de rekenworkload van een tenant wordt beïnvloed door de activiteit van andere tenants.

Gegevenslekken tussen tenants

Rekenlagen kunnen worden onderworpen aan gegevenslekken tussen tenants, als ze niet goed worden verwerkt. Dit is meestal niet iets wat u moet overwegen wanneer u een multitenant-service in 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

Vermijd het Drukke-front-end-antipatroondoor te voorkomen dat de front-endlaag van systemen veel van het werk uitvoert dat kan worden verwerkt door andere onderdelen of lagen van uw architectuur. Deze antipatroon is met name 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 door gebruik te maken van wachtrijen of andere berichtenservices. Met deze aanpak kunt u ook QoS- -besturingselementen (Quality of Service) 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 mogelijk een uitgebreidere set toegewijde middelen hebben om het werk vanuit hun wachtrijberichten te verwerken.

Inelastisch of onvoldoende schaalbaarheid

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

Zorg ervoor dat u goed gebruik maakt van de elasticiteit en schaal van de cloud. Overweeg of u horizontale of verticale schaalaanpassing moet gebruikenen gebruik autoscaling om automatisch pieken in de belasting te verwerken. Test uw oplossing om te begrijpen hoe deze zich gedraagt onder verschillende belastingsniveaus. Zorg ervoor dat u de laadvolumes opneemt die worden verwacht in de productie en de verwachte groei. U kunt een volledig beheerde service gebruiken, zoals Azure Load Testing, om te leren hoe uw toepassing zich gedraagt onder stress.

Geen antipatroon voor opslaan in cache

De Geen antipatroon in cache opslaan is wanneer de prestaties van uw oplossing te lijden hebben, omdat de toepassingslaag herhaaldelijk gegevens aanvraagt of gegevens hercomputeert die opnieuw kunnen worden gebruikt in 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/databaselaag te verminderen.

Onnodige statefulheid

Het uitvloeisel van het antipatroon Geen Caching is dat u ook moet voorkomen dat onnodige toestand in uw computelaag 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 mogelijkheid om te schalen of te groeien wanneer de workloadpatronen van uw tenants veranderen. U kunt ook de status opslaan in een externe cache, zoals Azure Cache voor Redis.

Medewerkers

Dit artikel wordt onderhouden door Microsoft. Het is oorspronkelijk geschreven door de volgende inzenders.

Hoofdauteurs:

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

Andere inzenders:

Volgende stappen

Bekijk servicespecifieke richtlijnen voor uw rekenservices: