Zkušenosti z provozu aplikací na Windows Azure, díl I.

Během krátké doby, po kterou je dostupná platforma Windows Azure, vznikla celá řada zkušeností. Následující seznam, který budu nadále rozšiřovat, vniknul na reálných projektech celé řady mých kolegů z Microsoftu.

Afinita rolí a datového úložiště

Ve Windows Azure při vytváření nové webové/pracovní role a Storage služby máme možnost volit, kde budou provozovány. Vedle volby „kdekoli“, jsou k dispozici volby jednotlivých regionálních datových center. Není úplně vhodné používat volbu „kdekoli“ a to hned ze dvou důvodů. Jednak může vaše aplikace nebo data skončit na druhé straně světa, ale zákazníci jsou jen z Evropy a jednak může aplikace být umístěna v jednom regionu a data v jiném. Oba tyto případy mají negativní vlivy:

• Pokud jsou zákazníci obsluhováni z jiného regionu, je latence sítě s vysokou pravděpodobností větší
• Pokud jsou aplikace a data v odlišných datových centrech, platí se za přenos dat mezi aplikací a Storage služnou. Aplikace a data by měly být jak z důvodu rychlosti, tak z důvodu ceny (interní přenosy v datacentru jsou zdarma) co nejblíže.

Nezapomeňte tedy nastavit afinitu aplikace a datové služby k jednomu datovému centru.

Uložte do Azure Storage co se dá

Pokud nepotřebujete bezpodmínečně relační vazby mezi daty a tedy použití SQL Azure, ukládejte data do Azure Storage. Výhody jsou následující:

• Cena Storage je o několik řádů levnější. 1 GB SQL dat je řádově za $10/měsíc, zatím to 1GB ve Storage za $0,15/měsíc.
• Na Storage lze napojit službu Azure CDN, která dnes disponuje 18 geograficky rozmístěnými servery, které cachují obsah dodávaný uživatelům. Přístup k datům se tak může výrazně zrychlit.

Web server s většími možnostmi

Standardní webová role nemá možnost provádět některé systémové konfigurace, spouštět více aplikací a virtuálních adresářů, nabízet obsah webu z Azure Drive a mnohé další. Pokud potřebujete takovou funkcionalitu, lze hostovat web core v pracovní roli. Řešení najdete na MSDN Code Gallery. Stinnou stránkou je fakt, že tímto řešením ztrácíte celou řadu automatizovaných úkonů, které obsahu standardní Web role, a přebíráte na sebe zodpovědnost za nastavení a administraci.

Velikost balíčku nasazení

Po překladu Azure aplikace vzniknou dva soubory - binární balíček s veškerým obsahem pro nasazení a konfigurační soubor. Pokud zdrojové kódy obsahují i velká data, nedávejte je přímo do projektu, dostanou se totiž do tohoto jednoho souboru. Pokud jeho velikost překročí hranici stovek MB, nepodaří se vám jej nasadit. Data vždy nahrávejte samostatně.

Platnost SLA u webové role

Každá Azure služba má své SLA, včetně compute (webová nebo worker) role. Aby byla dodržena deklarovaná dostupnost, je nutné, aby webová role běžela ve dvou instancích (více zde).

Auto upgrade Azure OS s rezervou

Implicitně se nabízí, že Azure OS, na kterém běží vaše aplikace, může být automaticky upgradován. Druhou možností je výběr konkrétní verze Azure OS. Osobně doporučuji druhý postup, kdy je OS opraven záplatami a je garantováno, že vaše aplikace nebude ovlivněna. Pokud chcete využít novější verzi OS, nejdříve si aplikaci otestujte na staging serveru a pak proveďte přehození produkční a staging verze.

Azure a IntelliTrace

Pro historické ladění používejte Visual Studio IntelliTrace. Detailní popis je na tomto blogu.

Optimalizace přenosů a ceny dat

• Pro práci s daty uloženými v Azure Storage doporučuji:
• Provádět komprimaci, pokud to dává smysl
• Zapnout cachování všude, kde to jde
• Pokud jsou data opakovaně pouze čtena, uložit si je v lokální kopii na compute instanci
• Provádět bulk zápisy a čtení. Jde vždy o jednu transakci.