Model omezování rychlosti

Řídit rychlost, s jakou vaše aplikace odesílá požadavky do služby, abyste zůstali v mezích limitů omezování služby a celkové kapacitě. Tento přístup vám pomůže vyhnout se chybám způsobeným omezením rychlosti nebo je omezit na minimum a přesněji odhadnout propustnost.

Omezení rychlosti je vhodné v mnoha scénářích, ale je užitečné zejména pro rozsáhlé opakované automatizované úlohy, jako je dávkové zpracování.

Kontext a problém

Provádění velkého počtu operací s omezenou službou může vést ke zvýšení provozu a snížení propustnosti, protože potřebujete sledovat odmítnuté požadavky a potom operaci opakovat. S rostoucím počtem operací může limit škrcení vyžadovat opakované znovuodesílání dat v několika průchodech, což má větší dopad na výkon.

Představte si například následující problematický proces opakování při chybě pro příjem dat do Azure Cosmos DB:

1. Vaše aplikace potřebuje ingestovat 10 000 záznamů do služby Azure Cosmos DB. Každý záznam stojí 10 jednotek požadavků (RU) pro ingestaci, takže k dokončení úlohy je celkem potřeba 100 000 RU.

2. Vaše instance Azure Cosmos DB má zřízenou kapacitu 20 000 RU.

3. Všech 10 000 záznamů odešlete do služby Azure Cosmos DB. 2 000 záznamů se úspěšně zapíše a odmítne se 8 000 záznamů.

4. Zbývající 8 000 záznamů odešlete do služby Azure Cosmos DB. Úspěšně zapsáno 2 000 záznamů a odmítnuto je 6 000 záznamů.

5. Zbývající 6 000 záznamů odešlete do služby Azure Cosmos DB. 2 000 záznamů se úspěšně zapíše a odmítne se 4 000 záznamů.

6. Zbývající 4 000 záznamů odešlete do služby Azure Cosmos DB. 2 000 záznamů se úspěšně zapíše a zamítne se 2 000 záznamů.

7. Zbývající 2 000 záznamů odešlete do služby Azure Cosmos DB. Vše bylo úspěšně zapsáno.

Úloha příjmu dat se úspěšně dokončí, ale až po odeslání 30 000 záznamů do Azure Cosmos DB. Celá datová sada se skládá pouze z 10 000 záznamů.

V tomto příkladu je potřeba vzít v úvahu další faktory:

• Velký počet chyb může také vést k práci navíc při zaznamenávání těchto chyb do protokolu a zpracování takto vzniklých dat protokolu. Předchozí přístup zpracovává 20 000 chyb a protokolování těchto chyb může vyžadovat náklady na zpracování, paměť nebo prostředky úložiště.

• Vzhledem k tomu, že neznáte omezení služby příjmu dat, nemáte způsob, jak nastavit očekávání pro dobu zpracování dat. Omezení rychlosti vám umožní vypočítat čas potřebný k příjmu dat.

Řešení

Omezování rychlosti může snížit provoz a potenciálně zlepšit propustnost snížením počtu záznamů odeslaných do služby v daném časovém období.

Služba může omezovat požadavky na základě různých metrik v průběhu času, například:

• Počet operací (například 20 požadavků za sekundu)
• Množství dat (například 2 GiB za minutu).
• Relativní náklady na provoz (například 20 000 RU za sekundu)

Bez ohledu na metriku, kterou používáte pro omezování, bude implementace omezování rychlosti zahrnovat řízení počtu a/nebo velikosti operací odesílaných do služby během určitého časového období. Omezení rychlosti pomáhá optimalizovat využívání služby, aniž by došlo k překročení jejích limitů.

Ve scénářích, kdy vaše rozhraní API můžou zpracovávat požadavky rychleji než omezené služby příjmu dat, musíte spravovat, jak rychle službu používáte. Zacházení s omezováním pouze jako s nesouladem rychlosti přenosu dat a ukládání požadavků na příjem do vyrovnávací paměti, dokud se služba nezotaví, představuje riziko. Pokud vaše aplikace v tomto scénáři přestane reagovat, můžou se ztratit všechna data uložená do vyrovnávací paměti.

Abyste se tomuto riziku vyhnuli, zvažte odeslání záznamů do odolného systému zasílání zpráv, který dokáže zpracovat vaši plnou rychlost příjmu dat. (Služby, jako je Azure Event Hubs, můžou zpracovávat miliony operací za sekundu.) Potom můžete použít jeden nebo více procesorů úloh ke čtení záznamů ze systému zasílání zpráv s kontrolovanou rychlostí, která je v mezích omezení služby. Odesílání záznamů do systému zasílání zpráv může ušetřit vnitřní paměť tím, že umožňuje odložit pouze záznamy, které lze zpracovat během daného časového intervalu.

Azure poskytuje několik trvalých služeb zasílání zpráv, které můžete použít s tímto vzorem, včetně:

• Azure Service Bus
• Azure Queue Storage
• Event Hubs

Tok začíná tím, že uživatel odesílá dávku 10 000 zpráv do komponenty rozhraní API. API předává všechny zprávy komponentě perzistentní služby zasílání zpráv. Ze služby spolehlivého zasílání zpráv vedou tři samostatné toky ke třem komponentám zpracování úloh. Každý tok je označený x100 / s, což označuje, že každý procesor úloh odvolá zprávy s kontrolovanou rychlostí 100 za sekundu. Všechny tři komponenty zpracování úloh se připojují ke komponentě služby s omezenou propustností. Omezovaná služba označená jako "omezení při 300 záznamech za sekundu", což se rovná kombinovanému výstupu tří procesorů.

Při odesílání záznamů může být časové období, které používáte pro jejich odesílání, jemnější než období, podle kterého služba omezuje propustnost. Systémy často nastavují limity na základě časových intervalů, kterým lze snadno porozumět a snadno s nimi pracovat. U počítače se službou však tyto časové rámce můžou být velmi dlouhé ve srovnání s tím, jak rychle může zpracovávat informace. Například může systém omezovat propustnost na sekundu nebo na minutu, ale zpracování kódu obvykle probíhá v řádu nanosekund či milisekund.

I když se nevyžaduje, často se doporučuje odesílat menší počet záznamů častěji, aby se zlepšila propustnost. Takže místo toho, abyste se pokoušeli dávkovat záznamy k odeslání jednou za sekundu nebo jednou za minutu, můžete zvolit jemnější členění, aby zatížení prostředků (paměti, CPU a sítě) bylo rovnoměrnější. Tento přístup zabraňuje potenciálním kritickým bodům způsobeným náhlým nárůstem požadavků. Pokud například služba umožňuje 100 operací za sekundu, implementace omezovače rychlosti může dokonce vyřadit požadavky uvolněním 20 operací každých 200 milisekund, jak je znázorněno v následujícím grafu.

Graf má název Rate Limited Flow (Rychlost omezeného toku). Vykreslí počet operací na ose y od 0 do 25 proti časovému razítku na ose x od 0,0 do 4,0. Od časového razítka 0.0 do 0.2 je počet operací 0, což znamená, že se neposílají žádné operace. Mezi 0,2 a 0,4 čára prudce stoupá na 20, což znamená, že omezovač rychlosti dosáhl svého nastaveného horního limitu. V časovém razítku 3,0 se čára výrazně sníží na 0, což značí, že práce je dokončená nebo že omezovač rychlosti přestal vydávat záznamy. Od 3,2 do 3,8 zůstává hodnota 0. Klíčovou vlastností grafu je plochá plošina mezi 0,4 a 3,0. Ukazuje, že omezování rychlosti vytváří konzistentní, předvídatelnou propustnost, nikoli nárůsty a poklesy, které jsou spojené s problematickým přístupem při opakování při chybě.

Kromě toho je někdy nutné, aby několik nekoordovaných procesů sdílelo omezené služby. Pro implementaci omezení rychlosti požadavků v tomto scénáři můžete kapacitu služby logicky rozdělit a poté použít distribuovaný systém pro vzájemné vyloučení ke správě exkluzivních zámků nad těmito částmi. Nekoordované procesy pak můžou soutěžit o zámky v těchto oddílech, kdykoli potřebují kapacitu. Každému oddílu, na němž proces drží zámek, je přidělena určitá kapacita.

Pokud například systém s omezenou propustností umožňuje 500 požadavků za sekundu, můžete vytvořit 20 oddílů, z nichž každý bude mít kapacitu 25 požadavků za sekundu. Pokud by proces potřeboval odeslat 100 požadavků, mohl by distribuovaný systém vzájemného vyloučení požádat o čtyři oddíly. Systém může přidělit dva oddíly na 10 sekund. Proces pak omezí rychlost na 50 požadavků za sekundu, dokončí úlohu za dvě sekundy a pak uvolní zámek.

Jedním ze způsobů implementace tohoto modelu je použití Azure Storage. V tomto scénáři vytvoříte v kontejneru jeden objekt blob o velikosti 0 bajtů pro každý logický oddíl. Vaše aplikace pak mohou získat výhradní pronájem přímo pro tyto objekty blob na krátkou dobu (například 15 sekund). Pro každé zapůjčení aplikace může využít kapacitu tohoto oddílu. Aplikace pak potřebuje sledovat dobu zapůjčení, aby aplikace, kdy vyprší její platnost, přestala využívat kapacitu, která byla udělena. Když tento vzor implementujete, často budete chtít, aby se každý proces pokusil pronajmout si náhodně vybraný oddíl, když potřebuje kapacitu.

Pokud chcete dále snížit latenci, můžete pro každý proces přidělit malou exkluzivní kapacitu. Proces by pak usiloval o pronájem sdílené kapacity pouze v případě, že by potřeboval překročit svou vyhrazenou kapacitu.

Diagram znázorňuje čtyři procesy, které se ucházejí o výhradní pronájmy šesti očíslovaných oddílů blobů uložených v Blob Storage. Čtyři procesy jsou označené jako A, B, C a D. Blob Storage obsahuje šest oddílů objektů blob očíslovaných 0 až 5. Od procesu A směřuje k oddílu 0 zelená šipka, která označuje úspěšné získání pronájmu. Červená šipka směřuje od procesu A k oddílu 1 a označuje neúspěšný pokus o získání pronájmu, protože jiný proces už má tento oddíl pronajatý. Od procesu D vede zelená šipka k oddílu 1, což znamená, že proces D má pronájem tohoto oddílu. Proto pokus procesu A na oddílu 1 selhal. Druhá zelená šipka směřuje od procesu D k partition 4 a označuje druhý lease držený procesem D. S procesy B a C nejsou spojeny žádné šipky, protože nedrží žádný lease. Oddíly 2, 3 a 5 také nejsou pronajaté.

Jako alternativu k Azure Storage můžete také implementovat tento druh systému správy zapůjčení pomocí technologií, jako je ZooKeeperatd., a Redis/Redsync.

Problémy a důležité informace

Při rozhodování o implementaci tohoto modelu zvažte následující body:

• I když model omezování rychlosti může snížit počet chyb omezování, vaše aplikace stále potřebuje správně zpracovat všechny chyby omezování, ke kterým může dojít.

• Ujistěte se, že opakování jsou sladěné s omezováním rychlosti. Bezhlavé nebo příliš agresivní opakované pokusy mohou zvýšit zatížení a vyvolat laviny opakovaných pokusů, proto přenášejte signály zpětného tlaku (například HTTP 429 s Retry-After) a používejte omezený počet opakovaných pokusů s malými náhodnými prodlevami mezi pokusy.

• Pokud má vaše aplikace více pracovních proudů, které přistupují ke stejné omezené službě, musíte všechny z nich integrovat do strategie omezování rychlosti. Můžete například podporovat hromadné načítání záznamů do databáze, ale také dotazování na záznamy ve stejné databázi. Kapacitu můžete spravovat tím, že zajistíte, aby všechny pracovní toky procházely stejným mechanismem omezení rychlosti. Případně můžete pro každý pracovní tok vyhradit samostatné kapacitní fondy.

• Omezovaná služba se může používat ve více aplikacích. V některých případech je možné toto použití koordinovat (jak je znázorněno výše v tomto článku). Pokud se vám začne zobrazovat větší než očekávaný počet chyb omezování, může toto zvýšené číslo znamenat kolizí mezi aplikacemi, které přistupují ke službě. V takovém případě možná budete muset zvážit dočasné snížení propustnosti, kterou váš mechanismus omezování rychlosti ukládá, dokud se využití z jiných aplikací nezmenší.

Kdy použít tento vzor

Tento model použijte v těchto případech:

• Potřebujete snížit chyby omezování vyvolané službou omezenou rychlostí.

• Chcete minimalizovat síťový provoz ve srovnání s naivními přístupy založenými na opakování při chybě.

• Spotřebu paměti je potřeba snížit tak, že budete záznamy odebírat z fronty pouze tehdy, když je dostatečná kapacita pro jejich zpracování.

Tento vzor nemusí být vhodný v těchto případech:

• Operace vyžaduje okamžité synchronní dokončení s velmi nízkou latencí a nemůže tolerovat řazení do fronty nebo odložené zpracování.

• Primární kritickým bodem není rychlost požadavků, ale místo toho dochází ke kolizím prostředků nebo souběžnosti (například sytost procesoru nebo dlouhotrvající práce v letu). V těchto případech jsou vhodnější kontroly škálování nebo souběžnosti.

Návrh úloh

Vyhodnoťte, jak použít model omezování rychlosti v návrhu úlohy k řešení cílů a principů popsaných v pilířích Azure Well-Architected Frameworku. Následující tabulka obsahuje pokyny, jak tento model podporuje cíle jednotlivých pilířů.

Pilíř	Jak tento model podporuje cíle pilíře
Spolehlivostní rozhodnutí o návrhu pomáhají vaší pracovní zátěži stát se odolná proti poruchám a zajistit, aby se po selhání obnovila do plně funkčního stavu.	Tato taktika chrání klienta tím, že potvrzuje a respektuje omezení a náklady na komunikaci se službou, pokud služba dává přednost před nadměrným využitím. - RE:07 Sebezáchování

Pokud tento model představuje kompromisy v rámci pilíře, zvažte je proti cílům ostatních pilířů.

Example

Následující ukázková aplikace umožňuje uživatelům odesílat záznamy různých typů do rozhraní API. Každý typ záznamu má jedinečný procesor úloh, který provádí následující kroky:

1. Ověřování
2. Rozšiřování
3. Vložení záznamu do databáze

Všechny komponenty aplikace (API, procesor úloh A a procesor úloh B) jsou samostatné procesy, které lze škálovat nezávisle. Procesy vzájemně nekomunikují přímo.

Diagram znázorňuje dva uživatele, kteří odesílali záznamy prostřednictvím sdíleného rozhraní API. Každý typ záznamu se směruje do samostatné fronty, zpracuje vyhrazený procesor úloh a zapíše se do omezené databáze s kontrolovanou rychlostí, která se řídí zapůjčením oddílů objektů blob v Azure Storage. Všichni dva uživatelé odesílají dávku zpráv do komponenty rozhraní API. Jeden uživatel odešle 10 000 zpráv a druhý odešle 5 000 zpráv. Rozhraní API směruje 10 000 zpráv do fronty A a 5 000 zpráv do fronty B. Fronta A se připojí k procesoru úloh A a fronta B se připojí k procesoru úloh B. Procesor úloh A zapíše do databáze rychlostí 300 záznamů za sekundu. Procesor úloh B zapisuje do databáze s 500 záznamy za sekundu. Oba procesory úloh se připojují k databázové komponentě s označením „omezená na 800 záznamů za sekundu“. Pod dvojicí procesorů úloh obsahuje Azure Storage osm oddílů blobů označených čísly 0 až 7. Poznámka uvádí, že každý oddíl odpovídá 100 záznamům za sekundu. Několik šipek propojuje procesory úloh s oddíly blobů. Zelené šipky směřují od zpracovatele úloh A k oddílům 0, 4 a 6, což znamená, že má pronajaté tyto tři oddíly. Tyto pronájmy stojí za jeho rychlostí 300 záznamů za sekundu. Zelené šipky ukazují z procesoru úloh B na oddíly 1, 2, 3, 5 a 7. Tyto šipky označují, že tento procesor uchovává zapůjčení v pěti oddílech. Tyto pronájmy stojí za jeho rychlostí 500 záznamů za sekundu. Neúspěšné pokusy o zapůjčení se zobrazují jako červené šipky, které přejdou na oddíly, které už ostatní procesor drží. Tyto šipky představují rozlišení kolizí. Diagram ukazuje, že součet všech přiřazených oddílů napříč oběma procesory činí 800 záznamů za sekundu, což odpovídá limitu omezení propustnosti databáze.

V tomto příkladu každé zapůjčení objektu blob představuje pevný podíl povolené propustnosti databáze. Procesor může dekadovat a zapisovat pouze v kombinované sazbě zapůjčení, které aktuálně uchovává. Jak procesory postupem času získávají nebo ztrácejí leasey, mění se jejich povolená rychlost zápisu, čímž se celkový provoz databáze udržuje v rámci nakonfigurovaného limitu a zároveň se umožňuje pokračování veškeré práce zařazené do fronty.

Tento diagram zahrnuje následující pracovní postup:

1. Uživatel odešle do rozhraní API 10 000 záznamů typu A.
2. API zařadí těchto 10 000 záznamů do fronty A.
3. Uživatel odešle do rozhraní API 5 000 záznamů typu B.
4. Rozhraní API zařadí těchto 5 000 záznamů do fronty B.
5. Procesor úloh A zjistí, že fronta A obsahuje záznamy, a pokusí se získat výhradní pronájem objektu blob 2.
6. Procesor úloh B vidí, že ve frontě B jsou záznamy, a pokouší se získat výhradní pronájem blobu 2.
7. Zpracovateli úloh A se nepodařilo získat pronájem.
8. Procesor úloh B získá pronájem objektu blob 2 na 15 sekund. Teď může omezit četnost požadavků na databázi rychlostí 100 za sekundu.
9. Procesor úloh B odřadí 100 záznamů z fronty B a zapíše je.
10. Jedna sekunda projde.
11. Procesor úloh A vidí, že fronta A má více záznamů a snaží se získat výhradní zapůjčení objektu blob 6.
12. Procesor úloh B vidí, že fronta B obsahuje více záznamů a snaží se získat výhradní zapůjčení objektu blob 3.
13. Procesor úloh A získá pronájem objektu blob 6 na 15 sekund. Teď může omezit četnost požadavků na databázi rychlostí 100 za sekundu.
14. Procesor úloh B získá pronájem objektu blob 3 na 15 sekund. Teď může omezit požadavky na databázi rychlostí 200 za sekundu. (Má také pronajatý objekt blob 2.)
15. Procesor úloh A odřadí 100 záznamů z fronty A a zapíše je.
16. Procesor úloh B odebere z fronty B 200 záznamů a zapíše je.
17. Jedna sekunda projde.
18. Zpracovatel úloh A vidí, že fronta A má více záznamů, a pokouší se získat výhradní zámek k objektu blob 0.
19. Procesor úloh B vidí, že fronta B obsahuje více záznamů a snaží se získat výhradní zapůjčení objektu blob 1.
20. Procesor úloh A získá pronájem objektu blob 0 na 15 sekund. Teď může omezit požadavky na databázi rychlostí 200 za sekundu. (Obsahuje také zapůjčení objektu blob 6.)
21. Procesor úloh B získá pronájem objektu blob 1 na 15 sekund. Teď může omezit požadavky na databázi rychlostí 300 za sekundu. (Má také pronajaté objekty blobu 2 a 3.)
22. Procesor úloh A odřadí 200 záznamů z fronty A a zapíše je.
23. Procesor úloh B odebere z fronty B 300 záznamů a zapíše je.
24. A tak dále.

Po 15 sekundách se jedna nebo obě úlohy stále nedokončí. Když vyprší platnost zapůjčení, procesor by měl také snížit počet požadavků, které odpisuje a zapisuje.

Implementace tohoto modelu jsou k dispozici v různých programovacích jazycích:

• Implementace Go je dostupná na GitHubu.
• Implementace Java je k dispozici na GitHubu.

Další kroky

Při implementaci tohoto modelu můžou být relevantní také následující pokyny:

• Pokročilé omezování požadavků pomocí Azure API Management Toto použijte jako doplňkové řízení přijímání požadavků na okraji sítě k vynucování limitů četnosti volání a kvót pro jednotlivé klíče a k poskytování konzistentních signálů přetížení klientům.

• Vyberte si mezi službami zasílání zpráv Azure. Vyberte nejlepší odolnou páteřní síť zasílání zpráv pro ukládání do vyrovnávací paměti a řízený příjem dat.

• Zpracování přechodných chyb v aplikacích Azure Navrhněte chování opakovaných pokusů tak, aby klienti při dosažení limitů správně prodlužovali intervaly mezi pokusy.

Související zdroje informací

Při implementaci tohoto modelu můžou být relevantní také následující vzory a pokyny:

• Throttling. Model omezování rychlosti se obvykle implementuje v reakci na omezené služby.

• Retry. Pokud požadavky na službu s omezenou propustností vedou k chybám způsobeným omezením požadavků, je obecně vhodné tyto požadavky po odpovídajícím intervalu zopakovat.

• Vyrovnávání zatížení založené na frontě se podobá vzoru Rate Limiting, ale v několika klíčových ohledech se liší:

  • Omezování rychlosti nemusí nutně používat fronty ke správě zatížení, ale potřebuje využívat odolnou službu zasílání zpráv. Například model omezování rychlosti může používat služby, jako je Apache Kafka nebo Event Hubs.

  • Vzorec omezování rychlosti zavádí koncept distribuovaného systému vzájemného vyloučení napříč oddíly, který umožňuje spravovat kapacitu pro více nekoordinovaných procesů, jež komunikují se stejnou službou s omezenou propustností.

  • Model vyrovnávání zatížení Queue-Based je použitelný vždy, když dojde k neshodě výkonu mezi službami nebo chcete zlepšit odolnost. Jedná se tedy o širší model než omezování rychlosti, který se konkrétně zabývá efektivním přístupem k omezené službě.