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 innehavare drar ofta nytta av delade beräkningsresurser, eftersom en högre täthet av 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 flera klientorganisationer på beräkningstjänster, tillsammans med vissa antimönster att undvika.

Viktiga överväganden och krav

Flera klientorganisationer och den isoleringsmodell som 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 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. När antalet klienter och mängden trafik ökar kan du behöva öka resursernas kapacitet, hålla jämna resultat 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 klientorganisations resurser oberoende av varandra. Om du skalar resurserna i en lösning där beräkningsresurser delas mellan flera klientorganisationer kan alla dessa klienter använda den nya skalan. Men alla kommer också att drabbas 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 horisontellt eller lodrätt. I en flerklientlösning med ett växande antal klienter ger skalning horisontellt vanligtvis större flexibilitet och ett högre övergripande skalningstak.

Prestandaproblem förblir ofta oupptäckta 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 de utlösare 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 drabbas av problem med bullriga grannar. 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 inte några 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 din programnivå genom att minska antalet begäranden till serverdelslagringstjänster. När du till exempel använder ett minnesinternt cacheminne 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 betjänade en annan begäran.

I program som är känsliga för svarstid kan kostnaden för cachelagring bli betydande. En lösning för flera klientorganisationer 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 möjligheten för programnivån att använda sin 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 behåller beräkningsnivån tillståndslös.

Viktigt

Undvik att läcka data mellan klienter när du använder minnesintern cache eller andra komponenter som upprätthå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 klientorganisationer har du ofta många alternativ att överväga för isoleringsnivån mellan klienter, 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 har kompromisser. För att 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 för att passa en klientorganisations arbetsbelastning.

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

Metoder och mönster att tänka på

Automatisk skalning

Azures 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 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 för flera klientorganisationer finns i Översikt.

Mönster för konsolidering av beräkningsresurser

Mönstret för konsolidering av beräkningsresurser hjälper dig att uppnå en högre densitet för klientorganisationer till beräkningsinfrastrukturen 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 bullriga grannar. 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 tillämpa 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 den bullriga grannen genom att se till att beräkningsresurserna för varje klientorganisation är isolerade från de andra. Det gör det också möjligt att 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 måste du distribuera olika dedikerade resurser på följande sätt:

  • 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 distinkta program för varje klientorganisation och du kan vara värd för programmen på 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 bullriga grannar.

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å tillämpa styrning på poddnivå för att åtgärda 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 klienternas programarbetsbelastningar kan API-servern uppleva konkurrens från ett stort antal begäranden mellan klienterna.

Antimönster att undvika

Antimönstret Noisy Neighbor

När du distribuerar komponenter som delas mellan klienter är noisy neighbor-problemet 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 andra klientorganisationers aktivitet.

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 klientorganisationer bör du överväga om några 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 en stor del av arbetet som kan hanteras av andra komponenter eller nivåer i din arkitektur. Det här antimönstret är särskilt viktigt när du skapar delade klientdelar för en lösning för flera klientorganisationer, 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 tjänstkvalitetskontroller (QoS) för olika klienter baserat på deras krav. Alla klienter kan till exempel dela en gemensam klientdelsnivå, men klienter som betalar för en högre servicenivå 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 omfattas ofta av stora 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 horisontell 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 beter sig under olika belastningsnivåer. Se till att du inkluderar de belastningsvolymer som förväntas i produktion 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

Antimönstret Ingen cachelagring är när lösningens prestanda påverkas eftersom programnivån upprepade gånger begär eller beräknar om information som kan återanvändas mellan begäranden. Om du har data som kan delas, antingen mellan klienter 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åndskänslighet

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 klient- eller programnivåer kan minska din möjlighet att skala. Tillståndskänsliga beräkningsnivåer kräver vanligtvis också sessionstillhörighet, vilket kan minska din förmåga 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 Cache for Redis.

Deltagare

Den här artikeln underhålls av Microsoft. Den skrevs ursprungligen av följande deltagare.

Huvudförfattare:

  • Dixit Arora | Senior Customer Engineer, FastTrack för Azure
  • John Downs | Huvudkundstekniker, FastTrack för Azure

Andra deltagare:

Nästa steg

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