Rendszermodellezs ttekints Kapacitstervezsi metodika Budapesti Mszaki s Gazdasgtudomnyi

Rendszermodellezés Áttekintés: Kapacitástervezési metodika Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék

Tartalom

Kapacitástervezés § „Annak becslése, hogy a rendszer mikor telítődik a terhelés hatására” § „A leginkább költséghatékony módszer megtalálása, mellyel a rendszer túlterhelése a lehető legjobban késleltethető” § Figyelembe veszi a nyújtani kívánt szolgáltatás szintjét

A mennyiségi analízis lépései

Mitől függ az elvárt kapacitás? § Service Level Agreement (SLA): o A vezetés által meghatározott mérőszámok (válaszidő, elérhetőség, átbocsátóképesség) § Használt technológiák, szabványok § Pénzügyi lehetőségek § Kapacitástervezés: o kvantitatív szemlélet o cél: ne kelljen túl sűrűn változtatni a rendszeren

Mitől nőhet a terhelés? § A rendszer változatlan, nő az átlagos terhelés o pl. eddigi 10000 helyett 15000 látogató § Új alkalmazások/szolgáltatások o pl. szemelvények a könyvekből § Változik a felhasználók viselkedése o hirtelen változás az informatikai rendszeren kívül (pl. hirdetési kampány, 9. 11. ) o navigációs minták változnak (többen keresnek)

Üzleti szintű leírás lépései Üzleti folyamat leírása Üzletmenet változás terv Funkciók (működés) változásának terve Üzleti folyamat modell Funkcionális analízis Funkcionális modell

Üzleti folyamat leírása § Példa folyamat: o online könyvkereskedés § Folyamat típusa o pl. B 2 C áruház, C 2 C aukció, B 2 C szolgáltatás o itt: B 2 C áruház § Kiszállítás módja o azonnal letölthető (pl. cikk) o periodikusan küldik (upgrade) o fizikai kiszállítás o itt: fizikai áruküldés

Üzleti folyamat leírása § Külső szolgáltatások o hirdetés o fizetés külső szolgáltatás segítségével o itt: más cégek honlapjai (banner) § Mennyiségi leírás o hány könyv van a rendszerben, most: 4000, cél : 10000 o milyen árkategóriából mennyit akarunk eladni o vásárlási minta (milyen időszakban milyen valószínűséggel érkeznek bizonyos kérések) o egyéb eddigi statisztikák o készletek

Online könyvesbolt vásárlási mintája

Zipf törvénye § p (popularity ): o szöveg „rangja” (csökkenő sorrendben) § f (frequency): o gyakoriság § § Web dokumentumokra: P: hivatkozások (elérések) r: rang (1 = leggyakoribb) k: pozitív konstans

Zipf törvénye (példa)

Üzleti folyamat leírása § Nyitvatartás o lehet adott időszak (H-P/9 -17) o lehet állandó (7*24) § Piac meghatározása o földrajzilag pl. 85 % USA - letöltések miatt is érdekes § A leírás eredménye az üzleti (folyamat) modell - business modell

Funkcionális analízis § A leírás eredménye a funkcionális modell lesz § Milyen szolgáltatások (funkciók) valósítják meg a folyamatot? o A Web oldal (portál) funkciói ~ az oldalak/menüpontok o Pl. Könyv kiválasztása, Személyes adatok bevitele, Rendelés lemondása, stb. § Hogyan jellemezhetők ezek a funkciók? § Interakciós modell o hogyan kommunikál a felhasználó a folyamattal (hogyan éri el az adott szolgáltatást az oldalon belül) o pl. kell X darab HTML form

Felhasználói szint Felhasználó viselkedésének modellezése CBMG megalkotása Statikus: oldalak szerkezet alapján HTTP logok alapján Hasonló viselkedésű felhasználók csoportosítása § Hogyan változik a modell az új funkciók bevezetése után? § § § o Pl. a Home oldalról egyenesen mehet a Felolvasáshoz?

Felhasználói, terhelés és erőforrás modellek § Felhasználói modell o navigációs minták: felhasználhatók a későbbi terhelés előrejelzéséhez (mi történik, ha hirtelen több felhasználó jelenik meg, többet keresnek, stb. ) o eszköz: Customer Behavior Model Graph (CBMG) , Customer Behavior Model Statechart (CBMS) o terhelési paraméterek meghatározása: ha csak a jelenlegi terhelési modell felírása a cél, elég egy kevésbé részletes felírás o eszköz: Customer Visit Model (CVM), kevésbé részletes, nem használható előrejelzésre o mindig egy session-t vizsgálunk (azonos felhasználótól egy látogatás alatt érkezett kérések sorozata )

Felhasználói modell – CBMG § Irányított gráf az oldalak közti lehetséges átmenetek és valószínűségeik ábrázolására § n csúcs, ahol o 1. csúcs: Entry állapot, absztrakt belépési pont, minden felhasználó innen indul ide nem tér vissza o n. csúcs: Exit állapot, absztrakt kilépési pont, a folyamat vége (nem mindig ábrázoljuk) o a többi csúcs megfelel a felhasználó által elérhető szolgáltatásoknak (oldalaknak) Üzleti modell Funkcionális modell Felhasználói modell § élek: az oldalak szerkezete határozza meg a csúcsok közt lehetséges átmeneteket Erőforrás modell

CBMG meghatározása § Statikus CBMG: oldalak és köztük lévő lehetséges átmenetek o az oldalak által nyújott szolgáltatások meghatározása • (pl. Login, Register, Add Item, Remove Item, Pay, Get Quotes, Download, Subscribe, stb. ) o a szolgáltatások halmazának finomítása – az infrastruktúrát különböző mértékben terhelő szolgáltatásokra • (pl. Download szétválasztása Download Audio, Download Video szolgáltatásokra) o lehetséges átmenetek meghatározása – az oldalak megjelenítésének vizsgálatával • (linkek, formok, menüpontok, stb. )

Felhasználói modell: CBMS § Customer Behavior Model Statechart § UML állapotdiagram § Hasonló információt hordoz, mint CBMG, de mindezt szabványos módon jeleníti meg § Állapotok: az oldal funkciói (állapotai) § Lehetséges átmenetek: rendszer modellje alapján § Átmenetekhez valószínűség tartozik (dinamikus viselkedés) o meghatározás: „Terhelés” ea.

Felhasználói viselkedés állapotdiagram modellje

Felhasználói viselkedés vizsgálata § Dinamikus CBMG ill. CBMS alapján különböző mérőszámokat határozhatunk meg: o o Hits/sec: az oldalról letöltött objektumok száma (képek, bannerek is) Page View/Day: adott oldalt hányszor nézték meg Click-throughs: hányan néztek meg egy adott hirdetést Unique Visitors: hány különböző látogató volt egy adott időszakban

Felhasználói viselkedés vizsgálata § További mérőszámok (felhasználói modell és egyéb statisztikák alapján): o Revenue Throughput: az oldal által elért átlagos bevétel o Potential Loss Throughput: mennyibe kerül a szolgáltatás kiesése egy adott időszakban o Visit Ratio: átlagosan hányszor vesznek igénybe egy adott szolgáltatást (egy session alatt) o Buy to Visit Ratio: átlagosan hányszor vásárolnak egy session alatt (tényleges eladási tanzakció) o Average Session Length: egy session átlagosan hány szolgáltatást vesz igénybe (nem időt mér) o mindezen mérőszámok változása, ha a bemenő paraméterek megváltoznak (pl. egyes átmenetek valószínűségei)

Felhasználói viselkedés vizsgálata § Az előbbi példából kinyerhető adatok : o Buy to Visit Ratio (BV): Pay állapot előfordulásának várható értéke, k [ P(i, j)] az összes lehetséges Entry-Pay útra (k darab), BV értéke itt 0. 058 (5. 8 %) o Végrehajtott eladási tranzakciók száma: ha naponta 100000 látogató (session) van, akkor átlagosan 100000*0. 058=5800 o Átlagos session hossz (average session length): az állapotok átlagos előfordulásainak összege, itt. 7. 998 (Exit és Entry állapotok előfordulási gyakorisága mindig 1, itt nem számítanak) o mindezen adatok kiszámolhatóak más átmeneti valószínűségek esetén is (pl. ha megnő a keresés után vásárlók száma)

Customer Visit Model (CVM) § CVM: különböző típusú felhasználók viselkedését jellemző vektorok (melyik állapotban hányszor járt) § A felhasználók csoportosítása cluster technikákkal történik, ld. „Terhelés” ea. § Nem jelzi az egyes állapotok közti átmenetek gyakoriságát, kevésbé alkalmazható előrejelzésre

Session azonosítás § Cookie-k használatával o szerver generál egy ID-t, amit a kliens minden kéréssel elküld, az kliens mellett az alkalmazás állapotát is tárolhatja (pl. bevásárlókocsi) § Autentikációs mechanizmusok, rejtett mezők HTML oldalak formjaiban, dinamikus URL-ek, stb. § Szerver logok alapján, várakozási küszöbérték (threshold) használatával o ha ennél hosszabb a szünet kérés (request) elküldése közt, akkor két külön session

C/S Interaction Sequence Diagram (CSISD) § Szekvenciadiagramok minden lehetséges esetre § Objektumok: kliens és a különböző szerverek (erőforrások) § Nyilak: üzenetküldés § Üzenetek: [p, m] párok, ahol p az üzenet küldésének valószínűsége, m a mérete (byte) o pl. [0. 05, reject_message]: 5% valószínűséggel reject_message méretű üzenetet küldünk § Minden lehetséges végrehajtási szekvencia kliensből indul ki és kliensben végződik § CSID: C/S Interaction Diagram o a szekvenciák összessége

CSISD példa 1. § Kliens kér valamilyen adatot a Web szervertől, 3 lefutási lehetőség § 1. eset: A Web szerver túlterhelt: elutasítja a kérést Kliens Web szerver [1. 0, request_message] [0. 05, reject_message]

CSID példa 2. § 2. eset: A Web szerver továbbküldi a kérést valamilyen alkalmazásnak (alk. szerver), az alkalmazás cache-ből visszaadja az adatot Kliens Web szerver Alkalmazás szerver [1, request_message] [0. 95, request_data] [0. 2, return_data] [1. 0, reply_message]

CSID példa 3. § 3. eset: A Web szerver továbbküldi a kérést, az alkalmazás lekérdezést hajt végre az adatbázisszerveren, majd visszaadja az adatot Kliens Web szerver Alkalmazás szerver Adatbázis szerver [1, request_message] [0. 95, request_data] [0. 8, query_message] [1. 0, query_answer] [1. 0, return_data] [1. 0, reply_message]

CSISD elemzése § mennyi a lokális hálózat forgalma, ha minden szerver ugyanazon a LAN-on van? (p*m) minden szerverek közti üzenetre § Mi történik, ha a Web szervert leválasztjuk? o (Web szerver: LAN 1, többi LAN 2) o (Szerver oldali) hálózati késleltetés meghatározása sávszélesség és üzenetméret alapján § Milyen lesz a teljesítmény, ha minden szerver ugyanazon a gépen fut?

Funkcionális analízis § Felhasznált web technológiák o pl. Active. X control, Java applet, stb. § Autentikáció o használ-e autentikációs protokollt o ha igen, milyet, pl. SSL § Példa: Személyes adatok bevitele o egy HTML formon keresztül történik o a felhasznált technológia HTMl és CGI o autentikáció: SSL § A kapott információk hasznosak a Client/Server Interaction Diagram felírásához

Üzletmenet változásának vizsgálata § Az üzletmenet (üzleti folyamat) várható (tervezett) változásai § Új adatbázist építünk be a rendszerbe o árjegyzék használt könyvekre o új alkalmazás kell ennek eléréshez o megnő a terhelés § Portált építünk (további szolgáltatások) § Erős marketing kampány indul o meg kell növelni a kapacitást, különben az oldal lassú lesz és az eddig vásárlók is elpártolnak o 3 terv a hatásra: optimista, realista, pesszimista

A funkciók változásának vizsgálata § Az előbb vizsgált változások hatásai a funkcionális modell szintjén o nincs mindig funkcionális szintű változás, pl. ha a rendszerben elérhető kereskedők száma nő, attól nem változik a modell § Példa: Multimédiás bővítés o új funkció: Részletek a könyvből (felolvasás); egy HTML form a felhasználói interakcióhoz, a használt technológia HTML és Quicktime, nincs autentikáció

Erőforrás szintű kapacitástervezés lépései

Erőforrás szint § Felhasznált IT erőforrások konkrét meghatározása az előző modellek alapján § Informatikai környezet meghatározása o infrastruktúra és o terhelés leírása o e-business funkciókhoz tartozó programok meghatározása § Infrastruktúra: o hardver (szerver gépek, diszk farmok, routerek, tűzfalak. . . ) o szerverek (Web ~, alkalmazás ~, adatbázis ~, DNS. . . ) o szoftverek (OS, middleware, adatbáziskezelő. . . ) o Hálózati kapcsolat, hálózati protokoll o Fizetési szolgáltatás (Payment service)

Erőforrás szintű terhelés meghatározása R: adott erőforrás F: funkciók halmaza E[terhelés. R] = |F|(gyakoriság. F*E[terhelés. F, R]) közgazdasági (nem inf. ) mérték … csal, mert • nem additív a terhelés • Taszkváltás, cache frissítés, stb. • lehetnek kiugró erőforrásigények informatikai (műszaki) mérték

Infrastruktúra leírása

Informatikai környezet meghatározása § Cél: meghatározni a funkciókhoz tartozó tranzakciókat (elemi lépéseket) és az ezek által használt erőforrásokat

Példa: a kereskedés informatikai infrastruktúrája FW Internet T 3 Link LAN 1 LAN 2 Alkalmazás szerver Web szerver R FW Adatbázis szerver

Terhelés leírása

Terhelés leírása § Az előző lépésben meghatározott modellt veszi alapul o melyik szolgáltatás milyen erőforrásokat használ § Alapvető komponensek: tranzakciók § CSISD (szekvenciák) felírása, minden szerveroldali objektumhoz tranzakciónév § Komponensekhez gyakoriság (érkezési ráta) és erőforrásigények meghatározása § Cél: Szolgáltatások erőforrásigényeinek meghatározása

Klaszter technikák A klasszikus statisztikai jellemzők, pl. átlag az egész mintát jellemzik. Klaszterek: koherens csoportok

Klaszter alapfogalmak § Klaszter: o összetartozó, hasonló értékek csoportja § Klaszter középpontja: centroid o ezzel helyettesíthető az adott csoport § Különböző (n dimenziós) távolságfogalmak o nem csak euklideszi § Különböző algoritmusok § Algoritmus + távolság definíció klaszter technika

A komponensek jellemzése

Terhelés modell

Terhelés modell meghatározása § Adatgyűjtés o benchmarkok (Terhelés ea. ) o ökölszabályok o „best practices” o mérések § Monitorozás o belső (szerver) o külső (kliens, hálózat) § Adatok rendszerezése o klaszter technikák

Terhelés mérése ellenőrzött környezetben Kliens gépen futó tesztelő szkript Dedikált szerver Teljesítmény monitorozás DEDIKÁLT HÁLÓZAT

Terhelés benchmark példa § § § Standard Performance Evaluation Corp. Alkalmazás szerver SPEC CINT 2000=431 Egy szolgáltatás CPU igénye 10 ms Új szerver, SPEC CINT 2000=518 Új CPU igény: 10 / (518/431) = 8. 3 ms § Fontos: jó benchmarkot válasszunk! § Pl. lebegőpontos számítás esetén SPEC CFP 2000 kéne

Terhelés modell minta

Terhelés előrejelzés § A terhelési modell várható változása § Többféle technika létezik („Terhelés” ea. ) § Példa: lineáris regresszió

Teljesítmény modell

Teljesítmény modell paraméterei

Queuing Network modellezés § § § Erőforrások Várakozási sorok Összeköttetések Hierarchikus (finomítható) Részletesebben „Teljesítmény” ea.

Queuing Network példa Finomítható

Queuing Network példa 2.

Little törvénye N R X § N: a rendszerben lévő kérések átlagos száma § X: áteresztőképesség § R: a rendszerben töltött átlagos idő

Kalibrálás és validálás

Kalibrálás és validálás § Modell torzítja a valóságot ellenőrzés § A terhelés modellt és az aktuálisan mért érteket összevetjük § Ha elfogadható (10%, esetleg 30% hiba) o Validált modell § Ha túl nagy a hiba o A modellt újra kell kalibrálni

Kalibrálás és validálás folyamata

Költség modellezés

Informatikai költségek Részletesebben: ld. „Infrastruktúra” ea.

Ökölszabályok („tradicionális”) 1. A memória tárhely minden 3 évben megnégyszereződik (Moore) 2. A processzor sebessége minden 3 évben megduplázódik (Moore) 3. A háttértár kapacitása 10 évenként megszázszorozódik 4. A hálózati sávszélesség minden 3 évben megnégyszereződik (Gilder) 5. A RAM MB/MIPS arány 1 -ről 4 -re növekszik (Amdahl)

What-if analízis

What-if analízis § Mi történik, ha berakunk egy új Web szervert? o teljesítmény nő o költség is § Megéri-e gyorsabb hálózatra váltani? § Mi történik, ha replikáljuk az adatbázis szervert (eddigi 1 helyett 2) ? §… § A hatást visszacsatoljuk az üzleti modellbe