Cloud - un alt buzz word pe care îl auzim aproape în fiecare zi. În momentul de faţă există mai mulţi provideri care oferă acest serviciu: Amazon, Microsoft (Windows Azure), Google, Rackspace.
Când ne gândim la cloud ce ne vine în minte? Una, două sau mai multe instanţe pe care le ţinem într-un cloud, iar când avem nevoie de mai multe resurse putem să creştem foarte uşor numărul de instanţe.
În momentul de faţă un provider de cloud precum Microsoft ne oferă mult mai multe puncte de scalabilitate. În cadrul acestui articol vom vedea prin ce alte moduri putem să creăm o aplicaţie pentru cloud care să fie scalabilă şi să folosească serviciile pe care Windows Azure le pune la dispoziţie.
Să ne imaginăm că avem o aplicaţie web care conţine foarte mult conţinut static. Prin conţinut static înțelegem orice conţinut precum imagini, CSS, HTML care nu se schimbă în fiecare secundă (la fiecare request în parte). În mod normal în momentul în care observăm că încărcarea pe maşinile noastre este mare vom încerca să creştem numărul de instanţe. Acest lucru poate să fie o soluţie la problema noastră, dar din punct de vedere a costurilor s-ar putea să nu fie cea mai bună.
Chiar dacă vom încerca să facem cache la conţinut pe server (prin IIS sau alte metode), toate request-urile vor ajunge până la maşinile noastre. Din această cauză pentru fiecare request acestea o să fie nevoite să răspundă, consumând resursele pe care le avem la dispoziţie.
În acest caz o soluţie pentru problema noastră poate să fie folosirea unor Content Delivery Network (CDN). Prin intermediul acestui serviciu conţinutul static poate să fie cache-uit pe diferite CDN-uri în funcţie de locaţia fizică a clientului. Toate cererile pentru conţinutul static o să fie rezolvate de către CDN-uri. În mod normal un CDN poate să se ocupe doar de conţinutul static, dar noile versiuni de CDN-uri suportă şi conţinutul dinamic. Acest serviciu este oferit şi de către Windows Azure şi poate să fie integrat cu uşurinţă în aplicaţiile noastre.
Prin folosirea unui mecanism de livrare a conţinutului precum acesta, maşinile care găzduiesc aplicaţia noastă nu vor mai fi lovite la fiecare cerere a unei resurse. În mod automat nivelul de încărcare a acestora va scadea destul de mult.
Următorul loc în aplicaţie unde putem să introducem foarte uşor un punct de scalabilitate este cache-ul. Ca să evităm să facem nenumărate request-uri la diferite servicii externe sau să recalculăm diferiţi parametri, putem să folosim un mecanism de caching.
Windows Azure oferă acest serviciu în diferite moduri. Avantajul folosirii unui serviciu pentru a face cache la date este în momentul în care avem nevoie să scalăm mecanismul de cache nu trebuie să ne punem problema de achiziţionarea unei maşini, a licenţelor şi sincronizarea acestor noduri.
În prezent, când creăm o maşină în Windows Azure putem să specificăm câtă memorie RAM să fie alocată pentru cache. Un alt sistem de caching este prin crearea unor maşini dedicate pentru acest lucru, în care toată memoria RAM va fi alocată pentru caching. În ambele variante, sincronizarea datelor dintre două sau mai multe instanţe de cache este suportată nativ. Aceste setări se pot face înainte să facem deploy la soluţie.
A treia variantă de caching pe care o avem la dispoziţie este prin folosirea unui serviciu dedicat de cache. În acest caz, noi nu trebuie să ne ocupăm deloc de instanţe, această resursă fiind văzută în întregime ca un serviciu.
Folosirea unui mecanism de caching de acest gen ne ia de pe umeri probleme pe care ni le poate pune un mecanism de caching clasic. Probleme precum sincronizarea sau adăugarea unui nou nod de cache dispar în totalitate.
Până acuma am analizat două probleme clasice care apar în orice aplicaţie web. Dar ce putem face dacă este nevoie să facem stream video. După cum toţii ştim, acest lucru este extrem de costisitor nu doar din punct de vedere a resurselor consumate pe partea de server cât şi a bandei de internet.
În mod normal putem să ajungem să avem maşini dedicate care să se ocupe de streaming video. Iar momentele în care avem foarte mulţi clienţi activi pot să ne pună probleme destul de mari. Pentru aceste cazuri Windows Azure ne vine în ajutor cu un serviciu dedicat pentru acest lucru. Windows Azure Media Services se ocupă în totalitate de streaming-ul video. Începând de la partea de encoding, ajungând la encriptare şi livrare a conţinutului (offline şi online).
Acest serviciu eliberează în totalitate instanţele noastre, care ar fi trebuit să se ocupe de procesarea şi livrarea acestuia. Fiind un serviciu dedicat pentru acest lucru, scalabilitatea ne este asigurată din start.
Momentan am văzut trei locuri diferite unde putem să scalăm folosind diferite servicii în cloud fără să fie nevoie să multiplicăm numărul de instanţe a aplicaţiei. În funcţie de tipul de aplicaţie, s-ar putea să expunem diferite servicii web care colectează diferite informaţii de la client.
Ce putem să facem dacă există momente când există un număr prea mare de clienţi care doresc să se conecteze la noi? În mod normal am încerca să alocăm un număr mai mare de instanţe care să se ocupe de acest lucru.
O soluţie pe care Windows Azure ne-o oferă este Service Bus Relay. Prin intermediul acestui serviciu putem să expunem orice serviciu web de tip "fire and forget". Toate cererile o să fie stocate sub forma unei cozi de mesaje, iar serviciul nostru o să le poate procesa pe rând. Chiar dacă numărul de cereri creşte extrem de mult, serviciul pe care îl avem expus la clienţi o să fie mereu disponibil.
Windows Azure Service Bus Relay poate să fie integrat cu uşurinţă în aplicaţia noastră. Singura modificare de care este nevoie într-o aplicaţie care foloseşte WCF este modificarea fişierului de configurare.
În general când avem o aplicaţie complexă, vom avea diferite tipuri de maşini pe care vor rula componente ale aplicaţiei noastre. Va fi necesar să asigurăm între aceste instanţe un mod de comunicare persistent şi independent de fiecare instanţă în parte.
Putem să încercăm să implementăm un sistem de comunicare prin intermediul unei baze de date sau prin intermediul altei instanţe care să se ocupe doar de acest lucru. În momentul în care este nevoie să scalăm, ar fi necesar să ne gândim cum putem să rezolvăm probleme precum sincronizarea instanţelor.
Windows Azure ne vine în ajutor, punând la dispoziţie diferite moduri de trimitere de mesaje. Toate aceste servicii sunt accesate pe baza unui URL şi pot să fie accesate din orice locaţie de pe internet.
Cel mai de bază serviciu, dar care are şi cele mai mici costuri este Windows Azure Queues. Acestă coadă de mesaje ne permite să distribuim mesajele într-un mod foarte simplu, rapid şi ieftin. Dacă este necesar să putem distribui mesajele la mai mulţi consumatori, să avem suport de death-letters sau să putem garanta ordinea mesajelor atunci când lucrăm cu Windows Azure Service Bus Queues şi Windows Azure Service Bus Topics.
O aplicaţie client-server poate să însemne un schimb permanent de date. De foarte multe ori acest lucru înseamnă expunerea de diferite servicii web prin care clienţii noştri pot să execute query-uri peste o bază de date. În aceste cazuri aplicaţia noastră va trebui să conţină instanţe care expun acest serviciu şi o bază de date (relaţională sau non-relaţională). Pe lângă că este nevoie să ţinem aceste instanţe va fi nevoie să ne ocupăm şi de mentenanţa acestor servicii web.
În astfel de cazuri ne putem imagina într-un alt mod sistemul nostru. Putem să stocăm şi să expunem datele pe care le avem prin intermediul Windows Azure Table Storage Service. Aceste tabele non-relaţionale ne permit să stocăm sute de giga de conţinut fără nici un fel de probleme.
Când dorim să folosim o astfel de soluţie ne pot apărea în minte două probleme: ce informaţie poate să acceseze fiecare client şi audit. Prin intermediul unor token-uri pe care le putem genera pentru fiecare client în parte putem să definim la ce conţinut are clientul acces, ce fel de operaţii poate să execute şi cât timp un token este valabil. Acestă funcţionalitate poartă numele de Shared Access Signature şi ne permite să eliminăm din ecuaţie instanţele care trebuie să ofere date clienţilor. Aceste tabele nu trebuie să reprezinte modul în care stocăm noi datele intern, ci datele pe care noi dorim să le oferim clienţilor noştri.
Windows Azure Storage Service suportă în mod nativ audit-ul. Tot ce este necesar este să îl activăm şi să specificăm la ce fel de operaţii dorim să facem audit.
Folosind o astel de soluţie va fi necesar să avem o componentă care se ocupă de generarea şi managmentul acestor token-uri. Nu mai avem nevoie de alte componenete.
Am analizat diferite modalităţi prin care putem să facem aplicaţia noastră scalabilă. Începând de la diferite sisteme de cache sau de trimitere de mesaje, la servicii care ne permit să facem stream video fară să ne punem problema de alocare de resurse sau de securitate.
Cel mai important lucru pe care trebuie să îl facem când începem să ne gândim la o aplicaţie în cloud este să încercăm să identificăm toate punctele în care putem să scalăm şi să căutam servicii care ne pot oferi acest lucru. În cazul în care diferite funcţionalităţi de care avem nevoie nu le putem găsi deja pe cloud atunci este bine să încercăm să le separăm pe instanţe diferite sau cel puţin pe diferite procese. Astfel încât dacă este nevoie să scalăm, să ne fie mai uşor să creştem numărul de instanţe care se ocupă de o anumită funcţionalitate.
În ziua de azi o soluţie cloud înseamnă mai mult decât mai multe maşini pe care rulează aplicaţia noastră împreună cu un load balancer - scalabilitate pe orizontală. Cloud înseamnă o multitudine de servicii care vin în ajutorul nostru pentru a putea crea aplicaţii mai complexe şi care să scaleze acolo unde avem nevoie.
de Dan Suciu
