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 tillgängliga strategier för att hantera varierande belastning i molnet, beroende på programmets affärsmål. En strategi är att använda autoskalning för att matcha de etablerade resurserna efter användarens behov vid en viss tidpunkt. Det har potential att konsekvent uppfylla användarbehov, samtidigt som löpande kostnader optimeras. Men även om automatisk skalning kan utlösa etablering av fler resurser, är den här etableringen inte omedelbar. 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. På så sätt kan systemet fortsätta att fungera och uppfylla alla serviceavtal (SLA) som finns på plats. 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 klienter minskar den här metoden prestandan 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 Prioritetskö kan användas för att implementera den här metoden, liksom att exponera olika slutpunkter för de olika tjänstnivåerna/prioriteringarna.
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.
Du bör vara försiktig när du integrerar med vissa tjänster från tredje part som kan bli otillgängliga eller returnera fel. Minska antalet samtidiga begäranden som bearbetas så att loggarna inte fylls i onödan med fel. Du kan också undvika de kostnader som är associerade med att i onödan försöka bearbeta begäranden som skulle misslyckas på grund av den tjänsten från tredje part. När begäranden bearbetas går du sedan tillbaka till vanlig ohroterad bearbetning av begäranden. Ett bibliotek som implementerar den här funktionen är NServiceBus.
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 förbli hög ger begränsning en tillfällig lösning medan systemet skalar ut. Nu kan systemets fullständiga funktioner å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. Nu kan systemet börja skalas ut. Men om de nya resurserna inte blir tillgängliga tillräckligt snabbt kan de befintliga resurserna vara 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 autoskalningen har slutförts och de extra resurserna är tillgängliga kan begränsningen vara avslappnad.
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 tillfälligt behöver neka en användarbegäran bör den returnera en specifik felkod som 429 ("För många begäranden") och 503 ("Servern är för upptagen") så att klientprogrammet kan förstå att orsaken till vägran att hantera en begäran beror på begränsning.
- HTTP 429 anger att det anropande programmet skickade för många begäranden i ett tidsfönster och överskred en förutbestämd gräns.
- HTTP 503 anger att tjänsten inte är redo att hantera begäran. Den vanligaste orsaken är att tjänsten har fler tillfälliga belastningstoppar än förväntat.
Klientprogrammet kan vänta en stund innan ett nytt försök görs med förfrågan. Ett Retry-After HTTP-huvud bör inkluderas för att stödja klienten i valet av strategi för återförsök.
Begränsning kan användas som en tillfällig åtgärd när ett system autoskalas. I vissa fall är det bättre att bara begränsa, snarare än att skala, om en aktivitetstoppar är plötslig och inte förväntas vara långlivade eftersom skalning kan öka driftskostnaderna avsevärt.
Om begränsning används som ett tillfälligt mått medan ett system autoskalning, och om resursbehoven ökar mycket snabbt, kanske systemet inte kan fortsätta att fungera , även när det körs 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.
Normalisera resurskostnader för olika åtgärder eftersom de vanligtvis inte medför samma körningskostnader. Begränsningar kan till exempel vara lägre för läsåtgärder och högre för skrivåtgärder. Att inte ta hänsyn till kostnaden för en åtgärd kan resultera i uttömd kapacitet och exponera en potentiell attackvektor.
Dynamisk konfigurationsändring av begränsningsbeteende vid körning är önskvärt. Om ett system står inför en onormal belastning som den tillämpade konfigurationen inte kan hantera kan begränsningsgränserna behöva öka eller minska för att stabilisera systemet och hålla jämna steg med den aktuella trafiken. Dyra, riskfyllda och långsamma distributioner är inte önskvärda just nu. Med hjälp av mönsterbegränsningskonfigurationen för det externa konfigurationsarkivet externaliseras och kan ändras och tillämpas utan distributioner.
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.
Design av arbetsbelastning
En arkitekt bör utvärdera hur begränsningsmönstret kan användas i arbetsbelastningens design för att uppfylla de mål och principer som beskrivs i grundpelarna i Azure Well-Architected Framework. Till exempel:
| Grundpelare | Så här stöder det här mönstret pelarmål |
|---|---|
| Beslut om tillförlitlighetsdesign hjälper din arbetsbelastning att bli motståndskraftig mot fel och se till att den återställs till ett fullt fungerande tillstånd när ett fel inträffar. | Du utformar gränserna för att förhindra resursöverbelastning som kan leda till fel. Du kan också använda det här mönstret som en kontrollmekanism i en graciös nedbrytningsplan. - RE:07 Självbevarande |
| Beslut om säkerhetsdesign bidrar till att säkerställa konfidentialitet, integritet och tillgänglighet för arbetsbelastningens data och system. | Du kan utforma gränserna för att förhindra resursöverbelastning som kan uppstå till följd av automatiserat missbruk av systemet. - SE:06 Nätverkskontroller - SE:08 Härdningsresurser |
| Kostnadsoptimering fokuserar på att upprätthålla och förbättra arbetsbelastningens avkastning på investeringen. | De framtvingade gränserna kan ligga till grund för kostnadsmodellering och kan till och med vara direkt knutna till programmets affärsmodell. De lägger också tydliga övre gränser på användningen, som kan räknas in i resursstorleken. - CO:02 Kostnadsmodell - KOSTNADER FÖR CO:12-skalning |
| Prestandaeffektivitet hjälper din arbetsbelastning att effektivt uppfylla kraven genom optimeringar inom skalning, data och kod. | När systemet är under hög efterfrågan hjälper det här mönstret till att minska överbelastningen som kan leda till flaskhalsar i prestanda. Du kan också använda den för att proaktivt undvika scenarier med bullriga grannar. - PE:02 Kapacitetsplanering - PE:05 Skalning och partitionering |
Som med alla designbeslut bör du överväga eventuella kompromisser mot målen för de andra pelarna som kan införas med det här mönstret.
Exempel
Den sista bilden visar 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 vägledning kan också vara relevant 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 om autoskalning. 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.
Relaterade resurser
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önster för 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.
- Mönster för externt konfigurationslager. Genom att centralisera och externalisera begränsningsprinciperna kan du ändra konfigurationen vid körning utan att behöva distribuera om. Tjänster kan prenumerera på konfigurationsändringar och därmed tillämpa den nya konfigurationen omedelbart för att stabilisera ett system.