Model omezení využití sítě

Ří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í aplikace v cloudu se obvykle postupem času mění podle toho, kolik uživatelů je aktivních, nebo podle typů činností, 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é.

K dispozici je mnoho strategií pro zpracování proměnlivé zátěže v cloudu, které u konkrétní aplikace závisí na podnikových cílech. Jednou z možných strategií je použití automatického škálování tak, aby zřízené prostředky odpovídaly 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. I když může toto automatické škálování spustit zřízení dalších prostředků, neproběhne toto zřízení hned. 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. Takto bude moci systém fungovat a vyhovět veškerým platným podmínkám SLA. 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 jednotlivých tenantů. 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. K implementaci tohoto přístupu by se dal použít model prioritní fronty.

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

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á, představuje omezení dočasné řešení, zatímco se systém škáluje na více systémů. V tomto okamžiku je možné obnovit všechny funkce 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 tuto chvíli může systém začít škálovat na více systémů. Pokud ale nové prostředky nejsou k dispozici dostatečně rychle, může dojít k vyčerpání stávajících prostředků a selhání systému. 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í, když jsou k dispozici další prostředky, se může omezení zmírnit.

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 dočasně odmítnout žádost uživatele, měla by vrátit určitý kód chyby, aby mohla klientská aplikace poznat, že provedení určité operace bylo zamítnuto z důvodu omezení. Klientská aplikace může nějakou dobu počkat a pak zkusit žádost znovu odeslat.

• Omezení se dá použít jako dočasné opatření při automatickém škálování systému. V některých případech, pokud aktivita naroste náhle a neočekává se, že bude trvat dlouho, je jednoduše lepší omezení než škálování, protože škálování může významně zvýšit provozní náklady.

• Pokud se omezení používá jako dočasné opatření během toho, kdy systém provádí automatické škálování, a pokud začíná počet žádostí velice rychle narůstat, nemusí být systém schopný dál fungovat – a to i v případě, že se jedná o provoz 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í.

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.

Příklad

Na posledním obrázku vidíte, jak se dá 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 mohou 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žívání služeb s cílem získat představu 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 pro automatické š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í informace

Při implementaci tohoto modelu mohou 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í.