Cloud computing je sousloví, o kterém se píšou články, vytvářejí marketingové kampaně, vedou diskuze na fórech a dokonci již existuje v reálném světě – je k dispozici několik cloudových služeb (Amazon AWS, Google App Engine, Microsoft Azure). Ta nejdůležitější informace chybí – jak správně vyvíjet aplikace pro toto prostředí. Možná proto, protože dobře napsaná aplikace pro cloud vyžaduje zásadní změnu postupů a architektury – komu by se do toho chtělo? Je možné, že cloudy s sebou přináší revoluční změny v SW vývoji. Je možné, že se mýlím…

Oprava oblíbených omylů

Asi největším nedorozuměním je tvrzení, že v cloudu získáme neomezený výkon. Když se podíváme například do ceníku Amazon EC2, nalezneme zde nejvýkonnější virtuální server, který je sice relativně výkonný, ale nepřesahuje výkon běžného serveru. Pojem „neomezený výkon“ znamená, že si můžeme pořídit neomezené množství takových serverů, ale ne to, že by nám poskytovatel nabídl x86 server s výkonem mainframe.

Dalším omylem je výhodnější cena. Cloudy oproti vlastnímu HW mají jiný model pořizovacích a provozních nákladů – u cloudů se typicky platí za reálné používání služby. Nelze jednoznačně říci, že platba za spotřebovaný výkon je výhodnější, závisí na typu aplikace a chování jejich uživatelů. A také na tom, zda je aplikace dobře optimalizovaná.

Za největší největší problém cloudů je uváděna bezpečnost – svá data svěřujeme jiné firmě. Podle mého názoru je to lichý argument – spousta malých a středních firem svěřuje svá nejcennější data jiným firmám, když si nechává zpracovat účetnictví a nikdo to za bezpečnostní riziko nepovažuje. Z pohledu vývojáře je nebezpečí někde úplně jinde, a to závislost na poskytovateli (vendor lock) – aplikace využívající specifických nástrojů poskytovatele je závislá na jeho infrastruktuře a přechod k jinému poskytovateli je obtížný a drahý.

Proč cloud?

Nejzajímavější na všech článcích o cloudech je nerozhodnost autorů, pro koho je tato služba určena. Někteří tvrdí, že cloud je ideální pro provozování menších aplikací, neboť za málo peněz získá provozovatel kvalitně spravovanou infrastrukturu. Jenže malá aplikace nebude zpravidla navržená škálovatelně, protože by to její vývoj prodražilo. Provozovatel velké aplikace bude mít dostatek financí, aby investoval do vlastního HW. Pro koho jsou cloudy určeny?

Příliš se mi nezdá ani argument, že aplikace v cloudu se lépe vyrovná se špičkovou zátěží. Reálná webová aplikace musí být dostatečně dimenzovaná kvůli špičkám, které vyplývají z podstaty internetového provozu. Jde o špičky, kdy dojde ke skokovému navýšení zátěže například 10x. Pochybuji, že někdo dokáže napsat aplikaci tak dobře škálovatelnou, aby se dokázala přizpůsobit například stonásobnému zvýšení provozu.

Vliv na architekturu aplikace

Pojem cloud computing je velmi široký, řadí se pod něj jak firmy, které nabízejí pronájem virtuálního serveru, až po firmy, které nabízejí pronájem své aplikace. My se zaměřme na to, jak vyvíjet aplikace v nejznámějším cloudu – v Amazon AWS. Už na první pohled bude aplikace pro cloud vycházet z jiných požadavků než běžná aplikace:

• Běh aplikace na jednom stroji nebude pravděpodobně výkonem dostačovat, aplikace by tedy měla běžet v clusteru a měla by být dobře škálovatelná.
• V některých případech aplikace může používat jen technologie, které nabízí poskytovatel cloudu. Je sice možné si do virtuálního stroje leccos doinstalovat, ale nemůže to být databáze – například Amazon jasně deklaruje, že data na lokálním disku virtuálního stroje nejsou zálohována a nemusí být obnovena po havárii.
• Vliv na architekturu bude mít i ceník cloudových služeb – výpočetní výkon je u Amazon AWS dražší než zabraný souborový/databázový prostor.
• V cloudu si nepronajímáme fyzický server, ale virtuální.
• Harwareovou ani síťovou infrastrukturu nemáme pod kontrolou, nemůžeme si například zjednodušit práci tím, že nasadíme pro všechny servery společný (hardwareový) firewall.

Pojďme se nyní podívat na praktické důsledky těchto požadavků.

MVC

Jak již jsem psal výše, výpočetní výkon je dražší než prostor na disku nebo v databázi. Řešení pro webovou aplikaci je jednoduché – nebudeme vytvářet HTML stránky dynamicky, ale budou uložené a zobrazované pomocí (souborové) databáze, v případě Amazonu pomocí databáze Amazon S3. Musíme ovšem zařídit aktualizaci HTML stránek při změně dat. I zde má Amazon AWS připravené řešení, a to je poslání při změně dat a její (offline) zpracování pomocí Amazon Simple Queue Service.

Důsledky předchozího odstavce jsou pro architekturu aplikace zásadní. Návrhový vzor MVC bude použitý dost odlišným způsobem (a má ještě vůbec smysl?). Statické stránky neumožní tolik interaktivity s uživatelem jako ty dynamické. Některé nezbytně dynamické fragmenty stránky (košík v e-shopu, login uživatele atp.) bude muset aplikace řešit alternativním způsobem (například použitím AJAXu).

Relační databáze

Limitujícím faktorem škálovatelnosti aplikace je relační databáze. V běžné aplikaci je použita obvykle jen jedna centrální databáze, to je ale úzké místo. Některé relační databáze oficiálné umožňují práci v clusteru, ale jejich škálovatelnost je reálně limitována na několik málo serverů. Existuje několik přístupů, které toto omezení překonávají:

• master-slave replikace – data se zapisují do master serveru, odkud se replikují do všech slave serverů, kde jsou k dispozici pro čtení (v PostgreSQL součástí jádra databáze od verze 9).
• Shard – data z jedné tabulky jsou umístěna na více serverů (tj. při 3 serverech bude každý první záznam na prvním serveru, každý druhý na druhém a každý třetí na třetím serveru) – je možné použít například knihovnu Hibernate Shards.
• modularizace – data rozmístíme po serverech podle logické návaznosti, například server s uživateli, server s produkty, server s články atd.
• NoSQL databáze si umí s clusterem poradit lépe, některé z nich byly navrženy za účelem dobré škálovatelnosti.

Použití NoSQL databáze jeho hlavního úložiště dat v aplikaci znamená její kompletní přepsání. Ale ani ostatní výše navržené přístupy nejsou zadarmo – některé vlastnosti nebude možné použít nebo jen omezeně. Refereční integrita, sekvence, uložené procedury – nic z toho nebude fungovat přes více databázových serverů.

MapReduce

Kdysi bylo dávkové zpracování naprosto běžné, se zvyšováním výkonu počítačů bylo čím dál tím více úloh programováno na interaktivní spouštění. I když interaktivní spouštění úloh je uživateli bližší a lépe se programuje, nemáme-li výkon serveru odpovídající velikosti dat nebo složitosti úlohy, není jiné řešení než dávkové spouštění. To není jediné omezení – protože výkon jednoho serveru je v cloudu limitován, měl by algoritmus úlohy být upraven pro paralelní běh na více strojích. Další omezení jsou kvóty, které některé cloudy vyžadují, například maximální doba běhu threadu u Google App Engine. Řešením může být použití MapReduce, ale to se hodí jen pro některé typy úloh.

Komunikace mezi servery

Ke cloudovým službám dostanete také load balancer pro vytvoření clusteru, spolupráce instancí aplikace na jednotlivých server je pochopitelně na vás. Je potřebujeme nějaký způsob komunikace mezi instancemi aplikace. Může jít například o síťovou cache – existuje velké množství síťových cache, známé jsou Terracotta, Memcached nebo Java Caching System.

Někdy je potřeba přímá komunukace mezi instancemi aplikace. Nabízí se REST používající například XML. Jenže to je řešení, které je pomalé. Jednak http protokol je navržený na přenos jednoho dokumentu a pak dojde k uzavření spojení. Jednak XML je příliš „upovídaný“ formát. Lépe budou fungovat protokoly Protocol Buffers nebo Thrift.

Závěr aneb Výzva

Podle mého názoru nejsou cloudy jen jakousi nedůležitou módou, ale technicky i obchodně zajímavým směrem vývoje aplikací. Nelze ale očekávat, že stačí vzít existující aplikaci, nasadit ji do cloudu a očekávat, že se tím vyřeší problémy s výkonem. Smysluplné nasazení aplikace v cloudu znamená její úpravy, někdy i rozsáhlé. Přesto tuto technologii nezatracuji. Cloud computing může pomoci v případě, kdy chceme spustit rozsáhlejší aplikaci, ale na odpovídající serverové vybavení chybí na začátku dostatek financí nebo lidských kapacit. Cloudy by se mohly stát elegantním řešením problémů javového hostingu.

Na konec mého článku si dovoluji připojit výzvu. Máte nějaké praktické zkušenosti s cloudy? Víte, že určité technologie se do cloudu hodí nebo naopak nehodí? Napište to i pro ostatní čtenáře do komentáře pod článkem. Technických i praktických informací o této technologii je málo…