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 wijzigen

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 schaal onvoldoende is om hun totale belasting te verwerken. Zie het probleem Noisy Neighbor voor meer informatie.

Wanneer u cloudoplossingen bouwt, kunt u kiezen of u horizontaal of verticaal wilt schalen. In een multitenant-oplossing met een groeiend aantal tenants biedt 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, zoals Azure Load Testing, gebruiken 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 workloadpatronen van elke tenant die gebruikmaakt van de resources, om ervoor te zorgen dat uw ingerichte capaciteit kan voldoen aan de totale vereiste capaciteit en om de kans te minimaliseren dat een tenant het probleem met Noisy Neighbor ondervindt. 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.

Provincie

Rekenresources kunnen staatloos zijn of stateful zijn. 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 is gegevens 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. Tijdelijke status is gegevens die tijdelijk worden opgeslagen en die alleen-lezen in-memory caches bevatten 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, voor gebruik door alle tenants, toegewezen rekenresources voor elke tenant of iets tussen deze uitersten. Elke optie wordt geleverd met 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 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 om Azure Chaos Studio te gebruiken als onderdeel van uw reguliere geautomatiseerde testproces om opzettelijk fouten te introduceren die echte storingen simuleren en controleren of uw oplossing geen gegevens tussen tenants lekt 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 bieden ondersteuning voor 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:

  • Azure-app Service: geef regels voor automatisch schalen op die uw infrastructuur schalen op basis van uw vereisten.
  • Azure Functions: Selecteer uit meerdere schaalopties, waaronder een gebeurtenisgestuurd schaalmodel dat automatisch wordt geschaald, op basis van het werk dat uw functies uitvoeren.
  • Azure Container Apps: Gebruik gebeurtenisgestuurde automatische schaalaanpassing om uw toepassing te schalen op basis van het werk dat wordt uitgevoerd en de huidige belasting.
  • Azure Kubernetes Service (AKS): als u aan de vereisten van uw toepassing wilt voldoen, moet u mogelijk het aantal knooppunten aanpassen waarop uw workloads worden uitgevoerd. Daarnaast kunt u virtuele knooppunten gebruiken om toepassingsworkloads snel te schalen in een AKS-cluster.
  • Virtuele machines: Een virtuele-machineschaalset kan het aantal VM-exemplaren waarop uw toepassing wordt uitgevoerd, automatisch vergroten of verkleinen.

Patroon Implementatiestempels

Zie Overzicht voor meer informatie over hoe het patroon Implementatiestempels kan worden gebruikt ter ondersteuning van een multitenant-oplossing.

Patroon Consolidatie van berekenbronnen

Het patroon Consolidatie van rekenresources helpt u bij het bereiken van een hogere dichtheid van tenants voor het berekenen van de infrastructuur 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 rekenresources verhoogt echter de kans op het probleem met ruis. 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):implementeer gedeelde pods met een multitenancybewuste toepassing.
  • Virtuele machines: implementeer één set virtuele machines voor alle tenants die moeten worden gebruikt.

Toegewezen rekenresources per tenant

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

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

  • Azure-app Service en Azure Functions: Implementeer afzonderlijke App Service-plannen voor elke tenant.
  • Azure Container Apps: afzonderlijke omgevingen implementeren voor elke tenant.
  • Azure Kubernetes Service (AKS):implementeer toegewezen clusters 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 benadering introduceert echter het risico van het probleem Noisy Neighbor.

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 governance op podniveau toepassen om het probleem met Noisy Neighbor te beperken. Zie Best practices 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 conflicten ondervinden van een groot aantal aanvragen in de tenants.

Antipatroon om te voorkomen

Luidruchtige buur antipatroon

Wanneer u onderdelen implementeert die worden gedeeld tussen tenants, is het probleem Noisy Neighbor 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 Front-end bezet

Als u het antipatroon Bezet-front-end wilt voorkomen, moet u voorkomen dat uw front-endlaag veel 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 , hebben mogelijk een hogere set toegewezen resources om het werk van hun wachtrijberichten te verwerken.

Inelastisch of onvoldoende schalen

Multitenant-oplossingen zijn vaak onderhevig aan bursty schaalpatronen. 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 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 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, zoals Azure Load Testing, gebruiken om te leren hoe uw toepassing zich gedraagt onder stress.

Antipatroon Geen caching

Het antipatroon Geen caching is wanneer de prestaties van uw oplossing te lijden hebben, omdat de toepassingslaag herhaaldelijk aanvragen doet of gegevens hercomputeert die opnieuw kunnen worden gebruikt voor 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

De corollary voor het antipatroon Geen caching is dat u ook moet voorkomen dat onnodige status in uw rekenlaag wordt opgeslagen. Wees expliciet over waar u de status onderhoudt en waarom. Stateful front-end- of toepassingslagen kunnen de mogelijkheid 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. De tekst is oorspronkelijk geschreven door de volgende Inzenders.

Belangrijkste auteurs:

  • Dixit Arora | Senior klanttechnicus, FastTrack voor Azure
  • John Downs | Principal Software Engineer

Andere Inzenders:

Volgende stappen

Bekijk servicespecifieke richtlijnen voor uw rekenservices: