Mönster för begränsning

Begränsa förbrukningen av resurser i en instans av ett program, en enskild klientorganisation eller i hela tjänsten. Det kan göra att systemet kan fortsätta att fungera och uppfylla serviceavtal, även när en ökad efterfrågan innebär en extrem belastning på resurser.

Kontext och problem

Belastningen på ett molnprogram varierar vanligtvis över tid baserat på antalet aktiva användare eller vilka typer av aktiviteter de utför. Till exempel är sannolikt fler användare aktiva under kontorstid eller så måste kanske systemet utföra beräkningsmässigt dyra analyser i slutet av varje månad. Det kan också förekomma plötsliga och oförutsedda ökningar av aktivitet. Om systemets behandlingskrav överskrider kapaciteten för de resurser som är tillgängliga leder det till sämre prestanda och eventuellt även avbrott. Om systemet måste uppfylla en överenskommen servicenivå kan sådana avbrott vara oacceptabla.

Det finns många strategier för hantering av varierande belastning i molnet, beroende på affärsmålen för programmet. En strategi är att använda autoskalning för att matcha de etablerade resurserna med användarbehoven vid en given tidpunkt. Det har potential att konsekvent uppfylla användarbehov, samtidigt som löpande kostnader optimeras. Autoskalning kan utlösa etablering av ytterligare resurser, men etableringen sker inte omedelbart. Om efterfrågan ökar snabbt kan det uppstå en tidsperiod med ett resursunderskott.

Lösning

En annan strategi för autoskalning är att tillåta program att endast använda resurser upp till en gräns och sedan begränsa dem när gränsen har nåtts. Systemet bör övervaka hur resurser används så att förfrågningar från en eller flera användare kan begränsas när användningen överskrider tröskelvärdet. Det gör att systemet kan fortsätta att fungera och uppfylla tillämpliga serviceavtal (SLA). Mer information om övervakning av resursanvändning finns i Vägledning om instrumentation och telemetri.

Systemet kan implementera flera begränsningsstrategier, bland annat:

• Avvisa förfrågningar från en enskild användare som redan har anslutit till system-API:er fler än n gånger per sekund under en viss tidsperiod. Det kräver att systemet mäter användningen av resurser för varje klientorganisation eller användare som kör ett program. Mer information finns i Vägledning om tjänstmätning.

• Inaktivera eller försämra funktionen för valda oviktiga tjänster så att viktiga tjänster kan köras obehindrat med tillräckliga resurser. Om programmet till exempel strömmar videoutdata kan det växla till en lägre upplösning.

• Använda belastningsutjämning för att jämna ut aktivitetsvolymen (den här metoden beskrivs i mer detalj i Mönster för köbaserad belastningsutjämning). I en miljö med flera klientorganisationer minskar den här metoden prestanda för varje klientorganisation. Om systemet måste kunna hantera en blandning av klientorganisationer med olika serviceavtal kan arbetet för klientorganisationer med högt värde utföras direkt. Förfrågningar för andra klientorganisationer kan hållas tillbaka och hanteras när kvarvarande uppgifter har minskat. Mönstret för prioritetskö kan användas för att implementera den här metoden.

• Skjuta upp åtgärder som utförs åt program eller klientorganisationer med lägre prioritet. De här åtgärderna kan inaktiveras eller begränsas, med ett undantag som genereras för att meddela klientorganisationen att systemet är upptaget och att åtgärden bör försökas igen senare.

Bilden visar ett ytdiagram för resursanvändning (en kombination av minne, CPU, bandbredd och andra faktorer) mot tid för program som använder tre funktioner. En funktion är exempelvis en komponent som utför en specifik uppsättning uppgifter, ett kodavsnitt som utför en komplicerad beräkning eller ett element som tillhandahåller en tjänst, till exempel en minnescache. De här funktionerna är märkta med A, B och C.

Området direkt nedanför linjen för en funktion visar de resurser som används av program när de anropar den här funktionen. Området nedanför linjen för funktion A visar till exempel de resurser som används av program som använder funktion A, och området mellan linjerna för funktion A och funktion B visar de resurser som används av program som anropar funktion B. En sammanställning av områdena för varje funktion visar systemets totala resursanvändning.

Föregående bild illustrerar effekterna av att skjuta upp åtgärder. Precis före tid T1 når de totala resurserna som allokerats till alla program som använder de här funktionerna ett tröskelvärde (gränsen för resursanvändning). Programmen riskerar då att få slut på tillgängliga resurser. I det här systemet är funktion B mindre viktig än funktion A och funktion C, så den inaktiveras tillfälligt och de resurser som den använde frisläpps. Mellan tid T1 och T2 fortsätter programmen som använder funktion A och funktion C att köras som vanligt. Slutligen minskar resursanvändningen för de här två funktionerna tills det, vid tid T2, finns tillräckligt med kapacitet för att aktivera funktion B igen.

Metoderna för autoskalning och begränsning kan även kombineras för att programmen ska fortsätta vara responsiva och uppfylla serviceavtal. Om efterfrågan förväntas vara fortsatt hög ger begränsning en tillfällig lösning medan systemet skalas ut. I det här läget kan alla funktioner i systemet återställas.

På nästa bild visas ett ytdiagram över övergripande resursanvändning av alla program som körs i ett system mot tid. Det illustrerar hur begränsning kan kombineras med autoskalning.

Vid tid T1 nås tröskelvärdet som anger den mjuka gränsen för resursanvändning. I det här läget kan systemet börja skala ut. Men om de nya resurserna inte blir tillgängliga tillräckligt snabbt kan de befintliga resurserna bli uttömda och systemet kan misslyckas. För att förhindra att det inträffar begränsas systemet tillfälligt, enligt beskrivningen ovan. När autoskalning har slutförts och ytterligare resurser finns tillgängliga kan begränsning minskas.

Problem och överväganden

När du bestämmer hur det här mönstret ska implementeras bör du överväga följande punkter:

• Begränsning av ett program, och vilken strategi som ska användas, är ett arkitekturbeslut som påverkar hela designen av ett system. Begränsning bör övervägas tidigt i programdesignprocessen eftersom det inte är lätt att lägga till när ett system har implementerats.

• Begränsning måste utföras snabbt. Systemet måste kunna upptäcka en ökning av aktivitet och reagera utifrån den. Systemet måste också kunna återgå till det ursprungliga tillståndet snabbt när belastningen har minskat. Det kräver att lämpliga prestandadata kontinuerligt samlas in och övervakas.

• Om en tjänst måste neka en användarförfrågan tillfälligt bör den returnera en specifik felkod så att klientprogrammet förstår att orsaken till nekandet att utföra en åtgärd beror på begränsning. Klientprogrammet kan vänta en stund innan ett nytt försök görs med förfrågan.

• Begränsning kan användas som en tillfällig åtgärd när ett system autoskalas. I vissa fall är det bättre att begränsa, i stället för att skala, om en ökning av aktivitet är plötslig och inte förväntas vara länge eftersom skalning kan öka löpande kostnader betydligt.

• Om begränsning används som en tillfällig åtgärd när ett system autoskalas, och om resursbehoven växer mycket snabbt, kanske systemet inte kan fortsätta att fungera – även när det används i ett begränsat läge. Om det inte är acceptabelt bör du överväga att ha större kapacitetsreserver och konfigurera aggressivare autoskalning.

När du ska använda det här mönstret

Använd det här mönstret:

• För att säkerställa att ett system fortsätter att uppfylla serviceavtal.

• För att förhindra att en enskild klientorganisation använder alla resurser som tillhandahålls av ett program.

• För att hantera ökningar av aktivitet.

• För att kostnadsoptimera ett system genom att begränsa de maximala resursnivåer som krävs för att det ska fungera.

Exempel

Den sista bilden illustrerar hur begränsning kan implementeras i ett system med flera klientorganisationer. Användare från varje klientorganisation ansluter till ett molnbaserat program där de fyller i och skickar undersökningar. Programmet innehåller instrumentation som övervakar den frekvens med vilken de här användarna skickar förfrågningar till programmet.

För att förhindra att användarna från en klientorganisation påverkar programmets svarstider och tillgänglighet för alla andra användare tillämpas en gräns för antalet förfrågningar per sekund som användarna från en klientorganisation kan skicka. Programmet blockerar förfrågningar som överskrider den här gränsen.

Nästa steg

Följande riktlinjer kan också vara relevanta när du implementerar det här mönstret:

• Vägledning kring instrumentation och telemetri. Begränsning beror på insamling av information om hur mycket en tjänst används. Beskriver hur du genererar och samlar in anpassad övervakningsinformation.
• Vägledning om tjänstmätning. Beskriver hur du mäter användningen av tjänster för att få en förståelse för hur de används. Den här informationen kan vara användbar när du fastställer hur du ska begränsa en tjänst.
• Vägledning för automatisk skalning. Begränsning kan användas som en interimåtgärd när ett system autoskalas, eller för att ett system inte ska behöva autoskalas. Innehåller information om strategier för autoskalning.

Närliggande information

Följande mönster kan också vara relevanta när du implementerar det här mönstret:

• Mönster för köbaserad belastningsutjämning. Köbaserad belastningsutjämning är en mekanism som ofta används för implementering av begränsning. En kö kan fungera som en buffert som jämnar ut den frekvens med vilken förfrågningar som skickas av ett program levereras till en tjänst.
• Mönstret Prioritetskö. Ett system kan använda prioritetskö som en del av sin begränsningsstrategi för att upprätthålla prestanda för kritiska program eller program med högre värde, samtidigt som prestanda minskar för mindre viktiga program.