Windows Azure lépésről lépésre, 9. fejezet – interjú és részlet

A tervek szerint március 12-én megjelenik a „Windows Azure lépésről lépésre”, az első magyar nyelvű szakkönyv a Microsoft felhőplatformjáról. Mostantól kezdve egészen a megjelenés napjáig minden munkanapon foglalkozunk a könyvvel: rövid interjúkat készítünk az egyes fejezetek szerzőivel, és egy-egy részletet is közzéteszünk a könyvből. Ezúttal ismét Király Istvánnal beszélgetünk munkájáról, az Azure-ral való kapcsolatáról és a könyvben vállalt szerepéről.Az előző bejegyzések:

Egy korábbi bejegyzésben már beszéltél magadról, a Windows Azure-hoz fűződő kapcsolatodról és a saját területeden jelentkező újdonságokról. Mit tudhat meg az általad írt fejezetből az olvasó?

Második fejezetem a Cloud Services címet viseli, és az Azure egyik legérdekesebb témakörébe enged betekintést. A könyv (és a blogbejegyzések) korábbi részében az olvasó megismerhette az Azure virtuális gépeket és a hozzájuk fűződő további szolgáltatásokat, amelyekkel a helyi adatközponthoz hasonló funkcionalitást lehet elérni a felhőben – csak persze a hardvert és az ezzel kapcsolatos nyűgöket a felhő intézi helyettünk.

A Cloud Services (az Azure Platform-as-a-Services szolgáltatások egyike) egy lépéssel továbbmegy. Nem csak a hardverüzemeltetés, de a szoftverüzemeltetés problémáinak nagy részét is leveszi a vállunkról.

Ehhez alkalmazásainkat a megfelelő formában kell elkészíteni (vagy meglévő alkalmazásunkat viszonylag kis munkával átalakítani). Az Azure pedig képes az ilyen alkalmazások számára szükséges virtuális gépeket teljesen önállóan feltelepíteni (méghozzá a kívánt darabszámban és méretben), a kész gépeket patchelni és hardver/szoftverhiba esetén újratelepíteni. Emellett egy ötletes technikával tudunk úgy alkalmazásverziókat váltani, hogy közben egy másodpercnyi kiesés sincs a szolgáltatásunkban, és (megfelelő előkészítés esetén) alkalmazásunk önskálázó is lehet: a terhelés függvényében önállóan módosíthatja saját példányszámát felfelé és lefelé.

A Cloud Services segítségével tehát némi előkészítéssel rengeteg munkát háríthatunk át a felhőre.

Fejezetemben a fentiek technikai hátterét és gyakorlati alkalmazását ismerheti meg az olvasó.

Részlet a 9. fejezetből:

Az Almabéka Kft. nyelvfüggetlen közösségi oldala

Hasonlítsunk össze a helyi infrastruktúra, az IaaS és a PaaS viselkedését egy – természetesen sarkalatos és leegyszerűsített – példán keresztül! Eközben megismerheted a PaaS alapfogalmait és IaaS-tól, illetve a helyi infrastruktúrától való alapvető eltéréseit.
Cégünk, az Almabéka Kft. új közösségi oldalt indít. Ez lesz a világ első nyelvfüggetlen közösségi oldala. A felhasználók videókat, képeket és egyéb adatokat tölthetnek fel, melyet közösségi oldalunk automatikusan lefordít a fordítómotorunk által támogatott összes nyelvre, így mindenki mindenkivel ismerkedhet majd nyelvi korlátok nélkül.

Vizsgáljuk meg ezt a történetet három lehetséges módon!

Helyi infrastruktúra

Derék fejlesztőcsapatunk megbecsüli a várható igényeket, tizenöt rendkívül erős szervert és különféle hálózati hardvereket vásárol, majd nekilát a fejlesztésnek. A szerverekre Windows Servert, SQL Servert, IIS-t, ASP.NET-et telepítenek, beállítják rajtuk a tűzfalat, tanúsítványokat vesznek.
Az első igazán stabil verzió elkészülésekor pezsgőt bontanak, telepítik az oldalt a szerverekre és meghirdetik a nyilvánosság felé. Hamarosan már tízezrek használják az oldalt.
Két héttel később egy hangos durranás hallatszik és egy rossz UPS miatt a szerverek harmadában kiégnek az alaplapok. Backup természetesen mindenről volt, így adatvesztés nincs, a csapat azonban két napig pánikban van, mire sikerül a megfelelő új szerverhardvert megrendelni, elszállítani, telepíteni és szolgálatba állítani.
Egy hónap múlva már akkora az igény az oldalra, hogy a szerverek mindegyike 90%-os terheltséggel fut. Nincs más hátra: újabb szervereket kell rendelni. A csapat ismét csak kénytelen a beszerzéshez fordulni, a rendszergazdák fél napot töltenek el minden újabb „vas” telepítésével és munkába állításával. Az ügyvezető eközben a fejét vakarja és az oldal exponenciális bővülését összeveti azzal az exponenciális mennyiségű szerverrel, amire szükség lesz.
Másfél hónap múlva eljön az első komoly verziófrissítés ideje. Harminc szervernél ez nem egyszerű! A csapatnak vagy le kell állítani az oldalt egy órára, vagy meg kell oldania, hogy a régi és az új verzió – amelyek között igen komoly eltérések vannak – egyszerre tudjon futni mindaddig, amíg minden szerveren sikerül elvégezni a verzióváltást. Mindenki éjszakázik, de végül megoldják a váltást.
Két hónap múlva itt az újabb hidegzuhany! A világ legnagyobb közösségi hálójának megtetszik az ötlet és előrukkol a saját hasonló szolgáltatásával. A látogatók hirtelen elmaradnak. A csapat próbálja felvenni a versenyt, az ügyvezető pedig farkasszemet nézhet a 30 teljesen fölöslegesen álldogáló, méregdrága szerverhardverrel.

Infrasturcture-as-a-Service, IAAS

A történet kezdete hasonló. A fejlesztőcsapat nekiugrik a fejlesztésnek, ám ezúttal Azure IaaS mellett döntenek. Induláskor egy szervert is elegendőnek látnak, mert tudják, hogy később bármikor létrehozhatnak újakat, a felhőben nem kell napokat várni a beszerzésre. Így aztán létrehoznak egyetlen virtuális gépet a felhőben, Windows Servert, SQL Servert, IIS-t, ASP.NET-et telepítenek, beállítják a tűzfalat, tanúsítványokat vesznek.
Megtörténik az oldal indulása.
Két héttel később egy hangos durranás hallatszik az Azure adatközpontban és egy rossz UPS miatt húsz szerverben, többek között a hőseink virtuális gépét kiszolgáló szerverben kiég az alaplap. Főszereplőink erről mit sem tudnak, mert néhány perc alatt az Azure másik fizikai hardverre mozgatja át virtuális gépüket, ami vidáman dolgozik tovább.
Egy hónap múlva az oldal 90%-ban terhelt és új gépeket kell beállítani. Ugyan a rendszergazdák továbbra is sokat dolgoznak az új gépek konfigurálásával, de már semmit nem kell venniük: árkatalógusok böngészése és autózás helyett a New Virtual Machine gombot nyomogatják. Ez sokkal kevesebb ideig tart.
Másfél hónap múlva verzióváltás. Sajnos csapatunk most sem ússza meg a komoly munkát: gépeik ugyan az Azure-ban futnak, de ettől még ők üzemeltetik őket, ezért most is mindenki éjszakázik, amíg minden gépre fel nem „csempészik” az új szoftververziót.
Két hónap múlva megérkezik a konkurencia. Visszaesés van a látogatószámban, de az ügyvezetőnek ez kevésbé esik rosszul, mint az előző esetben: nem áll pénz a saját szerverekben, a csapat egyszerűen letöröl pár fölöslegessé vált virtuális gépet, és így a látogatószámmal együtt a költségeik is visszaesnek, ezért az üzlet addig is jövedelmezően megy tovább, amíg a válaszlépésen gondolkoznak.

Platform-as-a-Service, PaaS

A fejlesztőcsapat elkészíti az alkalmazást, ám úgy gondolják, hogy egyáltalán nincs kedvük gépek telepítgetésével szórakozni. Ezért Azure PaaS-t használnak.
Egy Azure PaaS alkalmazás szerepkörökből (role) áll. Visual Studio és .NET esetén egy szerepkör – kevés kivétellel – egy Visual Studio projektnek felel meg. Egy szerepkörből, azaz Visual Studio projektből futási időben a felhőben egy vagy több virtuális gép lesz, ezeket az adott szerepkör példányainak (instance) hívjuk.
A Visual Studio projektek kódot tartalmaznak, és ezek mellett néhány XML fájl is van, amik leírják, hogy a szerepkörből készülő virtuális gép példányok hogyan nézzenek ki. Ezek az XML fájlok adják meg, hogy a virtuális gépek mérete mekkora legyen, milyen tűzfalportok legyenek rajtuk kinyitva, vannak-e speciális telepítési igények (pl. minden virtuális gép létrejöttekor fusson le egy szkriptfájl) és így tovább. Egy szerepkör tehát olyan, mint egy recept, vagy sablon virtuális gépekre.
Hőseink gyakorlott ASP.NET fejlesztők, és már félig készen van az alkalmazásuk, amikor az Azure PaaS mellett döntenek. Nem ijednek meg különösebben: félig már elkészült ASP.NET projektjüket egy kattintással szerepkörré, azon belül is webes szerepkörré (web role) alakítják, azaz melléteszik az Azure számára szükséges XML fájlokat. A kódhoz lényegében hozzá sem kell nyúlniuk. Mivel webes szerepkörről van szó, az Azure tudni fogja, hogy a kód alá a felhőben webszervereket kell tennie (azaz Windows Servert, IIS-t, ASP.NET-et kell telepítenie), az XML fájlokból pedig kiolvassa a csapat által kívánt tűzfalbeállításokat, tanúsítványokat és egyebeket.
Az alkalmazás fontos része a weboldal mellett a videók, képek lefordítását végző komoly üzleti logika is. Ezt a csapat korábban Windows szolgáltatásként (Windows Service) implementálta, és a webszerveren akarta futtatni. Ezt továbbra is megtehetnék (a webes szerepkörön belül megoldhatnák, hogy a létrejövő példányokra települjön fel a Windows szolgáltatásuk), de tudják, hogy ennél van elegánsabb megoldás is.
Korábbi projektjüket munkavégző szerepkörré (worker role) alakítják. Ez a másik fontos szerepkörtípus az Azure PaaS-ban. Egy munkavégző szerepkör példányain csak .NET Framework van (IIS és ASP.NET nincs), a gép indulásakor az Azure meghívja a szerepkörben lévő kód belépési pontját, és attól kezdve az a kód fut a gép működésének teljes ideje alatt. A munkavégző szerepkörök tehát általános célúak, a webes szerepkörök pedig kimondottan ASP.NET alkalmazásoknak lettek kitalálva.
Elindul az oldal. Az előző két esettől eltérően nincs telepítgetés: a vezető fejlesztő létrehoz az Azure-ban egy Cloud Service-t – ezzel lefoglal az alkalmazásnak egy DNS nevet –, majd a Visual Studio megfelelő menüjében lévő Publish opcióra kattint. A kód feltöltődik a Cloud Service-be, majd az Azure a két szerepkörből önállóan létrehozza a kívánt darabszámú és méretű szerverpéldányt. Ez kb. 20 percig tart, közben mindenki nézelődik és beszélget, mert a művelet során emberi beavatkozásra nincs szükség.
Két hét múlva hangos pukkanással kileheli a lelkét az egyik UPS az Azure adatközpontban, magával rántva a szerverek egy részét is. Ahogy az IaaS esetében, a csapat itt sem vesz észre semmit, az Azure automatikusan korrigálja a hibát.
Egy hónap múlva a szerverek 90%-os terheltségen futnak. A vezető fejlesztő ezt egy kávé mellett elújságolja az ügyvezetőnek, majd az Azure portálon egy csúszkát feljebb húzva megnöveli a gépek számát. Az Azure néhány perc alatt elvégez minden telepítési és konfigurációs feladatot.
Másfél hónap múlva verzióváltás. Az alkalmazás aktuális kódja a csapat Cloud Service-ének úgynevezett Production slotjában fut néhány szerverpéldányon, és a külvilág számára is látható. A vezető fejlesztő publikálja az alkalmazás új verzióját a Staging slotba, ami ugyanúgy a Cloud Service-en belül van, de tartalma nem látható a külvilág számára. A publikálást követően az Azure kb. 20 perc alatt önállóan létrehozza az új verzió számára szükséges szerverpéldányokat (így egy rövid ideig a régi verzióból és az új verzióból is vannak szerverpéldányok).
Mivel a telepítés automatikusan történik, a fejlesztők ezalatt élesítik tesztelő-eszközeiket, majd nyugodt körülmények között kitesztelik a Staging slotban lévő új verziót. Amikor elégedettek, a vezető fejlesztő megnyomja a Swap VIP gombot, erre a Production és a Staging slotban lévő szerverek kb. harminc másodperc alatt megcserélődnek – és hirtelen, mindenféle szolgáltatáskiesés nélkül már az új verzió érhető el a külvilág számára. A vezető fejlesztő egy-két óráig fennhagyja a régi gépeket, hátha valami hiba miatt vissza kell állni a régi verzióra (nem aggódik, mert jól tudja, hogy a Swap VIP gombot ismét megnyomva ez újabb fél perc alatt végbemegy), végül letörli őket és a többiekkel együtt időben hazamegy.
Két hónap múlva megérkezik a konkurencia. Ahogy az IaaS esetében, így itt sem aggódik az ügyvezető, mert nem állnak milliók a szerverekben. A csapat egyszerűen lejjebb veszi a futó gépek számát, ezzel azonnal lecsökkennek a költségeik is, és megfontoltan készülnek a válaszlépésre.

Kellemes hétvégét mindenkinek, hétfőn a 10. fejezettel folytatjuk!

10 thoughts on “Windows Azure lépésről lépésre, 9. fejezet – interjú és részlet

  1. Visszajelzés: Windows Azure lépésről lépésre, 10. fejezet – interjú és részlet | Felhők között

  2. Visszajelzés: Windows Azure lépésről lépésre, 10. fejezet – interjú és részlet - A magyar Windows Azure közösség blogja - devPortal

  3. Visszajelzés: Windows Azure lépésről lépésre, 11. fejezet – interjú és részlet | Felhők között

  4. Visszajelzés: Windows Azure lépésről lépésre, 12. fejezet – interjú és részlet | Felhők között

  5. Visszajelzés: Windows Azure lépésről lépésre, 12. fejezet – interjú és részlet - A magyar Windows Azure közösség blogja - devPortal

  6. Visszajelzés: Windows Azure lépésről lépésre, 13. fejezet – interjú és részlet | Felhők között

  7. Visszajelzés: Windows Azure lépésről lépésre, 14. fejezet – interjú és részlet | Felhők között

  8. Visszajelzés: Windows Azure lépésről lépésre, 15. fejezet – interjú és részlet | Felhők között

  9. Visszajelzés: Windows Azure lépésről lépésre, 16-17. fejezet – interjú és részlet | Felhők között

  10. Visszajelzés: Windows Azure lépésről lépésre, 17. fejezet – interjú és részlet | Felhők között

Vélemény, hozzászólás?

Adatok megadása vagy bejelentkezés valamelyik ikonnal:

WordPress.com Logo

Hozzászólhat a WordPress.com felhasználói fiók használatával. Kilépés / Módosítás )

Twitter kép

Hozzászólhat a Twitter felhasználói fiók használatával. Kilépés / Módosítás )

Facebook kép

Hozzászólhat a Facebook felhasználói fiók használatával. Kilépés / Módosítás )

Google+ kép

Hozzászólhat a Google+ felhasználói fiók használatával. Kilépés / Módosítás )

Kapcsolódás: %s