Begränsningsmönster

Begränsa de resurser som en programinstans, en enskild klientorganisation eller en hel tjänst kan använda. På så sätt kan systemet fungera och uppfylla sina servicenivåmål (SLO) under plötslig eller ihållande belastning.

Kontext och problem

Belastningen på ett molnprogram varierar över tid baserat på aktiva användare och deras aktivitet. Fler användare loggar in under kontorstid och systemet kör beräkningsmässigt dyra analyser i slutet av varje månad. Plötsliga utbrott inträffar också. Om bearbetningsbehovet överskrider den tillgängliga kapaciteten saktar systemet ned eller misslyckas. Om systemet har en överenskommen servicenivå innebär det felet en överträdelse av servicenivåmålet.

Flera strategier hanterar varierande belastning, beroende på programmets affärsmål. En strategi är automatisk skalning, som matchar etablerade resurser med aktuell efterfrågan och styr kostnaden. Men etablering av nya resurser tar tid och lägger till kostnader. Efterfrågan som överskrider kapacitetstillväxten eller budgeten skapar ett resursunderskott.

Lösning

Ett alternativ till automatisk skalning är att begränsa resursanvändning och begränsa begäranden när användningen överskrider det taket. Arbetsbelastningen övervakar sin egen resursanvändning och begränsar begäranden från en eller flera användare när användningen överskrider tröskelvärdet. Systemet fortsätter att fungera och uppfylla sina SLO:er.

Strypning är en reglerslinga, inte ett enskilt beslut om att släppa igenom. Systemet behöver signaler med låg svarstid i tre lager: infrastrukturanvändning, programtillstånd och räknare per huvudnamn. Den mäter kontinuerligt mättnad, tillämpar gränser vid väldefinierade gränser och anpassar dessa gränser när trafikmönstren ändras. Överlagring är ett normalt driftsläge som ett moget system identifierar och återställer från. Begränsning ger självbevarande funktioner i din arbetsbelastning.

Systemet kan tillämpa flera strypnings- eller relaterade strategier:

• Frekvensgränser per huvudnamn: Avvisa begäranden från en användare som redan har överskridit den konfigurerade hastigheten under ett definierat fönster. Denna strategi kräver att systemet kopplar varje begäran till en identitet och mäter resursanvändningen mot den identiteten. För arbetsbelastningar för flera klientorganisationer, se Mäta konsumtionen för varje klientorganisation.

• Graciös funktionsförsämring: Inaktivera eller försämra icke-nödvändiga funktioner så att viktiga funktioner har tillräckligt med resurser. Den här strategin offrar fullständiga svar för högre tillgänglighet. Till exempel kan ett videoströmningsprogram sjunka till en lägre upplösning.

• Belastningsutjämning: Jämna ut aktivitetsvolymen med hjälp av en kö. I en miljö med flera klienter minskar utjämning prestandan för varje klientorganisation. När hyresgäster har olika servicenivåavtal (SLA:er) ska du hantera arbete för hyresgäster med högt värde omedelbart och vänta med arbete med lägre prioritet tills arbetskön minskar. Implementera den här metoden med hjälp av mönstret Prioritetskö eller genom att exponera separata slutpunkter för varje prioritetsnivå.

• Prioritetsbaserad uppskjutning: Skjut upp åtgärder för program eller klientorganisationer med lägre prioritet. Avbryt eller begränsa operationer och returnera ett undantag som anger att klientorganisationen ska försöka igen senare.

• Utgående hastighetsgränser: Begränsa dina egna utgående anrop när ett externt beroende misslyckas eller returnerar fel. Minska antalet förfrågningar under flygning för att stoppa översvämningsloggar och för att undvika återförsökskostnader mot ett felfritt beroende. Återställ det normala begärandeflödet när beroendet har återställts. Till exempel implementerar NServiceBus den här funktionen.

Följande diagram visar resursanvändning (en kombination av minne, PROCESSOR, bandbredd och andra faktorer) över tid för ett program som använder tre funktioner, märktA, B och C. En funktion är ett specifikt funktionsområde, till exempel en komponent som utför en specifik uppsättning uppgifter, en kod som utför en komplex beräkning eller ett element som tillhandahåller en tjänst, till exempel en minnesintern cache.

Diagrammet är ett staplat ytdiagram. Området under funktion A:s rad visar de resurser som funktion A förbrukar, området mellan raderna funktion A och funktion B visar de resurser som funktion B förbrukar och området mellan raderna funktion B och funktion C visar de resurser som funktion C förbrukar. Funktion C:s linje ligger överst i stacken, så den visar även total användning av systemresurser över tid.

Diagrammet visar en gradvis försämring av funktionaliteten. Strax före tid T1 närmar sig den totala resursanvändningen tröskelvärdet och riskerar att uttömma tillgänglig kapacitet. Funktion B är mindre kritisk än funktion A eller funktion C, så systemet stänger av funktion B och släpper sina resurser. Mellan gångerna T1 och T2 fortsätter funktion A och funktion C normalt. Efter tid T2 minskar den totala resursanvändningen tillräckligt för att aktivera funktion B igen.

Du kan kombinera autoskalning, kontrollerad degradering och strypning för att hålla applikationer responsiva och inom SLA:er. När du förväntar dig att efterfrågan ska förbli hög upprätthåller strypning stabiliteten medan systemet skalas ut. När skalningen har slutförts återställer systemet full funktionalitet.

Nästa diagram visar den totala resursanvändningen över tid och hur strypning samverkar med automatisk skalning och andra kompenserande styrmekanismer.

Vid tidpunkten för T1 når systemet den mjuka gränsen och börjar skala ut. Om nya resurser inte tas emot i tid kan efterfrågan uttömma befintliga resurser och systemet kan misslyckas. Strypning avvisar för många begäranden vid uppskalning för att hålla resursanvändningen under den hårda gränsen och häver sedan dessa begränsningar när ny kapacitet blir tillgänglig.

Problem och överväganden

Tänk på följande när du bestämmer hur du ska implementera det här mönstret:

• Fatta beslut om begränsning tidigt. Strypning är ett arkitekturbeslut som påverkar hela systemet. Att eftermontera det senare är dyrt.

• Anpassa begränsningsgränserna efter den komponent som först blir fullt utnyttjad.

  Begärandefrekvensen är den mest välbekanta dimensionen att begränsa, men den verkliga flaskhalsen är ofta samtidiga förfrågningar under flygning, ködjup, PROCESSOR- eller minnesanvändning eller ett underordnat beroendes egna gränser. En gräns för förfrågningar per sekund skyddar inte ett system vars flaskhals är samtidiga förfrågningar vid en förgreningspunkt.

  Vid varje gräns där begränsning tillämpas, till exempel gatewayen, tjänsten, en partition eller ett nedströmsberoende, identifiera vilken resurs som först blir mättad och sätt gränsen för den dimensionen. För skydd med begränsad samtidighet vid fan-out-punkter, se Bulkhead-mönstret, som kompletterar begränsning av genomströmning.

• Välj en begränsande algoritm avsiktligt. Matcha den med toleransen för den komponent som du skyddar.

  Algorithm	Beteende och bästa passform
  Token-bucket	Stöder bursts upp till en konfigurerad storlek och framtvingar en stadig påfyllningshastighet. Används för gatewayer som behöver absorbera korta toppar.
  Läckande bucket	Avger med konstant hastighet. Använd för backend-system som behöver en jämn inkommande trafik.
  Fast fönster	Enkelt att implementera, men medger burstar i direkt följd vid fönstergränser.
  Skjutfönster	Jämnar ut fönstergränsproblemet för fasta fönster på bekostnad av mer tillståndsinformation.

• Bestäm vem gränsen påverkar. Begränsning av trafik på en övergripande nivå, till exempel i en regional gateway, kan påverka många oberoende användare när det bara är ett fåtal av dem som orsakar belastningen.

• Bestäm var räknaren finns när en gräns sträcker sig över flera noder. Lokala räknare är snabba men underskattar antalet när samma klient når flera repliker. En centraliserad räknare i ett delat arkiv som Redis ser varje begäran men lägger till svarstid för varje beslut. Om du vill approximera en global hastighet delar du upp gränsen över replikerna och stämmer av med jämna mellanrum.

• Fatta beslut om begränsning snabbt. Systemet måste identifiera ökande belastning, reagera och återgå till det normala när belastningen har minskat. Den här processen kräver kontinuerlig prestandainstrumentation.

• Kasta belastning proaktivt, inte vid kanten av kollapsen. En strypning som börjar avvisa först efter att en komponent har nått kapacitetstaket får svarstiden att skjuta i höjden innan anropande klienter märker något baktryck.

  När användningen närmar sig den hårda gränsen börjar du avvisa en växande del av begäranden. Tidiga avvisningssignaler får anropare att backa och förhindrar den latenskollaps som tvära begränsningar ofta utlöser. Använd p99-svarstid mot ditt SLO som primär utlösare. Det genomsnittliga resursutnyttjandet kan se bra ut samtidigt som p99 redan har överskridit gränsvärdet.

  Där du kan skilja mellan förfrågningars värde bör du först välja bort arbete med lägre värde eller arbete som lättare kan köras om. Mer information finns i mönstret Prioritetskö.

• Returnera en statuskod som anger för klienten när en tillfällig avvisning beror på begränsning av begärandefrekvensen:

  • HTTP 429 (för många begäranden): Anroparen överskrider en konfigurerad begärandefrekvens över ett definierat fönster.
  • HTTP 503 (tjänsten är inte tillgänglig): Tjänsten kan inte hantera begäran just nu, ofta på grund av en oväntad belastningstoppar.

  Inkludera ett Retry-After HTTP-huvud så att klienten kan välja en återförsöksstrategi. Returnera tillräckligt med kontext för att anroparen ska kunna försöka igen avsiktligt i stället för att gissa. Namnge till exempel den gräns som anroparen överskrider, klargöra det berörda omfånget eller föreslå en hastighet som skulle lyckas. Oförklarliga avslag hjälper inte uppringare att anpassa sig.

• Vidarebefordra överbelastningssignaler från dina beroenden i stället för att absorbera dem. En tjänst som begränsar anropshastigheten för sina anropare måste också respektera de begränsningssvar som den får från sina egna nedströmsberoenden. Om tjänsten döljer ett 429- eller 503-svar från en underliggande tjänst genom att göra tysta omförsök eller genom att returnera ett generiskt HTTP 500-svar (Internal Server Error), kan anropare inte sänka takten, omförsöken ökar och överbelastningen fortplantar sig tillbaka uppströms. Antimönstret Retry Storm beskriver det här felläget. Förmedla bakåttryck till anropare uppströms så att hela anropskedjan minskar belastningen tillsammans.

• Gör avslag billigare än det arbete som det förhindrar. Om nekande av en begäran kräver omfattande autentisering, djup parsning eller komplex principutvärdering kan en flod av avvisade begäranden fortfarande mätta systemet. Avvisa så tidigt som möjligt i begärandekedjan och belastningstesta själva avvisningsflödet.

• Planera för situationer där strypning inte kan ge tillräckligt med tid för automatisk skalning. Om efterfrågan växer snabbare än ny kapacitet tas i drift kan även ett strypt system fallera. När det resultatet är oacceptabelt behåller du större kapacitetsreserver och konfigurerar mer aggressiv autoskalning.

• Använd inte cachelagring i stället för strypning. En cache sänker den genomsnittliga belastningen på ursprunget men begränsar inte den högsta belastningen. Varje cachemiss går vidare till ursprungsservern, och när en populär nyckel löper ut vid hög belastning kan många anrop försöka fylla den igen. Använd cachelagring för att minska den normala belastningen och strypning för att begränsa utfallet i värsta fall. Mer information finns i mönstretCache-Aside.

• Normalisera resurskostnader för olika åtgärder eftersom de vanligtvis inte medför samma körningskostnader. Strypningsgränser kan till exempel vara högre för läsåtgärder och lägre för skrivåtgärder. Om du ignorerar kostnaden per åtgärd kan kapaciteten förbrukas och en attackvektor skapas.

• Gör att strypningskonfigurationen kan ändras vid körning. När onormal last uppstår behöver du justera gränsvärden utan driftsättning. Distributionerna är långsamma och riskfyllda under en incident. Mönstret Extern konfigurationslagring externaliserar konfigurationen så att du kan ändra den vid körning.

• Överväg anpassningsbara gränser i stället för statiska gränser. Vissa begränsnings-SDK:er reagerar på svarstider eller ködjupsignaler så att gränsen spårar faktiska komponentförhållanden. Kombinera alltid en adaptiv limiter med ett fastställt maxvärde.

• Gå tillbaka till dina gränser när arbetsbelastningen utvecklas. Anpassningsbara begränsare kan inte spåra alla typer av drift, till exempel SLO-ändringar, ändringar i beroendekapacitet eller förändringar i kostnaden per åtgärd. Schemalägg periodisk operatörsgranskning mot dessa indata.

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

Använd det här mönstret:

• För att hålla ett system inom sina SLO:er.

• För att förhindra att en enskild klientorganisation monopoliserar programresurser.

• För att hantera ökningar av aktivitet.

• Begränsa den maximala resursnivå som ett system behöver.

• För att minska lågvärdesberäkning under perioder med hög kolintensitet i rutnätet.

Design av arbetsbelastning

Utvärdera hur du kan använda strypningsmönstret i utformningen av en arbetsbelastning för att uppfylla de mål och principer som behandlas i grundpelarna i Azure Well-Architected Framework. Följande tabell innehåller vägledning om hur det här mönstret stöder målen för varje pelare.

Om detta mönster inför kompromisser inom en pelare bör du överväga dem mot målen för de andra pelarna.

Example

I följande diagram visas begränsningar i ett system med flera klientorganisationer.

Användare från flera klientorganisationer får åtkomst till ett molnbaserat program för att fylla i och skicka undersökningar. Programmet innehåller instrumentation som övervakar den hastighet med vilken varje klientorganisations användare skickar begäranden.

För att förhindra att användare från en klientorganisation försämrar svarstiden och tillgängligheten för användare i andra klientorganisationer begränsar programmet den frekvens för begäranden per sekund som en enskild klientorganisation kan skicka. Programmet blockerar förfrågningar som överskrider den här gränsen.

Nästa steg

• Arkitekturstrategier för att utforma ett övervakningssystem

Relaterade resurser

• Mäta förbrukningen för varje klientorganisation
• Automatisk skalning i Azure
• Mönster för köbaserad belastningsutjämning
• Mönster för prioritetskö
• Mönster för externt konfigurationsarkiv