Přejít k navigační liště

Zdroják » Různé » Cloud computing: Jiný pohled na aplikace

Cloud computing: Jiný pohled na aplikace

Články Různé

V dalším článku na téma Cloud computing se vrátíme opět trochu k teorii. Jak se cloud liší od běžných virtuálních serverů či hostingů, a to nejen po stránce obchodní či technické, ale i po stránce přístupu k vývoji aplikací? Na co je třeba při vývoji pro cloud dávat pozor? To vše se dočtete v článku.

Nálepky:

Když jsem v minulém článku popisoval možnosti jednoho z cloudů (Rackspace Cloud), tak mi několik čtenářů v komentářích vyčinilo, že jsem skočil Rackspace na lep, že vlastně nejde o nic jiného než o obyčejný VPS, který byl pouze „olepen“ módním štítkem Cloud, a že je to tedy prachsprostý marketingový trik pro věci neznalé laiky.

Taková tvrzení jsou ukázkou neporozumění. Proto dovolte, abych udělal v seriálu drobnou zastávku a znovu připomněl, jak se cloud liší od běžného hostingu či od VPS. Ti, co četli stručný úvod do problematiky na Zdrojáku (Cloud hosting aneb hosting v oblacích), mohou následující část přeskočit.

Cloud versus VPS

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.

Z této definice nemusí být jasně vidět, v čem se liší cloud od, například, VPS, tedy služby pronájmu virtuálního serveru. Na první pohled si mohou být poskytované služby podobné, minimálně z pohledu zákazníka: Někde má vlastní „čistý“ server, má k němu přístup přes SSH, může si nainstalovat vlastní software, a přitom nejde o konkrétní fyzický stroj, ale o virtualizovanou instanci OS. Z tohoto úhlu pohledu se cloud od VPS moc neliší.

Odlišnost je právě v tom, co je zdůrazněno v oné výše uvedené definici: Cloud podporuje snadné škálování – a to nejen škálování výkonu, kdy lze za běhu zvyšovat či snižovat výkon, 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 chcete 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.

U cloudu 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ý ta­rif.

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.

Jiný model, jiný přístup

Cloudy ve snaze zajistit co nejlepší škálovatelnost pozměňují i známý klasický model webových serverů. V té nejjednodušší podobě běží u klasického hostingu na jednom stroji http server, databáze i vlastní výkonné skripty. U náročnějších aplikací bývá oddělena  databáze na vlastním stroji, někdy mívá vlastní stroj (či více strojů) například media server… V praxi to přináší nutnost pronájmu většího počtu patřičně dimenzovaných počítačů.

U cloudů je podobné „rozdrobení“ spíš pravidlem. Poskytované služby bývají rozděleny minimálně na „virtuální server“ a „datové úložiště“, k nimž bývají přidány další služby – například jednoduché databáze, load balancery či jiné specializované služby.

Cloud GoGrid

Toto rozdělení z podstaty vyzývá k trochu jinému pohledu na vytváření aplikací – od „skriptocentric­kého“, při němž je v centru dění výkonný skript, který se stará o data i o jejich prezentaci uživatelům, k „datacentrickému“, kde jsou nejdůležitější data, a vlastní skripty, které s nimi „na uživatelův požadavek“ pracují, jsou jakoby v pozadí.

Popišme si rozdíl na příkladu ze světa blogů. Jednoduchý blogovací systém poskytuje jednak redakční rozhraní, v němž jsou vkládány články do databáze, a pak vlastní zobrazovací engine, který při požadavku na určitou stránku vezme data z databáze a vytvoří z nich podle šablony HTML kód. Takto může fungovat jednouživatelský systém s relativně malou návštěvností. Pokud vytváříme systém s obrovskou návštěvností a s mnoha uživateli, brzy zjistíme, že narážíme na výkonnostní limity. První optimalizační krok tak bude nejspíš zavedení stránkové cache. Druhým krokem pak bude předgenerování stránek při vložení nového článku. Pak se nabízí logické pokračování: Při vložení článku zavolat skript, který připraví výslednou stránku a uloží ji na oddělený server, určený pouze pro distribuci obsahu. Obsah tak může být distribuován optimalizovaným http serverem (který např. nemusí vůbec umět aktivní skriptování) a výkonnému jádru klesne zátěž, kterou způsobovalo distribuování obsahu.

Toto oddělení dat od výkonné aplikace například vysvětluje, proč cloudy nabízejí virtuální servery s udávanou kapacitou HDD v řádu jednotek či desítek GB – u cloudu totiž virtuální server nemusí udržovat statické stránky pro webserver ani veškerá data v nějaké lokální SQL databázi.

Cloud z pohledu vývojáře

Pro určité aplikace je použití cloudu opravdu na místě. Ovšem pokud na cloud aplikujeme „mechanicky“ stejné postupy jako na klasický hosting, dedikovaný server či VPS, může se snadno stát, že výsledek nebude odpovídat očekávání. Při vytváření aplikace pro cloud je dobré se zamyslet, uhnout ze zaběhnutých kolejí vývoje webových aplikací a podívat se na problém cloudovýma očima.

Pokud vývojář nerespektuje specifika cloudu, snadno se pak setká s tím, že aplikace neškáluje tak, jak si představoval, že ji vysoká zátěž shodí a že navíc provozovatel platí nehorázně velké peníze za spotřebovaný výkon, který ovšem není vidět. Proberme si některé zásady, které je dobré dodržovat (a těm, kterým budou připadat příliš samozřejmé, se předem omlouvám):

Používejte cache. Co můžete, to si ukládejte do cache. Práce virtuálního serveru je mnohem dražší než prostor v úložišti a distribuce dat.

Ukládejte cache na disk, ne do databáze. Pokud si do cache uložíte hotové stránky, můžete je distribuovat rovnou, bez zásahu řídicích skriptů. Když si je uložíte do úložiště, budou distribuovány s minimální režií. Pokud si je uložíte do databáze, budete muset při každém požadavku spouštět skript a přistupovat do databáze.

Generujte cache podle požadavků. Nechat vygenerovat data do cache například „jednou za hodinu“ zní možná lákavě, ale není to dobré řešení. Mnohem lepší je generovat obsah pouze tehdy, když se něco změní.

Neblokujte sami sebe. Není nic snazšího, než přistupovat k datům majetnicky – při každém přístupu zamknout vše, co jde, vyhradit si zdroje pro sebe a na konci operace zase odemknout. Pokud není takový přístup opravdu neoddiskutovatelně nutný, snažte se mu vyhnout. Představte si, že jednou bude váš projekt slavný, a místo jednoho virtuálního serveru jich poběží deset, a všechny budou dělat nějakou drobnou operaci s daty v jednu chvíli. Klasickým případem blokování je např. zápis do souboru, který je zároveň distribuován uživatelům. Buď si skript zamkne soubor pro čtení i zápis, a klienti tak budou muset čekat, nebo zamkne jen zápis, a pak se snadno stane, že klient dostane neúplný soubor. Přitom zrovna v tomto případě není třeba vymýšlet nějaké složité zámky či mechanismy – stačí zapsat data do pracovního souboru (soubor.html.tmp) a ten po skončení zápisu přejmenovat. Přejmenování souboru (a smazání starého) je u cloudových datových úložišť atomická operace, při níž k blokování nedochází.

Protentokrát nezbylo místo na nějaký praktický příklad ze světa cloudů, ale i tak doufám, že toto teoretické intermezzo bylo zajímavé a užitečné a že ubude hlasů, které považují cloudy za pouhé VPS s přidaným mediálním humbukem.

Komentáře

Subscribe
Upozornit na
guest
20 Komentářů
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
View all comments
Borek Bernard

Tolik popsaných řádků a já to pořád nechápu :)

Hlava mi celkem dobře bere služby typu App Engine nebo Azure Services –
maj nějaké API, proti kterému napíšu aplikaci, nahraju ji na servery Googlu
/ Microsoftu a o škálování se služba automaticky postará za mě. Jasné,
srozumitelné, technologicky pochopitelné.

Když si ale na „Cloud Serevers“ požádám o instanci Windows Serveru,
nainstaluju na ni nějaké blogovátko, např. BlogEngine.NET, asi těžko
můžu jen tak zavolat na podporu a říct „hele, zítra očekávám článek
na Slashdotu a potřebuju 100× větší výkon“. Nemají, jak by to technicky
zařídili, ne?

Pokud se nepletu, tak se Cloud Server chová stejně jako VPS pouze s tím
rozdílem, že jeho instance lze vytvářet a rušit přes web. Je tohle to, co
dělá z Cloud Servers „cloud“? Kdyby aspone.cz zítra přidalo
vytváření a rušení instancí přes webový formulář, stali by se podle
tebe poskytovatelem cloud hostingu?

(Jiná věc jsou „online databáze“ a datová uložiště – ty jsou
krásným příkladem cloud služeb, „nekonečně“ nafukovací a
škálovatelné.)

Borek Bernard

– Mám blog na BlogEngine.net. Je pro mě nějaký výrazný rozdíl mezi
Rackspace Cloud Servers a ASPOne? (kromě způsobu placení a podobných
„maličkostí“)

.

– Mám aplikaci, která data ukládá na S3 a je napsaná tak, že na server
stačí nahrát pár PHP/Python/Ruby souborů. Je pro mě nějaký výrazný
rozdíl, jestli ty soubory nahraju na Cloud Servers nebo na ASPOne?

.

Nic nepodsouvám, jen se snažím porozumět…

Borek Bernard

Mimochodem, tuhle vychytanou textareu dělal kdo? Že ho zdravím a přeju mu
všechno nejlepší :)

Borek Bernard

Trochu jsem o tom ještě přemýšlel a myslím, že řada nedorozumění
vychází z použité terminologie. Snažil jsem se ujasnit, co je podle tebe
cloud hosting, cloud, cloud computing, jestli tyto pojmy používáš
zaměnitelně či nikoliv, proč se vyhýbáš celkem jednoznačným pojmům
IaaS, PaaS a dalším „X“aaS a podobně a přiznám se, že se mi to moc
nepovedlo. V prvním článku třeba píšeš, že od Mossa je CloudSites
obdobou VPS, což třeba mně osobně přijde, že z jejich nabídky má k VPS
nejblíž Cloud Servers a CloudSites jsou naopak obdobou nějakého hostingu
nebo App Engine. Tuhle větu pak už nechápu vůbec:

„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.“

Tohle pro řadu cloud hostingů vůbec neplatí, jak ostatně sám
poznamenáváš na jiných místech, takže tady mě už
ztrácíš úplně.

Abych nebyl jenom u reptání, které je navíc možná způsobeno jen mou
nechápavostí (i když jsem se fakt snažil, přísahám :), co takhle popsat,
jak mi cloud hosting pomůže v situaci, kdy začínám mít super-úspěšný
web postavený na WordPressu (PHP + MySQL) a potřebuju škálovatelnost bez
velkých investic do vlastního železa? Musím celý aplikační kód zahodit a
přepsat ho třeba do Pythonu + BigTable, aby mohl běžet na GAE? Stačí mi
jen oddělit webový a databázový server a nějak si na Amazonu EC2 udělat
malou serverovou farmu s replikací? Jak to bude technicky vypadat? Mám
nějaké jiné možnosti? Článek o tomhle by byl určitě mnohem
přínosnější než „Co je to Cloud (pro nechápavé), potřetí a
naposledy“ :)

Jan Kodera

No Cloud Servers z nich to cloud dělá ten resizing, bez restartu. Pokud si
ASPOne tohle zavede a bude účtovat po minutách je možné hovořit o cloudu.
Se současnými tarify to nelze.

U Amazon EC2 a podobných je to prostě tak, že přes API se sleduje co
systém dělá a pokud je zatížen, tak se objednávají nové instance. (Lze
na toto najít hromadu skriptů). IaaS ale nikoho neodstiňuje od té
administrace. U Cloud Servers je to zatím poněkud nešťastné, protože
webové rozhraní není to co by dodávalo patřičnou flexibilitu. Takže si
můžete jít lehnout a ráno zjistíte, že článek na slashdotu už byl a
server nestíhal. Až bude plné API, tak se to bude hlídat automaticky.

Z pohledu vývojáře – Cloud Servers,Amazon EC2 apod. vám povolí
nainstalovat jakýkoliv software, který potřebujete. Na druhou stranu, vám
nepomohou s jeho administrací. To je na vás. Vy volíte jak bude vypadat
struktura vašich serverů a jakým způsobem budou škálovat.

U AppEnginu a dalších je to tak, že jste na začátku omezen výběrem
softwaru či knihoven které lze použít. Za to dostáváte automatické
škálování. A taky mizernou přenositelnos­t jinam.

Borek Bernard

Díky oběma za vysvětlení, asi o tom budu muset blognout :)

Michal

Mě není jasná jedna věc – v jednom z předchozích článků bylo
zmíněno že uzly v cloudu nemají persistentní úložiště. Když vypnu
instanci tak data která tam byla zmizí. Jak na něčem takovém můžu
provozovat třeba databázi??

Jan Kodera

Ty data z databáze si budete pravidelně zálohovat. Amazon má na to
udělátko, které děla obraz přírůstku, takže záloha je skoro okamžitá.
Když to zapínate, tak to proti této záloze sesynchronizujete. Je to podobné
jako když máte zapnutou replikaci a jeden uzel umře. Než ho vrátíte
zpátky musí obsahovat aktuální data.

Nemusíte ovšem používat něco od amazonu, ale nějaký jiný nástroj. Je
jich mnoho.

Ladislav Thon

Koupíte si další službu, kterou je – tradá – persistentní
úložiště :-)

Petr

Mě se konkrétně tento článek zdá trochu divný. Pochybuju, že celý
ten cloud masakr existuje jenom proto, abych si mohl generovat statické
soubory… Protože když zvolím tento přístup vývoje a provozu webu, pak
nepotřebuji cloud, ale servírovat statické HTML soubory zvládne i při
slashdot efektu ten nejlevnější webhosting. Snad naopak, cloud potřebuju
když se se musí něco (pokud možno dobře paralelizovatel­ného) dost hodně
zpracovávat… Statická stránková cache prostě asi nebude ta
killer-feature… Zato kdybych měl milion uživatelů jednou za týden
nějakým map-reduce strojem seskupit podle toho, co rádi poslouchají, to by
byl nejspíš pěkný příklad pro cloud computing, ne?

O co tedy jde v cloud computingu? Dobře, škálování. Jak se toto
škálování provádí? Na to, že je to tedy ta nejdůležitější vlastnost,
tu o tom snad ještě nepadla ani zmínka. Funguje to třeba tak (je jedno
jestli automaticky nebo přes API), že při nedostatku výkonu se mi dejme tomu
virtuální server přesune na silnější hardware, nebo že se mi třeba
naklonuje na deset dalších serverů jako deset virtuálních strojů
(lišících se víceméně jen IP adresou)? Znamená cloud computing (tak jak
je zde prezentovaný) v podstatě jen to, že nějaký web/server-hosting
konečně jednou pořádně nainstaloval plnou verzi VMware? Já nevím, jen se
tomu snažím porozumět (aniž bych investoval do toho to doopravdy vyzkoušet,
to bych pak Zdroják nemusel vůbec číst) :-)

b*d

Nebude to v tom, že většina „programátorů“ neumí uložit data
jinak než přes SQL databázi.

Tomas

spíše jde o to, že pokud máš fórum nebo web kde není problém díky návštevnosti počet který si web prohlíží, ale počet který vkládá/mění obsah, tam ti totiž revProxy/cache moc nepomůže…

totéž pro část e-shop webu, který obsluhuje spousty(200) online obchodů za časouvou periodu(min?sek?), kdy budete každému generovat jiný obsah stránky „obsah košíku“ potvrzení nákupu(s adresou)…

pak ano další otázka je zda je lepší použít loadballancin­g(pořád) nebo cloud(nárazově) či kombinaci(nižší parametry cloud stroju v ballanceru).

ti kterým pořád není jasné co to ten Cloud je by si možna měli najít a přečíst článek na root-u o cloud Computing to by jim možná pomohlo rozšířit obzor, na úrověn kdy jim přečtení těchto článků a jejich pochopení nebude dělat tak velký problém.

škálovatelnost CloudHostingu:
představte si serverovnu obsahující 100ky či 1000ce serverů, kteroukoli část tohoto početního a úložného prostoru máte k dispozici v otázce hodin/minut?
Máte tuhle možnost u VPS? Můžete u VPS zrušit 20 serverů s loadbalancingu behem hodiny a neplatit za zbytek měsíce?
Co se týče možná matoucí části kde většinu lidí možná mate informace, která je až nápadně podobná VPS, a to jsou parametry CloudServerů(aka RAM disk CPU) ano je to dost podobné, ale možnosti jsou jiné právě v kvantitě výkoných a výkonějších strojů neustále k dispozici.

Zatímco nějaké VPS si může postavit třeba i malá firmička s jedním max 3mi servery využívající serverHousing s nasmlouvaným připojením a traffikem, težko si tam nahodíte „virtuální stroj výkonu 4 dvoujádrových procesorů s 16GiB RAM. U cloudu vám Vás „virtuální stroj“ odletí z jednoho fyzickéhoClou­dStroje(1× dualCore 8GiB RAM, 4další virtuální stroje s minimální konfiguraci) na fyzickýCloudStroj zmíněných požadovaných parametrů, který od té chvíle máte vyhrazen.

ano, termín nekonečný výkon a prostor je i v CloudHosting-u trochu zavádějící.
15PB mi asi na noc nenabídnou.

Tomas

korekce vítány z redakce
serverů <b>z</b> loadbalancingu
U cloudu vám Vá[b]š[/b]
terminologii jsem si moc nekontroloval

asi taky zdravím tvůrce tohodle boxu…

Mastodont

Uvažoval někdy někdo o tom, že by se pojem „cloud computing“
přeložil do češtiny?

Tonda

Cau,

a slyseli jste uz o „cloud gaming“ sluzbach jako je OnLive nebo Gaikai? Momentalně jsou ve fazi testovani, behem pristiho roku by se to melo – minimalne OnLive – spustit naplno, teda zatim jenom v USA.
Herni vypocty probihaji v cloudu, vysledek se streamuje a posila po netu jako video a hrac ho ovlada na svem koncovem zarizeni – coz muze byt cokoliv, starej notebook nebo iPhone. Tomuto tematu se venuje tohle OnLive forum

Enum a statická analýza kódu

Mám jednu univerzální radu pro začínající programátorty. V učení sice neexistují rychlé zkratky, ovšem tuhle radu můžete snadno začít používat a zrychlit tak tempo učení. Tou tajemnou ingrediencí je statická analýza kódu. Ukážeme si to na příkladu enum.