Motivace pro používání škálovatelných řešení
Během 13let existence společnosti Et netera narážíme při vývoji webových aplikací na trvalý problém zajištění dostatečného výkonu. S trochou nadsázky, lze říci, že webové aplikace jsou v pasti Moorova zákona. S rostoucím výpočetním výkonem roste úměrně i požadavky na výkon generované jednak rostoucím počtem uživatelů a změnou jejich chování a druhak změnou technologických paradigmatů tvorby WWW aplikací označovaných souborně jako Web 2.0.
Budeme-li pro jednoduchost měřit požadavky na výkon počtem požadavků na webový server, lze snadno doložit na konkrétních případech dynamiku růstu. Následující obrázek (1) demonstruje tento fakt na metrice počtu požadavků (hitů) na jednu uživatelskou návštěvu. Graf zobrazuje reálná data jednoho provozovaného projektu, nicméně obdobný trend sledujeme u většiny provozovaných prezentací a webových aplikací. Dramatický nárůst je dán primárně masivním využíváním technik typu AJAX.
Graf přitom uvádí požadavky na jednu návštěvu. Dále je nutné vzít do úvahy, že samotný počet návštěv narostl za sledované období téměř desetinásobně. Celkové počty požadavků tedy za desetileté období vzrostly řádově stonásobně.
Obrázek 1: Vývoj počtu požadavků na jednu návštěvu serveru www.annonce.cz
Problematiku výkonu dále komplikuje fakt, že zátěž není rozložena v čase rovnoměrně, ale podléhá značné sezónnosti a špičkám. U vybraných serverů jsme nuceni počítat s výkonovou rezervou pro zátěž odpovídající více než desetinásobku typické dlouhodobé hodnoty. Tyto špičky jsou způsobovány kampaněmi v médiích, výprodejovými akcemi, případně spojením s významnými společenskými či sportovními událostmi.
Výše uvedené jasně demonstruje motivaci k uvažování o plně škálovatelných platformách využívajících technik označovaných souhrnně jako cloud computing [CLOUD].
Kromě technologického hlediska je nutné uvažovat i hledisko podnikatelské, kdy řada projektů startuje do velmi konkurenčního prostředí a vysokou mírou rizika. Z tohoto pohledu je proto rozumné nebudovat vlastní infrastrukturu dimenzovanou na očekávanou špičkovou zátěž, ale volit cestu pronájmu snadno rozšiřitelné vývojové kapacity. Tím dochází k přenosu počátečních investičních nákladů na provozní rozpočet, který lze lépe řídit s ohledem na reálné výsledky daného podnikatelského záměru.
Třetím faktorem motivující k využití cloudů pro hostování aplikací je problematika sociálních sítí. Aplikace nabízející služby například pro Facebook musí počítat s technologickým rizikem masivního nelineárního růstu zátěže v případě úspěšného šíření aplikace sociální sítí. Při klasické online propagaci zpravidla sledujeme lineární přirozený růst počtu uživatelů, nebo předvídatelný skokový způsobený investicí do reklamy. V případě sociálních sítí může dojít k velmi rychlému a často neočekávanému exponenciálnímu nárůstu počtu uživatelů a nutnosti navýšení výkonu v řádu hodin.
Koncepce Google Application Engine
Koncept Google Application Engine (dále GAE) [GAE] plně vyhovuje výše formulovaným požadavkům. Základním posláním je umožnit rychlý vývoj webových aplikací určených k hostování ve výpočetním mraku společnosti Google.
Oproti známějšímu Amazon EC2 [EC2] poskytuje odlišný přístup. Zatímco Amazon EC2 pronajímá uživatelům primárně výpočetní kapacitu formou virtuálních serverů, GAE poskytuje pouze soubor služeb a hostování aplikace využívající tyto služby. Vývojář je v GAE zcela odstíněn od technologických detailů distribuce aplikace a tyto služby využívá prostřednictvím definovaných rozhraní, aniž by měl šanci jakkoliv ovlivnit jakým způsobem je aplikace v rámci cloudu provozována. Systém GAE zcela transparentně alokuje potřebné prostředky dle reálné zátěže. Hostovaná aplikace tedy ani neví na kolika serverech je provozována apod.
Z hlediska obchodního je poměrně zásadním rozdílem též model, kdy jsou účtovány poplatky dle intenzity využívání jednotlivých API a nikoliv za virtuální servery. Zajímavostí je též nulový poplatek pro méně zatěžované prezentace.
Poznámka – při srovnání s Amazon EC2 jsem záměrně zanedbal související služby Amazon Simple Database a Simple Queue, které začínají poskytovat obdobné služby. V beta verzích jsou i další služby jako Amazon relational Databaze service. Ty však prozatím nepředstavují typické využití Amazon EC2. To zůstává na úrovni pronájmu virtuálních serverů.
Podporované platformy
V současné době jsou podporovány dva jazyky pro vývoj aplikací. Python 2.5, přičemž aplikace vycházejí z principů Web Server Gateway Interface [WSGI]. Druhým je Java 6, kdy se aplikace opírá o specifikace Java Servlet a Java Server Pages. V další části se budu věnovat výhradně použití jazyka Java, nicméně použití Pythonu je analogické jak z hlediska vývoje, tak z hlediska omezení a výkonu.
Základním omezením, které je nutné vzít na vědomí je omezení doby zpracování na dobu 30-ti sekund. GAE tedy nelze jednoduše využít pro dlouhodobé výpočty nebo jiné časově náročné operace.
Je nutné vzít dále na vědomí, že aplikace není provozována na plnohodnotném JVM či, ale na verzi upravené pro bezproblémový běh ve výpočetním mraku. Konkrétně jsou na aplikaci kladena tato omezení:
- Nelze zapisovat na filesystemem – jediným úložištěm je Google Datastore, popsaný dále
- Nelze otvírat obecné sockety – k dispozici je pouze port 80 a 443 prostřednictvím služby
- Omezeny jsou funkce java.lang.System (exit(), gc(), ….)
- Nelze vytvářet nové thready nebo thread group
- Zbytek Java API lze používat dle definovaného JRE Class White Listu
Pro tvorbu frontendu jsou pak k dispozici Java Server Pages. Pro řadu vývojářů je zajímavé, že existují porty různých jazyků a frameworků pracujících nad JVM. Ucelený přehled lze získat například v přehledu na diskusní skupině [JVMLIST].
Poskytované služby a nástroje
Výše uvedená omezení jsou částečně vyvážena nabídkou služeb platformy GAE. Aplikace může využít následující služby či rohranní:
- Datastore a blobstore slouží pro ukládání dat. Jelikož nelze využít klasické SQL databáze, je datastore jedinou možností jak ukládat relační data. Jedná se o distribuované objektové úložiště podporující technologie JPA a JDO pro persitenci javovských objektů. Jakožto klíčové komponentě se mu věnuji v samostatné kapitola.
- Memcache – samotný datastore je relativně pomalý. Proto existuje služba memcache, což je distribuované in-memory cache podporující standard JCache dle JSR 107. Typické použití je cachování dotazů do datastore a persistentních objektů.
- URL Fetch je jednoduchá služba pro stahování obsahu externích URL pomocí HTTP/HTTPS s omezením na porty 80 a 443.
- Mail je službou pro rozesílání a příjem emailů. Každá aplikace může přijímat emaily na adrese neco@appid.appspot.com a tyto zpracovávat jako requesty. K odesílání pošty pak slouží JavaMail (javax.mail) rozhraní.
- XMPP je službou pro rozesílání a příjem krátkých zpráv zasílaných prostřednictvím protokolu XMPP, který je využíván např. službou Jabber a GoogleTalk. Aplikace může zprávy jak posílat, tak přijímat.
- Image service poskytuje nástroje pro manipulaci s obrázky, primárně pak pro jejich transformaci. Interně je využíváno nástrojů použitých v Google službe Picassa, díky čemuž jsou výstupy konverzí velmi kvalitní. Služba kromě běžných transformací podporuje např. automatické vylepšení kontrastu, jasu a další optimalizace.
- Scheduled tasks service umožňuje definovat pravidelné akce. I zde platí pravidlo, že iniciovaný task nesmí běžet déle než 30 sekundový
- Task queue je službou umožňující částečně obejít 30 sekundový limit. Aplikace může vytvořit frontu úkolů, které představují defacto naplánované volání URL aplikace. Ty se následně spouští.
- User service zajišťuje autentikaci uživatele prostřednictvím Google Loginu. Výhledově se plánuje i podpora Open ID a dalších metod.
Každá z těchto služeb má samostatnou politiku kvót a omezení počtu volání či objemu zpracovaných dat.
Datastore
Lze říci, že síla aplikační platformy stojí a padá se schopnostmi úložiště zvaného Datastore. Tento umožňuje ukládat typované objekty, pro které užívá termín entity. Při návrhu datového modelu je vhodné se oprostit od relačního paradigmatu. Datastore se sice může chovat podobně jako relační databáze, ale daleko vhodnější je využít plnou sílu objektového přístupu. Ukládat tak můžeme entity obsahující:
- Základní datové typy
- Speciální atomické typy jako je email, účet Google, URL a další mapované na speciální třídy z balíku GAE
- Relace mezi uloženými objekty
- Embed classes
- Seznamy a kolekce – podporována je řada objektů balíků java.util jako je ArrayList, HashSet, List, Set, Stach a další
Persistence objektů může být řešena pomocí API Datastore, pomocí JDO nebo pomocí JPA, přičemž je na vývojáři, kterou metodu zvolí. V případě JDO či JPA je nutné třídy určené k uložení korektně anotovat a enhancovat. Vývojové prostředí poskytované GAE však tyto operace velmi účinně automatizuje, takže většinou postačí pouze anototovat třídy a propertieties.
Objekty jsou ukládány, získávány a mazána dle klíče generovaného pro každou entitu. K dispozici je dotazový jazyk JDOQL, který umožňuje dotazy podobným stylem jako jazyk SQL. V dotazech je možné tvořit podmínky na hodnoty atributů, filtrovat a řadit. Výsledkem je vždy seznam objektů daného typu k dalšímu zpracování.
U distribuovaného úložiště je kritické zajištění konzistence dat. GAE Datastore nabízí dva mechanismy k jejímu zajištění:
- Transakce – lze vytvářet skupiny operací nad Datastore, které buďto skončí všechny úspěšně, nebo neúspěšně
- Čtecí strategie – lze použít dvě strategie, které se liší mírou konzistence získávaných dat. Strong consitency garantuje získání konzistentních dat nezávisle na distribuci aplikace, zatímco Eventual consitency připouští možnost nekonzistence. Obě strategie se podstatně liší rychlostí odezvy řádu až stovek milisekund ve prospěch Eventual consistency. Více například [GAEBLOG]
Správa aplikace
Aplikace jsou hostovány na doméně applicationid.appspot.com. Pro každou aplikaci je k dispozici plně webové administrační rozhraní zpřístupňující řadu informací:
- Informace o využívání aplikace, stavu vzhledem ke kvótám a billingu
- Prohlížení datastore, front úkolů, plánovaných úloh
- Prohlížení logů
- Administraci aplikace
Velmi podstatnou funkcí je možnost spravovat různé verze aplikace, přičemž jedna z nich je hlavní. K náhledu jsou však všechny, což lze s výhodou použít pro testování nových verzí.
Aplikace je spojena s Google účtem vlastníka, nicméně lze volně přidávat další vývojáře a spolupracovat tak na vývoji. Drobnou nevýhodou je nemožnost snadného přesunu vlastnictví aplikace a dat pod jiný účet, takže není vhodné spojovat aplikaci s účty konkrétních vývojářů.
Vývoj a testování
Pro testování a vývoj je k dispozici vývojový server běžící na lokálním stroji, který plně simuluje produkční prostředí včetně datastore a dalších služeb. Pro Javu dodává společnost Google velmi dobrý plugin do IDE Eclipse, který automatizuje řadu vývojových činností, jako je zakládání projektů, enhancování tříd pro JDO, deployment aplikace na appspot.com a další.
Cena
Cenový model je relativně komplikovaný a vychází z limitů pro každou jednotlivou službu. Základní parametry jsou:
- Počet requestů
- Alokovaný výpočetní čas
- Objem přenesených dat
- Objem uložených dat v datastore
- Frekvence volání služeb
U těchto parametrů jsou vždy uvedeny denní a maximální minutové limity.
Velmi zajímavé je, že cena pro malé objemy je nulová, přičemž limity jsou nyní nastaveny poměrně benevolentně. Reálně tak lze provozovat zdarma poměrně slušně navštěvovaný site s 1,3 milióny hity denně. Více na ceníku [PRICE].
Výkon
Z testů prováděných na reálných aplikacích lze vyčíst následující závěry:
- Aplikace plynule škáluje, odezva aplikace se s rostoucím počtem konkurentních uživatelů nezpomaluje
- Určitý vliv na výkon má volba jazyka, který použijeme
- Veliký vliv na výkon má způsob komunikace s Datastore
- Veliký vliv na výkon má použití memcache
Škálování
V rámci zátěžových testů se nám nepodařilo dosáhnout zpomalení odezvy způsobené růstem současně kladených požadavků. To je demonstrováno výstupem z jednoho z testů (obrázek 2), realizovaného prostřednictvím Apache Benchmark utility.
Obrázek 2: Závislost rychlosti odezvy na počtu současných uživatelů
Vliv jazyka pro vývoj aplikace
Výkon aplikace závisí částečně na volbě jazyka. Experimentálně toto ověřil například server [DIST] a další. Lze říci, že aplikace v jazyce Python jsou v rámci GAE rychlejší než srovnatelné v Javě. Zásadní komlikací je však použití jiných JVM based jazyků jako je Groovy, JRuby apod. V těchto dochází k řídovému zpomalení aplikací, danému režijí těchto frameworků.
Vliv komunikace s datastore na výkon
Kromě samotného jazyka ovlivňuje zásadním způsobem výkon i způsob komunikace s datastore. Obecně lze říci, že jazyk python je rychlejší než Java. V Jave se pak vhodnost způsobu komunikace liší dle typu operace.
Toto demonstruje obrázek (3), který zachycuje různé operace s entitou (přidání, modifikace, získání, smazání) realizované různými API.
Obrázek 3: Rychlost operací s datastore dle typu jazyka a API
Použití memcache
Zcela zásadní vliv má použití memcache. Zatímco odezvy datastore se pohybují v řádu desítek až stovek milisekund, použití memcache sníží odezvu o řád. Tedy na milisekundy nebo desítky milisekund.
Dostupnost
Po dobu provozu několika měsíců nedošlo k nedostupnosti aplikace, což je velmi potěšující. Jediné komplikace byly občasné problémy se deploymentem nových verzí.
Možné požití platformy v rámci architektury webové aplikace
Výše uvedené vlastnosti a omezení naznačují možnosti využití GAE pro vývoj webových aplikací. Typicky lze uvažovat o dvou scénářích:
- Samostatná webová aplikace – základní omezení GAE představuje ukládání dat výhradně do datastore a velmi slabé integrační možnosti. Velmi obtížně lze realizovat například napojení na backoffice systémy, importy z jiných zdrojů atd. Vhodným scénářem jsou tedy různé komunitní nebo agregační služby ukládající udržující data primárně v rámci aplikace.
- Jako doplněk aplikací provozovaných klasickým způsobem. Pokud máme aplikaci realizovanou aplikačním serverem může GAE hostovat některé doplňky, které nevyžadují náročnou aplikační logiku.
Klasickým příkladem je realizace distribuce statického obsahu, zajištění obsluhy různých volání typu AJAX (našeptávače apod.), nebo poskytování přesně definovaných zátěžových služeb typu transformace obrázků pro centrální aplikaci.
Ve výsledku pak lze uvažovat o robustních aplikacích obsluhujících různé požadavky různými způsoby. Jedno z možných členění požadavků na obsah uvádí následující tabulka.
| Typ požadavku | Příklad | Obsluha požadavku |
| Statický obsah | CSS, obrázky, ... | Rychlé HTTP servery (BOA, …), případně content delivery networks |
| Dynamické čistě prezentační | Změna stavů navigace, konfigurace zobrazení, dočasná data uživatele | Web prohlížeč nebo cloud a AJAX |
| Dynamické bez vazby na aplikační logiku | AJAX, filtrování dat, netransakční zápisy dat, …. | např. Google Application Engine |
| Dynamické s vazbou na business logiku | Zápisy objednávek, transakce, … | Aplikační server, třívrstvá architektura |
Závěr
Google nabízí v rámci Google Application Engine ucelené řešení pro vývoj a provoz webových aplikací, která poskytuje kombinaci aplikačního serveru a distribuovaného objektového úložiště.
Oproti konkurenčním řešením nutí vývojáře pracovat s přesně definovaným API a aplikace jsou tedy nepřenositelné do jiného prostředí. Výhodou tohoto přístupu však je plná transparentnost provozu a neomezené škálování. Vývojář však musí mít na paměti, že samotné škálování nezajistí rychlou odezvu. Tu je nutné zajistit vhodným použitím dostupných API
Uvedené prostředí lze využívat v rámci určitých výkonových kvót zdarma, což jej činní ideálním pro startupy orientované na webové projekty.
Literatura a odkazy
[CLOUD] Wikipedia : the free encyclopedia [online], dostupný z WWW: <http://en.wikipedia.org/wiki/Cloud_computing>
[GAE1] Google Application Engine documentation[online]: dostupný z WWW: <http://code.google.com/appengine/docs/>
[EC2] Amazon Elastic Cloud Computing [online]: dostupný z WWW: <http://aws.amazon.com/ec2>
[WSGI] WSEGI.ORG [online]: dostupný z WWW: <http://wsgi.org/wsgi/>
[JSP] Sun developer network [online], Oracle Inc. : dostupný z WWW: <http://java.sun.com/products/servlet/>
[JVMLIST] Diskusní skupina Google App Engine Java [online]: dostupný z WWW: <http://groups.google.com/group/google-appengine-java/web/will-it-play-in-app-engine>
[GAEBLOG] Blog Google App Engine[online], Google Inc.: dostupný z WWW: <http://googleappengine.blogspot.com/2010/03/read-consistency-deadlines-more-control.html>
[DIST] Damon Oehlman, Blog Distractable [online]: dostupný z WWW: <http://distractable.net/coding/google-appengine-java-vs-python-performance-comparison/>
pekne zhrnutie, diky
OdpovědětVymazat