Dela via

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

  • Artikel

De flesta molnbaserade lösningar består av beräkningsresurser av något slag, till exempel webb- och programnivåer, batchprocessorer, schemalagda jobb och till och med specialiserade resurser som GPU:er och högpresterande beräkning (HPC). Lösningar för flera klienter drar ofta nytta av delade beräkningsresurser, eftersom en högre densitet för klientorganisationer till infrastruktur minskar driftskostnaderna och hanteringen. Du bör överväga isoleringskraven och konsekvenserna av delad infrastruktur.

Den här artikeln innehåller vägledning om de överväganden och krav som är viktiga för lösningsarkitekter att tänka på när de planerar en beräkningsnivå för flera klienter. Detta inkluderar några vanliga mönster för att tillämpa multitenancy på beräkningstjänster, tillsammans med vissa antimönster att undvika.

Viktiga överväganden och krav

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

Skala

Systemen måste prestera tillräckligt under föränderlig efterfrågan. I takt med att antalet klienter och mängden trafik ökar kan du behöva öka kapaciteten för dina resurser, hålla jämna takten med det växande antalet klienter och upprätthålla en acceptabel prestandafrekvens. När antalet aktiva användare eller mängden trafik minskar bör du på samma sätt automatiskt minska beräkningskapaciteten för att minska kostnaderna, men du bör minska kapaciteten med minimal påverkan på användarna.

Om du distribuerar dedikerade resurser för varje klientorganisation har du flexibiliteten att skala varje klients resurser oberoende av varandra. Om du skalar resurserna i en lösning där beräkningsresurser delas mellan flera klienter kan alla dessa klienter använda den nya skalan om du skalar resurserna. Men alla drabbas också när skalan inte räcker till för att hantera den totala belastningen. Mer information finns i Problem med bullriga grannar.

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 med ett växande antal klienter ger skalning horisontellt vanligtvis 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 beter sig 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 arbetsbelastningsmönstren för varje klientorganisation som använder resurserna för att säkerställa att din etablerade kapacitet kan uppfylla den totala kapacitet som krävs och för att minimera risken för att en klientorganisation får 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 klienter kan du när du registrerar fler klienter planera att skala så att dina resurser fördubblas för varje ytterligare 100 klientorganisationer.

Tillstånd

Beräkningsresurser kan vara tillståndslösa eller tillståndskänsliga. 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, och de kan omedelbart börja bearbeta begäranden. Om arkitekturen tillåter det kan du också återanvända instanser som har tilldelats till en klientorganisation och allokera dem till en annan klientorganisation.

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

Tillfälligt tillstånd är ofta användbart för att förbättra prestanda för programnivån genom att minska antalet begäranden till serverdelslagringstjä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 använder vissa lösningar sessionstillhörighet för att säkerställa att alla begäranden för en specifik användare eller klientorganisation bearbetas av samma beräkningsarbetsnod. Även om sessionstillhörighet kan förbättra programnivåns möjlighet att använda dess cache effektivt, blir det också svårare att skala och balansera trafikbelastningen mellan arbetare. Denna kompromiss måste övervägas noggrant. För många program krävs inte sessionstillhörighet.

Det går också att lagra data i externa cacheminnen, till exempel Azure Cache for Redis. Externa cacheminnen är optimerade för datahämtning med låg fördröjning, samtidigt som tillståndet hålls isolerat 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.

Viktigt!

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 ofta många alternativ att överväga för isoleringsnivån mellan klientorganisationer, inklusive distribution av delade beräkningsresurser, som ska användas av alla klienter, dedikerade beräkningsresurser för varje klientorganisation eller något mellan dessa ytterligheter. Varje alternativ levereras med kompromisser. Om du vill hjälpa dig att avgöra vilket alternativ som passar din lösning bäst bör du överväga dina krav på isolering.

Du kanske bryr dig om logisk isolering av klienter och hur du separerar de hanteringsansvar eller principer som tillämpas på varje klientorganisation. Du kan också behöva distribuera distinkta resurskonfigurationer för specifika klienter, till exempel distribuera en specifik SKU för virtuella datorer som passar en klientorganisations arbetsbelastning.

Oavsett vilken isoleringsmodell du väljer kontrollerar du att klientdata förblir korrekt isolerade även när komponenter inte är tillgängliga eller inte fungerar. Överväg att använda Azure Chaos Studio som en del av den regelbundna automatiserade testningsprocessen för att avsiktligt införa fel som simulerar verkliga avbrott och kontrollera att din lösning inte läcker data mellan klienter och fungerar korrekt även under press.

Metoder och mönster att tänka på

Automatisk skalning

Azure-beräkningstjänster har olika funktioner för att skala dina arbetsbelastningar. Många beräkningstjänster stöder autoskalning, vilket kräver att du överväger när du ska skala och dina lägsta och högsta skalningsnivåer. Vilka specifika alternativ som är tillgängliga för skalning beror på vilka beräkningstjänster du använder. Se följande exempeltjänster:

Mönster för distributionsstämplar

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

Mönster för konsolidering av beräkningsresurser

Konsolideringsmönstret för beräkningsresurser hjälper dig att uppnå en högre densitet för klientorganisationer för att beräkna infrastruktur genom att dela de underliggande beräkningsresurserna. Genom att dela beräkningsresurser kan du ofta minska de direkta kostnaderna för dessa resurser. Dessutom är dina hanteringskostnader ofta lägre eftersom det finns färre komponenter att hantera.

Konsolideringen av beräkningsresurser ökar dock sannolikheten för problem med den bullriga grannen. Alla klientorganisationers arbetsbelastningar 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 exempeltjänster:

  • Azure App Service och Azure Functions: Distribuera delade App Service-planer som representerar värdserverinfrastrukturen.
  • Azure Container Apps: Distribuera delade miljöer.
  • Azure Kubernetes Service (AKS): Distribuera delade poddar med ett program med flera klientorganisationer.
  • Virtuella datorer: Distribuera en enda uppsättning virtuella datorer som alla klienter kan använda.

Dedikerade beräkningsresurser per klientorganisation

Du kan också distribuera dedikerade beräkningsresurser för varje klientorganisation. Dedikerade resurser minskar risken för problem med bullriga grannar 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 har 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 måste du distribuera olika dedikerade resurser enligt följande:

  • Azure App Service och Azure Functions: Distribuera separata App Service-planer för varje klientorganisation.
  • Azure Container Apps: Distribuera separata miljöer för varje klientorganisation.
  • Azure Kubernetes Service (AKS): Distribuera dedikerade kluster för varje klientorganisation.
  • Virtuella datorer: Distribuera dedikerade virtuella datorer för varje klientorganisation.

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 arbetar med App Service och Azure Functions kan du distribuera olika program för varje klientorganisation och du kan vara värd för programmen i delade App Service-planer. Den här metoden minskar kostnaden för beräkningsnivån eftersom App Service-planer representerar faktureringsenheten. 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.

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

Azure Kubernetes Service (AKS) och Kubernetes ger en mängd olika alternativ för flera klientorganisationer, inklusive följande:

  • Klientspecifika namnområden för logisk isolering av klientspecifika resurser som distribueras till delade kluster och nodpooler.
  • Klientspecifika noder eller nodpooler i ett delat kluster.
  • Klientspecifika poddar som kan använda samma nodpool.

MED AKS kan du också använda styrning på poddnivå för att minska problemet med bullriga grannar. Mer information finns i Metodtips för programutvecklare för att hantera resurser i Azure Kubernetes Service (AKS).

Det är också viktigt att vara medveten om delade komponenter i ett Kubernetes-kluster och hur dessa komponenter kan påverkas av flera klientorganisationer. 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

Störande antimönster för granne

När du distribuerar komponenter som delas mellan klienter är problemet Med bullriga grannar en potentiell risk. Se till att du inkluderar resursstyrning och övervakning för att minska risken för att en klients beräkningsarbetsbelastning påverkas av aktiviteten hos andra klienter.

Dataläckage mellan klientorganisationer

Beräkningsnivåer kan utsättas för dataläckage mellan klientorganisationer om de inte hanteras korrekt. Detta är vanligtvis inte något 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 oavsiktligt kan visa eller ändra.

Antimönster med upptagen klientdel

Undvik antimönstret Upptagen klientdel genom att undvika att klientdelsnivån utför mycket av det arbete som kan hanteras av andra komponenter eller nivåer i arkitekturen. Det här antimönstret är särskilt viktigt när du skapar delade klientdelar för en lösning med flera klienter, eftersom en upptagen klientdel försämrar upplevelsen för alla klienter.

Överväg i stället att använda asynkron bearbetning genom att använda köer eller andra meddelandetjänster. Med den här metoden kan du också tillämpa QoS-kontroller (Quality of Service) för olika klienter baserat på deras krav. Till exempel kan alla klienter dela en gemensam klientdelsnivå, men klienter som betalar för en högre tjänstnivå kan ha en högre uppsättning dedikerade resurser för att bearbeta arbetet från sina kömeddelanden.

Oelastisk eller otillräcklig skalning

Lösningar för flera klientorganisationer utsätts ofta för vågiga skalningsmönster. Delade komponenter är särskilt känsliga 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 med distinkta användningsmönster.

Se till att du använder molnets elasticitet och skala på ett bra sätt. Överväg om du ska använda vågrät eller lodrät skalning och använd autoskalning 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 Azure Load Testing, för att lära dig hur ditt program beter sig under stress.

Antimönstret Ingen cachelagring

Antipattern 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-/databasnivån.

Onödig tillståndsfullhet

Följden 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 underhåller 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 över 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 Cache for Redis.

Deltagare

Den här artikeln underhålls av Microsoft. Det har ursprungligen skrivits av följande medarbetare.

Huvudsakliga författare:

  • Dixit Arora | Senior kundtekniker, FastTrack för Azure
  • John Downs | Huvudprogramtekniker

Övriga medarbetare:

Nästa steg

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