Frontu, která funguje jako vyrovnávací paměť mezi úlohou a službou, kterou vyvolá, použijte k hladkému přerušovanému vysokému zatížení, které může způsobit selhání služby nebo vypršení časového limitu úlohy. To může pomoct minimalizovat dopad špiček na poptávku po dostupnosti a odezvě pro úlohu i službu.
Kontext a problém
Mnoho řešení v cloudu zahrnuje spuštěné úlohy, které vyvolávají služby. Pokud je služba v takovém prostředí vystavena skokovým vysokým zatížením, může to způsobit problémy s výkonem nebo spolehlivostí.
Služba může být součástí stejného řešení jako úlohy, které ji používají, nebo může jít o službu třetí strany poskytující přístup k často používaným prostředkům, jako je mezipaměť nebo služba úložiště. Pokud stejnou službu používá několik současně spuštěných úloh, může být obtížné odhadnout množství žádostí, které bude muset služba v libovolné době zpracovat.
Ve službě může docházet ke špičkám v poptávce, které ji přetíží, a služba potom nebude moct včasně na žádosti reagovat. Zahlcení služby velkým počtem souběžných žádostí může také způsobit selhání služby, pokud nezvládne zpracovat kolizi, kterou tyto žádosti způsobují.
Řešení
Řešení refaktorujte a mezi úlohu a službu zaveďte frontu. Úloha a služba poběží asynchronně. Úloha odešle zprávu obsahující data vyžadovaná službou do fronty. Fronta funguje jako vyrovnávací paměť – uloží zprávu, dokud ji nenačte služba. Služba načte zprávy z fronty a zpracuje je. Žádosti z několika úloh, které je možné generovat velmi proměnlivou rychlostí, je možné službě odeslat prostřednictvím stejné fronty zpráv. Následující obrázek ukazuje použití fronty k vyrovnání zátěže působící na službu.
Fronta odpojí úlohy od služby a služba může zprávy zpracovávat vlastním tempem bez ohledu na množství žádostí ze souběžných úloh. Navíc nevzniká žádné zpoždění úlohy. Když není služba dostupná, zpráva se odešle do fronty.
Tento model má následující výhody:
Může pomoct maximalizovat dostupnost, protože zpoždění vznikající ve službách nebudou mít okamžitý a přímý vliv na aplikaci, která může nadále odesílat zprávy do fronty, i když služba není dostupná nebo aktuálně zprávy nezpracovává.
Může pomoct maximalizovat škálovatelnost, protože jak počet front, tak počet služeb je možné podle potřeby měnit.
Může také pomoct snížit náklady, protože počet nasazených instancí služby nemusí být tak vysoký, aby splňoval špičkovou zátěž, ale stačí aby splňoval pouze průměrnou zátěž.
Některé služby implementují omezení využití sítě, když poptávka dosáhne prahové hodnoty, za kterou by systém mohl selhat. Omezení využití sítě může omezit dostupné funkce. Pokud chcete zajistit, aby k dosažení této prahové hodnoty nedošlo, můžete u těchto služeb implementovat vyrovnávání zátěže.
Problémy a důležité informace
Když se budete rozhodovat, jak tento model implementovat, měli byste vzít v úvahu následující skutečnosti:
- Musíte implementovat logiku aplikace, která ovládá rychlost zpracování zpráv službami, 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 zátěží, abyste se ujistili, že poskytuje dostatečné vyrovnávání zátěže, a pokud tomu tak není, upravte počet front a počet instancí služby, které zpracovávají zprávy, abyste dostatečného vyrovnávání zátěže dosáhli.
- Fronty zpráv jsou jednosměrným komunikačním mechanismem. Pokud úloha očekává od služby odpověď, budete nejspíš muset implementovat mechanismus, který může služba použít k odeslání odpovědi. Další informace najdete v úvodu k asynchronnímu zasílání zpráv.
- Pokud použijete automatické škálování na služby, které naslouchají žádostem ve frontě, buďte opatrní. Může to způsobit zvýšenou kolizi libovolných prostředků, které tyto služby sdílí, a snížit efektivitu používání fronty k vyrovnání zátěže.
- V závislosti na zatížení služby můžete narazit na situaci, kdy jste v podstatě vždy na konci, kde systém vždy začíná do fronty více požadavků, než zpracováváte. Je třeba vzít v úvahu proměnlivost příchozího provozu do vaší aplikace.
- Vzor může ztratit informace v závislosti na trvalosti fronty. Pokud se vaše fronta chybově ukončí nebo zahodí informace (kvůli systémovým limitům), je možné, že nemáte zaručené doručení. Na základě potřeb vašeho řešení je potřeba vzít v úvahu chování fronty a systémových limitů.
Kdy se má tento model použít
Tento model je vhodný pro každou aplikaci používající služby, které podléhají přetížení.
Tento model není vhodný, pokud aplikace ze služby očekává odpověď s minimální latencí.
Návrh úloh
Architekt by měl vyhodnotit způsob použití modelu vyrovnávání zatížení na základě fronty v návrhu úlohy k řešení cílů a principů popsaných v pilířích architektury Azure Well-Architected Framework. Příklad:
| Pilíř | Jak tento model podporuje cíle pilíře |
|---|---|
| Rozhodnutí o návrhu spolehlivosti pomáhají vaší úloze stát se odolnou proti selhání a zajistit, aby se po selhání obnovila do plně funkčního stavu. | Přístup popsaný v tomto modelu 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 příjem. - RE:06 Škálování - RE:07 Úlohy na pozadí |
| 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ší úloze 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í, ve které se zpracovávají. - PE:05 Škálování a dělení |
Stejně jako u jakéhokoli rozhodnutí o návrhu zvažte jakékoli kompromisy proti cílům ostatních pilířů, které by mohly být s tímto vzorem zavedeny.
Příklad
Webová aplikace zapisuje data do externího úložiště dat. Pokud se souběžně spouští velký počet instancí webové aplikace, ú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 zahlcení úložiště dat velkým počtem souběžných požadavků z instancí aplikace.
K vyřešení tohoto problému můžete použít frontu k vyrovnání zatížení mezi instancemi aplikace a úložištěm dat. Aplikace Azure Functions čte zprávy z fronty a provádí požadavky na čtení a zápis do úložiště dat. Logika aplikace v aplikaci funkcí může řídit rychlost, s jakou předává požadavky do úložiště dat, aby se zabránilo zahlcení úložiště. (V opačném případě aplikace funkcí znovu zavede stejný problém na back-endu.)
Další kroky
Při implementaci tohoto modelu můžou být relevantní také následující pokyny:
Úvod k asynchronnímu zasílání zpráv: Fronty zpráv jsou ze své podstaty asynchronní. Pokud upravíte úlohu z komunikování přímo se službou na používání fronty zpráv, budete muset nejspíš změnit její logiku aplikace. Podobně nejspíš budete muset refaktorovat službu, aby přijímala žádosti z fronty zpráv. Případně ještě můžete implementovat službu proxy, jak je popsáno v příkladu výše.
Vyberte si mezi službami zasílání zpráv Azure. Informace o volbě mechanismu pro zasílání zpráv a řazení do front v aplikacích Azure.
Související prostředky
- Styl architektury Web-Queue-Worker Web i pracovní proces jsou bezstavové. Stav relace může být ukládán v distribuované mezipaměti. Veškeré dlouhotrvající pracovní postupy provádí asynchronně pracovní proces. Pracovní proces může být aktivován zprávou ve frontě, nebo může být spouštěn podle plánu pro dávkové zpracování.
Při implementaci tohoto modelu můžou být relevantní také následující vzory:
Model konkurenčních spotřebitelů: Můžete spustit několik instancí služby, kdy se každá instance bude chovat jako příjemce zprávy z fronty pro vyrovnávání zátěže. 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ě.
Model omezení využití sítě. Jednoduchým způsobem, jak do služby implementovat omezení využití sítě, je použití vyrovnávání zatížení na základě fronty a směrování všech žádostí do služby prostřednictvím fronty zpráv. Služba může žádosti zpracovat takovou rychlostí, která zajistí, že se prostředky vyžadované službou nevyčerpají a množství případných kolizí se sníží.