Řídí spotřebu prostředků používaných instancí aplikace, jednotlivým tenantem nebo celou služby. Takto může mít systém možnost dál fungovat a vyhovět podmínkám smluv o úrovni služeb, a to i tehdy, když se díky zvýšení poptávky výrazně zvýší zatížení prostředků.
Kontext a problém
Zatížení cloudové aplikace se obvykle v průběhu času liší podle počtu aktivních uživatelů nebo typů aktivit, které provádějí. Více uživatelů bude pravděpodobně aktivních například během pracovní doby nebo se může požadovat, aby systém prováděl na konci každého měsíce analýzy náročné na výpočetní prostředky. Může také docházet k náhlým a neočekávaným nárůstům aktivity. Pokud požadavky systému na zpracování překročí kapacitu prostředků, které jsou k dispozici, bude mít systém nízký výkon a může i selhat. Pokud má systém dosáhnout domluvené úrovně služby, může být takové selhání nepřijatelné.
Existuje mnoho strategií pro zpracování různých zatížení v cloudu v závislosti na obchodních cílech aplikace. Jednou z strategií je použití automatického škálování tak, aby odpovídalo zřízeným prostředkům potřebám uživatele v daném okamžiku. Toto řešení má potenciál konzistentně vyhovět poptávce uživatelů a současně optimalizovat provozní náklady. Zatímco automatické škálování může aktivovat zřizování dalších prostředků, toto zřizování není okamžité. Jestliže poptávka rychle roste, může vzniknout časové okno, během kterého nebude prostředek postačovat.
Řešení
Alternativní strategií k automatickému škálování je dát aplikacím možnost používat prostředky do té doby, než dosáhnou určitého limitu, a pak je omezit. Systém by měl použití prostředků sledovat, aby v okamžiku, kdy použití přesáhne prahovou hodnotu, mohl žádosti od jednoho nebo více uživatelů omezit. To umožňuje systému pokračovat v fungování a splňovat všechny smlouvy o úrovni služeb (SLA), které jsou zavedeny. Další informace o sledování využití prostředků najdete v pokynech pro instrumentaci a telemetrii.
V systému je možné implementovat několik strategií omezení, včetně následujících:
Odmítnutí žádostí od jednotlivých uživatelů, kteří už získali v daném časovém období přístup do rozhraní API systému vícekrát za sekundu, než umožňuje stanovený limit. U tohoto řešení musí systém měřit využívání prostředků u jednotlivých tenantů nebo uživatelů, kteří používají aplikaci. Další informace najdete v pokynech k měření služby.
Zakázání nebo snížení úrovně funkcí u vybraných služeb, které nejsou životně nezbytné tak, aby mohly životně důležité služby běžet bez překážky s dostatečnými prostředky. Pokud například aplikace streamuje výstup videa, bylo by možné přepnout na nižší rozlišení.
Použití vyrovnávání zatížení k vyladění objemu aktivity (tento přístup je podrobněji popsaný v informacích o modelu vyrovnávání zatížení na základě fronty). V prostředí s více tenanty tento přístup sníží výkon pro každého tenanta. Pokud systém musí podporovat kombinaci tenantů s různými smlouvami SLA, je možné, že zpracuje okamžitě tenanty s vysokou hodnotou. Žádosti ostatních tenantů se můžou pozastavit s tím, že se zpracují, až ubudou nevyřízené položky. Model Prioritní fronta by mohl pomoct s implementací tohoto přístupu, protože by mohl vystavit různé koncové body pro různé úrovně nebo priority služeb.
Odložení prováděných operací u aplikací nebo tenantů s nižší prioritou. Tyto operace se můžou pozastavit nebo omezit s výjimkou vygenerovanou pro účely informování tenanta o tom, že systém je zaneprázdněný a že se má operace zkusit opakovat později.
Při integraci s některými službami třetích stran, které můžou být nedostupné nebo vracející chyby, byste měli být opatrní. Snižte počet zpracovávaných souběžných požadavků, aby se protokoly zbytečně nevyplnily chybami. Také se vyhnete nákladům, které jsou spojené s nepotřebným opakováním zpracování požadavků, které by kvůli této službě třetí strany selhaly. Po úspěšném zpracování požadavků se pak vraťte k běžnému nezřízené zpracování požadavků. Jednou z knihoven, která tuto funkci implementuje, je NServiceBus.
Obrázek zobrazuje plošný graf využití prostředků (kombinace paměti, procesoru, šířky pásma a dalších faktorů) v čase pro aplikace, které používají tři funkce. Funkce představuje funkční oblast, jako je například komponenta, která provádí určitou sadu úloh, část kódu, který provádí složité výpočty, nebo element, který poskytuje službu, jako je například ukládání do mezipaměti. Tyto funkce se označují jako A, B a C.
Oblast bezprostředně pod řádkem funkce obsahuje informace o prostředcích, které využívají aplikace při volání této funkce. Například oblast pod řádkem Funkce A ukazuje prostředky používané aplikacemi, které používají funkci A, a oblast mezi řádky funkce A a funkce B určuje prostředky používané aplikacemi volajícími funkci B. Sečtením oblastí jednotlivých funkcí dostaneme celkové využití prostředků v systému.
Na předchozím obrázku vidíte, jaký dopad má odložení operací. Před časem T1 dosáhlo celkové množství prostředků přidělených všem aplikacím, které používají tyto funkce, prahové hodnoty (limit využití prostředků). V tomto okamžiku existuje nebezpečí, že aplikace vyčerpají dostupné zdroje. V tomto systému je Funkce B méně kritická než Funkce A nebo Funkce C, takže se dočasně zakáže a uvolní se prostředky, které používala. Mezi dobou T1 a T2 poběží aplikace, které používají Funkci A a Funkci C, jako obvykle. Využití prostředků těchto dvou funkcí se nakonec sníží natolik, že v čase T2 bude k dispozici dostatečná kapacita, aby bylo možné znovu povolit Funkci B.
Přístupy s automatickým škálováním a omezováním můžete také kombinovat, což může u aplikací pomoci při zajištění schopnosti dobře reagovat a současně dodržet podmínky SLA. Pokud se očekává, že poptávka zůstane vysoká, poskytuje omezování dočasné řešení, zatímco se systém škáluje na více instancí. V tomto okamžiku je možné obnovit plnou funkčnost systému.
Na následujícím obrázku vidíte plošný graf s celkovým využitím prostředků všemi aplikacemi spuštěnými v systému v určitém čase a to, jak je možné kombinovat omezení s automatickým škálováním.
V čase T1 bylo dosaženo prahové hodnoty určující doporučeného limitu pro použití prostředku. V tomto okamžiku může systém začít škálovat na více instancí. Pokud ale nové prostředky nebudou dostatečně rychle dostupné, můžou být stávající prostředky vyčerpány a systém může selhat. Aby k tomu nedošlo, systém se dočasně omezí výše popsaným způsobem. Po dokončení automatického škálování a dostupnosti dalších prostředků je možné uvolnit omezování.
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:
Omezení aplikace a strategie použití je rozhodnutí o architektuře, které má vliv na návrh celého systému. Možnost použití omezení je nutné zvážit v procesu návrhu aplikace včas, protože není jednoduché ho přidat po implementaci systému.
Omezení se musí provést rychle. Systém musí být schopný zjistit zvýšení aktivity a odpovídajícím způsobem reagovat. Systém také musí být schopný se rychle vrátit do původního stavu, když se zatížení sníží. K tomu je potřeba průběžně zachytávat a sledovat odpovídající data výkonu.
Pokud služba potřebuje požadavek uživatele dočasně odepřít, měl by vrátit konkrétní kód chyby, jako je 429 (Příliš mnoho požadavků) a 503 (Server je příliš zaneprázdněn), aby klientská aplikace pochopila, že důvodem odmítnutí žádosti je omezení.
- HTTP 429 označuje, že volající aplikace odeslala příliš mnoho požadavků v časovém intervalu a překročila předem určený limit.
- HTTP 503 znamená, že služba není připravená zpracovat požadavek. Běžnou příčinou je, že u služby dochází k dočasným špičkám zatížení, než se čekalo.
Klientská aplikace může nějakou dobu počkat a pak zkusit žádost znovu odeslat. Měla by být zahrnuta hlavička Retry-After HTTP, která podporuje klienta při výběru strategie opakování.
Omezení se dá použít jako dočasné opatření při automatickém škálování systému. V některýchpřípadechch zařízeních je v některých případech lepší jednoduše sníži
Pokud se omezování používá jako dočasná míra, zatímco se systém automaticky škáluje, a pokud se požadavky na prostředky velmi rychle zvětšují, systém nemusí být schopný pokračovat v fungování – i když pracuje v omezeném režimu. Pokud tato situace není přijatelná, zvažte možnost údržby větší rezervní kapacity a konfigurace aktivnějšího automatického škálování.
Normalizujete náklady na prostředky pro různé operace, protože obvykle nemají stejné náklady na provádění. Například limity omezování můžou být nižší pro operace čtení a vyšší pro operace zápisu. Vzhledem k nákladům na operaci může dojít k vyčerpání kapacity a vystavení potenciálního vektoru útoku.
Dynamická změna chování omezování za běhu je žádoucí. Pokud systém čelí neobvyklému zatížení, které použitá konfigurace nedokáže zpracovat, může být potřeba zvýšit nebo snížit omezení, aby se systém stabilizuje a udržel krok s aktuálním provozem. V tuto chvíli není žádoucí nákladné, rizikové a pomalé nasazení. Použití konfigurace omezování externího úložiště konfigurace je externalizováno a lze ho změnit a použít bez nasazení.
Kdy se má tento model použít
Použijte tento model:
Chcete zajistit, že bude systém nadále vyhovovat podmínkám smlouvy o úrovni služeb.
Nechcete, aby si jediný tenant přivlastnil prostředky poskytované aplikací.
Chcete zvládnout velký nárůst aktivit.
Chcete pomoci optimalizovat náklady na systém na základě omezení maximálních úrovní prostředků potřebných k zajištění fungování systému.
Návrh úloh
Architekt by měl vyhodnotit, jak lze model omezování použít 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. | Navrhujete limity, které vám pomůžou zabránit vyčerpání prostředků, které můžou vést k poruchám. Tento model můžete také použít jako řídicí mechanismus v plánu řádného snížení výkonu. - RE:07 Sebezáchování |
| Rozhodnutí o návrhu zabezpečení pomáhají zajistit důvěrnost, integritu a dostupnost dat a systémů vaší úlohy. | Limity můžete navrhnout tak, aby se zabránilo vyčerpání prostředků, které by mohly vést k automatickému zneužití systému. - SE:06 Řízení sítě - SE:08 Posílení zabezpečení prostředků |
| Optimalizace nákladů se zaměřuje na udržení a zlepšení návratnosti vašich úloh. | Vynucené limity můžou informovat modelování nákladů a mohou být dokonce přímo svázané s obchodním modelem vaší aplikace. Také dávají jasné horní hranice využití, které je možné zohlednit do velikosti prostředků. - CO:02 Model nákladů - 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. | Když je systém pod vysokou poptávkou, tento model pomáhá zmírnit přetížení, které může vést k kritickým bodům výkonu. Můžete ho také použít k proaktivnímu zabránění hlučným scénářům sousedů. - PE:02 Plánování kapacity - 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
Konečný obrázek znázorňuje, jak lze omezení implementovat v systému s více tenanty. Uživatelé z jednotlivých organizací tenanta získávají přístup k aplikaci hostované v cloudu, kde vyplňují a odesílají průzkumy. Aplikace obsahuje instrumentaci, která sleduje rychlost, jakou tito uživatelé posílají žádosti do aplikace.
Pokud chcete zabránit tomu, aby měli uživatelé z jednoho tenanta vliv na rychlost reakce a dostupnost aplikace pro všechny ostatní uživatele, použije se omezení počtu žádostí za sekundu, které můžou poslat uživatelé z jednoho tenanta. Aplikace blokuje žádosti, které toto omezení překročí.
Další kroky
Při implementaci tohoto modelu můžou být relevantní také následující pokyny:
- Pokyny pro instrumentaci a telemetrii. Omezení závisí na shromažďování informací o tom, jak často se služba používá. Popisuje, jak vygenerovat a zaznamenat vlastní informace týkající se sledování.
- Pokyny k měření služby: Popisuje, jak měřit využití služeb, abyste získali přehled o tom, jak se používají. Tyto informace můžou být užitečné při určování způsobu omezení služby.
- Pokyny k automatickému škálování: Omezení můžete použít jako dočasné opatření, když systém provádí škálování nebo když chcete v systému potřebu škálování zrušit. Obsahuje informace o strategiích automatického škálování.
Související prostředky
Při implementaci tohoto modelu můžou být relevantní také následující vzory:
- Model vyrovnávání zatížení na základě fronty: Vyrovnávání zatížení na základě fronty je běžně používaný mechanismus pro implementaci omezení. Fronta může fungovat jako vyrovnávací paměť, která pomáhá vyrovnat rychlost, s jakou se doručují žádosti odeslané aplikací do služby.
- Model prioritní fronty: Systém může použít prioritní fronty jako součást strategie omezení, aby bylo možné zachovat výkon pro aplikace zásadní důležitosti nebo aplikace vyšší hodnoty, když se snižuje výkon méně důležitých aplikací.
- Model externího úložiště konfigurace Centralizace a externalizace zásad omezování poskytuje možnost změnit konfiguraci za běhu bez nutnosti opětovného nasazení. Služby se můžou přihlásit k odběru změn konfigurace, a tím okamžitě použít novou konfiguraci ke stabilizaci systému.