Antimönstret Noisy Neighbor
System med flera klienter delar resurser mellan klienter. Det innebär att en klients aktivitet kan ha en negativ inverkan på en annan klientorganisations användning av systemet.
Problembeskrivning
När du skapar en tjänst som ska delas av flera kunder eller klienter kan du skapa den för att vara multitenant . En fördel med system med flera klienter är att resurser kan poolas och delas mellan klienter. Detta resulterar ofta i lägre kostnader och förbättrad effektivitet. Men om en enskild klientorganisation använder en oproportionerlig mängd av de resurser som är tillgängliga i systemet kan systemets övergripande prestanda drabbas. Problemet med den störande grannen uppstår när en klients prestanda försämras på grund av aktiviteter i en annan klientorganisation.
Tänk dig ett exempel på ett system med flera klienter med två klienter. Användningsmönster för klient A och användningsmönster för klient B sammanträffar, vilket innebär att den totala resursanvändningen är högre vid hög belastning än kapaciteten i systemet:
Det är troligt att den klientorganisations begäran som ankom först har företräde och den andra klientorganisationen upplever ett problem med en störande granne. Båda klienterna kan också få prestandaförseningar.
Problemet med störningar uppstår även när varje enskild klientorganisation förbrukar relativt små mängder av systemets kapacitet, men den samlade resursanvändningen för många klienter resulterar i en topp i den totala användningen:
Detta kan inträffa när du har flera klienter som alla har liknande användningsmönster, eller när du inte har etablerat tillräckligt med kapacitet för den samlade belastningen på systemet.
Så åtgärdar du problemet
Störande angränsande problem är en inbyggd risk i system med flera datorer och det går inte att helt eliminera risken för att påverkas av en störande granne. Det finns dock vissa steg som både klienter och tjänstleverantörer kan vidta för att minska sannolikheten för problem med störningar, eller för att minska deras effekter när de observeras.
Åtgärder som klienter kan vidta
- Köp reserverad kapacitet, om tillgängligt. När du till exempel använder Cosmos DB köp reserverat dataflödeoch när du använder ExpressRoute ska du etablera separata kretsar för miljöer som är känsliga för prestanda.
- Migrera till en instans av tjänsten för en enskild klientorganisation eller till en tjänstnivå med starkare isoleringsgarantier. När du till exempel Service Bus till premiumnivånoch när du använder Azure Cache for Redis du en standard- eller premiumnivåcache.
- Se till att programmet hanterar tjänstbegränsning föratt minska onödiga begäranden till tjänsten.
Åtgärder som tjänstleverantörer kan vidta
- Övervaka resursanvändningen för ditt system, både övergripande och för varje klientorganisation. Konfigurera aviseringar för att identifiera toppar i resursanvändningen och om möjligt konfigurera automatisering för att automatiskt åtgärda kända problem genom att skala upp eller ut.
- Tillämpa resursstyrning för att undvika en enda klientorganisation som överväldigar systemet och minskar kapaciteten som är tillgänglig för andra. Detta kan ske i form av kvottvingande, via mönstret Begränsning eller mönstret Hastighetsbegränsning.
- Överväg att etablera mer infrastruktur. Det kan handla om att skala upp genom att uppgradera några av dina lösningskomponenter, eller att skala ut genom att etablera ytterligare shards, om du följer mönstret för horisontellpartitionering eller stämplar, om du följer mönstret distributionsstämplar.
- Överväg att tillåta klienter att köpa företablering eller reserverad kapacitet. Detta ger klienterna mer säkerhet att din lösning hanterar arbetsbelastningen på rätt sätt.
- Överväg metoder för att jämna ut resursanvändningen:
- Om du är värd för flera instanser av din lösning bör du överväga att balansera om klienterna mellan instanserna eller stämplarna. Överväg till exempel att placera klienter med förutsägbara och liknande användningsmönster över flera stämplar för att platta ut topparna i deras användning.
- Överväg om du har bakgrundsprocesser eller resursintensiva arbetsbelastningar som inte är tidskänsliga. Kör dessa asynkront vid låg belastning för att bevara din högsta resurskapacitet för tidskänsliga arbetsbelastningar.
- Överväg om dina tjänster tillhandahåller kontroller för att minimera problem med störningar. När du till exempel använder Kubernetes bör du överväga att använda poddbegränsningar, och när du använder Service Fabric bör du överväga att använda de inbyggda styrningsfunktionerna.
- Om det är tillämpligt bör du överväga att begränsa de åtgärder som klienter kan utföra. Du kan till exempel förhindra att klienter kör åtgärder som kör mycket stora databasfrågor. Detta minskar risken för att klienter vidtar åtgärder som kan påverka andra klienter negativt.
- Om det är tillämpligt bör du överväga att tillhandahålla ett QoS-system (Quality of Service). När du använder QoS prioriterar du vissa processer eller arbetsbelastningar före andra. Genom att ta med QoS i din design och arkitektur kan du se till att åtgärder med hög prioritet prioriteras när det är hög belastning på dina resurser.
Överväganden
- I de flesta fall innebär inte enskilda klienter att de orsakar problem med störningar. Enskilda klienter kanske inte ens är medvetna om att deras arbetsbelastningar orsakar problem med störningar för andra.
- Det är dock också möjligt att klienter använder sårbarheter i delade komponenter för att angripa en tjänst, antingen individuellt eller genom att köra en DDoS-attack (Distributed Denial of Service).
- Oavsett orsak är det viktigt att hantera dessa problem som resursstyrningsproblem och tillämpa användningskvoter, begränsningar och styrningskontroller för att minimera problemet.
Anteckning
Se till att du berättar för dina klienter om eventuella begränsningar som du tillämpar eller eventuella användningskvoter för din tjänst. Det är viktigt att de på ett tillförlitligt sätt hanterar misslyckade begäranden och att de inte är överaskad över eventuella begränsningar eller kvoter som du tillämpar.
Så identifierar du problemet
Ur en klients perspektiv visas problemet med den störande grannen vanligtvis som misslyckade serverbegäranden eller begäranden som tar lång tid att slutföra. I synnerhet, om samma begäran lyckas vid andra tillfällen och verkar misslyckas slumpmässigt, kan det finnas ett problem med en störande granne. Klientprogram bör registrera telemetri för att spåra lyckade och prestanda för begäranden till tjänster, och programmen bör även registrera prestandamått för baslinjen i jämförelsesyfte.
Ur en tjänsts perspektiv kan problemet med den störande grannen förekomma på flera sätt:
- Toppar i resursanvändningen. Det är viktigt att ha en tydlig förståelse för din normala baslinjeresursanvändning och att konfigurera övervakning och aviseringar för att identifiera toppar i resursanvändningen. Se till att du överväger alla resurser som kan påverka tjänstens prestanda eller tillgänglighet. Dessa omfattar mått som processor- och minnesanvändning för server, disk-I/S, databasanvändning, nätverkstrafik och mått som exponeras av hanterade tjänster, till exempel antalet begäranden och syntetiska och abstrakta prestandamått, till exempel Azure Cosmos DB-enheter för programbegäran.
- Fel vid utförande av en åtgärd för en klient, även om klientorganisationen inte använder en stor del av systemets resurser. Ett sådant mönster kan tyda på att klientorganisationen är offer för problemet med den störande grannen. Överväg att spåra resursförbrukningen efter klientorganisation. När du till exempel använder Azure Cosmos DB bör du överväga att logga de enheter för begäran som används för varje begäran och lägga till klientens identifierare som en dimension i telemetrin, så att du kan aggregera förbrukningen av enheter för begäran för varje klientorganisation.