Model vyrovnávání zatížení na základě fronty

Použijte frontu, která funguje jako vyrovnávací paměť mezi úlohou a službou, kterou vyvolá, aby se přerušovaná vysoká zatížení, která může způsobit selhání služby nebo časový limit úkolu. To může pomoct minimalizovat dopad špičky v poptávce na dostupnost a rychlost odezvy 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.
• Dejte si pozor na použití automatického škálování u služeb, které naslouchají žádostem ve frontě. 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.

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í.

Příklad

Webová aplikace zapisuje data do externího úložiště dat. Pokud současně běží velký počet instancí webové aplikace, úložiště dat nemusí dostatečně rychle reagovat na požadavky, což způsobí časový limit požadavků, omezení nebo jiné 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.

Pokud chcete tento problém vyřešit, můžete použít frontu k vyrovnání zatížení mezi instancemi aplikace a úložištěm dat. Aplikace Azure Functions zprávy z fronty a provádí požadavky na čtení a zápis do úložiště dat. Aplikační logika 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ě bude aplikace funkcí na straně back-endu znovu zavádět stejný problém.)

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.

• Vylepšení škálovatelnosti ve webové aplikaci Azure. Tato referenční architektura zahrnuje vyrovnávání zatížení na základě fronty jako součást architektury.

Související informace

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íží.