Internet Developer Forum

Obsah 1

CLOUD COMPUTING ... JE VŠUDE OKOLO NÁS ___________________________________ 3

1.1

Co zůstává a co se mění: informatika v čase cloud computingu ______________________________________ 3 1.1.1

Cloud Computing podle Gartnerů ____________________________________________________________ 3

1.1.2

Cloud computing chtějí dělat všichni __________________________________________________________ 5

1.1.3

Cloud computing prakticky _________________________________________________________________ 7

1.1.4

Co získáte s Cloud Computing ______________________________________________________________ 8

1.1.5

Cloud Computing prakticky _________________________________________________________________ 9

2

CLOUD HOSTING ANEB HOSTING V OBLACÍCH __________________________________ 10

2.1

Grid computing, cloud computing, cloud hosting – co ta slova znamenají? ___________________________ 10

2.2

Tak co to tedy ten cloudhosting je a k čemu to je? ________________________________________________ 10

2.3

Jak to vypadá v praxi? _______________________________________________________________________ 10 2.3.1

Amazon EC2 ___________________________________________________________________________ 11

2.3.2

Amazon S3 ____________________________________________________________________________ 12

2.3.3

CloudFront_____________________________________________________________________________ 12

2.4

Mosso _____________________________________________________________________________________ 12

2.5

GoGrid_____________________________________________________________________________________ 12

2.6

K čemu to je? _______________________________________________________________________________ 13 2.6.1

Pro jaké projekty je ale vhodné o použití cloudhostingu uvažovat? _________________________________ 13

2.7

Ceny cloudhostingu _________________________________________________________________________ 13

2.8

Pro lidi i programátory… ______________________________________________________________________ 14

2.9

Závěr ______________________________________________________________________________________ 14

2.10

3

4

Užitečné odkazy:__________________________________________________________________________ 14

CLOUDY MAJÍ BUDOUCNOST, A TAKÉ PROBLÉMY ÚČETNÍ I PRÁVNÍ _______________ 15 3.1.1

Nevýhody právní ________________________________________________________________________ 15

3.1.2

Cloud má dopady investičně-účetní _________________________________________________________ 16

3.1.3

Technické argumenty pro jsou zajímavé ______________________________________________________ 16

AMAZON AWS ______________________________________________________________ 17 4.1.1

Jděte se už s tím buzzwordem vycpat! _______________________________________________________ 17

4.1.2

Amazon Web Services ___________________________________________________________________ 18

4.1.3

Použití AWS ___________________________________________________________________________ 18

5

POUŽÍVÁME DATOVÉ ÚLOŽIŠTĚ AMAZON S3____________________________________ 19

5.1

Než začneme… ______________________________________________________________________________ 20

5.2

Terminologie a organizace S3 _________________________________________________________________ 20

5.3

API ________________________________________________________________________________________ 21

5.4

Co umí S3 navíc? ____________________________________________________________________________ 22

5.5

Závěr: Začínáme_____________________________________________________________________________ 22

6

S3: HOSTUJEME STATICKÝ WEB V CLOUDU BĚHEM PĚTI MINUT___________________ 23 1

Internet Developer Forum 6.1

Statický web ________________________________________________________________________________ 23

6.2

Prakticky… _________________________________________________________________________________ 24 6.2.1

0. Statický obsah ________________________________________________________________________ 24

6.2.2

1. Vytvoříme bucket ______________________________________________________________________ 24

6.2.3

2. Upload souborů _______________________________________________________________________ 25

6.2.4

3. Nastavení práv _______________________________________________________________________ 25

6.2.5

3. Website mode ________________________________________________________________________ 27

6.2.6

4. DNS ________________________________________________________________________________ 28

6.3

Náklady ____________________________________________________________________________________ 28

7

ZÁKLADY AMAZON SIMPLEDB ________________________________________________ 29

7.1

Architektura SimpleDB _______________________________________________________________________ 29

7.2

Omezení ___________________________________________________________________________________ 30

7.3

Konzistence ________________________________________________________________________________ 30

7.4

Operace se SimpleDB ________________________________________________________________________ 31

7.5

Poznámky __________________________________________________________________________________ 32

8

AMAZON SIMPLEDB PRAKTICKY V PHP ________________________________________ 32

8.1

Autentizace SimpleDB ________________________________________________________________________ 33 8.1.1

Příprava požadavku _____________________________________________________________________ 33

8.1.2

Podepsání požadavku ____________________________________________________________________ 34

8.2

Praktická ukázka v PHP_______________________________________________________________________ 34

8.3

Závěr ______________________________________________________________________________________ 36

9

WINDOWS AZURE A PHP _____________________________________________________ 36 9.1.1

Výhody a nevýhody využití cloudu __________________________________________________________ 36

9.2

Potřebný software ___________________________________________________________________________ 36

9.3

Uložení souboru do cloudu jako blob ___________________________________________________________ 37 9.3.1

PHP stream wrapper _____________________________________________________________________ 37

9.4

Vytvoření storage na živém Azure serveru _______________________________________________________ 38

9.5

Úprava kódu pro živý Azure storage ____________________________________________________________ 39

9.6

A co jiná URL? Tahle je ošklivá… ______________________________________________________________ 39

9.7

Závěrem ___________________________________________________________________________________ 39

9.8

Odkazy ____________________________________________________________________________________ 40

10

LINUXOVÝ CLOUD HOSTING PRO OSOBNÍ POUŽITÍ V ČR? ______________________ 40

10.1

Virtuální servery __________________________________________________________________________ 40

10.2

První vlaštovka cloudových služeb? _________________________________________________________ 41

10.3

Rozhovor s Adamem Klimentem ze společnosti Virtualmaster ____________________________________ 42

2

Internet Developer Forum

1 Cloud computing ... je všude okolo nás Daniel Dočekal Doby kdy pojem „cloud computing“ označoval cosi chimérického, jsou nenávratně pryč. Dnes je Cloud computing prakticky běžnou součástí každodenního používání Internetu. A už možná ani nejde o něco výjimečného. Když se pojem „cloud computing“ objevil, bylo to něco těžko uchopitelného. A úplně v počátcích to bylo spojené se (tehdejšími) špičkovými technologiemi, nákladnou implementací a cílovou skupinou byli ti „movitější“. V průběhu let technologie pokročily, Internet se stal běžnou (a mnohdy i nevnímanou) součástí života. A stejně tak je tomu nakonec s cloud computingem. There is a world market for maybe five computers. (Thomas J. Watson, IBM, 1943)

O tom, jak obtížné bylo tento nový termín vstřebat, ostatně hovoří i to, že se ujal v češtině v anglické podobě. A jeho český překlad je poněkud problematický. Přeci jenom „výpočetní výkon v oblacích“ by znělo divně (asi tak jako čistonosoplena), „počítání mraků“ zní jako počítání oveček, „výpočetní/informační mrak“ ještě hůře a „život v oblacích“ vyvolává zcela jiné představy (byť jde o významově nejbližší zpodobnění). A v problému nakonec nejsme sami, mrkněte na cloud computing (http://forums.ec.europa.eu/sts/viewtopic.php?f=2&t=8) u sousedů Slováků. Dnešní „cloud computing“ je nejspíš a nejlépe charakterizovatelný jako technologie používané pro přístup ke službám na Internetu – možnosti informačních systémů a technologií jsou nabízeny jako služba, kterou uživatelé mohou používat kdykoliv, odkudkoliv a (skoro) na libovolném zařízení. Nepotřebují žádné vědomosti a schopnosti k tomu, aby takové služby získali a začali využívat (jejich používání samozřejmě nějaké ty vědomosti požaduje).

1.1 Co zůstává a co se mění: informatika v čase cloud computingu Dobrá definice ale je i ta, která je uvedena v anglické Wikipedii: Cloud computing is Internet-based computing, whereby shared resources, software and information are provided to computers and other devices on-demand, like the electricity grid. Zatímco v té české se setkáte s poněkud záhadným omezením na „přístup pomocí webového prohlížeče“, ale tak už to u „internetové encyklopedie“ chodí. 1.1.1

Cloud Computing podle Gartnerů Než se článek vydá směrem k trochu praktičtějším informacím, je vhodné projít trochou teorie. Poslouží k tomu definice a výzkumy od Gartnerů (Cloud Computing http://www.gartner.com/technology/initiatives/clou d-computing.jsp). První užitečnou věcí pro pochopení Cloud Computingu je stanovení šestí základních vlastností. Orientace na služby je jasná, cloud computing poskytuje nějaké služby (e-mail, výpočetní výkon,

datová úložiště, funkčnost nějakého programu).

3

Internet Developer Forum Škálovatelnost a elasticita naznačují, že poskytované služby se pružně přizpůsobují potřebám. „Pružně“ samozřejmě platí jenom v rámci stávajících technologických možností – a pokud služba poskytovaná cloud computingem nemá v záloze dostatek počítačového výkonu a odpovídající podporu infrastruktury, tak na to nakonec její uživatelé dost rychle doplatí. Jinou důležitou vlastností je i často citovaná výhoda – služba v Cloud Computing se může vylepšovat a pružně vyvíjet, aniž by bylo nutné podstupovat klasické procesy „upgrade“ lokálně instalovaného software. Sdílení (informací) je jedním z efektů toho, že služba zpravidla pracuje s informacemi uloženými kdesi „v mraku“ a pak už je snadné zpřístupnit tyto informace pro více uživatelů současně – a umožnit jim vzájemnou spolupráci. Zpoplatnění za užívání je obvyklý obchodní model (a má blízko k jinému termínu, SaaS neboli Software as a Service). Platíte za dobu užívání, případně za objem uložených dat. Zaměření na výsledek napovídá, že služby by měly (sic!) fungovat tak, aby poskytovaly co nejlepší výsledek činnosti – tedy efektivnost, snadnost používání. Z šesti definovaných vlastností jde nicméně o tu nejvíce problematickou. Používání internetových technologií je podmínkou nutnou. Dnes je Internet jedinou globálně dostupnou službou pro datové přenosy. Byť lze očekávat, že v průběhu dalších deseti let se od klasického Internetu vše přesune do internetu mobilního. Pro Gartnery je Cloud Computing dokonce nejdůležitější technologií pro rok 2010 – napovídá tomu ostatně i změna v žebříčku. Kde je mimochodem zajímavé si všimnout toho, že žebříček opustila unifikovaná komunikace (Cisco si toho zatím nevšimlo).

A není tedy asi překvapivé, že Cloud computing je právě na vrcholu známé „hype cycle“ křivky, kterou Gartneři zveřejnují pravidelně každý rok. A že tedy Cloud Computing čeká hlavně strmý pád do období ztráty iluzí a v příštích dvou až pěti letech vstup do fáze produktivního užívání.

4

Internet Developer Forum

A protože nejdůležitější jsou nakonec jenom a pouze peníze, tak ještě jedna předpověď – vývoj příjmů v oblasti SaaS (což je nakonec nyní hlavně a hlavně Cloud Computing) v oblasti podnikových aplikací (miliardy dolarů).

1.1.2

Cloud computing chtějí dělat všichni

Pozice Cloud computingu na vrcholu Hype křivky má své klasické příznaky – jde o věc, o které všichni nekriticky píší (k nějaké té kritice se nicméně dostaneme) a obdivují ji. Což samozřejmě vede k odpovídající panice v manažerské oblasti a výsledkem je to, že „všichni“ chtějí dělat právě tuhle věc. A považují ji za záchranu mizejících příjmů, problematických finančních plánů a pokud možno i celosvětové krize či hladomoru. Ne nadarmo se pro CIO (Chief Information Officers) stalo Cloud 5

Internet Developer Forum Computing tak důležitým, že v rámci global annual CIO survey (opět Gartneři - http://misasia.com/news/articles/gartner-cios-look-to-lighter-weight,-social-technologies-to-transform-it) bylo katapultováno z šestnácté na druhou pozici priorit. Tedy před Web 2.0, sítě, hlasovou a datovou komunikaci či bezpečnost. Dokonce i před tradiční hype v podobě BI (Business Inteligence).

A nelze se tedy divit, že dnes „mrak“ hlavních hráčů v Cloud Computing oblasti začíná vypadat pěkně bachratě. A že v něm najdete prakticky všechna velká jména. Včetně dinosaurů mainframe computingu, kteří ke Cloud Computingu přistupují stále stejně zkostnatělým způsobem. A najdete tam například i Dell, tedy firmu, která si kdysi před lety pokusila pojem „Cloud Computing“ patentovat. Příznačná je i snaha Microsoftu o získání dominance a náhlé „prozření“ – Microsoft CEO Steve Ballmer je (právě teď) přesvědčený, že Cloud computing je pro Microsoft budoucnost. A jde na to typickým způsobem, například zpřístupněním Office 2010 v internetové podobě – mající ovšem do snadné použitelnosti hodně daleko. A popravdě, největším problémem Microsoftu je Google. “Cloud computing represents the next frontier,” Ballmer prohlásil na výročním setkání Microsoftu s šéfy firem v Silicon Valely. “We’ve been betting or investing in the cloud for about 10 years and in earnest for about six or seven years.” A když už jsme u jmen firem, tak neuškodí připomenout některá podstatná (ale hlavně známá či užitečná) jména. Získáte tak základní představu o jedné podstatné věci – Cloud computing se skrývá prakticky všude. Akamai toho o Cloud computingu nikdy moc nenamluvili, ale CDN (Content Delivery Network) je typický příklad Cloud Computing platformy. Amazon EC2 je jedním z průkopníků „virtual computing“ a Cloud computing vůbec (EC2 = Elastic Compute Cloud) a patří mezi používané platformy. Cisco zamířilo do Cloud computingu poměrně čerstvou akvizicí společností WebEx a PostPath. Tradičně ale nejde o Cloud computing pro masy – firemní (a interní) využití je prioritou. Citrix nabízí Citrix Cloud Center (C3) coby platformu pro poskytovatele služeb. Google je v podstatě jedním z největších a nejpilnějších průkopníků Cloud computingu – většina služeb Google spadá právě do této oblasti. Včetně toho, že v této oblastí podal přes devět desítek patentů 6

Internet Developer Forum (máme se tedy v budoucnu na co „těšit“). A Google apps for Domains je přímou konkurencí Amazon EC2. Microsoft jsem už zmínil, takže dodám jenom další klíčové slovo. Azure. Oracle patří dlouhodobě k příznivcům Cloud computingu, byť se za ty desítky let vydalo různými směry (pamatujete ještě na „network computer“?). Dnes samozřejmě hlasitě říká, že mají to (jediné a správné) Cloud computing řešení. VMware je jedním z předních poskytovatelů platforem, které umožňují Cloud computing existenci. Cloud computing se dnes prakticky neobejde bez odpovídající úrovně virtualizace. A samozřejmě jsem vynechal řadu dalších hráčů -Adaptivity, Apache Hadoop, Bluewolf, Box-Net, Cloudera, Cloudscale, CohesiveFT, ElasticHosts, EMC, Enomalism, Force.com, GoGrid/ServPath, gOS, Grid Dynamics, HP, IBM, iCloud, Intel. Joyent, Netsuite, OpenNebula, OpSource, Parallels, Penguin Computing, Platform Computing, Rackspace, Red Hat, Savvis, Sun, Unisys či Zoho. Pokud chcete kompletnější přehled, The Top 250 Players in Cloud Computing je docela dobrý pokus. A není nezajímavé vědět, že v Praze proběhne šesté Cloud Computing Expo – 21. až 22. června. 1.1.3

Cloud computing prakticky

Cloud computing je tajuplný termín. A ti, co se ho snaží prodat dál, ho dělají ještě tajuplnější. Skutečnost a současnost je daleko jednodušší – Cloud computing je použití Internetu k vykonání činností, které děláte na svém počítači. A „cloud“ (mrak) je v tomto případě prostě „Internet“. Nic zvláštního vám určitě nepřijde na použití Gmail.com pro elektronickou poštu, kalendář, kontakty či úkolník. A zároveň používáte jeden z nejtypičtějších příkladu Cloud computingu. Nejspíš někde ukládáte fotografie, ať už je to třeba Flickr.com nebo Google Picasa – oboje je další perfektní příklad Cloud computingu. Cloud computing je služba využívání odkudkoliv a kdykoliv, většinou i z mnoha různorodých zařízení. Pixlr.com je prakticky plnohodnotná náhrada editoru fotografií ve vašem počítači. A je to Cloud computing služba. Dropbox.com je jedna z mnoha služeb vzdáleného úložiště, nabízí gigabajty prostoru, přístupné odkudkoliv, automaticky synchronizovatelné, sdílitelné s dalšími lidmi. A je to opět další příklad Cloud Computing služby. Amazon Simple Storage Service (S3) je příklad čistě komerční varianty.

EyeOS desktop (Beta) 7

Internet Developer Forum Cloud computing je platforma opět využitelná odkudkoliv a kdykoliv, s minimálním omezením na nutnost použití určitého operačního systému či zařízení. Ne nadarmo se o Internetu říká, že je to „operační systém budoucnosti“. Google Chrome OS (Chromium OS) je také jenom dalším vstupem Google do Cloud computingu. Platforma svého druhu je už i Google Docs a asi nelze nezmínit Facebook – ten je velkou „hrozbou“ pro nezávislost a otevřenost stávajícího Internetu právě na poli platformy. Již zmíněný Amazon EC2, Windows Azure či Google Apps (Google App Engine) jsou dalšími příklady kompletních platforem. Good OS (gOS) je kompletní operační systém pro Cloud computing, byť pozitivní dojem trochu kazí to, že ho musíte stále instalovat. O kus dál jde EyeOS – operační systém v prohlížeči. Cloud computing je mobilní je asi samozřejmá informace, ale iPhone či Google Android jsou dalším typickým příkladem Cloud computingu. Zejména ten druhý se s „cloud“ službami Google integruje opravdu hodně. A pak už je opravdu jedno, kde jste a co používáte – stačí vám libovolný prohlížeč. Nebo váš mobilní telefon. A všechno, co potřebujete, máte neustále u sebe. 1.1.4

Co získáte s Cloud Computing

Vysokou dostupnost. Zpravidla ano, tedy pokud poskytovatel Cloud computing služeb nebude mít výpadek. Pak budete mít velký problém. Pro škarohlídy je ale nutné připomenout, že i samostatná řešení (počítače, disky, servery, internetová připojení) mívají výpadky. A na rozdíl od plnohodnotných Cloud computing služeb je případná redundance problematická a nákladná. Kvalitní Cloud computing poskytovatelé mají datová centra, farmy počítačů, data i výpočetní výkon rozmístěný na mnoha různých místech, zálohovanou konektivitu. Vzdálená úložiště i vzdálené databáze jsou připojitelné zpravidla lokálně. A jsou dostupná odkudkoliv a kdykoliv. Pokud Cloud computing platforma umožňuje vývoj vlastních aplikací, můžete získat nové aplikace se skutečně vysokou dostupností odkudkoliv a kdykoliv. Včetně určité záruky možného růstu doslova z hodiny na hodinu, nikoliv v řádu týdnů, než se vám podaří schválit, koupit a nainstalovat nové hardware a software. Bezpečnost. S výhradami samozřejmě. Ukládat svá data „kamsi“ online je nejvíce citovaný nedostatek Cloud computingu. Nemáte svá data pod kontrolou, nevíte, kdo je může zneužívat, nevíte, kdo se kam může dostat. Vaše data jsou zpravidla několikanásobně zálohovaná, takže případné poškození není rizikem – přístup nepovolaných osob samozřejmě je. Ale i zde platí, že je otázkou – máte svou firemní síť skutečně dobře zabezpečenou? Cloud Computing přináší v oblasti bezpečnosti ale i jednu podstatnou výhodu – opravy chyb (nejenom bezpečnostních) jsou centrální. Celá platforma se „prostě“ povýší na novou verzi – ve srovnání s nutností instalace nového software na desítky až stovky míst ve firemních sítích je to nesrovnatelně rychlejší i pružnější. Tip: Užitečné čtení The Anamoty of cloud computing pomůže pochopit různé platformy. Mobilitu. A ta je k nezaplacení. V současnosti je k dispozici velké množství Cloud computing služeb, které vám mohou hodně zjednodušit život. Samozřejmě, za cenu „rizika“ ohrožení soukromí – svá data prostě musíte dát „někam“. Důležitá otázka je, zda výhody tím získáne převáží riziko. A také jak vám pomohou určité bezpečnostní zásady, které stačí dodržovat. Důležité je i vědět, zda něco takového skutečně potřebujete.

8

Internet Developer Forum 1.1.5

Cloud Computing prakticky

Přechod na Google Android mobilní telefon a ke Google (GMail) řešením vám zajistí snadnou dostupnost pošty, kalendáře, kontaktů i úkolníků kdykoliv a kdekoliv – na mobilním telefonu, ale také na libovolném počítači. Pokud vám nebude líto pár desítek dolarů, můžete přejít na Google Apps for Domains (Apps for Business) a přesunout prakticky vše tam – včetně možnosti používat řadu užitečných aplikací a používat vše pro webhosting. Své dokumenty můžete začít používat v Google Docs. A z vlastní zkušeností mohu říct, že tím získáte. Microsoft Office 2010 je sice skvělý, ale přeci jenom příšerně velký a komplikovaný (o tom, že je drahý, snad není ani potřeba mluvit). Otevření Google Docs pro libovolné soubory odstranilo poslední zásadní omezení. A možnost práce více lidí na jednom dokumentu je hodně užitečná. DropBox.com či některé další vzdálená uložiště jsou použitelná pro uložení všech dokumentů (nemají velikostní omezení jako Google Docs) a navíc nabízejí možnost synchronizace mezi počítači (a přístup i z mobilního telefonu). Pokud hledáte řešení pro backup, Mozy Backup je dobrý nápad. Pokročilejší služby tohoto druhu navíc nepočítají jenom s Windows, takže nebudete mít problém ani pod některým z Linuxů. Užitečné je Windows Live SkyDrive – snaha Microsoftu o vytvoření Cloud computing pro masy sice typicky kulhá v jednoduchosti, ale pokud používáte čistě Microsoft technologie, je to dobrá volba. Pokud budete chtít vzdálená uložiště používat, doporučím ještě věnovat pozornost Gladinet klientu. Flickr či Picasa poslouží pro ukládání a práci s fotografiemi víc než snaha vytvářet si úložiště fotek někde jinde. Pokud potřebujete ještě více, Amazon EC2, Windows Azure či Google Apps byly již zmíněny jako plné aplikační platformy. Programovatelné, s databázemi, souborovými systémy a řadou dalších možností.

9

Internet Developer Forum

2 Cloud hosting aneb hosting v oblacích Martin Malý Termíny grid computing, cloud computing nebo cloud hosting se objevují stále častěji. Bylo by chybou domnívat se, že jde o oblast vyhrazenou jen velkým firmám; vůbec tomu tak být nemusí a i váš projekt může některé z těchto technologií využít. Článek nastiňuje odpovědi na otázky: Jaké technologie, proč, na co a jak?

2.1

Grid computing, cloud computing, cloud hosting – co ta slova znamenají?

Terminologie je, podobně jako u každé novinky, poněkud neustálená, některé termíny jsou používány nepřesně či jsou volně zaměňovány. Z česky psaných textů na toto téma bych doporučil ty od Jana Kodery (Cloud vs Grid a Termíny spojené s cloudy), popř. tematickou sekci Buzzmagu. My se v tomto článku nebudeme pouštět do teoretických definic či sporů „cloud vs grid“, zůstaneme u praktických otázek, jako například:

2.2 Tak co to tedy ten cloudhosting je a k čemu to je? Představte si, že pro svůj projekt potřebujete určitý výpočetní výkon a datový prostor. Pořídíte si tedy stroj, který má odpovídající počet procesorů, odpovídající velikost úložiště a odpovídající rychlost. Váš projekt pak začne růst a ukáže se, že potřebuje vyšší výkon. Přidáte tedy procesor. Nebo dva. A zvýšíte frekvenci. Přidáte další disky do diskového pole. Pak přidáte další procesory, pak další a další… A nakonec máte výkonný počítač, který je za dva roky zastaralý. Nebo máte server s nějakou návštěvností. Lebedíte si, protože víte, že hardware utáhne i trojnásobnou zátěž. A pak jednoho dne o vás napíše Slashdot a odkáže Digg – a váš server za půl hodiny padne, protože je sice dimenzován na trojnásobnou zátěž, ale na padesátinásobnou už ne. A tak jen sledujete, jak si váš skvělý projekt dělá skvělou reklamu tím, že je nedostupný zrovna v TAKOVOU chvíli, no a vyčkáváte líbesbríf od vašeho poskytovatele hostingu, že překračujete povolený traffic a kdovíco ještě, a že byste měl zvážit… A v tu chvíli si povzdychnete: „Škoda, že server není nafukovací!“ Ale on nafukovací být může. Musel by být virtuální – každý, kdo kdy pracoval s nějakým emulátorem nebo virtuálním počítačem, ví, jak jednoduché je zvětšit paměť, výkon, počet procesorů, stačí je mít jen fyzicky k dispozici. A to je zároveň odpověď na otázku v podnadpisu. Cloud hosting je – zcela laicky řečeno – hosting, který oplývá clusterem s obrovským výpočetním výkonem a obrovským úložným prostorem, a tuhle svou kapacitu pronajímá zákazníkům v podobě virtuálních počítačů.

2.3 Jak to vypadá v praxi? Představte si obrovský celosvětový e-shop. Něco jako Amazon. Takový e-shop potřebuje obrovskou a kvalitní počítačovou infrastrukturu, dimenzovanou na sezónní nápory koupěchtivých, protože e-shop, co by třeba před Vánoci spadl, už příští rok nevstane. Takže provozovatelé pořídí gargantuovský cluster, který ustojí desetinásobek předvánoční nákupní špičky. Problém je ale ten, že po zbytek roku většina tohoto obřího výkonu zahálí, chytá lelky a z nudy píše emo básně (tzv. Marvinův syndrom) – čili jen zbůhdarma spotřebovává proud. Logické rozhodnutí je nenechat ležet výkon ladem, ale provozovat 10

Internet Developer Forum na něm virtuální servery a pronajímat je zákazníkům. Stačí už jen vymyslet název. Co třeba Elastic Computer Cloud (ECC), neboli: 2.3.1

Amazon EC2

Amazon Elastic Computer Cloud (EC2) patří do portfolia služeb, nazývaných souhrnně jako Amazon Web Services (AWS). Kromě cloudu EC2 do těchto služeb patří např. známější Simple Storage Service (S3) a další služby, jako je CloudFront (CDN – Content Delivery Network, tedy síť pro šíření obsahu), SimpleDB (jednoduchá databáze) či Simple Queue Service (SQS). Pojďme si říct pár slov o každé z těchto služeb, protože se s podobnými setkáme i u dalších podobných cloudhostingů. EC2 je platforma, na níž si zákazník spouští instance virtuálních strojů. Stačí specifikovat parametry počítače (počet procesorů, velikost operační paměti, velikost disku) a říct, jaký obraz operačního systému má být nahrán a spuštěn. Obrazy OS se v terminologii AWS nazývají AMI – Amazon Machine Image (obdoba virtuálních obrazů známých např. z VMWare) a můžete si vybrat z připravených nebo vytvořit vlastní. AMI obsahují většinou obraz nějakého systému (Windows server či *NIXový systém), někdy s předinstalovaným SW (webserver, databáze) či kompletní připravenou instalací nějaké aplikace, např. e-shopu.

Ale pozor: Virtuální stroj, který běží na platformě EC2, není persistentní. Pokud se stane, že konkrétní kus hardware, na němž zrovna váš AMI běží, zkolabuje, tak o data v něm vložená přijdete; Amazon totiž nikde negarantuje zálohování běžících virtuálních strojů. Přistupovat k EC2 jako k běžnému hostingu, kdy na jednom stroji máte server, statická data i databázi, by se mohlo ošklivě vymstít. Vypadá to na první pohled jako omezení, které sráží použitelnost podobného hostingu kamsi k nule, ale není tomu tak. Použití podobného hostingu totiž vyžaduje změnit nahlížení na aplikaci – z „programocentrického“ pohledu, v němž jsou nejdůležitější vaše (bezesporu geniální a kvalitní) skripty, na pohled „datacentrický“, tedy že „to nejdůležitější jsou data, server a skripty, a ty se mohou kdykoli obnovit ze záloh a nic závažného se nestane.“

11

Internet Developer Forum 2.3.2

Amazon S3

Amazon pro „to nejdůležitější“, tedy data, nabízí službu S3, tedy Simple Storage Service. V zásadě nejde o nic víc, než jednoduché datové úložiště, které umožňuje soubor uložit, přečíst či smazat. K tomu nabízí jednoduchý systém oprávnění podobný souborovým právům známým z unixu a rozhraní, postavené na HTTP (REST). Na rozdíl od virtuálních strojů v EC2 jsou data v S3 zálohována a ukládána redundantně. Do S3 si ukládáte nejen veškerá data, která potřebujete, ale ukládáte si tam i obrazy svých serverů (AMI), z nichž je snadno v případě potřeby nastartujete. Data jsou dostupná nejen vašemu virtuálnímu stroji, ale jsou přístupná veřejně (pokud, samosebou, jsou tak nastavena práva). Všimněte si např. u Twitteru, že některé soubory (obrázky, ikony) jsou načítány z adres, které začínají „http://s3.amazonaws.com“. 2.3.3

CloudFront

Se službou S3 je provázána služba CloudFront. CloudFront je služba, která slouží k rychlé distribuci dat po celém světě (CDN, Content Delivery Network). K tomu účelu používá několik datových uzlů v různých místech celého světa. Pokud chcete distribuovat velké objemy dat (video apod.), může být jejich distribuce z jednoho místa obtížná a pomalá. Pak je na místě využít CDN jako je CloudFront. Stačí označit data v S3 speciálním příznakem a infrastruktura Amazonu se postará o jejich zkopírování do uzlů tak, aby se k uživatelům kdekoli na světě dostala co nejrychleji.

2.4 Mosso Amazon není jediný, kdo podobné služby nabízí. Podobných nabídek se začíná objevovat čím dál víc. Amazon je ale do jisté míry průkopníkem komerčních služeb tohoto typu. Služby dalších poskytovatelů jsou těm od Amazonu často podobné. Jedním z příkladů je např. cloud společnosti Rackspace s názvem Mosso. Mosso nabízí vlastní obdobu EC2 pod názvem Cloud servers. Obdobou S3/CloudFront je u Mosso služba Cloud Files. Cloud Files nabízí krom úložiště i šíření obsahu pomocí CDN Limelight. Krom těchto základních služeb nabízí Mosso i předpřipravené virtuální servery, nazývané CloudSites (obdoba VPS).

2.5 GoGrid GoGrid je opět obdobou výše zmíněných, s drobnými rozdíly, např. nenabízí veřejný přístup k datovému úložišti. Už podle uživatelského rozhraní je GoGrid určen pro aplikace, které využijí load balancer, několik serverů, několik databázových strojů a datová úložiště. Samozřejmě že výše jmenované služby nejsou jediné. Svou variantu cloudhostingu 12

Internet Developer Forum nabízí např. i Google (App Engine) a další poskytovatelé. Předpokládám, že v tuto chvíli máte na jazyku hlavně dvě otázky. Odpovím nejdřív na tu obecnější.

2.6 K čemu to je? Podívejme se na nejčastější případy nových projektů u mladých nadějných internetových tvůrců a podnikavců, a na příkladech si ukažme, zda je vhodné použít cloudhosting. MFA microsite Není třeba Komunitní nástroj na sdílení odkazů Není třeba, nároky nepřesáhnou možnosti běžného hostingu Komunitní nástroj na sdílení odkazů, ale LEPŠÍ NEŽ OSTATNÍ Není třeba Vysoce odborný weblog o programování, obchodování na internetu a dění v naší třídě Nerentabilní Vyhledávač zboží a eshop Není třeba Hosting / bloghosting Není třeba Katalog stránek Není třeba „Nainstaluju Drupal / Joomlu / WordPress a…“ Nevhodné Pro 95 % nových projektů tedy cloudhosting není potřeba. 2.6.1

Pro jaké projekty je ale vhodné o použití cloudhostingu uvažovat?

• Pro projekty, které pracují s velkými objemy dat (např. videoservery, file hostingy, fotogalerie) • Pro projekty, u nichž je důvod předpokládat, že budou rychle růst a nevyplatí se investovat každého půl roku do nového stroje • Pro projekty, u nichž není nikdo schopen předem odhadnout nároky • Pro projekty, které lze snadno převést na paralelní úlohy a využít tak výhod paralelního zpracování dat více stroji • Pro projekty s „nárazovou“ návštěvností Já osobně bych použil právě výše zmíněné úložiště S3 např. i pro službu typu TWIO, tedy „úložiště obrázků pro twitterování“. Kdybych podobnou službu psal, tak využiji malé jádro na serveru, běžící klidně na sdíleném hostingu, a obrázky bych ukládal na S3, nezávisle na fungování českého serveru a doslova za pár korun. A tím jsme se nenápadně dostali k druhé otázce:

2.7 Ceny cloudhostingu Ceny jsou překvapivě „lidové“. Na rozdíl od klasického hostingu platíte u cloudhostingů jen „spotřebovaný strojový výkon“. Jednoduše řečeno – když nikdo nechodí a není provoz, tak platíte míň, když se provoz zvýší a přidáte na výkonu, zaplatíte víc. U výše zmíněného Amazonu vás přijde jedna hodina strojového času na „malé“ instanci" na deset amerických centů. Malá instance představuje jednu „procesorovou jednotku“ (zhruba odpovídá 1GHz Opteronu), 1.7GB RAM a 160GB HDD. Větší instance pak stojí 20, resp. 80 centů za hodinu času. 13

Internet Developer Forum 80 centů za hodinu zaplatíte např. za běh High-CPU instance – 20 jednotek, 7GB RAM, 1690GB HDD, 64bit. Podobně jsou účtovány ostatní služby – např. u S3 platíte 15 centů měsíčně za uložený gigabajt, 10 centů za přenesený gigabajt, 1 cent za každých 1000 POST/PUT/LIST/COPY požadavků a 1 cent za každých 10.000 GET požadavků. U CloudFront jsou ceny o něco vyšší. (Pokud jste z cen zmatení, nepanikařte – můžete použít kalkulačku (http://calculator.s3.amazonaws.com/calc5.html) a snadno zjistíte, že za „cosi jako malý vlastní server“ zaplatíte měsíčně okolo 75 USD.) U GoGrid je situace obdobná, tedy necelých 100 dolarů za měsíc provozu minimální sestavy. Pokud si chcete služby vyzkoušet, můžete – při registraci dostanete 50USD kredit na experimenty. Pro několikadenní testování je to ideální dárek. Mosso vychází ze všech tří zmiňovaných nejlevněji, provoz nejmenšího serveru vyjde na 25 dolarů za měsíc.

2.8 Pro lidi i programátory… Pokud se děsíte toho, že si budete muset psát nějaké knihovny pro přístup k datovým úložištím a studovat všechny ty REST API, tak vězte, že nebudete. K dispozici je mnoho knihoven v nejrůznějších jazycích, ať už přímo od poskytovatelů, nebo od třetích stran. Například obrazy virtuálních serverů u Amazonu obsahují rovnou nejdůležitější utility pro využití ostatních služeb, nemusíte se tedy obávat toho, že budete muset někde něco složitě stahovat, nastavovat a vymýšlet. Popisované služby mají dobře dokumentovaná rozhraní, takže k nim existují dostupné aplikace pro nejrůznější úlohy, a v případě potřeby si můžete vhodnou aplikaci napsat i sami, fantazii se meze nekladou. Co třeba použít Amazon S3 jako levné místo pro ukládání záloh? 10 uložených GB a 1GB uploadu měsíčně vás přijde na necelé dva dolary (1.60USD). Cloudy a CDN jsou často použity pro nejrůznější online služby typu „vytváření náhledů stránek“, „počítadla“, „statistiky“ apod. (Není náhodou, že do AWS patří i známá Alexa). Z těch zajímavějších aplikací mě napadá například StreamInCloud.com – služba, která převádí videa (AVI, MOV, MPEG apod.) do formátu FLV. Jediné, co pro to musíte udělat, je povolit jí přístup do vašeho S3 úložiště a nahrané soubory označit speciálním příznakem. Během několika chvil se objeví na určeném místě zkonvertovaný FLV soubor, připravený k distribuci…

2.9 Závěr Cloudhosting není ani „webhosting pro ty, co chtějí ukázat, jak jsou cool“ ani „předražený nesmysl“. Nasazovat na provoz weblogu pod WordPressem nebo na „katalog stránek“ cloudhosting nebude mít žádný citelný efekt, krom pošimrání ega. Cloudhosting je především služba, která umožňuje vytvářet výkonné a náročné online aplikace bez potřeby budování nákladné a předimenzované infrastruktury. Pokud cítíte, že vaše aplikace naráží na omezení, ať už kapacitní nebo výkonová, je načase zvážit, zda investovat další peníze do „železa“ (které stejně 90 % času zahálí a 5 % času nestíhá), nebo do migrace na „virtuální železo“. Cloudhosting je rozhodně zajímavou alternativou, která stojí za zvážení. Za ceny, které se blíží sdílenému hostingu nabízí komfort, leckdy převyšující vlastní dedikovaný server.

2.10 Užitečné odkazy: • Začínáme s Amazon EC2 (česky) 14

Internet Developer Forum • • • • • • • •

Dostupné AMI pro EC2/Europe AMI s Debian Lenny Ubuntu a Debian AMI pro EC2 EC2 Getting Started Elastic Server on Demand (vytvoří obraz pro VMware, Xen či EC2 podle požadavků) PHP knihovny pro Amazon S3 Windows S3 klient Cloudberry Tarzan AWS (PHP knihovna pro AWS)

3 Cloudy mají budoucnost, a také problémy účetní i právní Patrick Zandl Cloud computing není nic nového, ale přesto se tento přístup k operativnímu pronájmu výpočetních kapacit rozmáhá až v poslední době, kdy dostal své sexy jméno. O výhodách hovořil šéf vývojářů českého Microsoftu, skepticky se na nový šlágr zase díval hlavní architekt českého e-governmentu. Výhod je dost. Bohužel i výzev… Asi tak by se daly shrnout úvodní přednášky z konference Business Information Fórum 2010, která proběhla v úterý ve Slovanském domě v Praze. Skeptičtější část populace zastupoval Ondřej Felix (mikrorozhovor zde - http://www.lupa.cz/clanky/ondrej-felix-technologie-utekla-vsemu-ostatnimu/), někdejší generální ředitel Českého Telecomu a dnešní architekt českého e-governmentu, jeden z nejzkušenějších českých IT lidí, který sám sebe při přednášce označil za IT-dinosaura. Naopak optimismem hýřil Jiří Karpeta, ředitel vývojářské divize Microsoftu ČR. Cloud computingu jsme se po stránce nabídky, výkladu možností a jeho současného postavení na trhu na Lupě nedávno věnovali (Cloud computing … je všude okolo nás), názory lidí z branže na něj se zatím rozcházejí. 3.1.1

Nevýhody právní

Podle Ondřeje Felixe je jedním z hlavních problémů legislativa, což Felix lakonicky shrnul slovy: Svá data uložíte na cloud s licencí podle právního řádu státu Delaware, a jaká licence tedy bude chránit vaše data? Cloudy navíc přinášejí otázku spolehlivosti služeb a jejich vymahatelnosti. Kdo a jak bude zodpovídat za výpadek cloudu a jak se toto projeví v dalších návazných službách poskytovaných právě vaší společností na cloudu? Dnes je v telekomunikacích zákonem stanovený úzus, že firma nenese zodpovědnost za výpadek služby a nemusí tedy hradit škody výpadkem způsobené. Můžete věřit jejím slibům, že se postará, aby služba nevypadávala, ale když nepostará a vaše podnikání to ohrozí, nemáte se na kom zhojit. Vaši vlastní zaměstnanci a vaše vlastní IT oddělení je vám přitom podstatně lépe podřízeno a můžete mnohem spíše ovlivnit, co a jak provozuje. Proto jsou cloudy podle Felixe zatím spíše okrajovou záležitostí, kterou budou velké firmy používat pro nekritické aplikace, nikoliv pro jádro svého podnikání. S výše uvedenými výhradami souvisí problematika důvěryhodnosti a bezpečnosti. Jak poznat, který ze startupů nabízejících cloud computing je důvěryhodný a neprodá vaše data obratem dále? Neexistuje audit, podle něhož by se větší firmy mohly rozhodnout, je to pro ně vsázka do loterie a důvěra v dobré jméno, které ovšem v tomto oboru prakticky nebyl čas vytvořit. Podobný problém je s výkonnostními parametry, nejsou jednoduché metriky, jak je porovnat a je málo zkušeností s tím, jak je nakoupit a finančně vyhodnotit. To všechno vede k tomu, že IT oddělení větších firem se soustředí spíše na 15

Internet Developer Forum nákup vlastního hardware a na vlastní implementaci služeb, protože cloudy pro ně zatím stále nepředstavují komodizovanou službu, u níž by byly jasné výhody, nevýhody, ceny přímé i skryté vícenáklady – tedy jednoduchá možnost porovnání výhod a nevýhod nákupu vlastního řešení oproti jeho zajištění třetí stranou formou cloudu. Což, když zahrneme bezpečnostní dopady, je rozsáhlé téma, a není se čemu divit IT šéfům, že se jim do jeho rozkrývání nechce pouštět. 3.1.2

Cloud má dopady investičně-účetní

Zajímavou výhradu zmínil Felix ke cloudům po stránce účetní a investiční. Potíží totiž je i to, že cloudy se finančně v účetnictví projevují jako operativní výdaj (OPEX), zatímco nákup vlastního IT řešení je náklad investiční (CAPEX). Jenže mezi těmito položkami ve větších firmách se schváleným rozpočtem nelze šachovat jen tak, už proto, že podle těchto údajů hodnotí firmu investoři a citlivě na ně reaguje burza. Pro velké firmy tedy není jednoduché dělat přesuny větších finančních balíků směrem z investic do provozních výdajů. Navíc motivační programy ve velkých společnostech navazují bonusy zaměstnanců na hlídání operativních výdajů a je potom logické, že sami zaměstnanci a vedení IT oddělení nemají žádnou touhu měnit zaběhnutý systém, když by tím zasahovali do vlastních bonusů. Což je zajímavý pohled a postřeh, který zaznívá jen ojediněle, ale u velkých firem bude hrát svou roli. 3.1.3

Technické argumenty pro jsou zajímavé

Karpeta přirovnává cloudy k produkci elektřiny. Na to, abyste používali elektrospotřebiče, si také nekupujete elektrárnu, ale nakupujete elektřinu u externího dodavatele. Produkce elektřiny ve velkých elektrárnách zajistí úspory z rozsahu, dostatečná konkurence pak cenovou flexibilitu a služba je dostatečně komoditní na to, aby byla cenově i výkonnostně komparativní napříč různými dodavateli. Což, dlužno dodat, cloudy zatím nejsou – ta komparativnost zde vlastně chybí. Příměru lze přiznat přiléhavost, ale Felixovy výhrady tato přiléhavost neodstraňuje. Microsoft u cloudů zdůrazňuje technické výhody, především flexibilitu. Cloud si sjednáte a zprovozníte rychle, stejně rychle navýšíte kapacity, pokud se ty stávající ukážou být nedostatečné. Infrastruktura je elastická, snadno se přizpůsobuje tomu, co potřebujete, vše je postaveno na otevřených standardech, takže odpadají problémy s přenosy dat. To vede k redukci nákladů a snad i k jednodušší spolupráci na vývoji. První řešení na bázi Windows Azure v Česku začala nabízet Logica na jaře 2010, když Microsoft službu pro Česku spustil. Další lokální partneři Microsoftu v čele se společnostmi Unicorn, Ness Technologies, AutoCont a Kentico pracují na vlastních aplikacích pro Windows Azure. Celosvětově již Windows Azure využívají tisíce firem a organizací včetně NASA, Evropské environmentální agentury či koncernů Siemens a 3M. Platforma Windows Azure vytváří prostředí k provozu aplikací pro koncové uživatele, jako jsou Microsoft Dynamics, Office Live, Exchange Online, SharePoint Online nebo Windows Live, ale také zahrnuje vlastní operační systém pro webové služby, webovou relační databázi Microsoft SQL Azure a možnost propojení a spolupráce s .NET Services.

16

Internet Developer Forum Azure tak doplňuje dvojici nejznámějších komerčně dostupných aplikačních cloudů, Google Apps a Amazon Web Services (podrobně referujeme zde - http://www.lupa.cz/clanky/amazon-aws/). Jejich přehledné porovnání najdete například na Expert Developers Blogu. Existuje samozřejmě celá škála cloudových služeb a řešení „software jako služba“ a je zajímavé, že je zatím mají tendenci používat spíše začínající a menší firmy, které je snáze nasávají do svých vnitrofiremních procesů, jichž se například hostovaná CRM řešení nebo plánovací software stávají základem. To je ovšem specifická kapitola cloudů, stejně tak jako nejrůznější řešení CDN (content delivery network), sítě pro distribuci obsahu po Internetu. Zda a jak se cloudy chytí, ukáže budoucnost. Problémy s vyvedením dat mimo firmu považujeme za natolik zásadní, že si lze spíše představit, než migraci stávajících služeb, využití cloudů pro služby nově vznikající, kde tato rizika již budou nikoliv riziky, ale vlastnostmi obsaženými v konceptu služby. A pro Česko je podstatné, že řadu výhod deklasuje velikost trhu – například je obtížné vygenerovat v Česku provoz, který neobslouží levný webhosting. Proto se například cloudové úložiště dat Amazonu EC2 u nás neuchytilo, zatímco v USA je hojně využíváno pro předcházení „Digg efektu“. Ostatně, samotný cloud computing ještě není detailně vymezené a vyhraněné téma, prolíná se třeba se starším pojmem grid computing.

4 Amazon AWS Martin Malý Společnost Amazon není třeba ani v ČR nijak zvlášť představovat. Tento webový kolos není jen pravděpodobně největší internetový obchod, ale je také jedním z prvních poskytovatelů komerčních cloudových služeb, v tomto případě označovaných zkratkou PaaS - Platform as a Service. 4.1.1

Jděte se už s tím buzzwordem vycpat!

Slovo „cloud“ se v posledních letech skloňuje v IT všude možně a stalo se populárním termínem, kterým se ohání každý, kdo chce být „in“. Pravděpodobně ho postihne stejný osud jako třeba před patnácti lety populární slovo „multimediální“ – byly „multimediální sestavy“, „multimediální aplikace“, „multimediální systémy“, dokonce i „diskety vhodné pro ukládání multimédií“. Není divu, že je na toto slovo kdekdo alergický: od čtenářů odborných periodik po vývojáře. Ostatně není divu – cloud se stal povinnou součástí slovníku lidí, kteří o technologiích nevědí zhola nic („Naše stránky musí být komunitní, musí na nich být SEO a musí běžet v cloudu! A doufám, že je uděláte v HTML, o tom jsem teď četl, že to je hodně používané…“) Pod termín cloud je v poslední době zahrnováno leccos, často i věci a techniky, které s cloudem nemají nic společného. Asi nejpřesnější českou definici cloudu formuloval Jan Kodera: „Cloud computing označuje souhrnně technologie a postupy používané v datových centrech a firmách pro zajištění snadné škálovatelnosti aplikací dodávaných přes Internet.“ Na první pohled jsou služby podobné např. VPS – virtuálním serverům, minimálně z pohledu zákazníka: Někde má „vlastní“ server, má k němu přístup přes SSH, může si nainstalovat vlastní OS a software… Odlišnost je právě v tom, co je zdůrazněno ve výše uvedené definici: Cloud podporuje snadné škálování – a to nejen škálování výkonu, který lze za běhu zvyšovat či snižovat, ale i prostoru či dalších prostředků. U VPS vám poskytovatel vytvoří vlastní virtuální server s předem smluvenými parametry. Pokud je potřeba je za chodu změnit, nebývá to triviální. Můžete si relativně snadno zvýšit či snížit např. velikost operační paměti, ale pokud přijdete s tím, že potřebujete nárazově stonásobný prostor na disku, nebo že chcete na tři dny zvednout výkon na dvacetinásobek, bude s tím pravděpodobně problém. Stejně tak bude pravděpodobně nejmenším časovým obdobím pronájmu jeden měsíc – u cloudů je naproti tomu běžné platit za hodiny. 17

Internet Developer Forum U cloudových služeb je důraz kladen právě na snadné přizpůsobení parametrů. Můžete se na cloud dívat jako na neomezeně výkonný server, z něhož si vezmete tolik, kolik právě potřebujete a tehdy, kdy potřebujete. Navíc platíte pouze za skutečně využitý výkon, čas, prostor, služby… Nemusíte si tak kvůli např. každoměsíčním nárazům pořizovat předimenzovaný tarif. Ano, není to nic nového pod sluncem – koncept pronájmu strojového času pochází už z dob úsvitu počítačů. Přesto však nelze říct, že cloud je jen jiné slovo pro pronájem strojového času. 4.1.2

Amazon Web Services

Za komerčním pronájmem strojů od Amazonu stojí údajně Vánoce. V Amazonu totiž zjistili, že nápor na jejich servery v období před Vánoci mnohokrát přesahuje průměr ve zbytku roku. Proto svou infrastrukturu naddimenzovali tak, aby zvládla nápor předvánočního šílenství, ovšem vyvstala otázka: Co s touto obrovskou kapacitou po zbytek roku? Představa, že se hardware za miliardy dolarů jen tak válí a zbůhdarma žere energii, Amazon oprávněně děsila. Proto padlo rozhodnutí pronajímat tuto kapacitu jiným subjektům, čímž byl položen základ k dnešním AWS, neboli Amazon Web Services. AWS se skládají z několika částí, které si mohou zákazníci pronajmout nezávisle na sobě. Pronájem má tu příjemnou vlastnost, že se platí jen za zkonzumovanou službu. Tedy například za strojový čas, za přenesená data, za diskovou kapacitu,… Což má v porovnání s klasickými službami tu výhodu, že si zákazník může objednat jen to, co opravdu potřebuje. Například velký diskový prostor s relativně malou výpočetní kapacitou pro službu na ukládání souborů, nebo naopak silný výpočetní výkon a minimum diskové kapacity pro aplikace náročné na počítání. Dalším obrovským plusem je to, že není třeba předem přesně znát náročnost aplikace – kdykoli lze pružně přidat další virtuální server či zvětšit kapacitu. Vyhneme se tak situacím, kdy máme buď předimenzovaný server, který není využitý, protože návštěvnost webu je menší, než jsme počítali, nebo naopak výpadkům služby kvůli nedostatečnému výkonu; rovněž vykrytí sezónních výkyvů je mnohem snazší. Amazon ve svých Web Services nabízí např. úložiště S3 (Simple Storage Service), které nabízí „neomezený“ úložný prostor a službu CDN – Content Delivery Network, při níž jsou data kopírována do uzlových serverů po celém světě a uživatelům jsou vždy poskytována z nejbližšího uzlu. Další klíčovou službou je EC2 (Elastic Computer Cloud), která nabízí virtuální servery. AWS dál nabízí dvě databázové služby, SimpleDB (jednoduchá key-value databáze) a nedávno spuštěná RDS (Relational Database Service). Náročnějším zákazníkům nabízí vlastní privátní cloud, load ballancer, fulfillment service (službu kompletace zásilek a distribuce k zákazníkům), platební brány a další služby, včetně např. „pronájmu pracovní síly“, kdy si můžete pomocí služby Mechanical Turk najmout lidi k tomu, aby dělali práci, kterou stroj nezvládne – například pro ohodnocení relevance výsledků vyhledávání nebo např. k výběru vhodných ilustračních fotografií k výrobkům. Pro všechny tyto služby existuje dokumentované aplikační rozhraní (API), takže je možné jejich provoz řídit programově – např. podle potřeby spouštět další servery. Jen s malou mírou nadsázky lze napsat, že pokud aplikace potřebuje nějakou náročnou operaci, nemusí vytvářet nový proces, ale může si nechat vytvořit rovnou celý nový počítač, který spočítá potřebné, vrátí výsledky a zase se zruší – a pokud je třeba takových operací provést sto najednou, lze vytvořit sto virtuálních počítačů. 4.1.3

Použití AWS

Z výše napsaného by mohl někdo usoudit, že použití takových služeb je procházka růžovou zahradou, kde svítí stále slunce a vše je výborné, ale jestli chcete stěhovat svůj e-shop s pěti tisíci návštěvníky denně na cloud, zadržte! Nemá to totiž smysl.

18

Internet Developer Forum Vše, co jsme si výše o AWS a cloudech řekli, je sice pravda, všechny ty výhody existují, ale na malém e-shopu se neprojeví. Ani na katalogu stránek, ani na blogu. Skutečnou výhodu takové služby oceníte až jako provozovatelé opravdu velké služby. Takové, pro kterou plánujete např. nákup pěti serverů a pronájem tří linek. Pak má smysl zabývat se vážně myšlenkou využití cloudu. Když se mě někdo ptá na příklad, kdy má smysl u českého webu začít využívat nějaké cloudové služby, odpovídám: Pokud má vaše webová aplikace problémy s přenosovou kapacitou a vy zjistíte, že většinu přenosů tvoří statické soubory (videa, obrázky, neměnné CSS apod.). Typicky videoservery nebo fotobanky. U takových webů je na místě zvážit využití nějaké obdoby datového úložiště S3 (např. známý Twitter takto donedávna řešil zobrazování všech obrázků a avatarů). K tomu, aby web využil všech výhod cloudů, tedy především snadného horizontálního škálování výkonu i kapacity, je navíc zapotřebí, aby byl už od počátku navržen pro paralelní zpracování úloh. Aby v aplikaci nebyla kritická místa – nějaké „centrální uzly“ či procesy, které nelze dělat najednou na více místech. Už při návrhu je potřeba počítat s tím, že vyšší výkon nebude získáván silnějším hardwarem, ale větším počtem samostatných serverů, a stavět aplikaci tak, aby například nekonzistence dat (tzn. v jednom okamžiku mohou dva různé servery dostat z databáze různé údaje) neohrozila chod či nepředstavovala principiálně havarijní stav. Amazon Web Services má, stejně jako další velké cloudy (GoGrid, Rackspace, AppEngine), řadu výhod, které lze ale ocenit a využít pouze při určité změně pohledu na webovou aplikaci. Cloud neznamená „velký server“, ale „spousta malých“ – je potřeba změnit přístup, při němž se spoléhá na to, že lze koupit „silnější železo“. Od určité hranice je cena za dvojnásobně výkonnější stroj vyšší než cena dvou strojů. Tato hranice je ale poměrně vysoko, rozhodně výš, než kam dosáhne naprostá většina českých serverů, a české služby, které by opravdu využily pozitivní efekty cloudu, se dají počítat na desítky. Přesto i pro ty další mohou být některé služby, které cloudy poskytují, užitečné. Nejdůležitější pravidlo tu, stejně jako u dalších populárních technologií, zní: Nepřeceňovat možnosti, ani je nepodceňovat nebo iracionálně „nesnášet“ jen proto, že „o tom všichni mluví“. Cloud je jen technika, a za pár let, až vyvane étos žhavé novinky, nezmizí, ale stanou se běžnou součástí internetové infrastruktury, stejně jako hostingy nebo VPS.

5 Používáme datové úložiště Amazon S3 Martin Malý Jedním ze základních stavebních kamenů moderních webových služeb typu IaaS (Infrastruktura jako služba) jsou datová úložiště. Datová úložiště slouží, jak název napovídá, k ukládání souborů dat, k nimž pak přistupují buď další součásti služby (servery apod.) nebo přímo uživatelé. V článku si ujasníme některé základní pojmy a postupy, které nás ve světě datových úložišť čekají. V článku o cloud hostingu jsme si popsali některé známější cloud hostingy a jejich součásti. Pojďme se dnes podrobněji podívat na jednu z nich, na službu známou pod zkratkou S3. Amazon S3 (Simple Storage Service) je součástí Amazon Web Services, tedy služeb, které nabízí Amazon k pronájmu – kromě úložiště S3 jde např. i o cloud EC2, databázi SimpleDB, CDN CloudFront či správce front SQS. S3 má mezi těmito službami určité výsadní postavení – některé služby (typicky EC2) používají S3 jako úložiště např. pro zálohy či „obrazy systému“, další (jako CloudFront) jsou dokonce logickým rozšířením a nadstavbou (ovšem zvlášť placenou) nad S3. Pokud chcete zjistit, co AWS umí, je tedy logické začít právě od S3.

19

Internet Developer Forum

5.1 Než začneme… Před tím, než se pustíme do praktického testování S3, je potřeba udělat určité přípravné kroky. Jednak je potřeba být registrovaným uživatelem AWS – zde připomínám, že pro registraci je potřeba platební karta, na níž jsou účtovány měsíčně částky za služby. Není třeba se bát neočekávaných vydání, protože Amazon neúčtuje žádné „paušální částky“, ale pouze a jen poplatky za používání dle ceníku. Jako registrovaný uživatel získáte přístupové údaje (AWS Credentials), které se skládají z čísla účtu (account ID), přístupového klíče (access key) a tajného klíče (secret key). Amazon má, jak jste možná zjistili v ceníku, různé ceny pro USA a Evropu. Ale v tomto případě nejde o tolik oblíbené „dvojí ceny“, kdy zákazník z Evropy zaplatí v eurech tu samou částku, co zákazník z USA v dolarech (klasickým příkladem je Steam a spousta e-shopů), ale o rozdíl mezi datovými úložišti. Amazon má totiž svá centra nejen v Americe, ale kvůli zrychlení odezvy pro evropské zákazníky i v Evropě. Uložení v evropském datovém centru pak vyjde o něco (3 centy za gigabajt měsíčně) dráž. Nezáleží tedy na tom, jestli máte sídlo v USA nebo v Evropě, ale je na vaší volbě, ve kterém datovém úložišti chcete data mít. Pokud je většina vašich klientů z USA, nebo pokud počítáte s tím, že budete S3 používat pouze pro své potřeby a že rychlost oželíte, použijte úložiště v USA, pokud ale máte klienty po Evropě, bude asi lepší využít evropských center.

5.2 Terminologie a organizace S3 Úložiště S3 (a i další podobná) mají některé specifické vlastnosti, které je odlišují od běžného „disku na serveru“. Jednak je snadno škálovatelné – pro uživatele to znamená „nekonečný“ prostor, aniž by se musel starat, kde přesně se nové místo vzalo. Dále je trvalé – data jsou fyzicky ukládána redundantně na různých místech, takže ani výpadek, ani poškození HW by nemělo data nijak ohrozit. Je taky rychlé, jednoduché a levné. Tyto vlastnosti s sebou nesou i některé méně obvyklé efekty – například když uložíte soubor do S3 a vzápětí požádáte o výpis uložených souborů, pravděpodobně v něm ten nově uložený nenajdete. Zrovna tak budou ve výpisu vidět i „čerstvě smazané“ soubory. Je to způsobeno tím, že změna musí nejprve „probublat“ systémem, na všechna místa, kde je (bude) soubor fyzicky uložen. S3 tedy rozhodně není vhodné místo pro ukládání pracovních souborů, do nichž se neustále zapisuje či které se často mění, mažou, vytváří… S3 je vhodné pro data s delší trvanlivostí. Základní pojmy, s nimiž se u S3 setkáme, jsou object, bucket a key. Nejde o nic tajemného: Object je základní jednotka „uložené informace“ – skládá se z vlastních dat a z metadat. Odpovídá zhruba „souboru s atributy“. Data mohou mít velikost od jednoho bajtu až po 5GB. Metadata jsou tvořena dvojicemi „klíč = hodnota“. Mezi nimi jsou některé standardní údaje, známé

20

Internet Developer Forum z HTTP protokolu („Content-Type“ například), ale můžeme si specifikovat i vlastní atributy dle potřeby. Bucket („kyblík“) je místo, do něhož jsou objekty ukládány. Bucket má v rámci celého S3 jedinečné jméno, a každý soubor v něm uložený musí mít opět jedinečné jméno. Takových „kyblíků“ můžeme mít na jednom AWS účtu maximálně 100. Key je jednoznačná cesta k danému objektu v určitém „kyblíku“. Každý objekt, uložený v S3, má právě jeden unikátní klíč (key). Navíc existuje jednoznačné přiřazení mezi klíčem a dvojicí „bucket+object“. Například objekt s názvem „index.html“, uložený v bucketu „zdrojak“ bude mít klíč „http://zdrojak.s3.amazonaws.com/index.html“. V S3 neexistuje možnost vytváření podadresářů či „zanořených bucketů“ – úložiště není hlouběji strukturované pod úroveň bucketu, je ploché. Přesto lze, alespoň navenek, podadresáře simulovat – pokud do bucketu „zdrojak“ uložím objekt, a ten pojmenuji „styles/default.css“ (ano, jména objektů mohou obsahovat lomítko), tak jeho klíč (a tedy i přístupová adresa) bude http://zdrojak.s3.amazonaws.com/styles/default.css.

5.3 API S3 je, jak už samotný název napovídá, jednoduchá služba. Pokud čekáte nějaké komplikované API a desítky funkcí s tisícem parametrů, budete překvapeni. S3 nabízí dvojí API, jednak klasické SOAP, jednak stále populárnější REST. Konkrétní podrobnosti naleznete v Developer Guide (PDF verze), základní přehled pak můžete získat z Getting Started Guide (začátečníkům jednoznačně doporučuji, v tomto průvodci jsou popsány všechny potřebné kroky, od založení účtu u AWS po základní operace s objekty). Pokud nepoužíváte technologie, který usnadní použití SOAP (např. nástroje .NET), sáhnete pravděpodobně po REST API. Toto API lze použít téměř v libovolném jazyce, používaném ve světě webových aplikací, od Javy přes PHP po PERL. Naštěstí je k dispozici dostatek hotových knihoven a příkladů, které zapouzdřují vlastní API a umožní tak vývojáři soustředit se na vlastní úkol a neřešit záležitosti spojené s implementací komunikačního protokolu. S3 nabízí několik základních operací: Vytvoření či smazání bucketu, získání seznamu objektů v bucketu, vytvoření, změnu či smazání objektu a získání informací o objektu. Kromě těchto operací lze např. zjistit umístění konkrétního bucketu (US nebo EU) či měnit a zjišťovat informace o tom, kdo platí datový přenos bucketu (zda vlastník, nebo ten, kdo požaduje data). Pokud uložíte objekt (soubor) do S3 a nespecifikujete přístupová práva (ACP – Access Controll Policy) pomocí speciálního příznaku, bude váš objekt uložen s příznakem private, tedy 21

Internet Developer Forum soukromý. Pokud chcete umožnit jiným uživatelům přístup k tomuto objektu, můžete nastavit oprávnění public-read (ostatní mohou číst), public-read-write (ostatní mohou číst i zapisovat) nebo authenticatedread (mohou číst pouze ověření uživatelé AWS).

5.4 Co umí S3 navíc? S3 umožňuje vytvořit alias pro objekty, takže lze k nim přistupovat přes vlastní doménové jméno. Používá se k tomu jednoduchý trik – bucket je pojmenován stejně jako vlastní doména, a v DNS je pro tuto doménu vytvořen CNAME záznam. Příklad: Chceme vytvořit bucket, který bude přístupný na adrese http://data.zdrojak.cz. Vytvoříme si tedy bucket, který pojmenujeme „data.zdrojak.cz“ a v DNS nastavíme data.zdrojak.cz CNAME data.zdrojak.cz.s3.amazonaws.com. S3 dokáže pro objekt vytvořit torrent soubor – pokud tedy distribuujete větší soubory velkému počtu uživatelů (aktualizace, nové verze software apod.), můžete kromě přímého odkazu na soubor nabídnout uživatelům ke stahování i torrent soubor, čímž můžete významně snížit traffic. Když se podíváte do dokumentace na popis REST metody POST, zjistíte i další příjemnou věc: S3 umožňuje přímý upload souborů HTML formulářem (http://docs.amazonwebservices.com/AmazonS3/2006-03-01/UsingHTTPPOST.html), při kterém nejde soubor nejprve na váš server a z něj do S3, ale putuje od klienta přímo do úložiště S3. S3 ve spojení se službou CloudFront umožňuje rychlé šíření obsahu. CloudFront tvoří několik datových center v důležitých internetových uzlech, které zajišťují co nejrychlejší doručení obsahu uživatelům, podle toho, kde se nachází. Přenos dat ze S3 do uzlů CloudFront probíhá transparentně na pozadí, takže se nemusíme o nic starat, stačí jen oznámit, které objekty chceme šířit přes CloudFront (a, samozřejmě, si za tuto službu připlatit).

5.5 Závěr: Začínáme V podtitulku nejde o překlep – konec tohoto stručného úvodu je opravdu možné brát jako začátek vlastní práce s Amazon S3. Vyberte si vhodný příklad podle nástrojů, které používáte, zaregistrujte se jako uživatel AWS a můžete si zkusit nahrát první soubor. Nebojte se, že by to nějak zásadně zatížilo váš rozpočet – základní vlastnosti S3 si otestujete během jednoho odpoledne, a pokud nebudete zrovna uploadovat grabovaná DVD, tak se jistě vejdete do pětikoruny za měsíc. Pokud používáte PHP, začněte od S3 Example, nebo si stáhněte některou z AWS knihoven a zkuste si ukázkové příklady – já osobně jsem si vybral knihovnu Tarzan AWS, která poskytuje objektové rozhraní pro většinu AWS služeb, nejen pro S3.

Zkusme si třeba takové uložení souboru: create_object('data.zdrojak.cz', array(

22

Internet Developer Forum 'filename' => 'index.html', 'body' => '

Funguje to, funguje to!

', 'contentType' => 'text/html', 'acl' => S3_ACL_PUBLIC ) ); if ($file->isOK()) { echo 'OK'; } else { echo 'Chyba'; } ?>

Soubor je ukládán do bucketu „data.zdrojak.cz“ (smysl tohoto názvu je vysvětlen výše), jmenuje se „index.html“ a jeho obsah je patrný z textu. K tomuto souboru bude možné přistupovat přes http://data.zdrojak.cz.s3.amazonaws.com/index.html, a pokud budou správně nastavené údaje v DNS, tak i přes http://data.zdrojak.cz/index.html S Tarzanem je, jak je vidět, práce s AWS snadná, navíc je dobře dokumentovaný a opravdu jednoduchý. Ostatně podívejte se na desetiminutový screencast, v němž je vytvářen jednoduchý prohlížeč objektů, uložených v S3 bucketu. Tarzan poskytuje pro práci se soubory v S3 sadu metod, které vnitřně „překládá“ na volání REST API. Amazon S3 má opravdu obrovské možnosti použití, od ukládání osobních záloh za velmi příznivou cenu (málokdo nabízí 1GB za 10 centů) přes úložiště uživatelských dat až po nástroj k šíření velkých objemů dat (multimediálního obsahu) po celém světě. Oblast moderních internetových služeb je pestrá a se snižováním cen jsou podobné technologie stále dostupnější i pro menší projekty. Proto se brzy podíváme na další služby z rodiny Amazon Web Services a ukážeme si praktické použití na konkrétním příkladu.

6 S3: hostujeme statický web v cloudu během pěti minut Martin Malý Amazon nyní nabízí novinku, díky níž je nyní možné použít S3 jako serverovou službu pro hostování webů, které nepotřebují dynamické generování stránek na straně serveru. Ukažme si, jak na to. Pokud jste s Amazon S3 neměli zatím žádnou zkušenost, přečtěte si prosím nejprve článek Používáme datové úložiště Amazon S3 (http://zdrojak.root.cz/clanky/pouzivame-datove-uloziste-amazon-s3/). V něm je popsána základní terminologie, jejíž znalost bude v tomto textu nezbytná (Credentials, Bucket). Rovněž budeme předpokládat, že zájemce již má účet u služby S3 vytvořený a v textu nebudeme popisovat, jak jej založit.

6.1 Statický web Ačkoli se zdá, že je dnes naprosto nezbytné mít web hostovaný na serveru, kde běží PHP, Java, Python či jiná technologie pro dynamické vytváření obsahu, je stále ještě velké množství situací, kdy se bez serverových technologií obejdeme. Ať už to jsou statické prezentace nebo některé webové služby, které si vystačí s prostředky HTML/JS na straně klienta.

23

Internet Developer Forum Myšlenka hostovat takové weby v cloudových datových úložištích typu právě Amazon S3 je nabíledni: Taková úložiště jsou rychlá a levná, nemívají problémy s dostupností, a pokud využijete nadstavby v podobě nějakého CDN, budou vaše weby dostupné po celém světě s minimální latencí (díky redundantnímu ukládání v CDN po celém světě). Amazon S3 sice dokáže (díky REST rozhraní) vracet soubory stejně jako webový server (včetně správného MIME typu), ale měl jednu zásadní nevýhodu, kvůli níž nebylo, až do minulého týdne, možné použít jej k hostování celého statického webu (hostovaly se např. pouze knihovny nebo obrázky). Nedokázal totiž nabídnout tzv. „root document“ – tedy známý „index.html“ soubor. Jeho REST rozhraní namísto toho vracelo XML soubor se seznamem uložených souborů. Od minulého týdne to však už možné je (http://zdrojak.root.cz/zpravicky/hostujtestaticky-web-ci-webovou-aplikaci-v-cloudu-amazon-s3/) a my si v článku ukážeme, jak to udělat.

6.2 Prakticky… Ukažme si, krok za krokem, vytvoření takového statického webu v prostředí Amazon S3. Autor bude postup demonstrovat na svém starším weblogu… 6.2.1

Statický obsah

Nejprve je potřeba mít vlastní obsah. Pro potřeby této ukázky jsem pomocí programu WinHTTrack stáhl jeden svůj starší blog; upravil jsem odkazy, vyházel formuláře pro psaní komentářů a další věci, které na statickém webu nemají smysl. – pozn.aut. 6.2.2

Vytvoříme bucket

Bucket, „kyblík“, je v terminologii Amazon S3 oblast, do níž jsou ukládána data. Bucket musí mít název jedinečný v rámci celého S3 – např. bucket s názvem „zdrojak“ bude dostupný přes URL http://zdrojak.s3.amazonaws.com/. Pro zálohu vlastního webu je podobné URL velmi nešikovné. Naštěstí lze pomocí CNAME záznamu v DNS vytvořit alias, ale je potřeba splnit jeden požadavek. V příkladu budeme vytvářet web na URL „ http://cina.maly.cz“ (to proto, že jde o weblog se zápisky z dovolené v Číně – pozn.aut.). Amazon S3 umí pracovat s CNAME aliasem, ale vyžaduje, aby jméno aliasu bylo součástí jména bucketu (což není problém, protože jméno bucketu může obsahovat i tečky). Vytvoříme si tedy bucket s názvem „cina.maly.cz“ (a použijeme k tomu webovou konzoli AWS):

Tlačítkem Creatre Bucket vyvoláme formulář pro vytvoření bucketu:

24

Internet Developer Forum Zadáme jméno (cina.maly.cz) a jako umístění ponecháme US Standard (pozor – některé geografické lokace mohou být dražší, podívejte se do ceníku - http://aws.amazon.com/s3/#pricing).

Bucket máme vytvořen, a je prázdný.

6.2.3

Upload souborů

Připravené soubory můžeme nahrát na server. K nahrání můžeme použít opět AWS Console, nebo některý z programů, určených pro práci s úložištěm S3, např. Cloudberry Explorer. Při uploadu si můžeme všimnout možnosti „Use Reduced Redundancy Storage“. Pokud tuto volbu zaškrtnete, budou vaše data uložena „levněji“ – snížíte poplatek za uložený objem dat. Cenou za to je snížená garance jejich dostupnosti oproti plnohodnotnému S3 úložišti. Garance dostupnosti je zde 99,99% (plné S3 má těch devítek podstatně víc). Soubory v bucketu jsou uloženy v jednom adresáří; S3 nezná „vnořené adresáře“. Názvy souborů ale smí obsahovat lomítka, takže soubor foo/bar.html můžeme nahrát s tímto názvem (ne tedy „do adresáře foo soubor bar.html“, ale „do kořenového adresáře soubor "foo/bar.html“). Výše zmiňované programy (jako Cloudberry Explorer) ale dokáží toto chování navenek simulovat a dát uživateli pocit, že pracuje s adresářovou strukturou. Vnitřně ale funguje tak, jak jsme si popsali. 6.2.4

Nastavení práv

Máme soubory nahrané, můžeme se na ně podívat. Použijeme zatím standardní přístup pomocí S3 URL a zadáme „http://cina.maly.cz.s3.amazonaws.com/“ (jméno bucketu, následované .s3.amazonaws.com). Výsledkem bude chybové hlášení: 01.<Error> 02.AccessDenied 03.<Message>Access Denied 04.EB561FBB40EE7367 05.− 06. 07.w404IecvBzvCmtaRoYG1ysNiHVJwRySEQO5GGHU36ActWgbBbzabzfLnJjj2B2is 08. 09.

25

Internet Developer Forum Vidíme, že problém je s přístupovými právy. Je to proto, že nově vytvořený bucket a nahrané soubory jsou vždy „private“, pokud neurčíte jinak. Pokud chcete, aby soubory byly dostupné přes web, můžete

u bucketu vybrat z menu Action volbu Properties: a v těchto možnostech pak přidat právo „List“ pro „Everyone“.

Pokud pak zopakujete svůj požadavek, získáte výpis souborů uložených v daném bucketu: 01. 02.cina.maly.cz 03. 04.<Marker/> 05.<MaxKeys>1000 06.false 07.− 08. 09.0802archiv.html 10.2011-02-20T11:52:28.000Z 11.<ETag>"664d16bfe7fca40ab6d0041a5d043c87" 12.<Size>6161 13.<StorageClass>REDUCED_REDUNDANCY 14. 15.− 16. 17.659802-den-prvni.html 18.2011-02-20T11:52:27.000Z 19.<ETag>"5069fbfcab3c9da9f007031953f6d6c2" 20.<Size>11049 21.<StorageClass>REDUCED_REDUNDANCY 22.

26

Internet Developer Forum atd. Když se ale pokusíte otevřít nějaký soubor (http://cina.maly.cz.s3.amazonaws.com/index.html), opět se dočkáte chyby s přístupovými právy. Je totiž potřeba nastavit ještě u všech souborů právo „číst“. Naštěstí nemusíte toto řešit pro každý soubor zvlášť:

Vyberte všechny soubory z bucketu (pomocí Shift a kliknutí) a z menu Actions zvolte položku „Make Public“. Tato volba u všech vybraných souborů přidá uživateli „Everyone“ právo „Open“. Jakmile změna proběhne, bude přístup na index.html bez problémů. V tuto chvíli je náš statický web online a funkční – až na to, že přístup bez zadání index.html vrátí XML seznam souborů. Právě tento problém řeší nová funkce „website“. 6.2.5

Website mode

Bucket přepneme do módu „website“ jednoduše – z menu Actions (u seznamu bucketů, nikoli u seznamu souborů) vybereme opět Properties, a zde, v druhé záložce nazvané Website, tuto funkci povolíme, a zároveň oznámíme, jaký soubor má být ten „root document“, vrácený v případě, že žádný nebyl zadán.

Poslední řádek oznamuje, pod jakou adresou je naše statická website dostupná. Je to „http://cina.maly.cz.s3-website-us-east-1.amazonaws.com/“ (Adresa se skládá z jména bucketu a z fyzického umístění, zde s3-website-us-east-1) .

27

Internet Developer Forum 6.2.6

4. DNS

Adresu website nastavíme jako hodnotu CNAME pro danou doménu 3. řádu – zde tedy jako: cina IN CNAME cina.maly.cz.s3-website-us-east-1.amazonaws.com. Po nezbytné době, potřebné k „probublání“ DNS záznamů, bude vše fungovat na námi vybrané

doméně.

6.3 Náklady Jak sami vidíte, použití S3 k vytvoření statického webu je velmi snadné a nekomplikované a lze jej zvládnout doslova během několika minut. Pojďme se ještě podívat na to, jaké budou náklady. Amazon k tomu nabízí jednoduchou kalkulačku (http://calculator.s3.amazonaws.com/calc5.html). Cena služby S3 se odvíjí od počtu požadavků, objemu přenesených dat a objemu uložených dat. Uvažujme malý web – 100MB souborů, měsíčně cca 30.000 návštěv, 350.000 požadavků na soubory, cca 3.3GB přenesených dat (čísla pochází z reálného webu). Pokud vybereme umístění US Standard a zvolíme „reduced redundancy“, bude přibližná cena za měsíc provozu 0.37 USD (počítáno 20.2.2011; cena se může změnit). Při dnešním kurzu dolaru zaplatíte tedy za měsíc zhruba 7 Kč. V případě uložení v EU bude přibližná cena 0.34 USD. (Autor může potvrdit, že opravdu podobné částky sám platí.) Rychlost odezvy je, logicky, o něco nižší než u serverů, umístěných fyzicky v ČR (cca 170ms z USEast); zvýšení rychlosti odezvy je možné řešit buď přesunem do geograficky bližšího uzlu (z ČR vychází nejvýhodněji Irsko – dle měření je rychlost odezvy 80ms) nebo použitím CDN CloudFront (pokud vyžadujete co nejrychlejší odezvu po celém světě).

28

Internet Developer Forum

7 Základy Amazon SimpleDB Martin Malý Asi nejznámějším cloudem je Amazon AWS, který poskytuje širokou škálu služeb – od virtuálních strojů (EC2) a úložiště (S3) až po platební bránu či „webové rozhraní k lidské práci“ (Mechanical Turk). Jednou ze služeb je i NoSQL databáze, nazvaná prostě SimpleDB. V tomto článku se budeme věnovat právě jí. SimpleDB je součást cloudu AWS, ale při jeho použití nejsme nijak vázáni nutností využít dalších služeb, lze tedy používat pouze SimpleDB, a to i pro služby, které fungují na jiných serverech (je ale důležité si uvědomit, že data, která jsou přenesena v rámci AWS, jsou výrazně levnější). Databáze SimpleDB je zástupcem tzv. Key-Value databází, tedy databází, kde jsou data ukládána nikoli do tabulek ve vysoce normální formě, ale naopak jako poměrně nestrukturované shluky dat s plochou strukturou. Pro tyto databáze, spolu s dokumentovými, objektovými a dalšími nerelačními databázemi, se vžilo označení NoSQL. NoSQL databáze vyvolávají obrovské vášně (i v diskusích zde na Zdrojáku), kdy některým zastáncům relačního modelu připadá, že jsou NoSQL prezentovány jako univerzální všelék a spasení (což někdy může tak působit), a další zkrátka nejsou ochotni přijmout jiné paradigma, navíc takové, které z podstaty neobsahuje silný řád. Na úvod je tedy nezbytné poznamenat, že NoSQL, mezi něž SimpleDB patří, nejsou ani všelék, ani univerzální nástroj. Mají své místo, mají své výhody i nevýhody, a je potřeba k nim přistupovat jako ke každé jiné technologii: Nepoužívat je bezhlavě, ale s rozmyslem. Výhodou NoSQL databází je obvykle snadná škálovatelnost a vysoká rychlost, daná především denormalizovaným tvarem dat, redundantním ukládáním a minimální „inteligencí“ takových databází (zapomeňte na constraints, triggery, uložené procedury, JOINy a další věci, které jsou běžné – a nutné – v SQL světě). Daní, kterou je za to nutné zaplatit, je přesun veškeré logiky na stranu serveru, ztráta ACID, nutnost ošetřit případné nekonzistence na straně aplikace… NoSQL databáze tak zkrátka nejsou databází pro každou aplikaci. Svůj smysl mají na webech, kde se pracuje s obrovským počtem záznamů a s velkou zátěží (na NoSQL databázi, konkrétně Cassandra, například přešel Digg, kde jsou uváděny počty pageviews v řádu půl miliardy měsíčně). Tam se naplno projeví výhody jednoduché škálovatelnosti, kdy náklady na HW rostou s počtem záznamů pomaleji než u klasického SQL stroje. Na druhou stranu není nikde psáno, že byste nemohli použít NoSQL pro pohon svého blogu v PHP – jen to bude pravděpodobně overkill, kdy nevýhody takového řešení převáží nad výhodami, a to především co do snadnosti udržení takové aplikace či ceny.

7.1 Architektura SimpleDB Databáze SimpleDB používá jednoduchou strukturu dat: Na nejvyšší úrovni je uživatelský účet (account). V každém účtu se data dělí do domén (domains). Do domén jsou ukládány položky (items) – každá položka má v rámci domény unikátní identifikátor (name). Každá položka může mít až 256 atributů (attributes). Atributy pak nabývají určité hodnoty (value). Amazon pro výklad používá příměru k tabulce z tabulkového procesoru (tabulkou zde je míněno to, co známe z Excelu, nikoli databázovou tabulkou): Doména odpovídá listu dokumentu, položky jsou řádky, atributy sloupce a hodnoty pak konkrétní políčka. Pokud bychom chtěli sáhnout k analogii ze světa RDBMS, tak doména bude zhruba odpovídat databázové tabulce, položka záznamu, atributy pak 29

Internet Developer Forum sloupcům. Ovšem je třeba si uvědomit, že analogie s RDBMS je velmi volná, a to především z jednoho důvodu: Struktura dat není pevně daná! V praxi to znamená, že libovolný záznam může mít libovolné atributy. Je zcela na uživateli, jaké atributy záznamu vyplní; není svázán žádnou strukturou, žádnými „povinnými položkami“, ničím podobným. (Tato svoboda ale může snadno v rukou nezkušeného či neukázněného vývojáře napáchat neskutečné škody.) Srovnat by se to dalo snad jen s RDB tabulkou, která má povinný primární klíč ID, ostatní sloupce jsou nepovinné, a navíc vznikají ve chvíli, kdy jsou použity při zápisu do nějaké položky, transparentně a na pozadí (není je tedy nutno předem nijak specifikovat).

7.2 Omezení Pokud se vám v tuto chvíli dělá mdlo z „neřádu“, vydržte, bude ještě hůř. Hodnoty ukládané do SDB totiž nemají žádný typ. Lépe řečeno: Jsou to řetězce. Pokud chceme pracovat s čísly (například porovnávat), musíme počítat s tím, že SimpleDB nezná typ číslo a všechna porovnání bere jako porovnání řetězců. Řeší se to tak, že čísla jsou do SimpleDB ukládána v normalizovaném tvaru, tedy doplněné nulami zleva, a pokud mají být i záporná, tak jsou předem převedena na kladná přičtením offsetu. Ovšem tuto normalizaci nedělá databáze – musí na ni myslet programátor aplikace, a musí na ni myslet včas. Na tomto místě je vhodné zmínit limity SimpleDB. Jména atributů i hodnoty mohou mít nejvýše 1024 bajtů (obrázek tedy do databáze jen tak neuložíte, dokonce ani článek na blog). Stejně tak smí mít 1024 znaků jméno položky (ID). Každá položka může mít 256 dvojic atribut – hodnota. V jedné doméně může být použita maximálně jedna miliarda atributů, doména má maximální velikost 10GB a v jednom účtu smí být sto domén. SimpleDB tedy znamená opravdu „jednoduchá“ – i když relativně velká. Omezení velikosti záznamů, které bude pro switchery ze světa RDBMS asi nejcitelnější, vychází z filosofie AWS, kde je vše podřízeno škálovatelnosti. Jsou proto oddělena data od aplikace, a jsou zde oddělena i data od metadat – pro data je určeno S3, pro metadata právě SimpleDB. Pokud bychom psali tedy výše zmíněný blogovací nástroj nad AWS technologiemi, tak bychom museli ukládat texty článků a komentářů do souborů v S3 a informace o nich do SDB. (Já vám říkal, že to je nesmysl, a že to s **SQL půjde mnohem líp!)

7.3 Konzistence Dalším omezením, které je třeba zmínit, je konzistence. Veškeré domény jsou ukládány, kvůli vysokým nárokům na trvanlivost dat, odolnost proti výpadkům a rychlost přístupu, v několika kopiích. Při operacích zápisu se změny propagují do ostatních kopií, a tato propagace nějakou dobu trvá. Amazon uvádí, že v běžných případech jsou data změněna ve všech kopiích zhruba do jedné sekundy, ale zároveň dodává, že v případě epizodické vysoké zátěže může tato doba narůst. Není řečeno na jak velkou dobu, ale je garantováno, že nakonec jsou data zapsána. Problém nastane, jak je jistě patrné, v případě, kdy jeden proces čte položku, kterou jiný proces právě změnil. Bude záležet na tom, zda čte z kopie, kde je již změna uložena, nebo z nějaké, kde ještě není. SimpleDB přiděluje kopie domén k požadavkům na základě momentálního vytížení, tudíž nelze nijak ovlivnit, k jaké kopii se právě přistupuje – navenek se celý cluster domén tváří jako jeden celek, jen s tím drobným zádrhelem, že v jeden okamžik může dvěma procesům vrátit na stejný požadavek zcela rozdílná data.

30

Internet Developer Forum SimpleDB proto nabízí dva přístupy ke konzistenci dat pro čtecí operace: Konzistentní čtení a Časem konzistentní čtení (Consistent read a Eventually consistent read). Běžně se používá „časem konzistentní“ operace – tedy SDB vrátí data z té kopie, co plánovač právě přiřadí, i s rizikem toho, že mohla být mezitím změněna. Tento přístup je nejrychlejší – je minimální čekací doba na odpověď i největší průměrná přenosová rychlost. V případech, kdy na konzistenci opravdu záleží, lze specifikovat konzistentní čtení (pomocí parametru ConsistentRead=true) – v takovém případě je zaručeno, že data reflektují všechny předcházející zápisové operace, které skončily úspěšně. Nevýhody jsou zjevné: Je možné, že budete na data čekat, a přenos bude tedy i pomalejší. Podrobněji se otázkami konzistence a přístupu konkurenčních procesů zabývá Developer Guide – Concurrent Applications.

7.4 Operace se SimpleDB K SimpleDB lze přistupovat prostřednictvím dvou API – REST a SOAP. Tato API nabízejí několik základních operací, které si teď ve stručnosti představíme – ostatně už jejich jména jsou samovysvětlující: • • • • • • • • •

CreateDomain – vytvoření domény DeleteDomain – smazání domény ListDomains – výpis existujících domén DomainMetadata – informace o doméně – počty položek, počty atributů, velikost, čas změny apod. PutAttributes – zápis dat (hodnot atributů) k položkám BatchPutAttributes – obdoba předchozí funkce pro víc položek najednou GetAttributes – čtení atributů ze zadané položky DeleteAttributes – odstranění atributů z položky Select – Obdoba dotazu SELECT ze SQL

Možná vás zarazí, že SDB nemá různé operace pro vytvoření položky a její změnu. Vše podstatné se děje pomocí dvou operací, totiž PutAttributes (resp. BatchPutAttributes) a DeleteAttributes. PutAttributes má jako parametr jméno položky (jak jsme si řekli, je unikátní v rámci domény) a seznam atributů a jejich hodnot. Pokud položka s takovým jménem neexistuje, je vytvořena a jsou do ní zapsány atributy. Pokud položka existuje, je změněna. Zadané hodnoty existujících atributů jsou přitom přepsány, neexistující atributy jsou nově vytvořeny. Tato operace tak v sobě zahrnuje INSERT, MODIFY i ALTER TABLE. DeleteAttributes smaže atributy z položky. Pokud v položce už žádný atribut nezůstane, je odstraněna. Obě tyto operace, jak Put, tak Delete, mohou být podmíněny – např. tím, že jsou provedeny jen pokud hodnota nějakého atributu je rovna zadané hodnotě apod. Pro získání dat jsou používány dvě operace, a to GetAttributes a Select. GetAttributes očekává jméno položky a vrátí všechny přiřazené atributy a jejich hodnoty (popř. hodnotu jednoho specifikovaného atributu).

31

Internet Developer Forum Velmi silná je operace Select, která bude lidem znalým SQL připadat konečně povědomá. Umožňuje totiž vyhledávat data podle zadaných podmínek a vracet je. Syntaxí je velmi podobná dotazu SELECT ze SQL. Ve zkratce vypadá takto: select output_list from domain_name [where expression] [sort_instructions] [limit limit]

V podmínkách lze použít některé operátory, známé ze SQL, takže dotazy mohou vypadat třeba takto: select select select select '193%'

* from mydomain where * from mydomain where * from mydomain where * from mydomain where or Year = '2007'

Title = 'SimpleDB' Year > '1985' Rating like '****%' (Year > '1950' and Year < '1960') or Year like

SimpleDB umožňuje v operaci Select přistupovat k hodnotě atributu jako k vícenásobné hodnotě, ale podrobnosti by přesahovaly rámec tohoto článku. Zájemce proto odkazuji na dokumentaci (http://docs.amazonwebservices.com/AmazonSimpleDB/latest/DeveloperGuide/RangeValueQueriesSel ect.html). Funkce Select pracuje nad indexem, který si SimpleDB pro data vytváří. Vytváření tohoto indexu je transparentní, probíhá na pozadí a uživatel jej nemá možnost ovlivnit. Praktické ukázky práce, stejně jako popis REST API, si ale necháme až do dalších článků.

7.5 Poznámky Alternativou k SimpleDB je open source databáze M/DB, která je co do API a chování totožná se SimpleDB. Lze tedy při vývoji použít právě lokálně nainstalovanou M/DB a odladit aplikaci proti ní – ušetříte tím jednak prostředky, jednak se tím vyhnete vendor lock-inu: Svou aplikaci můžete z AWS přenést jinam bez výraznějšího zásahu do databázové vrstvy (je potřeba změnit jen endpoint). Základním místem, kde se SimpleDB začít, je (samosebou) přihlášení k SimpleDB. Pokud už přístupové údaje máte, je vhodné začít dokumentací, konkrétně SimpleDB Developer Guide a Getting Started Guide. Vhod může přijít i ukázková knihovna (Java, C#, Perl, PHP a VB.NET) – na rovinu řečeno není verze pro PHP moc hezká a bude lepší se porozhlédnout po nějaké jiné, popř. si napsat vlastní (jak na to si ukážeme příště). Knihovny pro ostatní jazyky jsem nezkoumal.

8 Amazon SimpleDB prakticky v PHP Martin Malý Amazon SimpleDB nabízí pro přístup k službám rozhraní SOAP a REST. V článku si ukážeme, jak využít to druhé, a to z prostředí jazyka PHP. Velké webové služby většinou nabízejí vlastní knihovny pro nejpoužívanější jazyky. Ani v případě Amazon SimpleDB tomu není jinak – k dispozici jsou knihovny pro PHP, Javu, Perl, C# a VB.NET. Ačkoli nejsem obecně příznivcem znovuvynalézání kola a řídím se heslem, že je lépe použít vyhovující knihovnu než opakovat stejné chyby jako její autoři, v případě SimpleDB a PHP jsem na vážkách – PHP 32

Internet Developer Forum knihovna nabízená Amazonem mi připadá poněkud těžkopádná. Sice je dobře dokumentovaná a testovatelná, ale osobně mi připadá poměrně nešikovně uspořádaná (jde spíš o otázku preferencí než o rozhodnutelný fakt). Ať tak či onak, faktem je, že na webu lze nalézt spousty knihoven třetích stran, jejichž autorům zjevně kód od Amazonu nevyhovoval, takže se rozhodli udělat vlastní knihovny, které sahají od jednosouborových wrapperů po komplexní knihovny pro celé Amazon AWS. Jako kuriozitu bych zmínil Super SimpleDB, což je knihovna, která nad SimpleDB simuluje SQL dotazy. Naštěstí je „REST“ rozhraní SimpleDB bohatě dokumentované, takže není problém s ním pracovat – vystačíme si v zásadě se základní schopností „poslat HTTP GET požadavek“ a s hashovacími funkcemi. V tomto článku si ukážeme, jak vytvořit požadavek na SimpleDB, jak ho podepsat a jak jej poslat. Poznámka: Amazon své rozhraní nazývá „REST“, ačkoli očividně nesplňuje základní znaky tohoto architektonického stylu – např. pro všechny požadavky, včetně těch co mění data, používá HTTP GET (pro zajímavost – o POSTu se zmiňuje dev guide takto: „If the length of the query string that you are constructing exceeds the maximum length of the HTTP GET URL, use HTTP POST and submit the query string parameters in the body of the message“), přístup není orientovaný na záznamy, ale na procedury atd. Ve skutečnosti jde spíš o „RPC over HTTP“. V dalším textu se ale přidržím terminologie Amazonu a budu toto rozhraní označovat, kvůli zachování konzistence s dokumentací, jako „REST“. Zájemce o podrobnější vysvětlení problematiky RESTu a rozdílu proti RPC odkážu na komentáře P. Rybára (http://zdrojak.root.cz/clanky/java-na-webovem-serveru-soap-webove-sluzby/nazory/8550/).

8.1 Autentizace SimpleDB SimpleDB používá pro přístup ke službám stejné údaje jako ostatní AWS služby – tedy unikátní dvojici řetězců Access Key a Secret Key. Access Key je posílán spolu s požadavkem jako identifikátor konkrétního uživatele, Secret Key je použit k výpočtu „podpisu“ pro konkrétní požadavek, a to pomocí HMAC-SHA256 algoritmu. Autentizace požadavku je poměrně jednoduchá, spočívá ve třech krocích: 1. Příprava požadavku 2. Výpočet HMAC-SHA256 hashe, kdy je použit Secret Key coby klíč 3. Přidání spočítaného hashe k požadavku Příprava požadavku je pravděpodobně nejnáročnější částí. Pojďme si ji probrat podrobněji. 8.1.1

Příprava požadavku

Požadavek se skládá z parametrů ve tvaru „název=hodnota“. Nejprve jsou parametry seřazeny podle názvu abecedně ve vzestupném pořadí. Následně jsou spojeny pomocí ampersandu, stejně jako v query u HTTP požadavků, a stejně jako u HTTP jsou i zde hodnoty enkódovány, s drobnými rozdíly – např. mezera není kódována jako „+“, ale jako „%20“. V PHP můžeme použít funkci rawurlencode. Příklad: AWSAccessKeyId=0123456789ABCDEF &Action=Select &DomainName=MyDomain &SelectExpression=select%20%2A%20from%20MyDomain%20where%20Ite%20%3E%20%270 100.00%27 &SignatureMethod=HmacSHA256

33

Internet Developer Forum &SignatureVersion=2 &Timestamp=2010-04-14T17%3A08%3A12%2B00%3A00 &Version=2009-04-15

Požadavek se skládá z některých povinných parametrů (AWSAccessKeyId – viz výše zmíněný Access Key, Action – název akce, viz předchozí článek - http://zdrojak.root.cz/clanky/zaklady-amazonsimpledb/, Domain Name – jméno domény, SignatureMethod, SignatureVersion, Version a Timestamp), z parametrů specifických pro daný požadavek (SelectExpression) a z nepovinných parametrů (zde není použit žádný, ale lze specifikovat např. počet vrácených záznamů). Máme-li požadavek takto normalizován (parametry seřazeny podle abecedy, hodnoty ošetřeny), vytvoříme si řetězec k podpisu: HTTPVerb + "\n" + Host + "\n" + RequestURI + "\n" + QueryString

HTTPVerb je použitá metoda (GET nebo POST), Host je plné jméno serveru malými písmeny (většinou „sdb.amazonaws.com“), RequestURI je v této verzi API vždy „/“, a QueryString je výše popsaný řetězec s požadavkem. Pro takto vytvořený řetězec spočítáme HMAC-SHA256 hash, kde jako klíč použijeme náš Secret Key, a výsledek přidáme k požadavku jako parametr Signature. 8.1.2

Podepsání požadavku

K výpočtu použijeme v PHP funkci hash_hmac s výstupem jako raw: $signature = hash_hmac ( 'SHA256', "GET\nsdb.amazonaws.com\n/\n" . $request , 'SECRET KEY', true );

Binární výstup funkce hash_hmac zakódujeme pomocí base64_encode a výsledek před vložením do požadavku ošetříme pomocí rawurlencode. S podepsaným požadavkem pak zavoláme HTTPS GET – buď přes cURL, nebo přes socks, nebo jiným způsobem, podle toho, co náš systém podporuje. Výsledkem operace je chybové hlášení nebo potvrzení operace. Má vždy formát XML souboru, lze jej tedy snadno parsovat a zpracovat.

8.2 Praktická ukázka v PHP Ukažme si, jak lze pracovat se SimpleDB přímo, bez použití knihovny. V ukázce se zaměříme na algoritmus podepisování a na volání API – nebudeme tedy ošetřovat chyby, timeout u HTTP požadavku, ani nebudeme zpracovávat výsledek. Nejprve si připravíme data pro požadavek, klidně jako asociativní pole: $query = array( 'Action'=>'PutAttributes', 'DomainName'=>'MyDomain', 'ItemName'=>'Svetr123', 'Attribute.1.Name'=>'Color','Attribute.1.Value'=>'Blue', 'Attribute.2.Name'=>'Size','Attribute.2.Value'=>'XXL', 'Attribute.3.Name'=>'Price','Attribute.3.Value'=>'000024.99');

34

Internet Developer Forum Je vidět, že voláme akci PutAttributes, budeme ji vykonávat v doméně MyDomain, jméno položky (klíč) bude Svetr123, a budou jí přiřazeny tři atributy – Color, Size a Price. Jistě vás nepřekvapí, že cena je zleva doplněna nulami – v minulém článku jsme si říkali, že SimpleDB zachází s čísly jako s řetězci, a pokud je chceme porovnávat, musíme je normalizovat. Všechny hodnoty proženeme přes funkci rawurlencode – lze použít array_filter. V tomto příkladu nejsou použity žádné znaky, které by bylo nutné ošetřovat, výsledek by měl být tedy stejný. K parametrům přidáme povinné údaje: $query['Version']='2009-04-15'; //vždy $query['Timestamp']= urlencode(date('c')); $query['SignatureVersion']='2'; //vždy $query['SignatureMethod']='HmacSHA256'; //vždy $query['AWSAccessKeyId']='0123456789ABCDEF';

Vy samosebou použijete vlastní Access Key.Version, SignatureVersion a SignatureMethod mají v současné verzi API výše uvedené hodnoty. Při testech jsem měl největší problém se správným formátem Timestamp, nakonec se jako použitelný ukázal urlenkódovaný výstup data a času podle ISO 8601, který vrací funkce date() s řetězcem ‚c‘. Pokračujeme podepsáním požadavku podle výše zmíněného postupu: ksort($query); //setřídění podle jména parametru $request = http_build_query ($query); $secret = 'bflmpsvzhkrdtn123456zabbfem/asoic-quake987'; //SecretKey $sign = hash_hmac ( 'SHA256', "GET\nsdb.amazonaws.com\n/\n" . $requesr , $secret, true ); $query = $request . '&Signature=' . urlencode(base64_encode($sign));

Výsledkem je požadavek ($query), doplněný o podpis. Je vidět, že protokol nezaručuje unikátnost požadavku – pokud by požadavek zachytil útočník na trase, může jej teoreticky zopakovat, protože podpis zůstane stejný. AWS umožní provedení operace po dobu 15 minut od času uvedeného v timestamp. Požadavek stačí už jen odeslat na server https://sdb.amazonaws.com/ – lze to udělat pomocí cURL, nebo i pomocí fsockopen – já použil druhou zmíněnou metodu: $response = ''; $fp = fsockopen("ssl://sdb.amazonaws.com", 443, $errno, $errstr, 30); if (!$fp) { echo "$errstr ($errno)\n"; } else { $out = "GET /?" . $query . " HTTP/1.1\r\n"; $out .= "Host: sdb.amazonaws.com\r\n"; $out .= "Connection: Close\r\n\r\n"; fwrite($fp, $out); while (!feof($fp)) { $response .= fgets($fp, 128); } fclose($fp); }

Výsledek operace získáme v proměnné response jako XML data.

35

Internet Developer Forum

8.3 Závěr Práce se SimpleDB pomocí REST rozhraní (s výhradou vůči pojmenování REST, viz výše) je opravdu snadná i bez použití knihoven. Jediná možná problematičtější pasáž je podepisování požadavků, ale po podrobnějším pročtení dokumentace (a odhalení správných funkcí pro hash, ošetření hodnot a vygenerování časového razítka) je tento úkol velmi snadný. Pokud budete zvažovat použití SimpleDB ve své aplikaci, sáhnete pravděpodobně po hotové knihovně, ale pro první pokusy a „osahání“ API na poměrně nízké úrovni lze, jak jsme si ukázali, použít těch nejjednodušších prostředků.

9 Windows Azure a PHP Martin Hujer Potřebuje ve své aplikaci ukládat velké množství dat? A ta pak zobrazovat návětěvníkům? Jedna z používaných metod je uložení v cloudu, jako je Amazon AWS, Google AppEngine nebo třeba Azure. V článku si ukážeme, jak v PHP můžeme využít právě možností neomezeného úložiště ve Windows Azure. Windows Azure Platform je cloud platforma od Microsoftu, která poskytuje zázemí pro kompletní běh webových aplikací. Vývoji pro tuto platformu se věnujeme i zde na Zdrojáku (Azure). Základem je Windows Azure, které obsahuje Data Storage – úložiště pro ukládání Blobů (Blobs), Tabulek (Tables) a Front (Queue). Dále máme k dispozici SQL Azure, což je vlastně MS SQL hostovaná v cloudu, a AppFabric, které slouží k vlastnímu hostování aplikací. 9.1.1

Výhody a nevýhody využití cloudu

Kompletní popis výhod a nevýhod využití cloudu by byl spíše na samostatný článek (zabývá se jí například Cloudcomputing: trend, nebo další buzzword? na Lupě). Z pohledu vývojáře je výhodou cloudu spolehlivost úložiště (data jsou uložena několikrát, na různých místech) a snadná škálovatelnost. Nevýhodou je bezpečnost dat (data nemáte pod kontrolou, ale jsou uložena „někde v cloudu“). V tomto článku se zaměříme na to, jak můžete využít výhody Windows Azure cloudu ve své aplikaci v PHP.

9.2 Potřebný software Základem je Windows Azure Software Development Kit (June 2010), který umožňuje vyvíjet aplikace s využitím lokální Storage a Developement Fabric, což je obdoba AppFabric. Dále obsahuje nástroje ke kompilaci aplikace pro spuštění na AppFabric (potřebujete Windows Vista SP1 a vyšší, .NET Framework 3.5 SP1 a další – detaily najdete přímo na stránce s downloadem). To, že vám lokální cloud storage funguje, si můžete ověřit zadáním adresy http://127.0.0.1:10000/ do prohlížeče. Pokud dostanete XML odpověď, která mj. obsahuje The requested URI does not represent any resource on the server, tak je vše v pořádku. Ještě budeme potřebovat REST rozhraní pro přístup k Azure. Použijeme knihovnu WindowsAzure SDK for PHP Developers. Buď si stáhneme nejnovější verzi z webu (vpravo nahoře Download), anebo 36

Internet Developer Forum provedeme export z SVN. Podpora pro Windows Azure je sice zahrnuta i v Zend Frameworku, ale je zastaralá, a proto ji nedoporučuji používat.

9.3 Uložení souboru do cloudu jako blob Jednotlivé bloby (z angl. Binary Large OBject – soubory s binárními daty) jsou uloženy v tzv. containerech (složkách). Struktura má jen jednu úroveň, containery nelze zanořovat do sebe. Nic nám ovšem nebrání použít v názvu blobu lomítko a tím si vytvořit virtuální adresářovou strukturu (podobně jako je tomu např. u Amazon S3). Začneme vytvořením instance třídy Blob. Pokud konstruktoru nepředáme v parametrech naše přihlašovací údaje, nastaví se automaticky na naši lokální storage. require_once 'Microsoft/WindowsAzure/Storage/Blob.php'; $storage = new Microsoft_WindowsAzure_Storage_Blob();

Dalším krokem je vytvoření containeru, který pojmenujeme testovaci-container (lze použít jen malá písmena, číslice a pomlčku – viz MSDN). Hned po vytvoření containeru ho nastavíme jako veřejně přístupný, protože do něj budeme ukládat obrázky, které budou součástí webové stránky. Pokud budeme bloby používat například k ukládání záloh, tak ho samozřejmě necháme private. $storage->createContainer('testovaci-container'); $storage->setContainerAcl('testovaci-container', Microsoft_WindowsAzure_Storage_Blob::ACL_PUBLIC_CONTAINER);

Posledním krokem je nahrání souboru, které vypadá následovně: $result = $storage->putBlob( 'testovaci-container', 'azure.png', 'C:\Users\Martin\Desktop\azure.png', array(), null, array( 'x-ms-blob-content-type' => 'image/png', ) ); echo $result->url;

Prvním parametrem je container, ve kterém chceme blob vytvořit, druhýparametr je název blobu a třetí parametr je název lokálního souboru, který tam ukládáme. Důležitý je ještě poslední parametr, kterým nastavíme správný Content-Type. Výsledkem je objekt, který obsahuje informace o vytvořeném blobu. Nás zajímá především url, pod kterou je náš obrázek přístupný. Na lokálním storage bude vypadat takto: http://127.0.0.1:10000/devstoreaccount1/testovaci-container/azure.png. Tuto URL můžeme použít přímo jako atribut src u obrázku ve webové stránce. 9.3.1

PHP stream wrapper

WindowsAzure třídy také umožňují aktivovat file stream wrapper, který dovoluje používat pro práci s bloby stejné funkce jako pro práci s normálními soubory: $storage->registerStreamWrapper(); copy('C:\Users\Martin\Desktop\azure.png', 'azure://testovacicontainer/azure2.png');

37

Internet Developer Forum Je možné zadat i název neexistujícího containeru, který bude automaticky vytvořen, ale poté bude nutné povolit veřejný přístup. Vytvořenému blobu pak také musíme nastavit správný Content-Type, jinak se použije výchozí application/octet-stream $storage->setBlobProperties( 'testovaci-container', 'azure2.png', null, array( 'x-ms-blob-content-type' => 'image/png', ) );

9.4 Vytvoření storage na živém Azure serveru Pro testování reálného použití je možné si aktivovat tzv. Introductory Special, kde je k dispozici omezené množství kapacity a výkonu zdarma. Po aktivaci účtu si vytvoříme projekt a do něj přidáme novou Service

Vybereme Storage Account:

A vyplníme nějaký smysluplný název a popis. Oboje se bude zobrazovat jen v administraci. V dalším kroku si zvolíme, pod jakou subdoménou bude náš blob přístupný. Jako region zvolíme „Anywhere Europe“

38

Internet Developer Forum Naše úložiště se vytvořilo. Vidíme adresy, pod kterými je přístupné, a přístupový klíč.

9.5 Úprava kódu pro živý Azure storage Do konstruktoru adaptéru pro blob přidáme přístupové údaje $storage = new Microsoft_WindowsAzure_Storage_Blob( 'blob.core.windows.net', 'zdrojak', 'l6SWXR2HGm(...)Q==' /* přístupový klíč */ );

Při uložení blobu se nám vrátí URL http://zdrojak.blob.core.windows.net/testovaci-container/azure.png

9.6 A co jiná URL? Tahle je ošklivá… Pokud nechcete ze své stránky linkovat externí adresy, je možné si nastavit vlastní URL:

Vyplníme vlastní URL – já jsem zvolil zdrojak.martinhujer.cz. Dostaneme vygenerovanou speciální subdoménu, kterou musíme pomocí CNAME záznamu nasměrovat na verify.azure.com a naši zvolenou doménu, kterou CNAME záznamem nasměrujeme na zdrojak.blob.core.windows.net. Pak už jen chvíli (několik hodin) počkáme, aby se záznamy v DNS zpropagovaly a klikneme na Validate.

Náš soubor teď bude přístupný i z adresy http://zdrojak.martinhujer.cz/testovaci-container/azure.png.

9.7 Závěrem V článku jsme si ukázali, jak můžeme využít cloud pro ukládání a distribuci obrázků z naší webové aplikace. Nedávno se objevil i plugin do Wordpressu, který umožňuje Windows Azure používat jako storage pro uploadovaná data. Samozřejmě, že to nemá smysl u blogu s pár stovkami návštěv denně, ale pro aplikaci nabízející webová alba pro tisíce lidí už to stojí za zvážení.

39

Internet Developer Forum

9.8 Odkazy • •

Hlavní stránka Windows Azure Manuál k PHPAzure

10 Linuxový cloud hosting pro osobní použití v ČR? Martin Malý Termín „cloud hosting“ je poměrně známý, ovšem spojujeme si jej spíš s velkými poskytovateli, jako jsou Amazon, Rackspace či Google. V České republice bychom cloud hosting zatím hledali marně, zde končí nabídka u virtuálních serverů. Před časem se objevila služba, která by mohla zahýbat i s tímto trhem. Jednou z největších výhod virtuálních serverů, které běží ve velkých cloudech, je jejich škálovatelnost „na počkání“. Změny parametrů serveru můžete provést kdykoli a zaberou nejvýše desítky minut. Navíc je pravidlem účtování po krátkých časových úsecích za spotřebované strojové prostředky – tedy nejčastěji za velikost paměti, počet procesorů, velikost HDD či datový přenos. Hodina provozu takového malého serveru vyjde na zlomky centů. Velkou výhodou cloudového hostingu je tedy téměř neomezená škálovatelnost, a to jak horizontální, tak vertikální. Chcete další server? Spustíte si jej. Chcete silnější? Upravíte si parametry. Když očekáváte zvýšení provozu, spustíte si load balancer a za něj posadíte deset, dvacet serverů. Jakmile nápor poleví, zase je vypnete. Platíte ale vždy jen to, co opravdu spotřebujete, takže odpadá počáteční rozvažování a odhadování potřebné velikosti a rychlosti serveru. Když nestačí, můžete jej kdykoli zvětšit, když je předimenzovaný, zmenšíme jej, abychom neplatili zbytečně.

10.1 Virtuální servery Velké cloudy nabízejí většinou několik služeb. Mezi ty základní patří virtuální server a datové úložiště, někdy kombinované s CDN (Content Delivery Network). Klasickým příkladem jsou služby od Amazonu, nazvané EC2 (Elastic Computer Cloud) a S3 (Simple Storage Service). Amazon nabízí i další, jako třeba databáze, službu front či platební systém. Základem je ale vždy virtuální server. Virtuální servery jsou nejčastěji řešeny pomocí virtualizačních nástrojů Xen, KVM, OpenVZ a podobných, běžících na linuxových OS a nabízejících opět hostované Linuxy. V nabídce některých cloudů naleznete i Windows, ale bývají dražší (licenční poplatky) a méně časté. V ČR začaly hostingové společnosti nabízet služby virtuálních hostingů (i ve variantě Managed), a takových nabídek je na trhu už slušná řádka (Ignum, Active24, VSHosting a mnozí další). Cenově se řadí někam mezi dedikované servery (tedy známé „pronajaté železo“) a sdílený hosting. Pro provozovatele jsou výhodné v tom, že mohou jeden fyzický stroj „rozparcelovat“ na víc virtuálních serverů, aniž by se museli starat o „neposlušné uživatele“, co přetěžují sdílený hosting – o to se stará virtualizační nástroj. Pro zákazníky je zase výhodná plná kontrola nad serverem. Nevýhodou je pak totéž, či lépe řečeno související nutnost mít někoho, kdo se o server postará. A zde opět nastupují hostingové společnosti, které za určitý obnos převezmou správu takového serveru za zákazníka (managed varianta).

40

Internet Developer Forum Virtuální servery, které nabízejí české hostingové společnosti, jsou ale většinou alternativou jejich klasických hostingových programů – tj. účtované měsíčně, s platbou na fakturu nebo převodem z účtu atd. O tom, že byste si na týden zvedli výkon stroje na desetinásobek (a zaplatili jen ten týden) si většinou můžete nechat zdát. (Alespoň tak tomu bylo u služeb velkých hostingových společností, které mají virtuální servery v nabídce. Je možné, že existuje malý hosting, který nabízí flexibilní účtování virtuálních serverů, ale až na jedinou výjimku, o níž bude řeč, jsem na takový nenarazil; pokud takový znáte, podělte se o tip s ostatními čtenáři v komentářích – pozn.aut.) Situace v ČR byla v době, kdy autor těchto řádků sháněl virtuální server pro své potřeby, tedy před necelým rokem, poměrně neradostná. Ze sedmi na webu nalezených a oslovených poskytovatelů odpověděli pouze tři. Lze předpokládat (či doufat), že se během té doby situace radikálně zlepšila. Zlepšovat se bude určitě i tím, jak poroste konkurence.

10.2 První vlaštovka cloudových služeb? Zajímavou nabídku představila, zatím poměrně neznámá, hostingová společnost Virtualmaster. Nabízí totiž virtuální servery, ale s opravdu „cloudovými“ parametry – tedy se snadno měnitelnými parametry, spustitelné během minut a účtované po hodinách provozu. Platit lze bankovním převodem nebo kartou (přes PayPal), takže od registrace po spuštění virtuálního serveru uplyne jen pár minut, což je na české poměry, kde je běžná stále ještě ruční administrace a bankovní převody, nevídaná rychlost. Cenově je nabídka srovnatelná s jinými poskytovateli virtuálních služeb – u malého serveru (128MB RAM, 4GB HDD) zaplatíte ve variantě „personal“ (jedno jádro, bez záloh atd.) cca 82 Kč bez DPH za měsíc, což je cena přijatelná i pro osobní použití. (Pokud je vaše aplikace náročnější, můžete si dohodnout i vyšší úroveň služeb nebo i některé poměrně speciální záležitosti, jako např. běh dvou serverů v geograficky různých lokalitách.) Velmi užitečná je možnost běhu testing serverů – tedy virtuálních strojů s 64MB RAM a 2GB HDD, které můžete spustit na 14 dní zdarma. Můžete si tedy na nich odladit konfiguraci serveru, nainstalovat potřebný SW, a pak snadno převést na placenou variantu, s větší pamětí i diskem. Prototyping serveru je tak velmi snadný. Navíc si můžete hotový a připravený server uložit jako šablonu (image), podle níž pak spustíte kdykoli zcela identický server. Samozřejmostí je, jako u všech poskytovatelů virtuálních serverů, že si můžete vybrat z předpřipravených šablon (v nabídce jsou různé Linuxy, od CentOS přes Debian/Ubuntu až po Gentoo či Slackware). Můžete vyjít nejen z „holého systému“, ale můžete použít i šablony, které už někdo připravil a nainstaloval, a které nabízejí třeba kompletní LAMP, Python server s Djangem, minimalistický Lighttpd s PHP či „enterprise“ šablony s webserverem, DNS serverem, OpenVPN a dalšími. Stejně tak můžete svou šablonu uložit jako veřejnou a umožnit tak ostatním, aby z ní vyšli při tvorbě vlastního stroje. Nejzajímavější na nabídce Virtualmasteru je právě to, že (pravděpodobně jako první v ČR) přichází s účtováním po hodinách a se snadnou změnou parametrů virtuálních serverů. Doufejme, že se inspirují i další poskytovatelé virtuálních serverů a že se brzy dočkáme hostingu s opravdu „cloudovými“ parametry, a to především co do flexibility. Zatím je opravdová flexibilita, bohužel, jednou ze slabších stránek českých hostingových společností a model „napište nám požadavek, my ho do dvou dnů vyřídíme, ale účtovat vám to budeme muset od začátku měsíce“ rozhodně není v menšině. Změnu přinese jen konkurence, která to bude nabízet, a poptávka uživatelů po takovém řešení.

41

Internet Developer Forum

10.3 Rozhovor s Adamem Klimentem ze společnosti Virtualmaster Můžete ve stručnosti představit firmu? Jak dlouho funguje, kolik lidí se o provoz stará… Společnost Virtualmaster byla založena začátkem tohoto roku mnou a mým kolegou Josefem Liškou, se kterým jsem se seznámil ve firmě ‚CHL počítače‘. Ačkoli to není z názvu patrné, firma CHL [čtěte cihla] :) se zabývá konvenční správou linuxových serverů a poskytováním SLA více jak deset let a celou dobu vychovává a sdružuje linuxové guru. Já a můj kolega Josef Liška jsme nyní jediní zaměstnanci společnosti Virtualmaster na plný úvazek. Já se zabývám řízením vývoje, kontaktem se zákazníkem a marketingem. Kolega Josef provádí výzkum ve low-level částech systému a stará se o linuxové distribuce a infrastrukturu. Jsme malá firma a snažíme se to tak udržet. Nonstop 24/7 pohotovostní službu, část vývoje, marketing a administrativu řešíme subdodavatelsky. Našimi zákazníky jsou převážně jednotlivci a malé a střední firmy. Další personální rozvoj plánujeme spíše na pozicích obchodníků. Jak vlastně vznikl Virtualmaster? Není hostingů v ČR už dost? Nápad vytvořit Virtualmaster vznikl v roce 2007 při navrhování datového modelu pro jednoduchou aplikaci v RubyOnRails na dokumentaci virtuální infrastruktury v telehouse. Mimochodem na základě těchto úvah vznikl základní objektový model, který je de facto totožný s tím, který využívá Deltacloud API (http://deltacloud.org/). Virtualmater nejříve sloužil pouze jako control panel k virtuálním serverům, s možností libovolně měnit parametry. Po konzolidaci všech serverů se virtualizací v CHL ušetřilo spousta prostředků a vzniklo spousta nevyužitého výpočetního výkonu. Naši kolegové a linuxoví známí používali Virtualmaster především na prototyping – tedy na hraní. Na začátku roku 2009 byla za využití ušetřených prostředků spuštěna první veřejná verze pro public testing. Virtualmaster jsme uživatelům představili jako nekonvenční linuxovou hračku, která měla sloužit v rámci virtualizační evangelizace: „virtuální server v prohlížeči na jedno kliknutí“. Inspirací nám byla jiná hračka pro programátory, která se mně osobně moc líbí: „Try ruby!“ (http://tryruby.org/). Byla to výzva. Když to jde s IRB, proč by to nemělo fungovat se sériovou konzolí, že. Virtualmaster nabízel po registraci každému uživateli virtuální server zdarma pro libovolné linuxové experimenty, tehdy bez jakékoli komerční nadstavby, pouze s limitem počtu a velikosti serverů. Po spuštění jsme se setkali s velkým ohlasem, především díky možnosti jemného škálování a rychlosti vytvoření serveru. Na základě statistik chování našich uživatelů jsme zjistili, že většina uživatelů server nepoužívá dlouhodobě, ale naopak servery opakovaně vytváří a mění konfiguraci v rámci svého limitu stejně jako jsme to dělali my při konsolidaci v CHL. Cítili jsme v tomto ohledu velkou možnost dát našim uživatelům naprostou volnost, na českém trhu unikátní, a tomu jsme přizpůsobili i způsob účtování. To bylo v době, kdy jste psal na rootu o hostingu v oblacích. Můžete prozradit něco málo o technickém pozadí hostingu? Na jakém HW vaše služby běží? Při public testing provozu jsme začínali s refurbished značkovým hardware – se servery IBM a Dell. Při plánování rozvoje jsme zjistili, že našim potřebám bude vyhovovat více malých serverů. Nyní používáme intenzivně testovaný komoditní hardware – desky a procesory Intel, paměti Kingston a disky Samsung a WD. Jednotlivé nody clusteru jsou bootované z flash disku. Používáte XEN, nebo OpenVZ? A proč právě to? 42

Internet Developer Forum Jako virtualizační platformu používáme Xen ovládaný přes libvirt. Důvodem je jednoznačně naprostá izolace jednotlivých virtualizovaných systémů a možnost nabídnout uživateli neomezeně manipulovat s vnitřním systémem. S Xenem máme již od začátku roku 2006 dobrou zkušenost, testovali jsme i dvojkovou řadu, od 3.0 byl pro nás použitelný. OpenVZ je takový lepší chroot, nelíbí se nám jeho filozofie. Snažíme se uživateli poskytnout zcela autonomní operační systém, což OpenVZ neumožňuje. Xen tato omezení nemá, systémy jsou zcela oddělené. Jakou distribuci používáte? Dříve jsme používali pro image nodů Ubuntu, avšak Ubuntu přestalo v jádře pro Dom0 podporovat XEN. V současnosti používáme modifikovaný live image Debianu s Xen 4 a s potřebným software (libvirtd, collectd, pmacctd, iscsi atd…). Plánujete další rozšíření cloudového typu, jako třeba storage service à la S3 či „lokální CDN“, nějakou jednoduchou databázi k pronajmutí atd.? Nabídnout storage a la S3 ani CDN zatím neuvažujeme. Snažíme se náš produkt udržet co nejjednodušší, a proto se v současnosti zaměřujeme pouze na vývoj podpůrných nástrojů pro manipulaci s virtuálními servery. V současnosti dokončujeme implementaci výše zmíněného Deltacloud RESTful API. Paralelně také probíhá lokalizace systému do angličtiny, v čemž vidíme lepší možnost zhodnocení našeho úsilí. V dlouhodobějším horizontu máme v plánu zpřístupnit naší infrastrukturu pro zálohování jako samostatnou službu. Bude možné si šablony stáhnout jako image pro vlastní virtuální server, nebo naopak uploadovat už připravené? Možnost stáhnout šablonu je na našem seznamu požadovaných vlastností, avšak jste první, kdo o tuto možnost projevil zájem. Implementaci funkcionality řídíme podle poptávky. Dávám jí tedy plus. Naopak po možnosti nasadit na Virtualmasteru vlastní šablony již poptávka byla. Tuto možnost v současnosti supluje boot rescue system, přes který je možné šablonu uploadovat pomocí SSH. V současnosti pracujeme na koncepčním řešení, které by uživatelům umožňovalo snadnou migraci fyzických a virtuálních serverů na infrastrukturu Virtualmasteru a opačně. Viděl jsem, že využíváte Twitter a Facebook, ostatně tam jsem si vašich služeb všiml i já. Můžete stručně říct, jak se vám kampaň v těchto sociálních sítích osvědčila? Přivedla vám významnější počet uživatelů? V průběhu provozu public testingu jsme inzerovali na Google AdWords, kde se nám nedařilo zasáhnout cílovou skupinu a cena za konverzi byla nepřiměřeně vysoká. Po zkušenostech s AdWords jsme udělali pár malých kampaní na Facebooku, v kterých jsme se snažili akcelerovat registrace do public testing provozu, kde byla míra konverze nesrovnatelně lepší. Narazili jsme však na problém, že zasažená demografická skupina uživatelů Facebooku je příliš mladá. V současnosti nám největší službu dělá virální efekt, který jsem se snažili podpořit možností publikovat veřejně šablony a bonusovým programem s affilate linky. Děkuji za rozhovor.

43