Backpressure nije bug: to je značajka za izgradnju otpornih sustava

Backpressure je skriveno pregovaranje između proizvođača i potrošača. Održavajte ga, a vaši sustavi graciozno skaliraju. Ignorirajte ga, a oni se raspadaju pod vrhunskim opterećenjem.

Backpressure je skriveno pregovaranje između proizvođača i potrošača. Održavajte ga, a vaši sustavi graciozno skaliraju. Ignorirajte ga, a oni se raspadaju pod vrhunskim opterećenjem.

Gornji citat sugerira da čak i najsnažniji i najbolje konstruirani jame ne mogu izdržati destruktivne sile nekontrolirane i nekontrolirane poplave.Distribuirani sustav, an unchecked caller can often overwhelm the entire system and cause cascading neuspjeh.

U APrethodni članak, Napisao sam o tome kako retry nevrijeme ima potencijal da oduzme cijelu uslugu ako odgovarajuće straže nisu na mjestu. ovdje, istražujem kada bi usluga trebala razmotriti primjenu povratnog tlaka na svoje pozivače, kako se može primijeniti i što pozivači mogu učiniti kako bi se nosili s tim.

Backpressure

Kao što i sam naziv sugerira, backpressure je mehanizam u distribuiranim sustavima koji se odnosi na sposobnost sustava da guta brzinu kojom se podaci konzumiraju ili proizvode kako bi se spriječilo preopterećenje samog sebe ili njegovih dolaznih komponenti.Sustav koji primjenjuje backpressure na svoj pozivač nije uvijek eksplicitno, kao u obliku throttling ili gubitka opterećenja, ali ponekad i implicitno, kao što je usporavanje vlastitog sustava dodavanjem latentnosti zahtjevima koji se služe bez da je izričito o tome.

I implicitni i eksplicitni povratni pritisak namjeravaju usporiti pozivača, bilo kada se pozivač ne ponaša dobro ili je sama usluga nezdrava i treba vrijeme za oporavak.

Need for Backpressure

U ovom primjeru gradimo uslugu kontrolne ploče s tri glavne komponente: frontend gdje se primaju zahtjevi klijenata, unutarnji red u kojem se bufferiraju zahtjevi klijenata i potrošačka aplikacija koja čita poruke iz reda i piše u bazu podataka za upornost.

Producer-Consumer Mismatch

Razmislite o scenariju u kojem akteri / kupci udaraju na prednji kraj s takvom brzinom da je unutarnji red pun ili je radnik koji piše u bazu podataka zauzet, što dovodi do punog reda. U tom slučaju, zahtjevi se ne mogu prekinuti, tako da je umjesto odustajanja od zahtjeva kupaca, bolje obavijestiti kupce unaprijed.

Resource Constraints and Cascading Failures

Zamislite scenarij u kojem se vaš red približava 100% njegovog kapaciteta, ali obično je na 50%. Da biste uskladili ovo povećanje ulazne stope, proširite svoju potrošačku aplikaciju i počnite pisati u bazu podataka s većom stopom.MTTRPrimjena povratnog tlaka na odgovarajućim mjestima postaje kritična u takvim scenarijima.

Missed SLAs

Razmislite o scenariju u kojem se podaci zapisani u bazu podataka obrađuju svakih 5 minuta, a druga aplikacija sluša kako bi se održala ažurirana.

Možete obavijestiti kupce da ćete propustiti SLA i zamoliti ih da ponovno pokušaju kasnije, ili primijeniti povratni pritisak tako što ćete ostaviti ne hitne zahtjeve iz reda kako biste zadovoljili SLA za kritične događaje / zahtjeve.

Backpressure Challenges

Na temelju onoga što je gore opisano, čini se da bismo uvijek trebali primijeniti povratni pritisak, i ne bi trebalo biti nikakve rasprave o tome.Da litrebamo primijeniti povratni pritisak, ali uglavnom okoKakoidentificirati prave točke za primjenu povratnog pritiska i mehanizme za njegovu primjenu koji zadovoljavaju specifične usluge/poslovne potrebe.

Backpressure zahtijeva kompromis između prodajnog kapaciteta i stabilnosti, što je učinjeno složenijim izazovom predviđanja opterećenja.

Identifying the Backpressure Points

Find Bottlenecks/Weak Links

Razmislite o sustavu u kojem velika flota podataka (tisuće domaćina) ovisi o maloj floti kontrolnih zrakoplova (manje od 5 domaćina) kako bi primili konfigure koji su i dalje prisutni u bazi podataka, kao što je prikazano u gornjem dijagramu.

Velika flota može lako preplaviti malu flotu. U ovom slučaju, kako bi se zaštitila, mala flota trebala bi imati mehanizme za primjenu povratnog tlaka na pozivač. Još jedna uobičajena slaba veza u arhitekturi su centralizirane komponente koje donose odluke o cijelom sustavu, poput antentropijskih skenera. Ako ne uspiju, sustav nikada ne može dostići stabilno stanje i može dovesti do smanjenja cijele usluge.

Use System Dynamics: Monitors/Metrics

Još jedan uobičajeni način za pronalaženje backpressure točkica za vaš sustav je da imate odgovarajuće monitore/metrije na mjestu. Kontinuirano pratite ponašanje sustava, uključujući dubinu reda, korištenje CPU-a/memorije i mrežnu snagu.

Stvaranje agregatnog pogleda pomoću metrika ili promatrača kao što su performanse kanare u različitim komponentama sustava je još jedan način da znate da je vaš sustav pod stresom i treba tvrditi povratni pritisak na svoje korisnike / poziva. Ovi performanse kanare mogu biti izolirani za različite aspekte sustava kako bi pronašli točke gušenja.

Boundaries: The Principle of Least Astonishment

Naj očiglednije stvari za kupce su površina usluga s kojom oni komuniciraju. To su obično API-ji koje kupci koriste kako bi dobili svoje zahtjeve. Ovo je također mjesto gdje će kupci biti najmanje iznenađeni u slučaju povratnog pritiska, jer jasno naglašava da je sustav pod stresom. To može biti u obliku šutnje ili gubitka opterećenja.

Isti princip može se primijeniti unutar same usluge na različite podkomponente i sučelja kroz koje oni međusobno djeluju.Ove površine su najbolja mjesta za izvršavanje povratnog pritiska.To može pomoći u minimiziranju zbunjenosti i povećanju predvidljivosti ponašanja sustava.

How to Apply Backpressure in Distributed Systems

U posljednjem odjeljku, razgovarali smo o tome kako pronaći prave točke interesa kako bi se utvrdio povratni pritisak.

Izgradnja eksplicitne kontrole protoka

Ideja je učiniti veličinu reda vidljivom vašim pozivateljima i dopustiti im da kontroliraju stopu poziva na temelju toga. Poznavajući veličinu reda (ili bilo koji resurs koji je čaša), oni mogu povećati ili smanjiti stopu poziva kako bi se izbjeglo prekomjerno opterećenje sustava. Ova vrsta tehnike je posebno korisna gdje više unutarnjih komponenti rade zajedno i ponašaju se kao što mogu bez utjecaja jedni na druge. Rješenje ispod može se koristiti u bilo kojem trenutku za izračunavanje stope poziva. Napomena: Stvarna stopa poziva ovisit će o raznim drugim čimbenicima, ali jednadžba ispod trebala bi dati dobru ideju.

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

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

Invert Responsibilities

U nekim sustavima, moguće je promijeniti redoslijed u kojem pozivači ne šalju zahtjeve izričito usluzi, ali dopuštaju da zahtjev za uslugu samostalno radi kada je spreman za služenje. Ova vrsta tehnike daje usluzi koja prima punu kontrolu nad time koliko može učiniti i može dinamički promijeniti veličinu zahtjeva na temelju najnovijeg stanja.TOKEN BUKETstrategija u kojoj usluga koja prima ispunjava token, a to govori pozivaču kada i koliko mogu poslati na poslužitelj.

  # 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

Ponekad unaprijed znate da će vaš sustav uskoro biti preplavljen, a vi poduzimate proaktivne mjere kao što je traženje poziva poziva da usporite volumen poziva i polako ga povećate.

Tijekom tog razdoblja, vi ste započeli sa svim radom i sada ste spremni isprazniti ga kako biste zadovoljili svoje potrebe.SLAKada ga ispraznite brže od normalne stope, rizikujete da ćete smanjiti usluge u daljnjem toku.Da biste to riješili, proaktivno ograničavate ograničenja pozivača ili uključite pozivača kako biste smanjili volumen poziva i polako otvorili poplave.

Throttling

Ograničite broj zahtjeva koje usluga može poslužiti i odbacite zahtjeve iznad toga. Throttling se može primijeniti na razini usluge ili na razini API-ja. Ovo je izravan pokazatelj povratnog pritiska za pozivača da usporava volumen poziva. Možete uzeti ovo dalje i učiniti prioritetno ili pošteno da biste osigurali da klijenti vide najmanji utjecaj.

Load Shedding

Zahtjevi klijenata i dalje se mogu odbaciti ako se usluga suoči sa stresom i odluči proaktivno odbaciti zahtjeve koje je već obećala služiti.

Conclusion

Backpressure je kritičan izazov u distribuiranim sustavima koji mogu značajno utjecati na performanse i stabilnost. Razumijevanje uzroka i učinaka backpressure, zajedno s učinkovitim tehnikama upravljanja, ključno je za izgradnju robusnih i visokoučinkovitih distribuiranih sustava.

Međutim, ako se zloupotrijebi, može narušiti povjerenje kupaca i čak pridonijeti nestabilnosti sustava. Proaktivno rješavanje backpressure kroz pažljiv dizajn i praćenje sustava ključan je za održavanje zdravlja sustava. Dok provedba backpressure može uključivati kompromise, kao što je potencijalno utjecanje na prohodnost, prednosti u smislu ukupne otpornosti sustava i zadovoljstva korisnika su znatne.