Dela via

Arkitekturmetoder för beräkning i lösningar för flera klientorganisationer

De flesta molnbaserade lösningar består av beräkningsresurser. Dessa resurser kan omfatta webb- och programnivåer, batchprocessorer, schemalagda jobb eller specialiserade resurser som GPU:er och beräkning med höga prestanda. Lösningar för flera klienter drar ofta nytta av delade beräkningsresurser eftersom en högre täthet av klienter för varje infrastruktur sänker driftskostnaderna och förenklar hanteringen. Du bör överväga isoleringskraven och konsekvenserna av delad infrastruktur.

Den här artikeln innehåller vägledning om viktiga överväganden och krav för lösningsarkitekter att tänka på när de planerar en beräkningsnivå för flera klienter. Den här vägledningen innehåller vanliga mönster för att tillämpa multitenancy inom beräkningstjänster och antimönster som bör undvikas.

Viktiga överväganden och krav

Både multitenancy och den isoleringsmodell som du väljer påverkar skalning, prestanda, tillståndshantering och säkerhet för dina beräkningsresurser. I följande avsnitt går vi igenom viktiga beslut som du måste fatta när du planerar en beräkningslösning för flera klientorganisationer.

Skala

Systemen måste fungera korrekt när efterfrågan ändras. När antalet klienter och trafik ökar kan du behöva skala dina resurser för att matcha den växande efterfrågan och upprätthålla godtagbara prestanda. När antalet aktiva användare eller mängden trafik minskar bör du på samma sätt automatiskt minska beräkningskapaciteten till lägre kostnader. Du bör dock minimera eventuella störningar för användare när du justerar kapaciteten.

Om du distribuerar dedikerade resurser för varje klientorganisation har du flexibiliteten att skala varje klients resurser oberoende av varandra. I en lösning där beräkningsresurser delas mellan flera klienter gör skalning av dessa resurser att alla klienter kan dra nytta av den ökade kapaciteten. Alla hyresgäster drabbas dock när skalan inte räcker till för att hantera den totala belastningen. Mer information finns i Noisy Neighbor antipattern.

När du skapar molnlösningar kan du välja om du vill skala vågrätt eller lodrätt. I en lösning med flera klienter som har ett växande antal klienter ger skalning horisontellt ofta större flexibilitet och ett högre övergripande skalningstak.

Prestandaproblem förblir ofta oidentifierade tills ett program är under belastning. Du kan använda en fullständigt hanterad tjänst, till exempel Azure Load Testing, för att lära dig hur ditt program fungerar under stress.

Skalningsutlösare

Oavsett vilken metod du använder för att skala måste du vanligtvis planera utlösarna som gör att komponenterna skalas. När du har delade komponenter bör du överväga varje klientorganisations arbetsbelastningsmönster för att säkerställa att din etablerade kapacitet uppfyller den totala efterfrågan som krävs. Den här metoden hjälper till att förhindra resurskonkurrering och minskar sannolikheten för att klienter drabbas av problem med den bullriga grannen. Du kanske också kan planera din skalningskapacitet genom att ta hänsyn till antalet klienter. Om du till exempel mäter de resurser som du använder för att betjäna 100 klientorganisationer kan du när du registrerar fler klienter planera att skala så att dina resurser fördubblas för varje extra 100 klientorganisationer.

Stat

Beräkningsresurser kan vara tillståndslösa, eller de kan vara med tillstånd. Tillståndslösa komponenter underhåller inga data mellan begäranden. Ur ett skalbarhetsperspektiv är tillståndslösa komponenter ofta enkla att skala ut eftersom du snabbt kan lägga till nya arbetare, instanser eller noder. Tillståndslösa komponenter kan också omedelbart börja bearbeta begäranden. Om din arkitektur stöder återanvändning av instanser kan du även omtilldela instanser från en klientorganisation till en annan klientorganisation.

Tillståndsbevarande resurser kan delas upp ytterligare baserat på vilken typ av tillstånd de bibehåller. Beständiga tillstånd är data som måste lagras permanent. Undvik att lagra ett beständigt tillstånd på beräkningsnivån i molnlösningar. Använd i stället lagringstjänster som databaser eller lagringskonton. Tillfälligt tillstånd är data som lagras tillfälligt. Den innehåller skrivskyddade minnesinterna cacheminnen och lagring av temporära filer på lokala diskar.

Tillfälligt tillstånd kan ofta vara användbart för att förbättra prestanda för applikationslagret genom att minska antalet begäranden till backend-lagringstjänster. När du till exempel använder en minnesintern cache kan du hantera läsbegäranden utan att ansluta till en databas och utan att utföra en intensiv fråga som du nyligen utförde när du hanterade en annan begäran.

I svarstidskänsliga program kan kostnaden för cachehydrering bli betydande. En lösning med flera klienter kan förvärra det här problemet om varje klientorganisation kräver att olika data cachelagras. För att åtgärda det här problemet tillämpar vissa lösningar sessionstillhörighet. Den här metoden säkerställer att samma beräkningsarbetsnod bearbetar alla begäranden för en specifik användare eller klientorganisation. Sessionstillhörighet kan förbättra programnivåns möjlighet att använda dess cache effektivt. Sessionstillhörigheten komplicerar dock även skalning och belastningsutjämning mellan arbetare. Tänk noga på den här kompromissen. För många program krävs inte sessionstillhörighet.

Det går också att lagra data i externa cacheminnen, till exempel Azure Managed Redis. Externa cacheminnen är optimerade för datahämtning med låg latens, samtidigt som tillståndet isoleras från beräkningsresurserna så att de kan skalas och hanteras separat. I många lösningar kan du med externa cacheminnen förbättra programmets prestanda, samtidigt som du håller beräkningsnivån tillståndslös.

Viktig

Undvik att läcka data mellan klienter när du använder minnesinterna cacheminnen eller andra komponenter som underhåller tillståndet. Överväg till exempel att lägga till en klientidentifierare för alla cachenycklar för att säkerställa att data separeras för varje klientorganisation.

Isolering

När du utformar en beräkningsnivå för flera klienter har du flera alternativ för klientisolering. Du kan distribuera delade beräkningsresurser för alla klienter, dedikerade beräkningsresurser för enskilda klientorganisationer eller en halvisolerad metod som faller mellan dessa ytterligheter. Varje alternativ har kompromisser. Om du vill hjälpa dig att avgöra vilket alternativ som passar bäst för din lösning bör du överväga dina krav på isolering.

Du kanske är orolig för den logiska isoleringen av hyresgäster och hur du separerar ansvarsområden eller policyer som tillämpas på varje hyresgäst. Du kan också behöva distribuera distinkta resurskonfigurationer för specifika klienter, till exempel distribuera en specifik SKU för virtuella datorer (VM) som passar en klientorganisations arbetsbelastning.

Beroende på vilken isoleringsmodell du väljer kontrollerar du att klientdata förblir korrekt isolerade, även om komponentfel eller avbrott inträffar. Överväg att använda Azure Chaos Studio i din regelbundna automatiserade testprocess för att införa fel som simulerar verkliga avbrott. Den här testningen hjälper dig att kontrollera att din lösning upprätthåller korrekt klientisolering och fortsätter att fungera under press.

Metoder och mönster att tänka på

Automatisk skalning

Azure-beräkningstjänster tillhandahåller olika funktioner som skalar arbetsbelastningar. Många beräkningstjänster stöder automatisk skalning, vilket kräver att du avgör när du ska skala och ange lägsta och högsta skalningsnivåer. De specifika skalningsalternativen beror på de beräkningstjänster som du använder. Se följande exempel på tjänster eller komponenter:

Mönster för distributionsstämplar

Mer information om hur du kan använda mönstret Distributionsstämplar för att stödja en lösning med flera klientorganisationer finns i Arkitekturmetoder för en lösning med flera klientorganisationer.

Mönster för konsolidering av beräkningsresurser

Konsolideringsmönstret för beräkningsresurser hjälper dig att uppnå en högre densitet av användare i beräkningsinfrastrukturen genom att dela de underliggande beräkningsresurserna. Genom att dela beräkningsresurser kan du minska den direkta kostnaden för dessa resurser. Dessutom är dina hanteringskostnader ofta lägre eftersom det finns färre komponenter att hantera.

Konsolidering av beräkningsresurser ökar dock sannolikheten för problem med den bullriga grannen. En hyresgästs arbetsbelastning kan förbruka en oproportionerlig mängd av den tillgängliga beräkningskapaciteten. Du kan ofta minska den här risken genom att se till att du skalar din lösning på rätt sätt och genom att använda kontroller som kvoter och API-gränser för att undvika klienter som förbrukar mer än sin beskärda del av kapaciteten.

Det här mönstret uppnås på olika sätt, beroende på vilken beräkningstjänst du använder. Se följande exempel på tjänster eller komponenter:

  • App Service och Azure Functions: Distribuera delade App Service-planer som representerar värdserverinfrastrukturen.

  • Containerapplikationer: Distribuera delade miljöer.

  • AKS: Distribuera delade poddar med en multitenancy-medveten applikation.

  • Vms: Distribuera en enda uppsättning virtuella datorer som alla klienter kan använda.

Dedikerade beräkningsresurser för varje klientorganisation

Du kan också distribuera dedikerade beräkningsresurser för varje klientorganisation. Dedikerade resurser minskar risken för problem med den bullriga grannen genom att se till att beräkningsresurserna för varje klientorganisation är isolerade från de andra. Du kan också distribuera en distinkt konfiguration för varje klientorganisations resurser baserat på deras krav. Dedikerade resurser medför dock vanligtvis en högre kostnad eftersom du har en lägre densitet för klienter till resurser.

Beroende på vilka Azure-beräkningstjänster du använder kan du behöva distribuera olika dedikerade resurser:

  • App Service och Azure Functions: Distribuera separata App Service-planer för varje klientorganisation.

  • Containerappar: Distribuera separata miljöer för varje hyresgäst.

  • AKS: Distribuera dedikerade kluster för varje klientorganisation.

  • Vms: Distribuera dedikerade virtuella datorer för varje klientorganisation.

Fysisk isolering på värdnivå kan också tillhandahållas genom att köra virtuella klientdatorer på dedikerade Azure-värdar, som reserverar en hel fysisk server för en enskild kund. Den här metoden är dock vanligtvis dyrare än att använda delade värdar.

Halvisolerade beräkningsresurser

Halvisolerade metoder kräver att du distribuerar aspekter av lösningen i en isolerad konfiguration medan du delar de andra komponenterna.

När du använder App Service och Azure Functions kan du distribuera olika program för varje klientorganisation och vara värd för programmen i delade App Service-planer. Den här metoden minskar kostnaden för din beräkningsnivå eftersom App Service-planer representerar en faktureringsenhet. Du kan också använda olika konfigurationer och principer för varje program. Den här metoden medför dock risken för problem med den bullriga grannen.

Du kan använda Container Apps för att distribuera flera program till en delad miljö och sedan använda Dapr och andra verktyg för att konfigurera varje program separat.

AKS och Kubernetes, mer generellt, ger olika alternativ för multitenanslösningar:

  • Klientspecifika namnområden som kan ge logisk isolering av klientspecifika resurser, som distribueras till delade kluster och nodpooler

  • Klientspecifika noder eller nodpooler i ett delat kluster

  • Klientspecifika poddar som kan utnyttja samma nodpool

Du kan också använda AKS för att tillämpa styrning på poddnivå för att minska problemet med den bullriga grannen. Mer information finns i Metodtips för programutvecklare för att hantera resurser i AKS.

Det är också viktigt att vara medveten om delade komponenter i ett Kubernetes-kluster och hur flera klientorganisationer kan påverka dessa komponenter. Kubernetes API-servern är till exempel en delad tjänst som används i hela klustret. Även om du tillhandahåller klientspecifika nodpooler för att isolera klientorganisationens programarbetsbelastningar kan API-servern uppleva konkurrens från ett stort antal begäranden mellan klienterna.

Antimönster att undvika

Undvik följande antimönster.

Antimönstret störande granne

När du distribuerar komponenter som hyresgäster delar, finns det en potentiell risk för bullrig granneproblematik. Se till att du inkluderar resursstyrning och övervakning för att minska risken för att andra klientorganisationers aktivitet påverkar en klients beräkningsarbetsbelastning.

Dataläckage mellan klientorganisationer

Beräkningsnivåer kan utsättas för dataläckage mellan klientorganisationer om de inte hanteras korrekt. Den här risken är vanligtvis inte något som du behöver tänka på när du använder en tjänst för flera klientorganisationer i Azure eftersom Microsoft tillhandahåller skydd på plattformsnivå. Men när du utvecklar ett eget program för flera klienter bör du överväga om delade resurser, till exempel lokala diskcacheminnen, RAM-minne och externa cacheminnen, kan innehålla data som en annan klientorganisation av misstag kan visa eller ändra.

Intensivt frontend-antimönster

För att undvika antimönstret Upptagen frontend kontrollerar du att klientdelsnivån inte utför det mesta av det arbete som andra komponenter eller nivåer i arkitekturen kan hantera. Det här dåliga mönstret är särskilt viktigt när du skapar delade gränssnitt för en lösning med flera klienter, eftersom ett överbelastat gränssnitt försämrar upplevelsen för alla användare.

Överväg i stället att använda asynkron bearbetning med hjälp av köer eller andra meddelandetjänster. Med den här metoden kan du också använda QOS-kontroller (Quality of Service) för olika klienter baserat på deras krav. Till exempel kan alla hyresgäster dela en gemensam front-end nivå, men hyresgäster som betalar för en högre tjänstnivå kan ha fler dedikerade resurser för att bearbeta arbetet från sina kömeddelanden.

Oelastisk eller otillräcklig skalning

Lösningar för flera hyresgäster utsätts ofta för plötsliga skalningsmönster. Delade komponenter är särskilt sårbara för det här problemet eftersom omfånget för burst är högre och effekten är större när du har fler klienter som har distinkta användningsmönster.

Se till att du drar nytta av molnets elasticitet och skala. Överväg om du ska använda horisontell eller lodrät skalningoch använd automatisk skalning för att automatiskt hantera toppar i belastningen. Testa din lösning för att förstå hur den fungerar under olika belastningsnivåer. Se till att du inkluderar de belastningsvolymer som förväntas i produktionen och din förväntade tillväxt. Du kan använda en fullständigt hanterad tjänst, till exempel belastningstestning, för att lära dig hur ditt program fungerar under stress.

Ingen cache-antimönster

Antimönstret Ingen cachelagring är när lösningens prestanda påverkas eftersom programnivån upprepade gånger begär eller omberäknar information som kan återanvändas mellan begäranden. Om du har data som kan delas, antingen mellan klientorganisationer eller mellan användare i en enda klientorganisation, är det troligtvis värt att cachelagra dem för att minska belastningen på serverdels- eller databasnivån.

Onödig tillståndsfullhet

Implikationen av antimönstret Ingen cachelagring är att du också bör undvika att lagra onödigt tillstånd på beräkningsnivån. Var tydlig med var du hanterar tillstånd och varför. Tillståndskänsliga klientdels- eller programnivåer kan minska möjligheten att skala. Tillståndskänsliga beräkningsnivåer kräver vanligtvis också sessionstillhörighet, vilket kan minska din möjlighet att effektivt belastningsbalansera trafik mellan arbetare eller noder.

Överväg kompromisserna för varje tillstånd som du underhåller på beräkningsnivån och om det påverkar din förmåga att skala eller växa när klientorganisationens arbetsbelastningsmönster ändras. Du kan också lagra tillstånd i en extern cache, till exempel Azure Managed Redis.

Bidragsgivare

Microsoft ansvarar för den här artikeln. Följande deltagare skrev den här artikeln.

Huvudförfattare:

  • Dixit Arora | Senior kundtekniker, FastTrack för Azure
  • John Downs | Principal Software Engineer, Azure Patterns &Practices

Andra deltagare:

Om du vill se linkedin-profiler som inte är offentliga loggar du in på LinkedIn.

Granska tjänstspecifik vägledning för dina beräkningstjänster: