Backpressure är inte en bugg: Det är en funktion för att bygga motståndskraftiga system

Backpressure är den dolda förhandlingarna mellan producenter och konsumenter. Behärska det, och dina system skalar graciöst. Ignorera det, och de krymper under toppbelastning.

Backpressure är den dolda förhandlingarna mellan producenter och konsumenter. Behärska det, och dina system skalar graciöst. Ignorera det, och de krymper under toppbelastning.

Ovanstående citat tyder på att även de mest robusta och välkonstruerade dammarna inte kan motstå de destruktiva krafterna hos en okontrollerad och okontrollerad översvämning.Distribuerat system, en okontrollerad uppringare kan ofta överväldiga hela systemet och orsaka kaskadermisslyckanden.

i aTidigare artikel, Jag skrev om hur en retry storm har potential att ta ner en hel tjänst om lämpliga vaktskärmar inte är på plats. här utforskar jag när en tjänst ska överväga att tillämpa baktryck på sina uppringare, hur det kan tillämpas och vad uppringare kan göra för att hantera det.

Backpressure

Som namnet antyder är backpress en mekanism i distribuerade system som hänvisar till ett systems förmåga att driva den hastighet vid vilken data förbrukas eller produceras för att förhindra överbelastning av sig själv eller dess nedströmskomponenter. Ett system som tillämpar backpress på sin uppringare är inte alltid explicit, som i form av driva eller lasta bort, men ibland också implicit, som att sakta ner sitt eget system genom att lägga till latens till förfrågningar som serveras utan att vara explicit om det.

Både implicit och explicit backpressur syftar till att sakta ner uppringaren, antingen när uppringaren inte beter sig bra eller tjänsten själv är ohälsosam och behöver tid att återhämta sig.

Need for Backpressure

I det här exemplet bygger vi en kontrollplanstjänst med tre huvudkomponenter: en frontend där kundförfrågningar tas emot, en intern kö där kundförfrågningar buffras och en konsumentapp som läser meddelanden från köen och skriver till en databas för uthållighet.

Producer-Consumer Mismatch

Tänk på ett scenario där aktörer / kunder träffar den främre änden med en sådan hög hastighet att antingen den interna köen är full eller arbetaren som skriver till databasen är upptagen, vilket leder till en full kö. I det fallet kan förfrågningar inte kvittas, så i stället för att släppa kundförfrågningar är det bättre att informera kunderna i förväg.

Resource Constraints and Cascading Failures

Föreställ dig ett scenario där din kö närmar sig 100% av sin kapacitet, men det är normalt vid 50%. För att matcha denna ökning i inkommande hastighet, du skalar upp din konsumentapp och börjar skriva till databasen med en högre hastighet.MTTRAtt tillämpa baktryck på lämpliga ställen blir kritiskt i sådana scenarier.

Missed SLAs

Tänk på ett scenario där data som skrivs till databasen bearbetas var femte minut och en annan applikation lyssnar för att hålla sig uppdaterad.Nu, om systemet inte kan uppfylla det SLA av någon anledning, som att köen är 90% full och potentiellt tar upp till 10 minuter att rensa alla meddelanden, är det bättre att tillgripa backpressure tekniker.

Du kan informera kunderna om att du kommer att missa SLA och be dem att försöka igen senare, eller tillämpa backpress genom att släppa icke-brådskande förfrågningar från köen för att möta SLA för kritiska händelser / förfrågningar.

Backpressure Challenges

Baserat på vad som beskrivs ovan verkar det som om vi alltid bör tillämpa backpress, och det borde inte finnas någon debatt om det.Om detvi bör tillämpa backpress, men mestadels runtHuridentifiera de rätta punkterna för att tillämpa backpress och mekanismerna för att tillämpa den som tillgodoser specifika servicebehov.

Backpressure tvingar en kompromiss mellan genomströmning och stabilitet, som görs mer komplicerad av utmaningen att förutsäga belastning.

Identifying the Backpressure Points

Find Bottlenecks/Weak Links

Tänk på ett system där en stor dataplanflotta (tusentals värdar) är beroende av en liten kontrollplanflotta (mindre än 5 värdar) för att få konfigurationer som kvarstår i databasen, som framgår av diagrammet ovan.

Den stora flottan kan lätt överväldiga den lilla flottan. I det här fallet, för att skydda sig, bör den lilla flottan ha mekanismer för att tillämpa baktryck på uppringaren. En annan vanlig svag länk i arkitektur är centraliserade komponenter som fattar beslut om hela systemet, som antientropiskannrar. Om de misslyckas kan systemet aldrig nå ett stabilt tillstånd och kan bryta ner hela tjänsten.

Use System Dynamics: Monitors/Metrics

Ett annat vanligt sätt att hitta backpress point för ditt system är att ha lämpliga monitorer/metriker på plats. Kontinuerligt övervaka systemets beteende, inklusive ködjup, CPU/minneutnyttjande och nätverksgenomströmning. Använd dessa realtidsdata för att identifiera framväxande flaskhalsar och justera backpress point i enlighet därmed.

Att skapa en aggregerad vy genom mätvärden eller observatörer som prestationskanaler över olika systemkomponenter är ett annat sätt att veta att ditt system är under stress och bör hävda backpress på sina användare/samtalare. Dessa prestationskanaler kan isoleras för olika aspekter av systemet för att hitta kvävningspunkterna.

Boundaries: The Principle of Least Astonishment

De mest uppenbara sakerna för kunder är de serviceytor som de interagerar med. Dessa är vanligtvis API: er som kunder använder för att få sina förfrågningar tillgodosedda. Detta är också där kunderna kommer att vara minst förvånade i händelse av backpressure, eftersom det tydligt framhäver att systemet är under stress.

Samma princip kan tillämpas inom själva tjänsten över olika underkomponenter och gränssnitt genom vilka de interagerar med varandra. Dessa ytor är de bästa platserna för att utöva backpress.

How to Apply Backpressure in Distributed Systems

I det senaste avsnittet pratade vi om hur man hittar rätt punkter av intresse för att hävda backpressure.När vi vet dessa punkter, här är några sätt vi kan hävda denna backpressure i praktiken:

Skapa explicit flödeskontroll

Tanken är att göra radstorleken synlig för dina samtalare och låta dem styra samtalshastigheten baserat på det. Genom att veta radstorleken (eller någon resurs som är en flaskhals) kan de öka eller minska samtalshastigheten för att undvika att överväldiga systemet. Denna typ av teknik är särskilt användbar där flera interna komponenter arbetar tillsammans och beter sig så bra som de kan utan att påverka varandra. Ekvationen nedan kan användas när som helst för att beräkna samtalshastigheten. Observera: Den faktiska samtalshastigheten beror på olika andra faktorer, men ekvationen nedan bör ge en bra idé.

CallRate_new = CallRate_normal * (1 - (Q_currentSize / Q_maxSize))

CallRate_new = CallRate_normal * (1 - (Q_currentSize / Q_maxSize))

Invert Responsibilities

I vissa system är det möjligt att ändra ordningen där samtalare inte uttryckligen skickar förfrågningar till tjänsten men låter tjänsteförfrågan fungera själv när den är redo att serveras.Den här typen av teknik ger den mottagande tjänsten full kontroll över hur mycket den kan göra och kan dynamiskt ändra storleken på begäran baserat på dess senaste tillstånd.Köp Bucketstrategin där den mottagande tjänsten fyller på token, och det berättar för uppringaren när och hur mycket de kan skicka till servern.

  # Service requests work if it has capacity

 if Tokens_available > 0: 

             Work_request_size = min (Tokens_available, Work_request_size _max) # Request work, up to a maximum limit 

             send_request_to_caller(Work_request_size) # Caller sends work if it has enough tokens

 

if Tokens_available >= Work_request_size: 

send_work_to_service(Work_request_size)

             Tokens_available = Tokens_available – Work_request_size

# Tokens are replenished at a certain rate

Tokens_available = min (Tokens_available + Token_Refresh_Rate, Token_Bucket_size)

Proactive Adjustments

Ibland vet du i förväg att ditt system kommer att bli överväldigat snart, och du tar proaktiva åtgärder som att be uppringaren att sakta ner samtalets volym och långsamt öka den.

Under den perioden har du köpt upp allt arbete och är nu redo att dränera det för att möta dittSLANär du dränerar det snabbare än den normala hastigheten riskerar du att ta ner nedströmstjänsterna.För att ta itu med detta begränsar du proaktivt ringergränserna eller engagerar ringer för att minska volymen och långsamt öppna översvämningsgränserna.

Throttling

Begränsa antalet förfrågningar en tjänst kan betjäna och kasta bort förfrågningar bortom det. Throttling kan tillämpas på servicenivå eller API-nivå. Denna throttling är en direkt indikator på baktryck för att ringer att sakta ner samtalets volym. Du kan ta detta längre och göra prioriterad throttling eller rättvisa throttling för att säkerställa att kunderna ser den minsta effekten.

Load Shedding

Throttling pekar på att kasta bort förfrågningar när du bryter mot vissa fördefinierade gränser. Kundförfrågningar kan fortfarande kastas om tjänsten står inför stress och bestämmer sig för att proaktivt släppa förfrågningar som den redan har lovat att betjäna.

Conclusion

Backpressure är en kritisk utmaning i distribuerade system som kan påverka prestanda och stabilitet avsevärt. Att förstå orsakerna och effekterna av backpressure, tillsammans med effektiva hanteringstekniker, är avgörande för att bygga robusta och högpresterande distribuerade system.

Men om det misshandlas kan det undergräva kundernas förtroende och till och med bidra till systemets instabilitet.Proaktivt ta itu med backpress genom noggrann systemdesign och övervakning är nyckeln till att upprätthålla systemets hälsa.Medan implementering av backpress kan innebära kompromisser, såsom potentiellt påverkar genomströmningen, är fördelarna med den övergripande systemets motståndskraft och användarnöjdhet betydande.