Vývoj aplikací v Cloud Computingu

Bankovní institut vysoká škola Praha Katedra matematiky, statistiky a informačních technologií Vývoj aplikací v Cloud Computingu Diplomová práce Autor: Bc. Michal Kruml Informační technologie a management Vedoucí práce: Ing. Vladimír Beneš Praha Leden, 2011

Prohlášení: Prohlašuji, že jsem diplomovou práci zpracoval samostatně a v seznamu uvedl veškerou použitou literaturu. Svým podpisem stvrzuji, že odevzdaná elektronická podoba práce je identická s její tištěnou verzí, a jsem seznámen se skutečností, že se práce bude archivovat v knihovně BIVŠ a dále bude zpřístupněna třetím osobám prostřednictvím interní databáze elektronických vysokoškolských prací.... V Praze, dne 20.6.2011 Michal Kruml

Poděkování Touto cestou bych rád poděkoval vedoucímu diplomové práce, panu Ing. Vladimíru Benešovi za pomoc s výběrem tématu, vstřícný přístup a připomínky k této diplomové práci.

Anotace Tato diplomová práce popisuje základní principy architektury pro aplikace běžící v Cloud Computingu. Úvod práce se zabývá definicí Cloud Computingu a jeho vývojem. Následuje představení tří hlavních poskytovatelů Cloud Computingu a jejich služeb. Hlavní část je věnována doporučeným praktikám a postupům pro vývoj aplikací v Cloud Computingu se zaměřením převážně na Microsoft Windows Azure. Praktická část popisuje vývoj aplikace pro přehrávání video souborů pomocí technologie Smooth Streaming v prostředí Windows Azure. Klíčová slova: Cloud Computing, Windows Azure, architektura aplikací, vývoj aplikací Annotation This diploma thesis describes basic architecture principles when developing aplications running in the Cloud Computing. It starts with Cloud Computing definition followed by basic history, and then introduces three main Cloud Computing providers and their services. Main part is related to the best practices for Cloud Computing application development with focus on Microsoft Windows Azure. Practical part describes development of Windows Azure application for media playback using Smooth Streaming technology. Keywords: Cloud Computing, Windows Azure, application architecture, application development

Obsah 1 Úvod... 6 2 Charakteristika Cloud Computingu... 7 2.1 Definice... 7 2.2 Model nasazení... 9 2.3 Distribuční model... 10 2.4 Vývoj Cloud Computingu... 11 3 Poskytovatelé Cloud Computingu a porovnání jejich nabídek... 15 3.1 Amazon... 15 3.2 Google... 17 3.3 Microsoft... 18 3.4 Jakého poskytovatele vybrat?... 20 4 Architektura aplikací pro Cloud Computing a její specifika... 22 4.1 Scénáře vývoje aplikací... 23 4.2 Typy vhodných aplikací... 23 4.3 Specifika při vývoji aplikací... 24 4.4 Návrhové vzory škálovatelné aplikace... 29 5 Požadavky na aplikaci a její vývoj ve Windows Azure... 32 5.1 Úvod do Windows Azure... 32 5.2 Windows Azure Compute... 33 5.3 Windows Azure Storage... 35 5.4 Požadavky na aplikaci... 39 5.5 Analýza požadavků... 41 6 Návrh, implementace a provoz... 47 6.1 Architektura aplikace... 47 6.2 Nahrávání souborů... 51 6.3 Zpracování videa... 54 6.4 Webový portál... 58 6.5 Diagnostika... 62 6.6 Dynamické škálování služby... 63 6.7 Nasazení do Windows Azure... 64 7 Vyhodnocení... 65

8 Seznam použité literatury... 66 8.1 Bibliografie... 66 8.2 Elektronické publikace... 66 8.3 Internetové články... 67 Příloha č. 1... 71 Příloha č. 2... 72

1 Úvod Cloud Computing je v poslední době často diskutované téma v oblasti informačních technologií. Podle společnosti Gartner je Cloud Computing spolu s mobilními aplikacemi, tablety a sociálními sítěmi jednou ze strategických technologií pro rok 2011. Největší poskytovatelé aplikací a služeb v oblasti Internetu, jakými jsou například Google, Amazon a Microsoft, investují prostředky do budování datových center a souvisejících technologií. Podniky řeší otázku využití nebo přechodu na Cloud Computingu ve své firemní informační strategii. Pracuji jako programátor aplikací v prostředí Microsoft.NET Frameworku a s pojmem Cloud Computing jsem se poprvé setkal před více než rokem, kdy Microsoft představil svojí verzi pod názvem Windows Azure. Toto téma mě zajímá právě z pohledu vývojáře, hlavně architektury a s tím spojených rozdílů mezi vývojem klasických desktopových nebo webových aplikací a aplikací běžících v Cloudu. Téma této diplomové práce je Vývoj aplikací v Cloud Computingu. Zaměřuje se především na specifika a problémy při návrhu a vývoji aplikací běžících v Cloud Computingu a to hlavně v prostředí Microsoft Windows Azure. První část se snaží o vysvětlení pojmu Cloud Computing, zmapování historie i předpověď vývoje. Následuje představení a porovnání nabídky největších poskytovatelů na trhu. Teoretickou část zakončí kapitola věnující se architektuře aplikací a její specifika. Druhá, praktická, část diplomové práce popisuje vývoj aplikace pro přehrávání video souborů pomocí technologie Smooth Streaming v prostředí Windows Azure. Součástí řešení je webový portál pro správu uživatelů a jejich souborů, aplikace Windows Presentation Foundation pro nahrávání souborů do datového úložiště a pracovní role starající se o asynchronní zpracování resp. převod video souborů do formátu kompatibilního pro přehrávání technologií Smooth Streaming. Hlavním cílem při vývoji aplikace bylo využití doporučených postupů a praktik pro vývoj v Cloud Computingu a Windows Azure speciálně. 6

2 Charakteristika Cloud Computingu 2.1 Definice Jak definovat Cloud Computing? Ačkoli se tento termín v poslední době velmi často používá, neexistuje pouze jedna pevně daná definice. Stejně, jako například v případě servisně orientované architektury (SOA), jej experti vysvětlují různým způsobem. Laicky je možné vznik tohoto pojmu popsat pomocí významu jednotlivých slov, kde cloud neboli obláček v různých schématech a grafických návrzích představuje prostředí Internetu a slovo compute vyjadřující počítání nebo volně přeloženo práci počítače. Podle tohoto vysvětlení je možné Cloud Computing chápat jako využívání výpočetních prostředků mimo vlastní firmu a to hlavně ve velkých datových centrech přístupných pomocí Internetu. Vysvětlení je v tomto případě pouze částečné, čím se například Cloud Computing liší od klasického web respektive server hostingu? Definice společnosti Gartner [40]: Cloud computing: styl práce s počítačem, který je škálovatelný, dokáže pružně reagovat na možnosti IT a je nabízen jako služba více zákazníkům používajících internetové technologie. Definice International Data Corporation (IDC) [27]: Cloud Services = produkty, služby a řešení pro spotřebitele a firmy, které jsou dodávané přes Internet v reálném čase. Cloud Computing = rozvíjející se model IT pro vývoj, implementaci a dodání, umožňující dodání produktů, služeb a řešení pomocí Internetu (tj. umožňuje cloud služby) Definice Forrester [44]: Cloud computing: standardizované schopnosti IT (služby, software nebo infrastruktura) poskytované prostřednictvím internetových technologií samoobslužným způsobem s platbami za spotřebované služby 7

Tři výše uvedené definice jsou pouze ukázkou z mnoha dalších dostupných nebo citovaných na internetu. V podstatě se snaží vystihnout různým způsobem Cloud Computing. Většina z nich také používá podobné termíny: Internet, služby, škálovatelnost, elasticita pružnost. Koncept Cloud Computingu není nový, technologie a služby, které jej podporují a umožňují, fungují již delší dobu, například SOA, Web 2.0 nebo virtualizace. Rozdílný je způsob, jakým jsou tyto technologie implementovány a používány k dosažení dynamické, škálovatelné a virtualizované infrastruktury, platformy nebo softwaru. Dokument vypracovaný společností Deloitte pro CPNI (Centre for the Protection of National Infrastructure) uvádí základní charakteristické vlastnosti Cloud Computingu: okamžité přizpůsobení využití prostředků snižování kapacity při malém zatížení a zvyšování při potřebě většího výkonu nebo rozložení zátěže, placení služby systémem pay-as-you-go tj. průběžné podle toho, kolik je spotřebováno bez dlouhodobých závazků, vysoká abstrakce, virtualizace uživatelé se nestarají o hardware nebo síťovou infrastrukturu, využití stejné služby různými zákazníky při současném zachování soukromí a bezpečnosti jejich informací. Tyto body korespondují s pěti klíčovými atributy Cloud Computingu představenými společností Gartner: Servisně založený spotřebitelé respektive zákazníci využívají zdroje pomocí předem definovaných rozhraní, které umožňují kompletně automatizované reakce a řízení služeb. Služba je navržená tak, aby sloužila specifickým potřebám cílové skupiny uživatelů a více než na technologických možnostech záleží na nastavení služby a definovaných atributech SLA (dostupnost, doba odezvy, výkon vs. cena). Škálovatelný a elastický službu lze škálovat automaticky nahoru nebo dolů podle požadavků zákazníka tj. přizpůsobit nastavené zdroje jejich využití. Pružně reagovat na potřebu vyšší kapacity nebo snížení již nastavené kapacity z hlediska ekonomické úspory. Sdílený služby sdílejí společné hardwarové prostředky pro vytvoření úspor z rozsahu, kdy jsou zdroje IT využívány s maximální efektivitou. Infrastruktura, 8

software nebo platforma jsou sdíleny mezi více uživateli, kteří o těchto zdrojích nemají podrobné informace. Měřený podle použití služby jsou sledované s použitím metrik, které umožňují několik platebních modelů, mezi které patří platba podle skutečné spotřeby, předplatné nebo i služba zdarma. Hrazení služby je založeno na skutečném využití služby a nikoli na nákladech za použité zařízení. Využívající internetové technologie služba je dodávaná prostřednictvím Internetu a využívá internetové identifikátory, formáty a protokoly (URL, HTTP, IP). Charakteristiku Cloud Computingu lze také stručně shrnout následujícími body: Virtualizované výpočetní zdroje. Zdánlivě neomezená kapacita/škálovatelnost. Dynamická správa zdrojů. Sdílení prostředků. Samoobslužná služba. Platba dle spotřeby. 2.2 Model nasazení Cloud computing rozdělujeme podle modelu nasazení a typu služby, kterou poskytuje. Model nasazení závisí na míře vlastnictví prostředků a technické architektuře a říká, jak je cloud poskytován. Rozlišujeme čtyři modely nasazení. Veřejný (Public) Cloud Computing služby jsou dostupné široké veřejnosti přes Internet za použití jednoho nebo více datových center. Soukromý (Private) Cloud Computing architektura je modelovaná na základě systému prodejce resp. poskytovatele, přesto vytvoření, provoz, správa a využití je pouze pro jednu organizaci. Data jsou kontrolována uvnitř organizace. 9

Hybridní (Hybrid) Cloud Computing mix veřejného a soukromého cloudu s vlastní IT infrastrukturou k vytvoření modelu, který používá standardní a osvědčené technologie pro dosažení specifických požadavků. Komunitní (Comunity) Cloud Computing model použitý pro organizace, které mají společné zájmy a cíle a dovolují sdílené služby a infrastrukturu. Může být nasazen za použití jakéhokoliv z modelů uvedených výše. Na obrázku je graficky znázorněn rozdíl mezi jednotlivými typy Cloud Computingu a jak je vidět v angličtině se začal používat i nový termín on premise, pro rozlišení vlastního resp. interního IT od prostředků Cloud Computingu. Obrázek č. 1: Model nasazení Zdroj: http://cs.wikipedia.org/wiki/cloud_computing 2.3 Distribuční model Cloud computing je obvykle popisován podle typu služby, jakou poskytovatel nabízí. Existují tři modely služby: SaaS, PaaS a IaaS. Software as a Service (SaaS) poskytnutí hotové aplikace uživateli přistupujícímu pomocí webového prohlížeče. Uživatel si kupuje pouze licenci pro využívání aplikace, ne aplikaci samotnou. V současné době zaujímá největší část trhu. Příklady: Zoho, Salesforce.com, Basecamp, Ulteo, Google Apps. Platform as a Service (PaaS) poskytnutí prostředků potřebných pro nasazení aplikace vytvořené zákazníkem do infrastruktury cloudu. Služba typicky zahrnuje podporu kompletního životního cyklu vývoje aplikace v podporovaných 10

programovacích jazycích a nástrojích (Java, Python, Net). Zákazník má kontrolu pouze nad nasazenou aplikací případně nad konfigurací hostujícího prostředí. Příklady: Windows Azure, Google App Engine, Aptana Cloud. Infrastructure as a Service (IaaS) poskytnutí počítačové infrastruktury jako služby tj. pronajmutí serverů, úložišť, síťových zařízení a dalších nezbytných prostředků. Tato hardwarová infrastruktura je typicky virtualizována. Příklady: Amazon Web Services (AWS), Akamai, Rackspace. Obrázek níže ukazuje rozdíl mezi jednotlivými modely a stupněm kontroly nad jednotlivými vrstvami systému. V případě tradičního modelu s vlastním hardwarem a softwarem v budově firmy jsou kladeny největší nároky na správu a údržbu. Další modely, v různě velkém měřítku, přenášejí starost například o hardwarové komponenty, instalace či aktualizace operačního systému nebo aplikací na poskytovatele služby. Obrázek č. 2: Distribuční model Zdroj: http://www.microsoft.com/windowsazure/whitepapers/the-economics-of-the-cloud.pdf 2.4 Vývoj Cloud Computingu Cloud computing je dalším stupněm ve smyslu využívání IT, od sálových počítačů přes rozvoj osobních počítačů a architektury klient-server až po využívání softwaru jako služby. Tento krok byl především umožněn rozvojem Internetu, zvyšováním rychlosti síťového připojení a potřeby většího výpočetního výkonu při současném snižování nákladů na pořízení 11

a provoz v podobě správy i např. spotřeby energie. V tomto směru může být Cloud Computing jedno z řešení pro podnikové IT. Obrázek č. 3: Vývoj podnikové IT architektury Zdroj: http://www.nec.co.jp/techrep/en/journal/g10/n02/100202.html Cloud computing je jedním z nejčastěji medializovaných termínů IT v posledních letech převážně od roku 2006, kdy byl poháněn jeho poskytovateli, ale nyní je řízený a ovlivňovaný i potencionálními zákazníky o tuto technologii. Koncept Cloud Computingu není nový, počátek je možné umístit do 50. let minulého století a prací společnosti AT&T v oblasti telefonních sítí. AT&T vyvíjela architekturu a systém, kde byla data centralizována a zpřístupněna pomocí telefonů a telefonní sítě. Ačkoli se služba nerealizovala, koncept a výhody byly pochopeny a přetrvaly do současnosti. V 60. letech John McCarthy představil myšlenku poskytovat výpočetní prostředky jako veřejnou utilitu tzv. utility computing. Služby jsou měřeny a účtovány zákazníkům stejným způsobem jako v případě telefonních nebo elektrických služeb. Na počátku 90. let Ian foster a Carl Kesselman přišli s novým konceptem tzv. grid computing. Grid computing označuje síť složenou z nezávislých výpočetních zdrojů, umístěných v různých doménách, využívajících paralelních výpočtů a spojených k dosažení jednoho cíle. S rozvojem Internetu a zvyšováním rychlosti připojení přichází nové typy aplikací na principu služeb (SaaS) a jedním z milníků je rok 1999, kdy je spuštěn Salesforece.com nabízející podnikovou aplikaci přístupnou pomocí webových stránek. V roce 2002 je uveden soubor služeb Cloud Computingu od společnosti Amazon pod označením Amazon Web Services. 12

Následně Amazon, v roce 2006, spustil webovou službu S3 (Simple Storage Service), nabízející úložný prostor s účtováním podle využití a o několik měsíců později Elastic Compute Cloud (EC2), komerční webovou službu umožňující malým společnostem i jednotlivcům pronajmout si počítač, na kterém mohou spouštět vlastní aplikace. Ostatní velké společnosti nezůstávají pozadu, v roce 2008 Google spouští svojí verzi Cloud Computingu s názvem Google App Engine a na podzim 2009 vstupuje do této oblasti Microsoft s Windows Azure. Obrázek č. 4: Vývojové stupně Cloud Computingu Zdroj: http://www-05.ibm.com/cz/events/forum2010/prezentace/ibm_cloud_computing-karel_machacek.pdf Hlavní motivací pro přechod na Cloud Computing je především úspora nákladů, ať už se jedná o pořizovací cenu hardwaru, licenci operačního systému, tak i správců IT anebo úsporu elektrické energie. V tomto směru by především mělo jít o snahu maximalizovat využití poskytovaných prostředků. Ty jsou dostupné jako služba a placené průběžně podle toho, jak jsou využívané. To také znamená, že pro přechod nejsou potřeba žádné počáteční investice do hardwarového vybavení. Na větším významu pak nabývá otázka architektury nasazené aplikace či aplikací a optimalizované využití zdrojů. Na obrázku číslo 5 jsou graficky zobrazeny nejčastější důvody pro přechod ke cloud Computingu podle výzkumu provedeného společností IBM. Z celkového pohledu je vidět, že převládá skupina úspor nákladů (Reduce costs), která se dále dělí na hardware, software, pracovní sílu, podporu apod. Za povšimnutí stojí i první hodnota v grafu zlepšení spolehlivosti a dostupnosti nebo naopak poslední vytvoření nových možností příjmů společnosti. 13

Obrázek č. 5: Důvody pro přechod na Cloud Computing Zdroj: http://www-05.ibm.com/cz/ibm/cloud/resources.html#n5: Dispelling the vapor around cloud computing 14

3 Poskytovatelé Cloud Computingu a porovnání jejich nabídek Na trhu v současné době existuje již mnoho poskytovatelů Cloud Computingu a to, jak veřejného, tak i privátního s různými typy služeb. Od firmy Amazon, průkopníka na poli nabídky výpočetního i úložného prostoru, přes Salesforce.com specializující se na poskytování CRM aplikace jako služby až například po Oracle dodávající technologie převážně do soukromých cloudů. Porovnání nabídek omezeno pouze na srovnání největších hráčů v oblasti poskytování veřejného Cloud Computingu jako platformy nebo infrastruktury. Všeobecně se za největší hráče považuje Amazon s AWS a EC2, Google App Engine a Microsoft s Windows Azure. 3.1 Amazon Amazon, největší on-line prodejce na Internetu je pravděpodobně také nejznámější poskytovatel Cloud Computingu a jeho průkopník. Už roku 2002 uvedl první službu pod názvem Amazon Web Services (AWS) a v roce 2006 spustil další dvě významné služby Amazon Simple Storage Service (S3) a Amazon Elastic Compute Cloud (EC2). Nyní již nabízí širokou paletu služeb a produktů i podporu různých technologií vývoje aplikací. Elastic Compute Cloud (EC2) webová služba, která umožňuje využívat volitelný výpočetní výkon. Má jednoduché webové rozhraní pro rychlé nastavení a konfiguraci potřebné kapacity a dovoluje kontrolu využití těchto zdrojů. Získání a zprovoznění nové instance serveru trvá jen několik minut, což dovoluje měnit množství instancí podle aktuální potřeby. Instance představuje virtuální prostředí, které podporuje různé operační systémy: Red Hat Entreprise, Windows Server 2003/2008, Oracle Enterprise Linux, Open Solaris, Ubuntu Linux, Debian a další. Kromě operačního systému jsou také podporovány i aplikace: IBM DB2, Microsoft SQL Server 2005/2008, MySQL Enterprise, Oracle 11g, Apache http, IIS/Asp.NET, IBM WebSphere Portal Server a další. Zákazník má možnost volby různých skupin typů instancí, od tzv. Micro Instances pro velmi malý výkon s 613MB paměti, přes Standard Instances použitelných pro většinu aplikací až po specifické skupiny instancí pro konkrétní využití: High-Memory, High-CPU, 15

Cluster Compute, Cluster GPU. Jednotlivé skupiny mohou být dále ještě rozděleny například v případě standardní instance: - Small Instance, 1,7 GB paměti, 1 EC2 Compute Unit, 160 GB na disku, 32-bit OS - Large Instance, 7,5 GB paměti, 4 EC2 Compute Unit, 850 GB místa na disku, 64-bit - Extra Large Instance, 15 GB paměti, 8 EC2 Compute Units, 1690 GB na disku, 64-bit Výkon je udáván v EC2 Compute Units, abstrakce představující výpočetní výkon, kde jedna jednotka je ekvivalent CPU 1,0 1,2 GHz 2007 Opteron nebo 2007 Xeon procesor. V případě Extra Large instance je 8 EC2 Compute Units rovno 4 virtuálním jádrům s 2 EC2 Compute Units každého. SimpleDB služba poskytující flexibilní databázové funkce, indexování a dotazy nad uloženými daty. Nejedná se o relační databázi, ale o nástroj pro ukládání a získávání strukturovaných dat pomocí požadavků webových služeb. Simple Storage Service (S3) datové úložiště, používá rozhraní webových služeb pro ukládání a získávání jakéhokoli množství dat kdekoli na Internetu. Stejnou datovou infrastrukturu používá Amazon pro své vlastní globální weby. S3 je záměrně vytvořeno s minimálním množstvím funkcí, je možné zapisovat, číst a mazat objekty, které mají velikost od 1 bytu až do 5 TB každý, přičemž množství těchto objektů je neomezené. Koncept modelu S3 se skládá ze tří úrovní: objektu, kyblíku (bucket) a klíčů. Jednotlivé objekty jsou uložené v kyblíku, který jim přiřazuje stejný jmenný prostor, a jsou identifikovatelné podle unikátního klíče. CloudFront webová služba pro doručování obsahu. Pracuje ve spojení s dalšími službami AWS zvláště s Amazon S3 pro distribuci kopií objektů/dat z nejbližšího úložiště přímo klientovi nebo aplikaci, která tyto data vyžaduje. Požadavek k získání dat je automaticky přesměrován k nejbližšímu síťovému bodu, a tak je obsah doručen s minimálním zpožděním. Simple Queue Service (SQS) služba pro spolehlivé ukládání zpráv do fronty. Tímto je možné zajistit spolehlivou komunikaci pomocí zpráv mezi počítači a umožňuje vytvářet vysoce škálovatelné aplikace. Komponenty mohou takto komunikovat nezávisle na sobě i v případě, kdy neběží nepřetržitě a jsou nedostupné. Služba podporuje všechny základní funkce fronty od vytvoření zprávy, získání seznamu zpráv až po jejich smazání. Elastic MapReduce služba navržená pro paralelní zpracování nebo analýzu velkého množství dat. Umožňuje zadat úlohu k výpočtu na volitelném množství instancí a získat 16

finální souhrnná data. Elastic MapReduce používá Apache Hadoop, open-source Java framework, který je vhodný pro jednodušší výpočty nad obrovským množstvím dat. Ceny za jednotlivé služby jsou detailně popsány na stránkách Amazonu, kde je k dispozici také kalkulačka měsíčních nákladů podle vybraných parametrů. Tabulka níže představuje základní cenový přehled. Tabulka č. 1: Základní cena služby Amazon EC2 Výpočetní výkon podle typu instance Linux/Unix* Windows* Micro $ 0,02 $ 0,03 Small (výchozí) $ 0,085 $ 0,12 Large $ 0,34 $ 0,48 Extra Large $ 0,68 $ 0,96 High-Memory Extra Large $ 0,50 $ 0,62 High-Memory Double Extra Large $ 1,00 $ 1,24 High-CPU Extra Large $ 0,68 $ 1,16 * Cena za 1 hodinu. Zdroj: http://aws.amazon.com/ec2/pricing/, upraveno Tabulka č. 2: Základní cena služby Amazon S3 Data Region EU a USA Transfer dat příchozí $ 0,100 za 1 GB Transfer dat odchozí (do 1 GB za měsíc) Zdarma Transfer dat odchozí (do 10 TB za měsíc) $ 0,150 za 1 GB Transfer dat odchozí (do 40 TB za měsíc) $ 0,110 za 1 GB Použití úložiště (do 1 TB za měsíc) $ 0,140 za 1 GB Použití úložiště (do 49 TB za měsíc) $ 0,125 za 1 GB Použití úložiště (do 450 TB za měsíc) $ 0,095 za 1 GB Zdroj: http://aws.amazon.com/ec2/pricing/, upraveno 3.2 Google Google provozující nejrozšířenější internetový vyhledavač vyvíjí a nabízí mnoho dalších produktů a služeb, mezi které patří například Google Maps, služba Google Mail, internetový prohlížeč Google Chrome, operační systém pro mobilní telefony a tablety Android. V oblasti Cloud Computingu poskytuje od roku 2008 službu Google App Engine umožňující vývoj a hostování webových aplikací na stejné infrastruktuře, na jaké běží ostatní aplikace Googlu. 17

Google App Engine je prostředí pro vývoj a nasazení webových aplikací. App Engine nabízí jednoduchou administraci a nasazení, použití frameworku dovoluje automaticky škálovat aplikaci bez nutnosti monitorování a zadávání požadavku na zvýšení potřebných zdrojů. Jsou podporována dvě vývojová prostředí: Java nebo Python. Webové stránky mohou spolu s HTML obsahovat i JavaScript a umožňují použití AJAXu. Z hlediska bezpečnosti není dovoleno zapisovat přímo na disk nebo otevírat síťové spojení. Pro ukládání dat App Engine nabízí vlastní datastore vytvořené na základě Bigtable distribuovaného systému pro ukládání strukturovaných dat, škálovatelný do velmi velké velikosti. Provozování aplikací je zdarma, pokud nepřekročí kvótu 500 MB prostoru a kolem pěti milionu zobrazení stránek. Větší výpočetní výkon lze dokoupit a platit pouze za skutečné použití podle následující tabulky. Tabulka č. 3: Cena služby Google App Engine Zdroje Jednotky Cena za jednotku Odchozí data GB $ 0.12 Příchozí data GB $ 0.10 CPU čas CPU hodin $ 0.10 Uložená data GB za měsíc $ 0.15 Úložiště s vysokou replikací GB za měsíc $ 0.45 Odesílání emailů Počet příjemců $ 0.0001 Nepřetržitá dostupnost Denně $ 0.30 Zdroj: http://code.google.com/intl/cs-cz/appengine/docs/billing.html, upraveno 3.3 Microsoft Microsoft, výrobce operačního systému Windows a dalších produktů pro osobní počítače i servery, vstoupil na trh Cloud Computingu na podzim roku 2009, kdy představil beta verzi platformy Windows Azure. Základními prvky jsou Windows Azure operační systém pro datová centra, SQL Azure relační databáze a AppFabric doplňkové služby po vývoj distribuovaných aplikací zahrnující aplikační sběrnici a řízení přístupu. Windows Azure se skládá z pěti základních částí: Compute, Storage, Fabric Controller, CDN a Connect. 18

Compute výpočetní prostředí pro běh aplikací v cloudu. Základem virtuálního prostředí je Windows Server 2008. Je možné zvolit ze tří různých typů rolí. Prvním typem je webová role, jejímž primárním úkolem je hostování webových aplikací pomocí Internetové informační služby (IIS). Dalším typem je takzvaná pracovní role (worker role), která je navržena pro běh Windows-aplikací bez nakonfigurované služby IIS. Třetí možností je VM role pro běh Windows Server 208 R2 image, která je vhodná pro nasazení stávající konfigurace aplikací z lokálního serveru do Windows Azure. Storage úložiště pro ukládání binárních a strukturovaných dat. Windows Azure nabízí tři typy úložiště: Blobs, Tables, Queues. Blob je zkratkou pro binary large objects a je typicky vhodné pro ukládání binárních dat. Table resp. tabulka slouží k ukládání velkého množství strukturovaných dat. Queue je jednoduchá fronta k ukládání dočasných zpráv a jejím cílem je umožnit komunikaci mezi jednotlivými aplikacemi nebo jejich částmi ve Windows Azure. Fabric Controller management služeb starající se o nasazení aplikací, správu a monitoring. Také se používá k automatickým aktualizacím softwaru v datovém centru. Content Delivery Network (CDN) urychluje globální přístup k datům z úložiště Windows Azure, udržováním binárních kopií dat v klíčových síťových uzlech. Connect umožňuje vytváření připojení na úrovni IP mezi lokálními počítači a aplikacemi ve Windows Azure. Tabulka č. 4: Cena služby Windows Azure Compute Výpočetní výkon Procesor Paměť Lokální disk Cena za 1 hodinu Extra Small 1,0 GHz 768 MB 20 GB $ 0,05 Small 1,6 GHz 1,75 GB 225 GB $ 0,12 Medium 2x1,6 GHz 3,5 GB 490 GB $ 0,24 Large 4x1,6 GHz 7 GB 1000 GB $ 0,48 Extra Large 8x1,6 GHz 14 GB 2040 GB $ 0,96 Zdroj: http://www.microsoft.com/windowsazure/compute/, upraveno Tabulka č. 5: Cena služby Windows azure Storage Data Cena Transfér dat příchozí $ 0,10 za 1 GB Transfér dat odchozí $ 0,15 za 1 GB Použití úložiště $ 0,15 za 1 GB za měsíc Transakce (I/O) $ 0,01 za 10000 transakcí Zdroj: http://www.microsoft.com/windowsazure/pricing/, upraveno 19

SQL Azure představuje relační databázový systém vytvořený na základě Microsoft SQL Serveru. Kromě samotného systému řízení báze dat SQL Azure Database se také skládá z SQL Azure Reporting, služby pro generování reportů a SQL Azure Data Sync, služby pro synchronizaci dat mezi lokálním SQL serverem a verzí Azure nebo synchronizací SQL Azure databázi v různých datových centrech. Tabulka č. 6: Cena služby SQL Azure Data Cena SQL Azure Web edice velikost 1GB $ 9,99 za měsíc SQL Azure Web edice velikost 5GB $ 49,95 za měsíc SQL Azure Business edice velikost do 10GB $ 99,99 za měsíc SQL Azure Business edice velikost do 20GB $ 199,98 za měsíc SQL Azure Business edice velikost do 50GB $ 499,95 za měsíc Zdroj: http://www.microsoft.com/windowsazure/pricing/ App Fabric pomáhá vyřešit běžné obtížnosti při vývoji distribuovaných aplikací, součástí je sběrnice Service Bus a služba pro řízení přístupu Access Control. 3.4 Jakého poskytovatele vybrat? Google App Engine nabízí nejjednodušší model z hlediska nasazení a správy aplikace, automaticky zajišťuje zvyšování instancí a dostupnosti podle potřeby. Programátorům stačí dodržovat doporučené postupy při vývoji aplikace a App Engine se následně postará o vše automaticky. Další výhodou je nabídka služby zdarma při nízkém vytížení. Do počtu 5 miliónů zobrazení stránek je aplikace zdarma a až následné požadavky jsou účtovány. Výborná je také integrace s dalšími službami od Google: e-mail, mapy, kontakty, kalendář a další. Nevýhodou Google App Engine je možnost nasazení pouze webových aplikací a podpora aplikací vyvíjených jen v jazyce Python nebo Java navíc s určitými omezeními je například zakázaný přístup na lokální disk. V případě Amazon AWS nebo Windows Azure se platí za čas procesoru běžící aplikace, což v praxi znamená, že i když například webová aplikace nemá žádného návštěvníka, tak provoz jedné instance ve Windows Azure uživatele stojí minimálně 86,6 dolarů. 20

Cena 1 instance ( Small ) za měsíc: $ 0,12 * 24 * 30 = $ 86,6 Windows Azure stojí někde mezi App Engine a AWS v případě nároků na správu systému a možnostmi konfigurace, aktualizace operačního systému jsou prováděny automaticky. Uživatel má možnost vlastní konfigurace, i když na druhou stranu se musí sám postarat o zvyšování nebo snižování počtu instancí. Ve Windows Azure, je možné provozovat jak webové aplikace, tak i podpůrné procesy nebo služby, jedinou podmínkou je běh v systému Windows. I když mezi podporované jazyky patří Java, PHP a Ruby tak nejpravděpodobnější a primární volba bude vývoj v prostředí.net Framework. Výhodou oproti Google App Engine je možnost použití relační databáze SQL Azure. Amazon AWS nabízí téměř všechna standardní virtuální prostředí od Windows Server 2000/2008 až po různé distribuce Linux, podporu různých databází, webových a aplikačních serverů. S tím se váže i podpora různých programovacích jazyků a nástrojů. Tím, že služby AWS patří do kategorie infrastruktury jako služby, tak má uživatel na jedné straně výhodu možnosti specifické konfigurace a nastavení virtuálního prostředí, s tím ovšem souvisí i zvýšené nároky na kontrolu a správu systému. Na první pohled rozsah základních služeb a cenová nabídka je velmi podobná u Windows Azure a Amazon AWS. Windows Azure bude patrně jasnou volbou pro aplikace vytvořené na platformě Windows a.net Framework. U aplikací běžících na Linuxu nebo využívající jiný webový nebo aplikační server je výhodnější použití Amazon AWS. Pro nově vyvíjené aplikace je otázkou, na jakém systému aplikace poběží a v jakém jazyce bude vyvíjena. Hlavní otázkou pro výběr poskytovatele je pravděpodobně cena, která se odvíjí od použití, architektury systému a předpokládaného zatížení. Součástí výběru může být také možnost přenositelnosti aplikace a hlavně dat k jinému poskytovateli Cloud Computingu. Nabídka jednotlivých poskytovatelů se může také postupem času měnit a to, jak přidáváním nových funkcí nebo přibližováním se konkurenci ve smyslu výkonu a ovládání. Google například na stránkách věnovaných App Engine oznamuje spuštění relační databázové služby pro firemní zákazníky. 21

4 Architektura aplikací pro Cloud Computing a její specifika Dříve než budou uvedena specifika architektury, je dobré zmínit, že ne všechny aplikace jsou vhodné pro hostování v cloudu. Jaké aplikace jsou tedy vhodné pro hostování v Cloud Computingu? Pokud zvažujeme cenu služby, kdy se platí za hodinu běhu procesoru, tak není rozumné použít například Windows Azure nebo Amazon AWS pro jednoduchou webovou prezentaci firmy nebo osobní blog. Ve srovnání s klasickým web hostingem by provoz byl příliš nákladný. Výjimku tvoří Google App Engine s kvótou zdarma pro určitý počet zobrazení stránek. Měřítkem může být velikost požadovaných zdrojů, kdy firma přesune své IT do cloudu z důvodu úspory nákladů na pořízení a provoz. Často uváděným důvodem je potřeba pružně reagovat na zvyšování a snižování výkonu resp. počtu serverů, a to jak pravidelně se opakující tak i náhodné. Typickým příkladem může být nově vznikající firma, která tímto způsobem ušetří na nákupu hardwaru i softwaru a v případě potřeby a většího zájmu jednoduše nakonfiguruje vyšší počet instancí. Pokud se firmě nedaří, stačí službu vypnout. Dalším příkladem může být on-line prodej vstupenek, kdy se zájem zvedá s uvedením například nějaké kulturní nebo sportovní události. Varianty měnících se požadavků na výkon ukazuje následující obrázek. Obrázek č. 6: Scénáře nasazení Cloud Computingu Zdroj: Microsoft.cz, WindowsAzurePlatformOverview_CZ.pptx 22

4.1 Scénáře vývoje aplikací - Vývoj aplikace od začátku - Migrace stávající aplikace - Rozšíření o služby Cloud Computingu Při přechodu firemního IT na Cloud Computing jsou tři možné způsoby: vývoj nové aplikace přímo pro cloud, migrace stávajícího řešení nebo rozšíření aplikace o možnosti Cloud Computingu a to například přidáním nových funkcí či služeb, použití cloudu v případě potřeby vyššího výkonu nebo jako prostředku pro zálohování. Většinou záleží na aplikaci samotné, její složitosti, designu, využívání komponentů a jiných prostředků. Pokud je aplikace poskytována jako služba a využívá principů SOA je migrace poměrně jednoduchá a v případě webových aplikací jsou nutné změny minimální. Otázkou může být použití úložiště a ukládání strukturovaných dat v nativním prostředí místo relační databáze nebo ukládání stavu aplikace, případně bezpečnost a to jak aplikace, tak i samotných dat. Obecně lze říci, že vývoj aplikace na zelené louce je z hlediska optimalizace výhodnější. Oproti tomu, vznikají na druhé straně náklady na vývoj, které nejsou vždy akceptovatelné, a tak jediným řešením je přizpůsobení stávající aplikace podmínkám Cloud Computingu. 4.2 Typy vhodných aplikací - Škálovatelné webové a podnikové aplikace. - Propojené aplikace založené na Web 2.0 nebo sociálních sítích. - Aplikace zaměřené na analýzu velkého objemu dat využívající paralelního zpracování. - Aplikace vyžadující vysoký výpočetní výkon. - Aplikace kombinující lokální firemní zdroje a služby Cloud Computingu. Primárním případem užití Cloud Computingu je hostování serverových aplikací například WCF, ASP.NET, PHP, JavaEE, kde klientem nebo konzumentem služeb je webový prohlížeč, mobilní telefon, tablet nebo jiná aplikace běžící lokálně u uživatele nebo přímo v cloudu. Vhodným příkladem použití jsou pak aplikace náročné na výpočetní výkon za použití mnoha virtuálních instancí a to, jak pro opakující se činnosti, tak i jednorázové. Datová centra poskytovatelů Cloud Computingu mohou také sloužit k uložení obrovského množství dat. 23

4.3 Specifika při vývoji aplikací Vývoj aplikací vhodných a optimalizovaných pro Cloud Computing s sebou přináší nové problémy, se kterými se architekt či developer musí vypořádat a to od návrhu přes vývoj, nasazení až po monitorování a správu. Vzhledem k povaze aplikací mezi největší problémy patří zajištění dobré škálovatelnosti a synchronizace dat mezi jednotlivými instancemi, dále také ladění, logování a monitorování v případě běhu někde v datovém centru. S postupným zdokonalováním služeb poskytovatelů Cloud Computingu se mění i přístup a řešení těchto problémů, některé jsou vyřešeny přímo poskytovatelem například přidáním nové funkcionality nebo nezávislými výrobci softwaru, kteří nabídnou řešení na míru. Za zmínku stojí také otázka bezpečnosti dat, archivace a přenositelnosti aplikace v budoucnosti. Jedním z hlavních důvodů pro přechod na Cloud Computing jsou náklady na provoz, proto už při návrhu aplikace je třeba myslet na to, jak tyto náklady snížit na možné minimum tj. například optimalizovat využití výkonu procesoru na 100%, snížit počet nutných dotazů do úložiště i počet transakcí. V některých případech se na první pohled jedná o zanedbatelné částky, ale u rozsáhlejší aplikace je třeba zvážit veškerá rizika. Například k nahrání souboru o velikosti 1 GB do Windows Azure Blob Storage je potřeba zhruba 250 transakcí (soubor se nahrává po částech o velikosti 4 MB). Cena 0,01 dolaru za 10 tisíc transakcí je minimální položka ve srovnání s dalšími platbami, ale všechny i zanedbatelné částky, je třeba zahrnout do celkové kalkulace, protože při změně zatížení aplikace mohou ovlivnit konečné náklady. Typické otázky při navrhování architektury aplikace pro Cloud Computing: - Je aplikace vhodná pro nasazení a běh v cloudu? - Jak zajistit rozšiřitelnost a škálovatelnost aplikace? - Jaký zvolit způsob ukládání dat relační databáze nebo strukturovaná data v tabulce? - Jak zabezpečit aplikaci a data, co je potřeba šifrovat a autorizovat? - Je aplikace beze-stavová? V případě potřeby ukládání stavu nebo používání relací, jakým způsobem toto zajistit? - Jakým způsobem budeme aplikaci ladit a monitorovat, jaké máme možnosti? - Jaké jsou předběžné kalkulace nákladů na provoz, jaký je potřeba výkon, kolik instancí? 24

Základní atributy designu aplikací Cloud Computingu: - Zdroje jsou abstraktní při vývoji se zaměřit především na potřeby a funkčnost, specifikace hardwaru není důležitá. Pokud se změní potřeby, mohou se v závislosti na tom přizpůsobit potřebné zdroje. - Poskytování podle požadavků využívat potřebné zdroje pouze, když jsou potřeba tj. požádat o ně až v momentu potřeby a zrušit vazbu, když potřeba pomine. - Škálovatelnost design aplikace by měl dovolit škálovat prostředky nahoru i dolu v závislosti na použití. - Nulové počáteční náklady žádné dlouhodobé kontrakty nebo závazky, platby pouze podle využití služeb. Optimalizovat využití zdrojů podle skutečné potřeby, ale umožnit možnost rozšíření výpočetního výkonu a zdrojů. - Dynamika systém by měl dynamicky identifikovat konfiguraci, využití výkonu, závislosti na ostatních částech aplikace a pružně reagovat na potřebné změny. Navrhování architektury a designu aplikace v Cloud Computingu s sebou přináší posun ve filozofii a je potřeba porozumět odlišnostem implementace, i když se může zdát, že vše je jinak a přitom nic není odlišné. Cloud computing klade největší důraz na vytvoření vysoce škálovatelné architektury v prostředí Internetu a zavádí nové koncepty pro vývoj i nasazení aplikací. Základem nicméně zůstává tradiční servisně orientovaná architektura (SOA). Kritickým prvkem je vytvoření škálovatelné architektury pro využití výhod škálovatelné infrastruktury cloudu. Cloud computing je v zásadě navržen k poskytování téměř neomezené škálovatelnosti a pokud aplikace tento koncept neimplementuje, není možné těchto výhod využít. Charakteristika opravdu škálovatelné aplikace zahrnuje: - Zvýšení prostředků vede k úměrnému zvýšení výkonnosti. - Škálovatelná služba je schopná zvládnout různorodost. - Škálovatelné služby jsou operativně efektivní. - Škálovatelné služby jsou přizpůsobivé (elastické). - Škálovatelná služba by měla být cenově efektivnější při rostoucích prostředcích (cena za jednotku se sníží, i když se počet jednotek zvyšuje). 25

Spolu se škálovatelností je potřeba porozumět i pružnosti aplikace (Elasticita) tj. jak aplikace reaguje na požadavky vyššího výkonu nebo dostupnosti a jak získané prostředky uvolňuje, když nejsou potřeba. Elasticita je jednou ze základních vlastností Cloud Computingu. Na základě konceptu Cloud Computingu, jeho obchodních i technický výhod existují doporučené praktiky designu aplikace, které zahrnují následující body: - Aplikace musí počítat s poruchami a možnými selháními. - Volná vazba mezi komponentami. - Implementovaná elasticita. - Paralelní zpracování. - Dynamická data blízko virtuální instance, statická data blízko uživatele. - Bezpečnost dat i aplikace. Při navrhování architektury aplikace v cloudu se vyplatí pesimistický přístup tj. vždy předpokládat, že cokoli může selhat ať je to závada na hardwaru, neočekávaný počet požadavků za sekundu, dočasný výpadek síťové konektivity nebo restartování virtuální instance v důsledku automatické aktualizace. Tento přístup nám už od začátku vývoje dovolí navrhnout systém odolný proti možným výpadkům a chybám, který je optimalizovaný pro běh v cloudu. Cloud computing posiluje princip SOA, tím že čím volnější je vazba mezi komponentami systému, tím více a lépe je možné aplikaci škálovat. Klíčovým prvkem je vytvoření komponent bez těsných závislostí mezi sebou, izolováním jednotlivých vrstev systému, které komunikují asynchronně a chovají se navenek jako black box. Elasticita je nový koncept, který přináší Cloud Computing. V závislosti na měnících se požadavcích na dostupnost nebo výkon aplikace je potřeba pružně reagovat a přizpůsobovat zdroje a nastavení aplikace. Elasticita může být implementována třemi různými způsoby: - Aktivní cyklické škálování: pravidelné škálování v předem daných intervalech (např. jiné nastavení během pracovní doby nebo v noci, kdy je slabší provoz). - Aktivní škálování podle událostí: škálování podle předem plánovaných akcí nebo událostí, kdy se předpokládá zvýšený zájem a požadavky na výkon (např. v důsledku reklamní kampaně nebo uvedení nového produktu). 26

- Automatické škálování podle požadavků: využitím monitorovací služby může aplikace sama reagovat na potřebu snižování nebo zvyšování výkonu (počtu instancí) podle předem daných metrik. Podpora paralelního zpracování by měla být samozřejmostí a implementace je v některých případech automaticky daná poskytovatelem Cloud Computingu např. AppEngine nebo Windows Azure u webových aplikací automaticky směruje požadavky na různé instance, jsou-li k dispozici. Existují dvě možnosti, jak získat zdroje pro paralelní operace: první je zvyšování počtu jader procesorů u virtuální instance, kde je v současné době limit 8. Druhou možností je zvyšování počtu instancí, kde jsou v principu omezení pouze nákladová. Příkladem může být využití Amazon Elastic MapReduce pro dávkové paralelní zpracování úkolů. Všeobecně dobrou praktikou je umístění dat co nejblíže výpočetní jednotce, která je zpracovává, aby se minimalizoval čas potřebný k jejich přesunu. To znamená dávat data a aplikaci do stejného datového centra, kde se zároveň neplatí za uskutečněné transakce. Naopak v případě statických dat jako jsou obrázky, video, zvuk, PDF, JavaScript a CSS soubory, které se nemění, se doporučuje umístit je na okrajový bod sítě co nejblíže uživateli a zkrátit tak dobu potřebnou k přenosu dat. Bezpečnost aplikací a dat v cloudu je poměrně silně diskutovaná otázka a může přinést pochybnosti řídícím pracovníkům při rozhodování o využití Cloud Computingu pro firemní IT. Bezpečnosti by proto měla být věnována náležitá pozornost, bezpečnostní mechanismy by měly být implementovány pro každou vrstvu architektury aplikace. Doporučené oblasti pro revizi z hlediska bezpečnosti: - Bezpečnost infrastruktury. - Zabezpečení dat a datového úložiště. - Správa přístupu a identity uživatelů. - Bezpečnostní management. - Zabezpečení důvěrných informací. - Audit. - Důsledek Cloud Computingu na firemní IT. 27

Jak uvádí T. Mather [3], strategie řízení bezpečnostních rizik je pro zákazníky Cloud Computingu velmi důležitá. Následující obrázek představuje možné rozdělení strategie na jednotlivé stupně. Obrázek č. 7: Strategie řízení bezpečnosti v Cloud Computingu Zdroj: Mather T., Cloud Security and Privacy Další doporučené praktiky: - Využít infrastruktury, komponent a nástrojů poskytovatele Cloud Computingu. - Použít nativní datové úložiště. - Rozdělit aplikaci a data na menší nezávislé komponenty. - Předávat informace a volání pomocí zpráv a asynchronní komunikace. - Optimalizovat aplikaci a datové struktury pro dobrou škálovatelnost. 28

4.4 Návrhové vzory škálovatelné aplikace Tato kapitola má za cíl představit některé prvky mající vliv na dobrou škálovatelnost aplikace a ukázat návrhové vzory jako např. MapReduce nebo volbu algoritmu pro indexové klíče strukturovaných dat. Horizontální a vertikální škálování V Cloud Computingu je možné zvolit model škálování horizontální (scale out) nebo vertikální (scale up). Vertikální škálování znamená použití výkonnější instance tj. místo jedné instance s jedním procesorem a malé velikostí RAM běží aplikace na instanci například s osmi procesory a 14 GB RAM. Toto řešení je vhodné například pro zpracování videa. Horizontální škálování místo výkonnějšího počítače zvyšuje počet instancí použitých pro zpracování úkolu. Data partitioning Datové rozdělení (partitioning) se používá pro rozložení dat nebo transakční zátěže. Rozlišuje se horizontální nebo vertikální rozdělení. Horizontální rozdělení se používá v tabulkách strukturovaných dat. Princip spočívá v uložení různých řádků tabulky na jiný disk. Oproti tomu vertikální rozdělení ukládá stejný typ dat dohromady, ale kombinuje různé typy úložiště podle sloupců tabulky, například binární data do Blob Storage a textové informace do SQL Azure. Obrázek č. 8: Horizontální a vertikální rozdělení Zdroj: Microsoft, Windows Azure Training Kit, Storage Strategies.pptx, upraveno Ve Windows Azure Table Storage jsou data rozdělena podle PartitionKey, který je částí indexu. Data mohou být umístěna na jednom nebo více disků, serverů. Pro malý počet dat jsou většinou data uložena pohromadě, ale v závislosti na přibývající velikosti dat nebo 29

vyšším počtu transakcí za sekundu je potřeba zatížení rozložit horizontálním rozdělením. Důležitá je pak správná volba klíče, tak aby bylo zajištěno rychlé vyhledávání nebo distribuce zátěže. Pro rychlé vyhledávání je vhodné volit přirozené klíče například jméno, druh zboží, kategorie apod. Pro eliminaci transakčního zatížení jednoho serveru je vhodné použít klíč, který se pravidelně mění a zároveň opakuje. Vhodný algoritmus poskytují matematické funkce například modulo operátor nebo hash funkce. Asynchronní zpracovávání pomocí front Pravděpodobně nejpoužívanější způsob distribuce úkolů v Cloud Computingu a paralelního zpracování. Fronty umožňují práci se zprávami, které mohou být nositeli informace resp. úkolu pro zpracování pomocí procesu běžícího současně na několika instancích. Frontu je možné také použít pro zajištění transakčního zpracování, v případě, kdy úkol na jedné instanci není dokončen. Na obrázku číslo 9 je zobrazen příklad použití fronty pro zpracování fotografie a vytvoření náhledu ve Windows Azure. Postup se skládá z následujících kroků: 1. Nahrání obrázku na webový server. 2. Uložení obrázku do blobu. 3. Zpráva s URL adresou obrázku je přidána do fronty. 4. Pracovní role pravidelně kontroluje frontu a vyzvedne zprávu. 5. Zpracuje obrázek, vytvoří náhled, který spolu s dalšími daty uloží. 6. Proces je ukončen a zpráva ve frontě smazána. Obrázek č. 9: Paralelní zpracování pomocí fronty Zdroj: vlastní úprava 30

MapReduce MapReduce je framework pro distribuované výpočty představený firmou Google. Využívá se pro zpracování velkého objemu dat. Amazon nabízí webovou službu Amazon Elastic MapReduce založenou na tomto modelu. Obrázek číslo 10 zobrazuje princip fungování MapReduce na příkladu zpracování veliké fotografie, kdy je původní originál nejprve rozdělen na menší části. Následuje zpracování těchto částí paralelně na několika instancích, které jsou nakonec složeny do výsledné upravené fotografie. Obrázek č. 10: Princip fungování MapReduce Zdroj: Microsoft, Windows Azure Training Kit, Running Asynchronous Workloads in Windows Azure.pptx, upraveno Pracovní role uvnitř webové role Tento model je specifický pro Windows Azure a má za cíl minimalizovat náklady na běh další služby resp. instance pracovní role vykonávající určitou činnost. Místo, aby pracovní role běžela na samostatné instanci, je stejný proces spuštěn na instanci hostující webovou roli, která kromě služby IIS, umožňuje stejné funkce jako role pracovní. V současné verzi webové role Windows Azure je také možný běh více webových aplikací. 31

5 Požadavky na aplikaci a její vývoj ve Windows Azure 5.1 Úvod do Windows Azure Windows Azure je operační systém pro platformu Cloud Computingu od společnosti Microsoft vhodný pro dosažení škálovatelnosti, dostupnosti a odolnosti proti výpadkům. Vývojář má k dispozici různé nástroje od SDK a Visual Studio pro vývoj v.net Framework až po knihovny a doplňkové moduly pro vývoj v Eclipse a podporu jazyků Java a PHP. Uživateli je k dispozici webový portál ke správě účtů a služeb Windows Azure na adrese http://windows.azure.com. Registrací spolu s volbou způsobu účtování, kdy je na výběr model tzv. pay-as-you-go nebo zvýhodněné předplatné, uživatel získává v rámci jednoho účtu možnost nasazení šesti různých služeb a vytvoření pěti účtů v datovém úložišti. Každá služba se skládá z veřejně přístupné URL adresy a maximálně pěti různých rolí, u kterých lze volit libovolný počet běžících instancí. Jednotlivé účty v datovém úložišti mají maximální kapacitu 100 TB. Aplikace pro svůj běh může využít jeden ze dvou typů rolí: worker role (pracovní role) nebo web role (webová role). Instance role se skládá z kódu aplikace, konfigurace a lokálních dat nasazených na dedikovaném virtuálním serveru. Počet instancí každé role je volitelný. Na obrázku číslo 11 je znázorněna architektura služby Windows Azure. Základem je load balancer (LB), který směruje externí požadavky protokolu TCP nebo HTTP k jednotlivým instancím webové (Web Role) nebo pracovní role (Worker Role) a k datovému úložišti (Storage). Požadavky jsou směrovány pomocí algoritmu round-robin a load balancer je typicky obeznámen se stavem jednotlivých instancí tj. zda jsou zastavené, běží nebo se inicializují. V případě poruchy serveru je požadavek okamžitě směrován na jinou instanci. Požadavky jednoho klienta jsou většinou směrovány na různé instance a není proto vhodné ukládat jakýkoli stav aplikace lokálně. K tomuto účelu je vhodné použít dostupné datové úložiště například SQL Azure. Pro interní komunikaci mezi pracovními a webovými rolemi lze použít fronty (Queues) v případě asynchronního volání nebo přímé spojení v rámci synchronní komunikace, která není směrována přes load balancer. 32

Obrázek č. 11: Architektura služby Windows Azure Zdroj: Microsoft, Windows Azure Training Kit, prezentace Windows Azure Compute.pptx 5.2 Windows Azure Compute Windows Azure Compute představuje službu poskytující výpočetní výkon. Jedná se o virtuální server s operačním systémem Windows Server 2008. K dispozici jsou tři typy výpočetních rolí, přičemž roli lze přirovnat ke službě systému Windows. Role začne pracovat ihned po nasazení a zastaví se v okamžiku, kdy je potřeba nebo nastane chyba v kódu. Typy rolí Windows Azure Compute: - Worker Role (pracovní role). - Web Role (webová role). - VM Role (virtuální role s manuálně instalovaným operačním systémem). Pracovní role typicky zahrnuje nekonečnou smyčku, uvnitř které se provádí požadované úkony. Role by sama od sebe neměla skončit. Většinou je ukončení inicializováno vně pracovní role například příkazem k zastavení instance nebo při aktualizaci aplikace nebo operačního systému. Existují tři modely způsobu práce s pracovní rolí: 1. Dotazování role se dotazuje fronty (Queue), zda obsahuje zprávy ke zpracování. Pokud ano, je zpráva vyzvednuta z fronty, úkol definovaný zprávou vykonán, zpráva 33

je následně z fronty vymazána a dotazování na nové zprávy pokračuje. Například se může jednat o asynchronní zpracování obrázků. 2. Poslouchání role čeká na příchozí požadavky protokolu TCP, kdy je možné vytvořit TcpListener a nebo WCF Service Host (službu Windows Comunication Foundation). Příkladem může být vytvořený SMTP server pro příjem pošty. 3. Externí procesy role spustí jakýkoli proces nebo aplikaci kompatibilní s operačním systémem Windows. Například webový server Apache. Webová role rozšiřuje možnosti pracovní role tj. má všechny její vlastnosti a navíc Internetovou informační službu (IIS) pro hostování webových aplikací. Je možné nasazení ASP.NET aplikací (WebForms, MVC), FastCGI aplikací (PHP). Přičemž na jednu webovou instanci je možné nasadit více webových aplikací. Základním prvkem pracovní role je třída WorkerRole a webové role je třída WebRole definované v souborech WorkerRole.cs a WebRole.cs. Tyto třídy obsahují metody Onstart(), Run() a OnStop(), kde jsou definovány činnosti, které se mají vykonat při startu, běhu a zastavení instance Windows Azure. Následující příklad zobrazuje typickou smyčku pracovní role, ve které probíhá požadovaná činnost (například kontrola fronty, spuštění WCF služeb nebo TCP serveru). using Microsoft.WindowsAzure.ServiceRuntime; public class WorkerRole : RoleEntryPoint public override void Run() while (true) // TODO: read queue, do computing Thread.Sleep(10*1000); } } public override bool OnStart() // TODO: start diagnostic, create tables return base.onstart(); } } public override void OnStop() // TODO: cleanup base.onstop(); } 34

VM Role nabízí možnost přenesení stávajících aplikací běžících na Windows Server 2008 do prostředí Windows Azure. Základem je vytvoření virtuálního obrazu disku s již nainstalovanými aplikacemi a jeho nasazení přímo na instance virtuálních serverů. 5.3 Windows Azure Storage Windows Azure Storage je dedikované datové úložiště Windows Azure, přičemž je možné jej využít přímo jednotlivými výpočetními instancemi nebo odkudkoli z Internetu. Přístup je zajištěn pomocí REST webových služeb. Protokol HTTP nebo HTTPS. Bezpečnost je zajištěna pomocí 512 bit symetrického klíče nebo pomocí tzv. Shared Access Signatures, kdy je možné na specifikovaný časový úsek nastavit sdílené přístupové oprávnění. Řetězec pro přístup do úložiště je možné definovat v konfiguračním souboru a má následující tvar. Skládá se z názvu účtu v úložišti, který je součástí URL adresy, protokolu HTTP nebo HTTPS a symetrického klíče: <Setting name="dataconnectionstring" value="defaultendpointsprotocol=https;accountname=mystorage;accountkey=1g18 k0r1a1ugjtrniftbslwvlcewpejq5n437xwildl1emtrug1gg8lvyhyrrdouqzak6ju520famnq WJUhKfQ==" /> Existují čtyři typy úložiště: Blob, Table, Queue, Drive. Přistupovat do Azure Storage je možné přímo voláním REST služeb nebo pomocí knihovny Microsoft.WindowsAzure.StorageClient. Vytvořená aplikace a všechny ukázky zdrojového kódu pro přístup do úložiště využívají tuto knihovnu. Prvním krokem je vytvoření instance CloudStorageAccount s parametrem řetězce pro přístup a následně vytvoření klienta pro komunikaci s Blob, Table nebo Queue Storage, který může mít nastavené různé vlastnosti: var account = CloudStorageAccount.Parse( RoleEnvironment.GetConfigurationSettingValue("DataConnectionString")); var blobclient = account.createcloudblobclient(); blobclient.retrypolicy = RetryPolicies.Retry(3, TimeSpan.FromSeconds(3)); blobclient.timeout = TimeSpan.FromMinutes(5); Blob Storage Služba Blob Storage slouží k ukládání binárních nebo textových souborů a jejich metadat. Adresa jednotlivých souborů má následující formát: http://<account>.blob.core.windows.net/<container>/<blobname> 35

Blob resp. soubor je uložen v kontejneru (container), který patří uživateli a jeho účtu (account). Účet může obsahovat libovolný počet kontejnerů s neomezeným počtem souborů až do celkové kapacity 100 TB. Existují dva typy Block Blob a Page Blob. Block blob představuje úložiště pro klasické soubory například obrázky nebo video. Maximální velikost jednoho souboru je 200 GB. V případě, že velikost souboru překročí 64 MB, lze jej nahrát do úložiště pouze po částech o velikosti 1 4 MB. Page blob slouží pro ukládání nesouvislých dat s libovolným přístupem, jedná se o pole stránek o velikosti 512 bytů do maximální kapacity 1 TB. K uložení souboru v Blob Storage je možné vytvořit kontejner a následně referenci na blob formou relativní cesty. Pro vytvoření pseudo-struktury adresáře je možné použít znak / k oddělení složek. Fyzicky jsou data uložena přímo v kontejneru, ale je možné vyhledávat a třídit soubory podle definovaného adresáře. V následujícím příkladě bude soubor po uložení dostupný na adrese http://mystorage.blob.core.windows.net/mediacontainer/testvideo.wmv. CloudBlobContainer container = blobclient.getcontainerreference("mediacontainer"); container.createifnotexist(); CloudBlob blob = container.getblobreference("testvideo.wmv"); NameValueCollection metadata = new NameValueCollection(); metadata.add("filename", "testvideo.wmv"); blob.properties.contenttype = "video/x-ms-wmv"; blob.metadata.add(metadata); blob.uploadfile(@"d:\mymovies\testvideo.wmv"); Výchozí nastavení přístupových práv ke kontejneru je soukromý (Private), pokud by bylo nastaveno právo na čtení (Public read access), bylo by možné soubor přímo stáhnout zadáním jeho URL. Table Storage Služba Table Storage slouží k ukládání strukturovaných dat, neumožňuje pracovat s relačními daty (v tom případě lze použít SQL Azure, kde je základem Microsoft SQL Server 2008 s některými omezeními). Data v úložišti jsou uspořádána do tabulek (Table), které obsahují jednotlivé záznamy (Entity) a ty obsahují kolekci pojmenovaných vlastností a jejich hodnot. Velikost jednoho záznamu je omezena 1 MB a počet párů (jméno-hodnota) v kolekci je maximálně 255. Není definováno žádné schéma tabulky, která může obsahovat záznamy s různými libovolnými vlastnostmi. 36

Vlastnosti (resp. sloupce tabulky) jsou silně typové podle.net, je možné použít typ string, byte, bool, DateTime, Guid, int, int64, double. Pořadí v tabulce určuje index (jediný možný) složený z povinných klíčů záznamu PartitionKey a RowKey. Klíč PartitionKey zároveň slouží ke škálování a rozdělení dat na více serverů v případě zvýšené zátěže nebo počtu záznamů. Záznamy se stejným klíčem PartitionKey jsou uloženy na stejném místě. To je důležité v případě návrhu struktury tohoto klíče a následné tvorbě dotazů. Dotaz obsahující hodnotu PartitionKey je rychlejší než dotaz bez tohoto klíče, kdy je potřeba prohledat celou tabulku, která může být rozdělena a umístěna na několika serverech. Práce s Table Storage pomocí knihovny Microsoft.WindowsAzure.StorageClient vyžaduje definování entit, které reprezentují řádky v tabulce a jejich vlastnosti jsou uloženy jako sloupce. Následující příklad definuje třídu TagEntry, kde hlavní index je složen z názvu tagu (například: komedie nebo thriller ) a unikátního řetězce Guid. Jednou z vlastností je BlobUrl, která slouží pro referenci video souboru. TagEntry dědí z třídy TableServiceEntity, která má vlastnosti PartitionKey, RowKey a Timestamp. public class TagEntry : TableServiceEntity public TagEntry () } public TagEntry (string tag, Guid referenceguid, string bloburl) this.partitionkey = tag; this.rowkey = referenceguid.tostring(); this.timestamp = DateTime.UtcNow; this.bloburl = bloburl; } } public string BlobUrl get; set; } public void AddTag(string tag, Guid referenceguid, string blobismurl) var account = CloudStorageAccount.Parse( RoleEnvironment.GetConfigurationSettingValue("DataConnectionString")); var cloudtableclient = account.createcloudtableclient(); } TableServiceContext datacontext = cloudtableclient.getdataservicecontext(); datacontext.addobject("tagtable", new TagEntry(tag, referenceguid, blobismurl)); datacontext.savechangeswithretries(); Pro získání všech záznamů se stejnou hodnotou tagu je možné použít následující dotaz. public List<TagEntry> GetEntriesByTag(string tag) 37

TableServiceContext datacontext = cloudtableclient.getdataservicecontext(); var query = from t in datacontext.createquery<tagentry>("tagtable") where t.partitionkey == tag select t; } return query.tolist(); Queue Storage Služba Queue Storage je určena pro spolehlivé doručování zpráv v rámci aplikace nebo mezi různými aplikacemi. Umožňuje škálovat aplikaci vytvořením asynchronní komunikace a zpracováním úkolů na pozadí. Služba pracuje se dvěma typy: frontou (Queue) a zprávou (Message). Zpráva může obsahovat libovolná textová data do velikosti 8 KB. Fronta může obsahovat neomezený počet zpráv, pracuje na principu FI-FO (první dovnitř první ven). Obrázek číslo 12 znázorňuje práci s frontou služby Queue Storage: 1. Zpráva (Message) je vložena do fronty například pomocí webové role. 2. Pracovní role se v pravidelných intervalech dotazuje, zda fronta obsahuje novou zprávu, pokud ano, zprávu si přečte a ta je schována dalším instancím. 3. Po vykonání požadovaného úkolu pracovní role zprávu vymaže. 4. V případě nějaké chyby nebo neočekávané události, kdy pracovní role nedokončila zpracování úkolu a zpráva nebyla vymazána, se automaticky objeví zpátky ve frontě a jiná pracovní role ji může zpracovat. Interval, po který je zpráva neviditelná, je standardně 30 sekund, ale je možné jej nastavit až na 2 hodiny. Zpráva je uložena ve frontě maximálně po dobu 7 dní. Obrázek č. 12: Přehled práce s Queue Storage Zdroj: Microsoft, Windows Azure Training Kit, prezentace Windows Azure Storage.pptx Práce s Queue Storage a zprávami je obdobná jako práce s tabulkami nebo bloby. Výchozím bodem je vytvoření instance účtu, klienta a pak fronty spolu se zprávou. Následující přiklad 38

představuje vytvoření jednoduché zprávy s URL adresou souboru, který čeká na zpracování v blobu. CloudQueueClient queueclient = account.createcloudqueueclient(); string queuename = "mediaqueue"; CloudQueue queue = queueclient.getqueuereference(queuename); queue.createifnotexist(); string bloburl = "https://mystorage.blob.core.windows.net/mediacontainer/testvideo.wmv" CloudQueueMessage msg = new CloudQueueMessage(blobUrl); queue.addmessage(msg); Windows Azure Drive Služba Windows Azure Drive umožňuje připojení disku formátu NTFS k instancím Windows Azure Compute. Výhodou je snazší migrace aplikací využívající NTFS disky do Windows Azure. Služba využívá Page blob úložiště, maximální velikost disku je 1 TB. Disk (Virtual Hard Drive VHD) může být připojen k jedné instanci pro čtení a zápis nebo jako obraz disku s možností čtení k více instancím. Instance může dynamicky připojit až 16 disků. 5.4 Požadavky na aplikaci Vize Cílem projektu je vytvoření aplikace pro přehrávání videa pomocí webového prohlížeče a jeho zpracování do požadovaného formátu v prostředí Windows Azure tak, aby v případě úspěchu aplikace byla zaručena její dostupnost a dostatečná kapacita pro uložení všech video souborů. Specifikace Výsledným produktem je webová aplikace pro přehrávání video návodů nebo reportáží bez nutnosti jejich stahování do počítače. Může se jednat o krátká videa v délce desítek vteřin nebo delší záznamy s dobou trvání desítek minut. Video by mělo být dostupné v co nejvyšší kvalitě v závislosti na rychlosti připojení uživatele. Součástí řešení musí být i možnost nahrávání video souborů z lokálního počítače uživatele nebo administrátora. Funkční požadavky 39

- Uložení resp. nahrání ( upload ) video souborů do velikosti 4 GB. - Podpora opakovaného nahrávání ( upload ) videa v místě přerušení bez nutnosti spuštění ukládání souboru od začátku v případě výpadku síťového připojení. - Nahrávání souborů umožnit pouze registrovaným uživatelům. - Indikace průběhu nahrávání souboru na server. - Zpracování resp. převod videa do kompatibilního formátu provádět na pozadí. - Indikace průběhu zpracování souboru do požadovaného formátu. - Automatické spuštění přehrávání videa po zadání definované URL adresy ve formátu http://<název-domény>/rok/měsíc/<titul-video-souboru>. - V závislosti na rychlosti připojení přizpůsobit kvalitu resp. velikost dat. - Registrace pomocí webového portálu. - Administrace video souborů na webovém portálu: výpis seznamu, smazání, nastavení přístupu. - Všechny hlavní činnosti uživatelů a výjimky ukládat do tabulky v Table Storage. - Statistika počtu zobrazení jednotlivých videí. - Možnost přiřazení popisku resp. tagu k videu a možnost vyhledávání. Nefunkční požadavky - Nasazení aplikace ve Windows Azure. - Maximální dostupnost webové aplikace (SLA 99,95%) - Úspora nákladů v případě, kdy nejsou žádné video soubory čekající na zpracování. - Pro přehrávání videa použít aplikaci Microsoft Silverlight. - Pro ukládání dat nepoužívat relační databázi SQL Azure. - Webová aplikace vytvořená v ASP.NET MVC. Rizika a omezení - Volba technologie pro obsluhu dat a jejich přenos uživateli. - Podpora formátu kódování pro přehrávání. 40

- Doba převodu videa do požadovaného kódování. - Zpoždění při požadavku na přehrání souboru. - Vyřešení případu, kdy není potřeba výpočetní kapacity pro zpracování videa. 5.5 Analýza požadavků Analýza požadavků se zaměřuje na mapování hlavních funkcí aplikace, volbu technologie, podporu nástrojů a použití existujících aplikací v rámci projektu. Nejdůležitějším resp. nejrizikovějším bodem řešení je, jakým způsobem zajistit přehrávání video souborů ve webovém prohlížeči tj. jakou zvolit technologii, jaká je podpora na straně serveru a jak doručit data klientovi. Projekt je možné rozdělit na tři samostatné části: - Přehrávání a zpracování videa. - Nahrávání video souborů. - Webový portál. V rámci řešení je zároveň důležité optimalizovat provoz ve Windows Azure tj. minimalizovat využití prostředků v případě slabého zatížení a možnost zvýšení počtu instancí nebo procesorů v závislosti na vzrůstajícím počtu uživatelů nebo video souborů čekajících na zpracování. Přehrávání a zpracování videa Pro přehrávání videa ze serveru existuje možnost použití tzv. Smooth Streaming což je implementace HTTP adaptativního streamování (adaptive streaming) od firmy Microsoft. Adaptive streaming je hybridní metoda doručování obsahu založená na progresivním HTTP stahování. Metoda zahrnuje doručení obsahu ze serveru na klienta pomocí HTTP stahování krátkých částí celkového souboru získaných jeho rozdělením. Video soubor je obvykle konvertován do několika souborů různé kvality a velikosti a v závislosti na propustnosti linky směrem k uživateli jsou použity části s nejvyšší možnou kvalitou záznamu. Následující obrázek znázorňuje schéma procesu doručení obsahu ve formátu Smooth Streaming ke klientovi. Proces začíná vytvořením videa, pokračuje jeho zpracováním a obsluhou ze serveru přes CDN do aplikace Silverlight běžící ve webovém prohlížeči klienta. 41

Obrázek č. 13: Smooth Streaming proces Zdroj: Knowlton Chris, SMEast2010-Microsoft.pdf Smooth Streaming je podporován technologií Silverlight tj. v systému Windows nebo Mac stačí nainstalovat modul Silverlight pro webové prohlížeče. Pomocí open source implementace Moonlight 2 je podpora zajištěna i pro platformu Linux. Převod video souboru do formátu podporující Smooth Streaming je možný pomocí volně dostupné verze softwaru Microsoft Expression Encoder 4. Výsledkem je několik souborů s příponou *.ismv video soubory ve formátu MP4 s různým bitrate a soubory s příponou *.ism a *.ismc soubory s informacemi ve formátu XML. V případě požadavku na přehrání videa, IIS7 server automaticky rozdělí MP4 soubory na fragmenty a odešle je klientovi jako jednotlivé soubory, kvalita je volena podle propustnosti linky. Obrázek č. 14 zobrazuje soubory, které jsou výsledkem zpracování originálního videa, ve formátu WMV o velikosti 60 MB, aplikací Microsoft Expression Encoder 4. Soubory jsou uloženy v blob storage a otevřené ve volně dostupném programu CloudXplorer od společnosti ClumsyLeaf Software. 42

Obrázek č. 14: Výsledné soubory pro Smooth Streaming Zdroj: vlastní úprava Microsoft plánuje přímou podporu Smooth Streaming pomocí Windows Azure CDN, bohužel v době psaní této práce tato možnost není k dispozici. Existují dvě možnosti řešení. První možnost zahrnuje použití IIS Media Services, doplňku IIS7 serveru, přímo na instanci webové role aplikace. Pro fungování je potřeba, aby byly video soubory na lokálním disku, kde běží IIS7 server. To znamená, že by všechny zpracované MP4 soubory a metadata musela být kopírována na jednotlivé instance webové aplikace, které mají omezenou kapacitu. Druhá možnost, která je vybrána v tomto projektu, jako dočasné řešení než bude Smooth Streaming podporovaný ve Windows Azure, je použití dostupné knihovny pro automatické rozdělení MP4 souborů na jednotlivé fragmenty a jejich uložení v Blob Storage podle struktury potřebné pro klientský přehrávač. Místo originálních osmi souborů je uloženo desítky až stovky jednotlivých fragmentů, které budou doručovány přímo z úložiště přes CDN, jak znázorňuje obrázek č. 15. 43

Obrázek č. 15: Datové fragmenty pro doručení Smooth Streaming Zdroj: vlastní úprava Pro vytvoření přehrávače bude použit Smooth Streaming Client 1.5 a Microsoft Media Platform: Player Framework. Tyto knihovny obsahují možnost využití již stávající komponenty přehrávače a jeho zahrnutí do kódu aplikace. Protože se služba Windows Azure účtuje pro všechny instance, i když nejsou v provozu, tj. aplikace je nasazená, ale virtuální servery jsou zastavené, je důležité monitorovat vytíženost části aplikace starající se o zpracování video souborů a operativně měnit počet běžících instancí nebo v případě nulového provozu nasazenou aplikaci kompletně smazat. Při změně stavu, uložením nových souborů, je pak možné aplikaci znovu nasadit v požadovaném počtu instancí. Windows Azure obsahuje Managemet API pro správu aplikací a k dispozici jsou také moduly v jazyce Power Shell pro podobné úkoly. Správu je možné provádět z lokálního počítače nebo jiné nasazené aplikace běžící ve Windows Azure. Z tohoto důvodu budou vytvořeny dvě nezávislé služby, které budou do Windows Azure nasazeny samostatně. První služba bude obsahovat webový portál a pomocné služby související s nahráváním souborů a správou druhé služby. Ta bude vykonávat pouze zpracování videa převod do správného formátu. První služba poběží ve Windows Azure nepřetržitě s minimálním počtem instancí 2. Druhá služba bude používat výkonnější specifikaci tj. instanci typu Large nebo Extra Large s 4 resp. 8 procesory, které jsou vhodnější pro zpracování video souborů v porovnání se stejným počtem instancí využívající pouze jeden procesor. Tuto samostatnou službu bude 44

jednodušší kompletně smazat v situaci, kdy nebude potřeba zpracovat nový video soubor a šetřit tak provozní náklady. Nahrávání video souborů Funkce nahrávání ( upload ) souborů bude zajištěna klientskou aplikací spouštěné z lokálního počítače uživatele kompatibilní se systémem Windows. Je možné použít konzolovou aplikaci nebo aplikaci typu WPF (Windows Presentation Foundation) pro uživatelsky příjemnější vzhled a komfort ovládání. Aplikace využije knihovnu Microsoft.WindowsAzure.StorageClient pro komunikaci se službou Azure Storage, která se pomocí REST rozhraní stará o práci s daty. Video soubory budou uloženy přímo do Blob Storage, do kontejneru určeného pro další zpracování. Originální soubory mohou být archivovány nebo smazány. Pro inicializaci dalších kroků bude použita fronta, kam aplikace uloží zprávu s URL adresou originálního souboru. Fronta zajistí škálovatelnost a odolnost zprávy resp. úkolu pro následné zpracování videa. Jakákoli instance k tomu určená, pak může vyzvednout zprávu a zpracovat video. Knihovna pro práci s datovým úložištěm také umožňuje paralelní nahrávání částí souboru, kterým je možné proces urychlit v závislosti na propustnosti síťového spojení. Při nahrávání souboru, který je větší než 64 MB, je tento soubor rozdělen na části o velikosti 1 až 4 MB a ty jsou uloženy postupně. Na stejném principu je možné modifikovat proces ukládání souboru do datového úložiště tak aby podporoval restart v případě nějaké chyby nebo výpadku spojení a nebylo nutné ukládat soubor znova od začátku. Webový portál Podle požadavků bude webový portál vytvořen pomocí ASP.NET MVC verze 3. Tato verze frameworku není automaticky kompatibilní s webovou rolí Windows Azure. Je nutné spolu s aplikací nahrát potřebné knihovny, které v systému chybí, ale jsou součástí instalace ASP.NET MVC 3. Hlavní funkcí portálu bude obsluha požadavků na stažení Silverlight přehrávače videa. MVC kontrolér nastaví vstupní parametry přehrávače podle zadané adresy požadavku. Odkaz na soubor obsahující Smooth Streaming manifest data bude směřovat do Blob Storage přes Azure CDN. 45

Mezi dalšími funkcemi portálu je registrace, autentizace a autorizace uživatelů pomocí jména resp. e-mailové adresy a hesla. Registrovaný uživatel má možnost spravovat své vlastní nahrané video soubory tj. zobrazit seznam, smazat soubor, nastavit přístup na veřejný nebo soukromý a přejmenovat soubor resp. změnit titulek videa, který je použitý v URL pro přehrání videa. Video souboru je možné přiřadit popisek v podobě hesel, podle kterých je možné jej následně vyhledat. Návštěvník webového portálu může zobrazit video zadáním konkrétní webové adresy, kterou získá přímo od vlastníka video souboru resp. uživatele, který video nahrál. V případě veřejných souborů lze vyhledat soubor podle popisku jednoduchého hesla (tag). Protože není použita relační databáze k ukládání dat, je potřeba vhodně zvolit strukturu indexu v jednotlivých tabulkách (PartitionKey, RowKey). Diagram případů užití na následujícím obrázku identifikuje hlavní aktéry aplikace, kterými jsou vlastník videa, divák a proces pro zpracování videa. Stěžejními činnostmi jsou: uložení souboru, zpracování videa, vyhledávání a zobrazení přehrávání. Obrázek č. 16: Diagram případů užití Zdroj: vlastní úprava 46

6 Návrh, implementace a provoz 6.1 Architektura aplikace Jak bylo uvedeno v analýze požadavků, aplikace se skládá ze dvou samostatných Windows Azure služeb pro obsluhu a zpracování video souborů a jedné Windows Presentation Foundation (WPF) aplikace pro nahrávání souborů přímo do Blob Storage a inicializace procesu zpracování videa. Obrázek č. 17: Základní architektura aplikace Zdroj: vlastní úprava 47

Veškerá data budou ukládána v Azure Storage. Použití Blob Storage pro video soubory a Queue Storage pro inicializaci souborů ke zpracování je vcelku jednoznačná volba. Pro uložení veškerých informací o uživatelích, souborech i záznamů různých logů lze zvolit SQL Azure nebo Table Storage. V rámci úspory nákladů a z cvičebních důvodů bude aplikace používat pouze Table Storage. SQL Azure by bylo výhodnější použít při vyšším počtu relačních dat spolu s kombinací Table Storage pro logování. Rozhodnutí nepoužívat relační databázi klade vyšší nároky na design tabulek a jejich indexů obzvláště klíčů PartitionKey pro optimalizaci dotazů. V aplikaci bude možné vyhledávat soubory podle kategorie resp. tagu, podle uživatele a podle názvu. Pro každý druh vyhledávání bude použita jedna tabulka. Veškerá volání metod a požadavků na přehrávání souborů budou ukládána do tabulky logů. Výjimky a ladící zprávy budou zapisovány standardní metodou Trace.TraceInformation() nebo Trace.TraceError() a v pravidelných intervalech ukládány do výchozí tabulky pro monitorování aplikaci ve Windows Azure. K tomuto účelu slouží tabulka WADLogsTable. Záznamy událostí z Windows Application a System logů budou ukládány do tabulky WADWindowsEventLogsTable. Registrace uživatelů a jejich autorizace bude využívat knihovnu AspProviders (Microsoft.Samples.ServiceHosting.AspProviders) implementující ASP.NET Membership Provider. Design tabulek pro video soubory a logování MediaTable Název atributu Datový typ Poznánka Tabulka č. 7: Návrh tabulky MediaTable PartitionKey String UserId (Guid) identifikátor uživatele. RowKey String MediaReference (Guid) identifikátor souboru, přiřazen při uložení videa ke zpracování. Timestamp DateTime Čas aktualizace v UTC. BlobUrl String Url adresa v Blob Storage. MediaName String Název videa (titulek). MediaUrlName String Název videa vhodný pro použití v URL a SEO. Bez nepovolených znaků a mezery nahrazeny pomlčkou. Tags String Hodnoty tag oddělené čárkou. Public Boolean True v případě, že je video veřejné. Zdroj: vlastní úprava 48

Tabulka MediaTable je hlavní tabulka se všemi důležitými daty. PartitionKey je volen tak, aby dotaz pro nalezení všech souborů jednoho uživatele byl co nejefektivnější. V případě, kdy je znám i identifikátor souboru, který je uložen v RowKey, je dotaz jednoznačně nejrychlejší. Tabulka MediaNameTable slouží pro vyhledání souboru v případě požadavku na přehrávání, kdy je identifikován ve tvaru /rok/měsíc/titulek-souboru. Volba PartitionKey umožňuje i vyhledávání podle roku nebo podle roku a měsíce. PartitionKey nepoužívá GUID jako jednoznačný identifikátor, z tohoto důvodu je nutná validace, protože spojení PartitonKey RowKey musí být unikátní. MediaNameTable Tabulka č. 8: Návrh tabulky MediaNameTable Název atributu Datový typ Poznánka PartitionKey String Rok a měsíc vytvoření ve formátu YYYYMM (např: 201106). RowKey String MediaUrlName stejné jako v tabulce MediaTable. Timestamp DateTime Čas aktualizace v UTC. BlobUrl String Url adresa v Blob Storage. MediaName String Název videa (titulek). MediaReference Guid Identifikátor souboru stejná hodnota jako RowKey v MediaTable. Zdroj: vlastní úprava TagsTable Název atributu Datový typ Poznánka Tabulka č. 9: Návrh tabulky TagsTable PartitionKey String Název tagu (kategorie) jedná se o jeden výraz. U víceslovných kategorií je použito podtržítko místo mezery. RowKey String MediaReference (Guid) identifikátor souboru, přiřazen při uložení videa ke zpracování. Timestamp DateTime Čas aktualizace v UTC. BlobUrl String Url adresa v Blob Storage. MediaName String Název videa (titulek). MediaReference Guid Identifikátor souboru stejná hodnota jako RowKey v MediaTable. Zdroj: vlastní úprava 49

Tabulka TagsTable má za cíl indexaci jednotlivých tagů nebo kategorií přiřazených k video souboru. Vyhledávání mezi záznamy v Table Storage jinými než PartitionKey a RowKey není efektivní. Když není znám PartitionKey je nutné při dotazu projít všechny záznamy v tabulce, to může být problém u většího počtu záznamů. Tabulka MediaEncodeTable slouží ke sledování stavu převodu video souboru do správného formátu. Umožňuje sledovat i dobu potřebnou ke zpracování. Hlavní funkcí této tabulky je zabránění tomu, aby byl jeden soubor paralelně zpracován více instancemi a také aby soubor, který je poškozen neblokoval proces zpracovávání a byl po několika neúspěšných pokusech odstraněn z fronty. MediaEncodeTable Tabulka č. 10: Návrh tabulky MediaEncodeTable Název atributu Datový typ Poznánka PartitionKey String MediaReference (Guid) identifikátor souboru, přiřazen při uložení videa ke zpracování. RowKey String Prázdný řetězec (String.Empty) Timestamp DateTime Čas aktualizace v UTC. CreatedOn DateTime Čas vytvoření v UTC. StartedOn DateTime Čas začátku zpracovávání videa v UTC. FinishedOn DateTime Čas ukončení zpracovávání videa v UTC. BlobUrl String Url adresa v Blob Storage. MediaName String Název videa (titulek). Status String Stav zpracovávaného souboru. Hodnoty např: Created, InProgress, Completed, Corrupted. DequeueCount Int Počet kolikrát byl soubor zpracováván. Zdroj: vlastní úprava Tabulka LogsTable je určena k monitorování provozu. Jsou zaznamenána veškerá volání metod spojených s procesem zpracovávání videa, činností uživatele i požadavků na přehrávání jednotlivých souborů. LogsTable Název atributu Datový typ Poznánka Tabulka č. 11: Návrh tabulky LogsTable PartitionKey String Hodnota dne zbývající do maximální hodnoty DateTime pro sestupné řazení. 50

RowKey String Čas zbývající do maximální hodnoty DateTime pro sestupné řazení + Guid jako jednoznační identifikátor. Timestamp DateTime Čas aktualizace v UTC. Message String Zpráva. LogType String Hodnoty: Critical, Error, Information, Verbose. MediaReference Guid Identifikátor souboru stejná hodnota jako RowKey v MediaTable. UserId Guid Identifikátor uživatele. LogOrigin String Název třídy a metody inicializující záznam logu. Zdroj: vlastní úprava 6.2 Nahrávání souborů Obrázek číslo 17 znázorňuje základní architekturu aplikace. Ve skutečnosti WPF aplikace pro nahrávání souborů nebude komunikovat přímo s Queue Storage, ale bude komunikovat prostřednictvím webové služby. Je možné, aby klient měl přímý přístup k tabulkám a frontám, ale v tom případě by bylo nutné sdílet tajný klíč. Protože aplikace pro nahrávání video souborů bude dostupná všem uživatelům, kteří z pochopitelných důvodů nemohou mít plný přístup ke všem datům, bude komunikace zajištěna pomocí WCF služby a pro přímý zápis souborů do Blob Storage bude využito tzv. Shared Access Signature. Shared Access Signature se používá pro zajištění přístupu do Blob Storage, bez nutnosti použití klíče k účtu úložiště, a spočívá v nastavení přístupových práv pro čtení, zápis nebo výpis seznamu pro kontejner nebo jednotlivý blob. Přístup je časově omezen a pro klienta je specifikován parametry sr, si a sig v řetězci URL adresy blobu. Nastavení práv pro blob je omezeno na jednu hodinu a nahrávání velkých souborů může trvat déle, aplikace využije nastavení přístupu na úrovni kontejneru, kdy pro každý soubor bude vytvořen dočasný kontejner s právem zapisovat. Níže je uveden příklad adresy: https://mystorage.blob.core.windows.net/ztemp20110601-981fda7c-b32d-4b25-9f77-b3f98fb231d8/aa574c42-6594-48cf-b367-512586b89921/56489167-689b-4995- b2f4- ab1c844e946b.wmv?sr=c&si=mypolicy&sig=h6brhpocij6jo4l8duhdeb2c9xjqlce7yezdk hrdwvg%3d URL adresa blobu s Shared Access Signature se skládá z názvu kontejneru, který je tvořen předponou ztemp, aktuálním dnem ve formátu YYYYMMDD a generovaným Guid. Strukturu složky tvoří ID uživatele (Guid) a název souboru reprezentovaný opět 51

identifikátorem Guid pro video soubor. Pro kontejner je nastaveno právo zapisovat po dobu 10 hodin s pojmenovaným podpisem přístupu mypolicy. public string GetSasBlobUrl(string username, string password, string filename) // Validate user and get userid + blobclient //... string containername = String.Format("ztemp0}-1}", DateTime.UtcNow.ToString("yyyyMMdd"), Guid.NewGuid()); CloudBlobContainer container = blobclient.getcontainerreference(containername); bool containercreated = container.createifnotexist(); BlobContainerPermissions containerpermissions = new BlobContainerPermissions(); containerpermissions.publicaccess = BlobContainerPublicAccessType.Off; containerpermissions.sharedaccesspolicies.add("mypolicy", new SharedAccessPolicy() SharedAccessStartTime = DateTime.UtcNow.AddMinutes(-5), SharedAccessExpiryTime = DateTime.UtcNow.AddHours(10), Permissions = SharedAccessPermissions.Write }); container.setpermissions(containerpermissions); string relativeblobreference = String.Format("0}/1}2}", userid, Guid.NewGuid(), Path.GetExtension(filename)); var blob = container.getblobreference(relativeblobreference); string sas = container.getsharedaccesssignature(new SharedAccessPolicy(), "mypolicy"); } return blob.uri.absoluteuri + sas; Nahrávání souboru ke zpracování bude probíhat v následujících krocích: 1. Volání metody GetBlobUrl(), která vytvoří dočasný kontejner, nastaví právo zapisovat a vygeneruje Shared Access Signature, který vrátí spolu s URL adresou blobu. 2. URL adresa je použita pro vytvoření reference a soubor je nahrán přímo do dočasného úložiště v Blob Storage. 3. Volání metody CommitMedia(), která přesune soubor do jiného neveřejného kontejneru, uloží data o souboru tabulky MediaEncodeTable a vloží novou zprávu s ID uživatele, souboru a adresou blobu do fronty, kde bude čekat na vyzvednutí pracovní rolí. 52

Podmínkou volání WCF služeb je nastavení jména a hesla, které je vyžadováno pro autorizaci požadavků a přístup je umožněn pouze registrovaným uživatelům. Metoda WPF aplikace pro uložení souboru v Blob Storage: public void UploadMediaFile(string filepath, string username, string password) FileInfo fi = new FileInfo(filePath); // get url AzureService.ServiceClient client = new AzureService.ServiceClient(); string tempurl = client.getsasbloburl(username, password, fi.name); // upload file CloudBlob blob = new CloudBlob(tempUrl); blob.uploadfile(filepath); // init encoding string blobref = client.commitmedia(username, password, fi.name, title, tags); } Metoda CommitMedia(), je součástí WCF služeb hostovaných webovou rolí, současně s MVC portálem. Uvnitř metody je validace uživatele, přesunutí souboru z dočasného blobu a jeho smazání, do kontejneru pro videa čekající na zpracování. Zároveň jsou data uložena do všech tabulek a nová zpráva je uložena do fronty. Třída EncoderMessage definuje zprávu, která je složena z id uživatele, id souboru a URL adresy, kde je soubor uložen. Jednotlivé hodnoty jsou odděleny znakem. public class EncoderMessage public Guid UserId get; private set; } public Guid FileReference get; private set; } public string InputBlobUrl get; private set; } public EncoderMessage(Guid userid, Guid filereference, string inputbloburl) this.userid = userid; this.filereference = filereference; this.inputbloburl = inputbloburl; } public static EncoderMessage Parse(string message) string[] values = message.split(' '); Guid userid = new Guid(values[0]); Guid filereference = new Guid(values[1]); string inputbloburl = values[2]; } return (new EncoderMessage(userId, filereference, inputbloburl)); 53

} public override string ToString() return String.Format("0} 1} 2}", this.userid, this.filereference, this.inputbloburl); } 6.3 Zpracování videa Část aplikace pro zpracování video souborů, resp. jejich převod do formátu Smooth Streaming tvoří vlastní projekt a je nasazena nezávisle na části s portálem MVC a službami WCF. Důvodem je možnost měnit počet instancí, případně kompletní službu smazat a opět znova spustit. Počet instancí lze měnit i v případě, že by pracovní role byla součástí projektu společně s webovou rolí, ale důležitá je možnost službu smazat a to lze pouze pokud běží samostatně. Pracovní role má dvě části. Samotnou třídu WorkerRole, která pokud se nezpracovává žádný soubor, pravidelně monitoruje frontu, zda neobsahuje nové zprávy. Nová zpráva znamená nový úkol, který pracovní role inicializuje. Samotné zpracování video souborů provádí vytvořená konzolová aplikace využívající Microsoft Expression Encoder SDK. Z tohoto důvodu musí být na instanci pracovní role nainstalován software Microsoft Expression Encoder verze 4. Instalace probíhá pomocí aplikace Web Platform Installer resp. její verze spouštěné z příkazového řádku tj. WebPICmdLine.exe. Instalace je umožněna pomocí tzv. Startup tasks úkolů, které jsou spuštěné při inicializaci Windows Azure role. Úkol je jakýkoli spustitelný soubor, většinou typu cmd. Na obrázku číslo 18 je vidět struktura projektu s otevřeným definičním souborem pracovní role, kde je specifikován úkol spouštěný souborem InstallEncoder.cmd. Ten mimo jiné obsahuje příkaz k instalaci Microsoft Expression Encoder 4: REM : Install Encoder "%~dp0\webpicmd\webpicmdline.exe" /accepteula /Products: ExpressionEncoder4 /log:encoder.txt 54

Obrázek č. 18: Projekt pracovní role ve Visual Studio 2010 Zdroj: vlastní úprava Po dokončení inicializace pracovní role včetně instalace potřebných aplikací, je volána metoda Run() třídy WorkerRole, která obsahuje nekonečnou smyčku pro kontrolu nových zpráv a zpracování souborů. Pokud dojde během procesu k chybě, není zpráva odstraněna z fronty a může dojít k opětovnému pokusu o transformaci videa. public override void Run() while (true) CloudQueueMessage msg = queue.getmessage(); if (msg!= null) try ProcessEncodingJob(msg); queue.deletemessage(msg); } catch (Exception ex) Trace.TraceError("Encoding error: " + ex.tostring()); } } else Thread.Sleep(10000); } } } 55

Zpracování souborů pomocí pracovní role, po příjmu zprávy obsahující text vytvořený třídou EncoderMessage, probíhá v následujících krocích: 1. Dekóduje zprávu a vytvoří instanci EncoderMessage. 2. Blob URL ze zprávy je použita pro stažení souboru na lokální disk instance. 3. Konzolová aplikace Windows pro video transformaci je spuštěna s parametry cesty ke zdrojovému souboru, výstupní složkou a identifikátorem souboru. 4. Konzolová aplikace v pravidelných intervalech (5 minut) aktualizuje tabulku MediaEncodeTable. V případě, že jiná instance vyzvedne zprávu a zjistí, že aktualizace proběhla v daném intervalu (10 minut), instance zprávu ignoruje a vrátí do fronty (podle nastavení VisibilityTimeout). 5. Po ukončení procesu transformace jsou soubory nahrány do Blob Storage a všechny lokální vstupní i výstupní soubory jsou smazány. 6. Nakonec je odstraněna i zpráva z fronty. Metoda RunEncodingJob() spouští proces konzolové aplikace a případné chybové výstupy přeposílá pomocí Trace.TraceError procesu monitorování a diagnostiky. private bool RunEncodingJob(string filepath, string outputdirectory, Guid filereference) bool isencoded = false; Process[] processes = Process.GetProcessesByName( Path.GetFileNameWithoutExtension(encoderAppPath)); if (processes.length == 0) ProcessStartInfo startinfo = new ProcessStartInfo(encoderAppPath); startinfo.arguments = String.Format("0} 1} 2}", filepath, outputdirectory, filereference); startinfo.redirectstandarderror = true; startinfo.useshellexecute = false; using (Process encoder = new Process()) encoder.startinfo = startinfo; encoder.start(); string error = encoder.standarderror.readtoend(); Trace.TraceError("EncoderConsoleApp.exe error: 0}", error); encoder.waitforexit(); isencoded = (encoder.exitcode == 0); } } return isencoded;} 56

Jádrem konzolové aplikace je Microsoft Expression Encoder SDK s třídami MediaItem a Job. Výstupní formát je definovaný v Presets.VC1IISSmoothStreamingScreenEncodingVBR. Výstupem jsou video soubory ve standardu VC1, kompatibilní s technologií Silverlight. // using Microsoft.Expression.Encoder; MediaItem mediaitem; mediaitem = new MediaItem(filename); // Create a job and the media item for the video to encode. Job job = null; try job = new Job(); job.mediaitems.add(mediaitem); // output silverlight smooth streaming files job.applypreset(presets.vc1iissmoothstreamingscreenencodingvbr); // Set up the progress callback function job.encodeprogress += new EventHandler<EncodeProgressEventArgs>(OnProgress); // Set the output directory and encode. job.createsubfolder = false; job.outputdirectory = outputdirectory; job.encode(); } catch (Exception ex) Console.Error.WriteLine("EncoderConsoleApp error: 0}", ex.tostring()); return ERROR; } finally timer.dispose(); job.dispose(); } return SUCCESS; Výstupní soubory jsou paralelně nahrány do Blob Storage a pomocí Azure CDN následně doručeny Silverlight klientovi. // upload encoded files to blob Parallel.ForEach(Directory.GetFiles(outputDirectory), filepath => string blobname = String.Format("0}/1}", blobdirectoryurl, Path.GetFileName(filePath)); CloudBlob blob = container.getblobreference(blobname); Trace.TraceInformation("Uploading blob '0}'.", blobname); blob.uploadfile(filepath, blobrequestoptions); }); 57

6.4 Webový portál Webový portál pro přehrávání video souborů pomocí technologie Smooth Streaming využívá technologii Silverlight, Microsoft Media Platform: Player Framework v2.5 dostupný na adrese http://smf.codeplex.com/ a Smooth Streaming Client dostupný na adrese http://www.iis.net/download/smoothclient. Microsoft Media Platform obsahuje komponenty přehrávače s podporou Smooth Streaming. Aplikace využívá základní nastavení, při inicializaci přehrávače je tak pouze potřeba nastavit cestu k XML souboru ( *.ism/manifest ) s informacemi o dostupných bitrate a časování. <UserControl x:class="mediaplayer.mainpage" xmlns=... assembly=microsoft.silverlightmediaframework.core" xmlns:media="clr-namespace:microsoft.silverlightmediaframework.core.media; assembly=microsoft.silverlightmediaframework.core" > <Grid x:name="layoutroot" Background="Beige"> <Core:SMFPlayer x:name="player > <Core:SMFPlayer.Playlist> <Media:PlaylistItem DeliveryMethod="AdaptiveStreaming" /> </Core:SMFPlayer.Playlist> </Core:SMFPlayer> </Grid> </UserControl> public partial class MainPage : UserControl public string PlayerMediaSource set if (String.IsNullOrEmpty(value) == false) Player.Playlist[0].MediaSource = new Uri(value); } } //... } MVC aplikace má definovány vzory pro směrování URL a pokud adresa obsahuje parametry rok (year), měsíc (month) a titulek souboru (medianame) je požadavek předán MCV kontroleru s metodou Play() včetně specifikovaných parametrů. Záznam je vyhledán v tabulce MediaNameTable a je vrácena URL adresa ism souboru v Blob Storage pomocí CDN. public ActionResult Play(int year, int month, string medianame) MediaRepository mr = new MediaRepository(); string url = mr.getcdnmanifesturl(year, month, medianame); } ViewBag.PlayerMediaSource = url; return View(); 58

View v části MVC aplikace pro přehrávání videa obsahuje objekt typu Sliverlight, kterému je v parametru initparams nastavena hodnota mediasource rovnající se adrese CDN manifest souboru. <object data="data:application/x-silverlight-2," type="application/x-silverlight-2" width="100%" height="100%"> <param name="source" value="/clientbin/mediaplayer.xap" /> <param name="onerror" value="onsilverlighterror" /> <param name="background" value="white" /> <param name="minruntimeversion" value="4.0.50826.0" /> <param name="autoupgrade" value="true" /> <param name="initparams" value="mediasource=@viewbag.playermediasource" /> <a href="http://go.microsoft.com/fwlink/?linkid=149156&v=4.0.50826.0" style="text-decoration: none"> <img src="http://go.microsoft.com/fwlink/?linkid=161376" alt="get Microsoft Silverlight" style="border-style: none" /> </a> </object> CDN adresa manifest dat má například následující tvar a výsledek přehrávače doručeného klientovi je vidět na obrázku číslo 19. http://az59814.vo.msecnd.net/videos/076a3c78-56e9-4029-aaef- 7a3f9cac5edc/5dca7969-b3a7-47dd-bf91-a893fc269c79.ism/Manifest Obrázek č. 19: Přehrávač videa v prohlížeči Internet Explorer 9 Zdroj: vlastní úprava 59

Obrázek číslo 20 znázorňuje průběh komunikace mezi klientem aplikací Silverlight a serverem, v tomto případě Azure CDN. Přehrávač posílá na server požadavky na fragmenty o různé kvalitě, které jsou následně z CDN doručeny klientovy. Obrázek č. 20: HTTP komunikace a fragmenty videa při přehrávání ve Fiddleru Zdroj: vlastní úprava Webový portál MVC, kromě jiných funkcí umožňuje vyhledávání podle kategorie resp. tagu. Soubor může mít přiřazen několik tagů oddělených čárkou. Při ukládání do tabulky TagsTable jsou jednotlivé tagy rozděleny a uloženy samostatně tj. pro jeden tag jednoho souboru existuje jeden záznam v tabulce. Dotaz na získání všech záznamů pro nějakou hodnotu tagu může vrátit velmi mnoho položek, z tohoto důvodu je pro toto vyhledávání implementováno stránkování. TableStorage neumožňuje získat celkový počet záznamů jedním dotazem pro součet by bylo nutné stáhnout všechny záznamy a lokálně je sečíst, což může být výpočetně velmi náročné. Zároveň je možné získat jedním dotazem maximálně 1000 záznamů. Problém se stránkováním a získáním většího počtu záznamů řeší tzv. Continuation Token identifikátor řádku v tabulce, kde má následující dotaz pokračovat. Ten je vrácen ze serveru spolu se záznamy a použije se v dotazu pro následující skupinu dat. Není možné náhodně přejít na libovolnou stránku. Vždy lze pouze procházet stránky v pořadí, jak jdou za sebou a 60