Jak opravu využít výkon velkých instancí na Windows Azure

Windows Azure nabízí pět verzí různě velkých virtuálních strojů – XS, S, M, L a XL. Často slýcháme komentáře typu „zatím používám velikost S, ale až bude větší tlak na aplikaci, přepnu na velikost větší, klidně XL“. Výsledek, který se takovou operací dostaví, vůbec nemusí odpovídat očekávání.

Scaling-up není bez práce

Důvod, který vede mnoho lidí k této úvaze, je pravděpodobně snaha získat větší výkon bez dodatečné práce. Pronájem většího virtuálního stroje (více jader, více paměti, větší disky, větší síťová propustnost) je lákavým řešením. Kýžený výsledek se ale ne vždy dostaví.

Zklamání totiž nastane často proto, že věší instance virtuálů nemají procesorová jádra o vyšším výkonu, nýbrž se zvyšuje jejich počet. U velikosti S je to 1 a s každou další velikostí se jejich počet zdvojnásobí. U XL to je proto 8. Pokud aplikace, která výkonově lapá po dechu není schopna rovnoměrně všechna procesorová jádra využít, migrace na větší virtuál je plýtvání penězi.

Kolega Michael Juřek na toto téma podniknul jednoduchý test, v němž použil aplikaci, která v běžném cyklu prováděla časově náročné výpočty. Volbou větších virtuálních stojů k žádnému nárůstu rychlosti zpracování dat podle očekávání nedocházelo. Dokonce naopak, došlo ke zpomalení. Prostou úpravou kódu a využití paralelního cyklu for, který je součástí Task Parallel Library, získal žádaný efekt – nárůstu rychlosti zpracování dat a tedy plné využití systémových zdrojů.

Jak je vidět z výše uvedené tabulky, nárůst výkonu není lineální, ale to je v paralelním světě běžné.

Použijte scale-out, když paralelizace není možná

Předchozí odstavce jednoznačně ukazují, že je nutné mít více vláken v jedné aplikaci, případně více aplikací běžících na jednom virtuálním stroji, aby se výkon využil. Co však v případě, že proces je jeden a algoritmus paralelizovat nelze? Využijte přirozenou funkci Windows Azure – možnost spustit aplikaci ve více instancích, které se automaticky load-balancují. Zde teoreticky zásah do kódu dělat nemusíme. To ale platí pouze tehdy, je-li aplikace bez stavová. O opačném případě je nutné je nutné se o zapamatování a sdílení stavu mezi instancemi postarat. Například pomocí nové služby Azure Cache.

Který model použít?

Odpověď je v podstatě vepsána mezi řádky výše uvedených odstavců. V každém případě platí, že pokud chci využít elastického chování cloudu, tedy schopnosti přidávat a ubírat výkon v závislosti na potřebě, scale-up je velmi špatná metoda. Téměř zabraňuje jakékoli automatizaci a naráží na prakticky jen 4 možné úrovně výkonu.

Pokud však potřebuji provádět numericky náročné algoritmy, které lze paralelizovat na mikroúrovni, výběr větší instance je určitě na místě. I zde však lze jednoho pěkného dne narazit na výkonností strop a nezbyde než se vydat cestou scale-out.

Závěrem bych ještě jednou rád poděkoval Michaelovi, který udělal všechna praktická měření.