Jak jezdit ve Windows Azure cloudu s optimální spotřebou

Jednou z charakteristik platformy Windows Azure je možnost regulovat množství pronajatého výkonu pro běh aplikací. Kvantifikovaná spotřeba pak přímo definuje velikost úhrady za službu. Na rozdíl od po léta typického neustálého rozšiřování výkonu (škálování) se dnes více hovoří o elastickém chování. To je charakterizované průběžným přizpůsobováním výkonu cloudu podle aktuální potřeby. To říká teorie. Jaká je však skutečnost? Chová se opravdu cloud tímto způsobem? A jak vlastně optimalizovat pronájem? To jsou otázky, které slýchám za posledního půlroku skoro nejčastěji.

Co neměřím, neřídím

Pokud se podíváme, jak Windows Azure nastavuje dodávaný výkon, zjistíme, že je skokově regulován pomocí tzv. Worker a Web rolí. Ve skutečnosti jde o virtuální stroje, na kterých běží naše aplikace (výpočetní nebo webové aplikace). Každý virtuální stroj může mít jednou ze 4 výkonnostních konfigurací. Pokud jeden virtuální stroj pro běh aplikace nestačí, lze pomocí konfigurace zapnout neomezené množství jeho kopií a aplikaci začít load-balancovat. Samotné nastavení počtu použitých strojů je realizováno pomocí konfiguračního souboru aplikace modifikovatelného přes webovou konzoli nebo její API.

Tímto se dostáváme ale k původní otázce – jak odhadnout potřebný výkon a jak jej průběžně měnit s cílem optimalizace? Windows Azure neobsahuje žádné prostředky, které by umožňovaly tento požadavek univerzálně řešit. Změna konfigurace, byť jde o prostou hodnotu v XML souboru, se provádí manuálně. Důvodem jsou odlišné požadavky v jednotlivých scénářích. V jednom případě můžeme např. potřebovat pravidelně regulovat výkon podle pracovní doby, kdy přes den je výkon větší, zatím co v noci zcela minimální. V jiném scénáři požadujeme regulaci na základě kritických parametrů aplikace – vytížení jednotlivých VM, obsazenost front požadavky, objemem přenášených dat atd. Tyto požadavky a jejich kombinace se aplikace od aplikace bude určitě významně lišit, včetně logiky reagující na kritické stavy. Pro zodpovědné řízení přidělovaného, tedy pronajímaného, výkonu je nutné průběžně sledovat parametry cloud aplikace a znát případné časové harmonogramy.

Dynamické přidělování výkonu

Kolegové Grzegorz Gogolowicz a Trent Swanson z Microsoftu pro realizaci této úlohy napsali aplikaci s volně šiřitelným zdrojovým kódem. Aplikaci AuzureScale včetně zdrojových kódů a dokumentace lze stáhnout z MSDN Code Gallery.

Úkolem aplikace je řídit počet použitých virtuálních strojů pro nasazené aplikace na základě:

• Zapínání a vypínání aplikace – on/off load pattern
• Časového harmonogramu – Predictable Bursting pattern
• Neočekávané zátěže – Un-Predictable Bursting pattern

Pro realizaci posledního vzoru je nutné sledovat požadované parametry cloudu a definovat business logiku. Výsledkem je aplikace níže uvedenou architekturou:

K dispozici máme tři části aplikace:

• LoadClient – slouží k simulování zátěže a testování algoritmů pro elastické chování
• ScalingEngine – slouží pro vlastní dynamické řízení výkonu cloudu podle definovaných pravidel
• MonitoringUI – volitelná služba umožňující průběžně sledovat zvolené metriky aplikace provozované v cloudu a dále pak monitorovat změny nastavené cloud infrastruktury.

Reálné použití

Tato aplikace vzorově ukazuje jak dynamicky řídit přidělávaní výkony cloud aplikacím. Nejde ale univerzální produkt. Pro konkrétní komerční řešení ji bude nutné vždy upravit, ať jde o sledované parametry nebo aplikační logiku. Pokud by mělo být navíc jedním z optimalizačních kritérií cena pronájmu, nikoli jen optimálně dodávaný výkon, použít ji nelze. V současné době bohužel není dostupné API pro průběžné sledování všech parametrů spotřeby.

Zcela samostatnou kapitolou, kterou jsem se v teoretické ani praktické rovině nezabýval, je DOS nebo DDOS útok. Tuto otázku neřeší ani základní funkce aplikace. Pokud budete nad dynamickým řízením výkonu přemýšlet, určitě je nutné i tuto eventualitu vzít v úvahu. Mějte na paměti – v PaaS cloudu se platí za odebraný výkon, ne za licence. Ochrana před těmito typy útoky však není jen otázkou cloud aplikací, ale i aplikací provozovaných ve vlastní infrastruktuře.