model vyrovnávání zatíženíQueue-Based

Použijte frontu, která funguje jako vyrovnávací paměť mezi úlohou a službou, kterou vyvolá. Tento přístup vyhladí přerušované vysoké zatížení, které může způsobit selhání služby nebo vypršení časového limitu úlohy. Pomáhá minimalizovat dopad špiček poptávky na dostupnost a odezvu úlohy a služby.

Kontext a problém

Mnohá cloudová řešení spouštějí úlohy, které volají služby. V tomto prostředí může přerušované vysoké zatížení způsobit problémy s výkonem nebo spolehlivostí služby.

Služba může být součástí stejného řešení jako úlohy, které ji používají, nebo to může být partnerová služba, která poskytuje přístup k často používaným prostředkům. Mezi příklady těchto typů služeb patří mezipaměť nebo služba úložiště. Když současně běží více úloh a používá stejnou službu, je obtížné kdykoli předpovědět objem požadavků.

U služby může docházet ke špičkám poptávky, které ji přetíží a aby služba nemohla rychle reagovat na požadavky. Zahlcení služby mnoha souběžnými požadavky může také způsobit selhání služby, pokud nedokáže zpracovat kolize, kterou tyto požadavky způsobují.

Řešení

Umístěte frontu mezi úlohu a službu. Úloha a služba poběží asynchronně. Úkol odešle do fronty zprávu, která obsahuje data požadovaná službou. Fronta funguje jako vyrovnávací paměť a ukládá zprávu, dokud si ji služba nevyzvedne. Služba načte zprávy z fronty a zpracuje je. Požadavky z více úloh, které je možné generovat ve vysoké proměnlivé míře, je možné předat službě prostřednictvím stejné fronty zpráv. Následující diagram znázorňuje, jak může fronta vyrovnát zatížení služby.

Diagram znázorňuje, jak fronta zpráv odděluje požadavky na úlohy proměnlivé rychlosti od služby, která je zpracovává konzistentní rychlostí. Tok se přesune zleva doprava. Vlevo směřují od tří ikon úloh ke středové frontě zpráv samostatné šipky, které ukazují, jak úlohy nezávisle odesílají požadavky do stejné fronty. Jedna šipka ukazuje z fronty zpráv na uzel služby úplně vpravo, který představuje způsob, jakým služba zpracovává zprávy konzistentní rychlostí.

Fronta odděluje úlohy od služby, aby služba mohla zpracovávat zprávy vlastním tempem i v případě, že souběžné úlohy generují vysoký objem požadavků. Úlohy se také nezpozdí, pokud služba není v době odesílání zpráv do fronty dostupná.

Tento model má následující výhody:

• Pomáhá maximalizovat dostupnost, protože zpoždění ve službě neovlivňují aplikaci okamžitě a přímo. Aplikace může dál publikovat zprávy do fronty, i když služba není dostupná nebo aktuálně nezpracovává zprávy.

• Pomáhá maximalizovat škálovatelnost, protože počet front a počet služeb se může lišit podle požadavků.

• Pomáhá řídit náklady, protože potřebujete jenom dostatek instancí služby, abyste splnili požadavky na průměrné zatížení, a ne na zatížení ve špičce.

Note

Některé služby implementují omezování, když poptávka dosáhne prahové hodnoty, která může způsobit selhání systému. Omezování může omezit dostupnou funkcionalitu. Implementujte v těchto službách vyrovnávání zatížení, abyste zajistili, že poptávka nedosáhne této prahové hodnoty.

Problémy a důležité informace

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

• Implementujte aplikační logiku, která řídí rychlost, jakou služby zpracovávají zprávy, aby nedošlo k zahlcení cílového prostředku. Vyhněte se předávání špiček v poptávce do další fáze systému. Otestujte systém pod zatížením a ujistěte se, že poskytuje požadované vyrovnání. Abyste dosáhli požadované vyrovnání, upravte počet front a počet instancí služby, které zpracovávají zprávy.

• Fronty zpráv jsou jednosměrným komunikačním mechanismem. Pokud úloha očekává odpověď ze služby, možná budete muset implementovat mechanismus, který může služba použít k odeslání odpovědi. Další informace najdete v tématu Asynchronní zasílání zpráv v Azure.

• Automatické škálování bez omezení souhrnné rychlosti požadavků konzumentů směrem na navazující služby jen přesouvá přetížení na navazující závislosti. Toto přetížení může zvýšit soutěžení o prostředky, které tyto služby sdílejí, a snížit schopnost fronty vyrovnávat zatížení.

• Pokud průměrná rychlost producenta překročí rychlost konzumenta, fronta bude dál narůstat a latence se zvýší. Monitorujte hloubku fronty a škálujte uživatele v rámci bezpečných limitů nebo pracujte u producenta.

• Tento vzor spoléhá na trvalost fronty, aby nedošlo ke ztrátě zpráv. Pokud broker neukládá zprávy do trvalého úložiště, může pád nebo omezení kapacity způsobit ztrátu dat zařazených do fronty dříve, než je příjemci zpracují. Zvolte službu front, která trvale ukládá zprávy na disk nebo do replikovaného úložiště, a seznamte se s jejími kvótami velikosti a limity doby uchovávání. U úloh, které vyžadují, aby zprávy přežily regionální selhání, vyhodnoťte možnosti geografického zotavení po havárii.

• Většina služeb fronty doručuje zprávy s alespoň jednou sémantikou, což znamená, že příjemci mohou přijímat stejnou zprávu více než jednou. Navrhujte logiku příjemce tak, aby byla idempotentní , aby zpracování stejné zprávy vícekrát vytvořilo stejný výsledek a zabránilo problémům, jako jsou duplicitní záznamy nebo opakované poplatky.

• Některé zprávy se nedají zpracovat, protože obsahují poškozená data, odkazovat na chybějící prostředky nebo aktivovat trvalé chyby. Místo aby tyto zprávy donekonečna kolovaly a blokovaly frontu, směrujte je do fronty nedoručitelných zpráv. Sledujte hloubku fronty nedoručených zpráv, aby váš provozní tým mohl v případě potřeby prošetřit chyby, opravit související problém a znovu odeslat zprávy.

• Zavedení fronty mezi producentem a příjemcem nezachovává původní pořadí odeslání za všech podmínek, zejména v případě, že několik příjemců zpracovává zprávy paralelně. Pokud vaše pracovní zátěž vyžaduje přísné pořadí, použijte funkce, jako jsou relace zpráv, ve službě Azure Service Bus. Pokud není vyžadováno striktní řazení, navrhněte uživatele tak, aby zpracovávali zprávy v libovolném pořadí, což zjednodušuje škálování.

Kdy použít tento vzor

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

• Vaše úlohy vykazují nárazové špičky, které mohou zahltit navazující služby.

• Abyste zlepšili odolnost a řízení nákladů, musíte oddělit příjem požadavků od propustnosti zpracování.

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

• Volající vyžaduje synchronní odpověď s nízkou latencí.

• Objem zátěže je předvídatelně nízký a stabilní, takže zavedení složitějšího frontování přináší jen malý užitek.

Návrh úloh

Vyhodnoťte, jak použít model vyrovnávání zatížení Queue-Based v návrhu úlohy k řešení cílů a principů popsaných v pilířích Azure Well-Architected Framework. 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.	Přístup, který tento model popisuje, může zajistit odolnost proti náhlému nárůstu poptávky oddělením příchodu úkolů od jejich zpracování. Může také izolovat poruchy zpracování fronty, aby neovlivňovaly vstupní proces. - RE:06 Škálování
Optimalizace nákladů se zaměřuje na udržení a zlepšenínávratnosti vašich úloh.	Vzhledem k tomu, že zpracování zatížení je oddělené od požadavku nebo příjmu úkolů, můžete pomocí tohoto přístupu snížit potřebu nadměrného zřízení prostředků pro zpracování zatížení ve špičce. - CO:12 Náklady na škálování
efektivita výkonu pomáhá vašim úlohám efektivně splňovat požadavky prostřednictvím optimalizací škálování, dat a kódu.	Tento přístup umožňuje záměrný návrh výkonu propustnosti, protože příjem požadavků nemusí korelovat s rychlostí zpracování. - PE:05 Škálování a dělení

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

Example

Webová aplikace zapisuje data do externího úložiště dat. Pokud několik instancí webové aplikace běží souběžně, úložiště dat nemusí dostatečně rychle reagovat na požadavky, což způsobí vypršení časového limitu požadavků, omezení nebo selhání. Následující diagram znázorňuje úložiště dat zahlcené souběžnými požadavky z instancí aplikace.

V diagramu ukazují šipky z několika svisle skládaných Azure App Service ikon instancí na jednu ikonu úložiště dat. Některé instance služby App Service se úspěšně připojují k úložišti dat. Dvě z instancí zobrazují vypršení časového limitu se symbolem blokovaného připojení, který značí, že pokus o připojení selhal.

Chcete-li tento problém vyřešit, použijte frontu k vyrovnání zatížení mezi instancemi aplikace a úložištěm dat. Aplikace Azure Functions čte zprávy z fronty Service Bus a zpracovává požadavky na čtení a zápis do úložiště dat. Azure Functions může škálovat instance na základě Service Bus backlogu pomocí cílového škálování v rámci nakonfigurovaných hranic škálování. Můžete také ladit nastavení souběžnosti triggerů pro ochranu úložiště dat. Pokyny k implementaci najdete v tématu Škálování na základě cílů a omezení horizontálního navýšení kapacity. Bez tohoto ladění může pracovní vrstva znovu zavést back-endové kolize.

Na diagramu šipky směřují od několika svisle uspořádaných ikon instancí služby App Service k frontě zpráv služby Service Bus. Další šipka vede z fronty zpráv přes funkční aplikaci do úložiště dat.

Jako technologickou variantu můžete implementovat stejný vzor pomocí Azure Container Apps místo Azure Functions. V takovém případě kontejnerizovaný pracovní proces spotřebovává zprávy z Service Bus a zapisuje do úložiště dat. Container Apps škáluje pracovní proces mezi nakonfigurovaným minimálním a maximálním počtem replik na základě pravidel škálování souvisejících s frontou. Stejný přístup můžete implementovat také pomocí Azure Queue Storage jako zdroj událostí. Pokyny k implementaci najdete v tématu Nastavení pravidel škálování v Container Apps a nasazení úlohy řízené událostmi pomocí Container Apps.

Další kroky

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

• Asynchronní zasílání zpráv v Azure: Fronty zpráv jsou ze své podstaty asynchronní. Pokud aplikace komunikuje přímo se službou, může být potřeba přepracovat logiku aplikace úlohy. Podobně může být nutné refaktorovat službu tak, aby přijímala požadavky z fronty zpráv.

• Choose mezi službami zasílání zpráv Azure: Získejte další informace, které vám pomůžou zvolit mechanismus zasílání zpráv a řazení do front v aplikacích Azure.

• Doporučení pro vývoj úloh na pozadí: Tento model použijte u úloh na pozadí, aby fronty zpráv mohly ukládat požadavky na úlohy na pozadí, když aplikace má vysoké zatížení.

• Styl architektury Web-Queue-Worker: Web i pracovní proces jsou bezstavové. Stav relace může být ukládán v distribuované mezipaměti. Worker provádí dlouhotrvající úlohy asynchronně a lze ho aktivovat zprávami z fronty nebo spouštět podle plánu pro dávkové zpracování.

Související prostředky

• Vzor konkurujících si příjemců: Je možné spustit více instancí služby, z nichž každá slouží jako příjemce zpráv z fronty pro vyrovnávání zatížení. Tento přístup můžete použít k úpravě rychlosti, kterou se zprávy přijímají a následně předávají službě.

• Vzor omezování: Jednoduchým způsobem, jak implementovat omezování ve službě, je použít vyrovnávání zátěže pomocí fronty a směrovat všechny požadavky na službu prostřednictvím fronty zpráv. Služba může zpracovávat požadavky rychlostí, která zajišťuje, že nevyčerpá prostředky, které potřebuje, a snižuje množství možných kolizí.