Adott a következő helyzet:
Van egy kis ‘számítástechnikai kereskedésünk, és mivel nagyon-nagyon 21. századi módon szervezzük a cégünket, szükségünk van egy komoly kereskedelmi rendszerre, amit megtámadunk több oldalról:
- Back-Office kereskedelmi-, számlázó-, CRM-, stb.-rendszer
- Kiosk kliens, amit a boltba betérő ügyfelek ‘simogatnak Windows7-es multi-touchos kijelzőn az üzlettérben 🙂
- és a lényeg: egy webshop ASP.Net + Silverlight 4.0
Rendszerünket a 18. Programozó és Bélyeggyüjtő Közhasznú Kft, átadja, majd 1-2 hónapig tökéletesen működik a “2-3” rétegű architektúra… És mivel az üzleti modellünkben nincs hiba, és gondolván a magyarul nem beszélő világpolgárokra akik tőlünk szeretnének vásárolni, már előre lokalizált az alkalmazásunk, így egyszer csak betámad minket a világ!!!
Az elején persze örülünk, dől a zsé. Aztán az oldal elkezd haldokolni. Winchesterek pörögnek, processzorok izzadnak… nincs mit tenni megtámogatjuk egy-két giga rammal a gépet, dobunk bele még egy procit… Kitart legalább egy hétig.
Ekkor megszületik a döntés még egy gép kell!!! SQL server szedi a sátorfáját és elköltözik másik gépre… huh. probléma megoldva. egy hétre.
’szerencsére sql programozó kolléga munkájában nincs kivetnivaló, az SQL adatbázis sem túl bonyolult (Customers-ProductCategories-Products-ProductPhotos-Inventories-OrderDetails-Orders sémánál megáll), termékből sincs sok, így egy kis performance analízis után azonnal látszik hogy a WEB-SERVER a ludas a sok lekérés miatt, no meg a képek!!!! mindeki látni akarja mit vesz meg!!! oldalról, elölről, kicsiben, hd-ben… Így készül egy cluster, loadbalancing… minden ami kell.
Eldöcög.jólesz.
Aztán persze ügyes programozó készít egy túlt, amivel Excel táblából importálni lehet termékeket a rendszerbe, és hirtelen lesz 1000 termék helyett 100.000, a hozzá tartozó képekkel, leírásokkal és még 100.000 elégedett vásárlóval, az akciókról nem is beszélve… SQL szerver ugyan nem száll el exponenciálisan ( bírná a terhelést ha 22Ghz-es lenne 30Gb cache-el, tehát skálázható elméletben,de akkor is…), de képtelen feldolgozni a sokszoros kérést….
Nincs más hátra mint architektúrális (ÁT)tervezés!!! (Vagy persze bele lehet ölni végtelen mennyiségű jó kemény magyar forintot több és több vasba, aminek csak az áramszámlája elviszi a hasznot)
Szakértőnk elemezvén a helyzetet arra a megállapításra jut, hogy az architektúra annyira nem feltétlen rossz, csak egy kis furfang kellene, mert tulajdonképpen az idő(erőforrások) nagy részét a termékek leírásának/adatlapjának az előkeresése, ill. a képek kiszolgálása viszi el. Továbbá erőforrás igényes és körülményes a raktárkészlet információk kezelése a megrendelések szempontjából. Egy termékből nem azt tartjuk nyilván hogy 5 darab, mert akkor csak azt kell figyelni hogy nagativba ne menjen a készlet, hanem minden egyes darab egy sort jelent egy táblában (az egyszerűség kedvéért tekintsük úgy hogy minden számítástechnikai termék egyedi azonosítóval rendelkezik. tehát nem csak a processzor, winchester, alaplap,stb. hanem minden…) (Ha ebbe nehéz belegondolni, akkor hozhatjuk példának a jegyásursítást. Ha helyre szóló jegyek vannak akkor egy jegyet pontosan egyszer lehet eladni.) Vagyis egyedi erőforrásként kell(ene) kezelni. Ez megnehezíti egy csöppet a helyzetünket (a cache-elése az ilyen adatoknak kihívás!!!).
Probléma még, mivel júzerikszperienből nem adunk alább, a session jellegű adatok megfelelő kezelése:
web-farm esetében A szerverren bejelentkezik Béla, majd a load-balancer valami miatt, pl A szerver hősi halála okán, B szerverre küldi a következő kérést… ekkor ugye érheti meglepetés Bélát…
(ugye ismerős? találkozhatunk hasonlóval, lehet ez webshop, közösségi oldal, valamilyen hullámzó terheltségű oldal, pl. egy foci-bajnoskság, póker-bajnokság oldal, stb.)
Szakértőnk elmélázik, hogy hogy is lehetne megoldani a helyzetet, és arra a nem meglepő következtetésre jut hogy bizony ide olyan gyorsítótár szolgáltatás kellene, mely nem bonyolítja túl az architektúrát, megfelelően kihasználja az erőforrásokat annak érdekénen hogy tehermentesítse az SQL szervert (amit ugye nehéz egy bizonyos szint főlé skálázni), villámsebesen kiszolgálja az alkalmazás motor által kért kéréseket, mindezt persze úgy hogy választ ad a fent részletezett problémákra, és teszi ezt programozó barát módon ( na jó, rendszergazda és programozó módon).
Szakértőnk nekikát és felvési az igényeket, hogy házalni tudjon vele, azon meggyőződéssel hogy ő márpedig ebből nem enged!!!
- kell egy bármilyen (értsd CLR, bináris, XML, szöveges, stb.) adatok cache-elését támogató memoria cache
(memória olcsó, relatíve olcsón hozzá lehet jutni akár terrabyte-okhoz is) - elosztott legyen, azaz tetszőleges számú gép lehessen a fürtben, így tetszőleges lehet a cache méret is->skálázhatóság
(Akár menet közben is közel online módon, pl. ideiglenesen megnövekvő forgalom esetén->akció,választás,stb.) - a programozónak ne kelljen az eloszottsággal törődnie, azaz fentről nézve egységes legyen.
- katalógus adatokat kezelje villámsebesen a lehető legnagyobb sebességgel
- a session adatokat kezelje megbízhatóan, a lehető leggyorsabban
- az erőforrás adatok kezelése megoldott legyen (ne lehessen eladni ugyan azt a terméket, lsd. fent)
- biztonságos legyen
- programozó barát legyen
- rendszergazda barát legyen (üzemeltetése a megszokott módon a megszokott lehetőségeket biztosítsa)
- ingyenes legyen 😀
Nos… azért ezt nem programozzuk le jövő hétre, ugye?!? Szerencsére nem is kell!!!
Windows Server AppFabric (született Velocity, Microsoft Distributed Cache)
(nincs köze az Azure AppFabric-hez, lsd névkommandós bejegyzés)
A Windows Server AppFabric cache szolgáltatása képes kezelni a fent vázolt helyzetet. Úgy gondolom hogy akkor is érdemes ezt az oldalát is ismerni az AppFabric-nek (nem csak a WCF+WF-t) és a .Net 4.0-nak, ha éppen nem olyan rendszer bütykölünk a garázsban ami 1.000.000 usert szolgál ki terrabyte-os adatbázisok felett. Ugyanis sose tudhatjuk hogy mikor válik ilyenné a rendszerünk :D, másrészről pedig nem feltétlen kell itt 10-20 gépes cache rétegekre godnolni, kis méretekben is hasznos tud lenni!!!
És miért is AppFabric? Beszéljenek a számok:
(ez egy quad gép, de kb 2008-ból)
Ezért tervezem hogy a következőkben megismerkedünk az AppFabric Cache hátterével (architektúra, mit tud, hogyan tudja, hogyan kell programozni), és különböző esetek segítésével megnézzük a teljesítményeket…
Összefoglalás
E sarkított bevezető után kitérünk egy ilyen cache rendszer sajátosságaira, és kirészletezzük a “specifikációban” megfogalmazott elvárásokat ill. következményeit. Vagyis szó lesz arról hogy hogyan kategorizáljuk a cache-elendő adatokat, hogy a kívánt célt érjük el (Katalógus adat->írtó gyors legyen, nagy áteresztő képességgel; Session adat->biztosított legyen, pl. HW hiba esetén; Katalógus adat-> zárolások).
Miután áttekintettük az elméletet megismerkedünk az API-val, vagyis hogyan programozzuk a kicsikét, ill. hogyan illeszthető mindez egy (meglévő) architektúrába…
S végül a legfontosabb, ha sikerül összehozni egy 5-10 gépes játékteret, performancia teszt alá vetünk egy-két állatorvosi-lovat és ASP.Net weboldalt, eljátszva az összes szituációt (kihuzza a takarítónő a szervert, hogy mögötte is feltakarítson, akciót hirdetünk 1 napra és felmegy a terhelés 3-5X-re).
És hogy addig se unatkozzunk, ajánlom figyelmébe mindenkinek a lenti linkek mögötti tartalmat, továbbá Tóth László (Tocsi) barátom előadását a Visual Studio 2010 bemutató eseményen.
Információk a Windows Server App Fabric Cache-ről:
- Esettanulmány :
- MSDN : http://msdn.microsoft.com/en-us/windowsserver/ee695849.aspx
- MIX 2010 : Designing and Delivering Scalable and Resilient Web Services
- PDC 2009 : http://microsoftpdc.com/Sessions/FT26
- MIX 2009 : http://videos.visitmix.com/MIX09/T59f
- PDC 2008 http://channel9.msdn.com/pdc2008/TL56/
http://channel9.msdn.com/pdc2008/TL14/
(Javaslom hogy a fenti listán idősorrendben menjünk, ugyan a 2008-as PDC előadás környékén még csak CTPx volt, de nagyon-nagyon hasznos infók hangzanak el az egész KONCEPCIÓVAL kapcsolatban, nem túl célravezető a végén kezdeni)
Bátyai Krisztián[KRis] 