Vzor škrcení

Azure

Řídí spotřebu prostředků používaných instancí aplikace, jednotlivým tenantem nebo celou služby. To může systému umožnit, aby i nadále fungoval a splňoval cíle na úrovni služeb (SLO), i když zvýšení poptávky představuje extrémní 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 na zpracování systému překračují kapacitu dostupných prostředků, dojde k nízkému výkonu a může dokonce 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 cíle na úrovni služeb (SLO), 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 směsici tenantů s různými úrovněmi SLA, může být práce pro tenanty s vysokou hodnotou provedena okamžitě. Žádosti ostatních tenantů mohou být pozdrženy a zpracovány, až se uvolní kapacity. Vzorek Prioritní fronty by mohl být použit k tomu, aby pomohl implementovat tento přístup, a také umožnit zveřejnění různých koncových bodů pro různé úrovně nebo priority služeb.

• Odložení operací prováděných ve prospěch 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. Jakmile budou požadavky úspěšně zpracovány, vraťte se k běžnému zpracování požadavků bez omezení. 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.

Předchozí obrázek znázorňuje účinky odkládání operací. Těsně před časem T1 dosáhne celkové množství prostředků přidělených všem aplikacím, které tyto funkce používají, prahovou hodnotu. Tato prahová hodnota představuje limit použ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 horizontálně. V této fázi 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í měkký limit pro využití prostředků. V tomto okamžiku může systém začít škálovat horizontálně. Pokud ale nové prostředky nebudou dostatečně rychle dostupné, stávající prostředky se mohou vyčerpat 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, která se má použít, je rozhodnutí o architektuře, které ovlivňuje celý návrh systému. Omezení výkonu by mělo být zváženo v rané fázi návrhu aplikace, protože není snadné ho přidat po implementaci systému.

• Regulace 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í častěji, než se očekávalo.

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í výkonu lze použít jakožto dočasné opatření při automatickém škálování systému. V některých případech je lepší omezit, než navyšovat kapacitu, pokud je nárůst aktivity náhlý a neočekává se, že bude trvat, protože navyšování může výrazně zvýšit provozní náklady.

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

• Normalizujte náklady na zdroje pro různé operace, protože obecně nemají stejné náklady na provedení. Například limity omezování můžou být nižší pro operace čtení a vyšší pro operace zápisu. Bez ohledu na náklady operace může dojít k vyčerpání kapacity a vystavení potenciálnímu vektorovému útoku.

• Je žádoucí, aby dynamické změny chování přiškrcení při běhu bylo možné provádět. 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ím vzoru externího úložiště konfigurace je konfigurace omezení externalizována a může být změněna a aplikována bez nutnosti nasazení.

Kdy se má tento model použít

Použijte tento model:

• Aby se zajistilo, že systém bude i nadále splňovat cíle na úrovni služeb (SLA).

• Nechcete, aby si jediný tenant přivlastnil prostředky poskytované aplikací.

• Pro zvládnutí náhlého zvýšení aktivity.

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

• Snížit nízkoprioritní výpočetní zpracování během období vysoké uhlíkové intenzity v elektrické síti.

Návrh úloh

Architekt by měl vyhodnotit způsob použití modelu omezování v návrhu úlohy k řešení cílů a principů popsaných v pilířích architektury Azure Well-Architected. 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 vzor můžete také použít jako kontrolní mechanismus v plánu plynulého snižování 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

Poslední diagram znázorňuje, jak lze škrcení výkonu implementovat v systému s multi-uživatelským prostředím. 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 intenzivně je služba využívána. 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 mohou být užitečné při rozhodování o regulaci poskytování služby.
• Pokyny k automatickému škálování: Škrcení výkonu můžete použít jako dočasné opatření během automatického škálování systému, nebo jako alternativu k odstranění potřeby, aby systém prováděl automatické škálování. 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í zátěže založený na frontě Vyrovnávání zatížení na základě fronty je běžně používaný mechanismus pro implementaci omezení. Fronta žádostí může fungovat jako vyrovnávací paměť, která pomáhá vyhladit rychlost, s jakou se doručují žádosti odeslané aplikací do služby.
• Model prioritní fronty: Systém může použít prioritní frontování jako součást strategie řízení, aby bylo možné zachovat výkon pro kritické nebo vyšší hodnotové aplikace, zatímco se snižuje výkon aplikací méně důležitých.
• Vzorec 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, která novou konfiguraci aplikuje okamžitě, aby se stabilizoval systém.

Řídí spotřebu prostředků používaných instancí aplikace, jednotlivým tenantem nebo celou služby. To může systému umožnit, aby i nadále fungoval a splňoval cíle na úrovni služeb (SLO), i když zvýšení poptávky představuje extrémní 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 na zpracování systému překračují kapacitu dostupných prostředků, dojde k nízkému výkonu a může dokonce 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 cíle na úrovni služeb (SLO), 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 směsici tenantů s různými úrovněmi SLA, může být práce pro tenanty s vysokou hodnotou provedena okamžitě. Žádosti ostatních tenantů mohou být pozdrženy a zpracovány, až se uvolní kapacity. Vzorek Prioritní fronty by mohl být použit k tomu, aby pomohl implementovat tento přístup, a také umožnit zveřejnění různých koncových bodů pro různé úrovně nebo priority služeb.

• Odložení operací prováděných ve prospěch 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. Jakmile budou požadavky úspěšně zpracovány, vraťte se k běžnému zpracování požadavků bez omezení. 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.

Předchozí obrázek znázorňuje účinky odkládání operací. Těsně před časem T1 dosáhne celkové množství prostředků přidělených všem aplikacím, které tyto funkce používají, prahovou hodnotu. Tato prahová hodnota představuje limit použ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 horizontálně. V této fázi 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í měkký limit pro využití prostředků. V tomto okamžiku může systém začít škálovat horizontálně. Pokud ale nové prostředky nebudou dostatečně rychle dostupné, stávající prostředky se mohou vyčerpat 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, která se má použít, je rozhodnutí o architektuře, které ovlivňuje celý návrh systému. Omezení výkonu by mělo být zváženo v rané fázi návrhu aplikace, protože není snadné ho přidat po implementaci systému.

• Regulace 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í častěji, než se očekávalo.

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í výkonu lze použít jakožto dočasné opatření při automatickém škálování systému. V některých případech je lepší omezit, než navyšovat kapacitu, pokud je nárůst aktivity náhlý a neočekává se, že bude trvat, protože navyšování může výrazně zvýšit provozní náklady.

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

• Normalizujte náklady na zdroje pro různé operace, protože obecně nemají stejné náklady na provedení. Například limity omezování můžou být nižší pro operace čtení a vyšší pro operace zápisu. Bez ohledu na náklady operace může dojít k vyčerpání kapacity a vystavení potenciálnímu vektorovému útoku.

• Je žádoucí, aby dynamické změny chování přiškrcení při běhu bylo možné provádět. 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ím vzoru externího úložiště konfigurace je konfigurace omezení externalizována a může být změněna a aplikována bez nutnosti nasazení.

Kdy se má tento model použít

Použijte tento model:

• Aby se zajistilo, že systém bude i nadále splňovat cíle na úrovni služeb (SLA).

• Nechcete, aby si jediný tenant přivlastnil prostředky poskytované aplikací.

• Pro zvládnutí náhlého zvýšení aktivity.

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

• Snížit nízkoprioritní výpočetní zpracování během období vysoké uhlíkové intenzity v elektrické síti.

Návrh úloh

Architekt by měl vyhodnotit způsob použití modelu omezování v návrhu úlohy k řešení cílů a principů popsaných v pilířích architektury Azure Well-Architected. 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 vzor můžete také použít jako kontrolní mechanismus v plánu plynulého snižování 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

Poslední diagram znázorňuje, jak lze škrcení výkonu implementovat v systému s multi-uživatelským prostředím. 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 intenzivně je služba využívána. 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 mohou být užitečné při rozhodování o regulaci poskytování služby.
• Pokyny k automatickému škálování: Škrcení výkonu můžete použít jako dočasné opatření během automatického škálování systému, nebo jako alternativu k odstranění potřeby, aby systém prováděl automatické škálování. 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í zátěže založený na frontě Vyrovnávání zatížení na základě fronty je běžně používaný mechanismus pro implementaci omezení. Fronta žádostí může fungovat jako vyrovnávací paměť, která pomáhá vyhladit rychlost, s jakou se doručují žádosti odeslané aplikací do služby.
• Model prioritní fronty: Systém může použít prioritní frontování jako součást strategie řízení, aby bylo možné zachovat výkon pro kritické nebo vyšší hodnotové aplikace, zatímco se snižuje výkon aplikací méně důležitých.
• Vzorec 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, která novou konfiguraci aplikuje okamžitě, aby se stabilizoval systém.