Tervezés és fejlesztés a teljesítmény nevében - Rendszer architektúra

Rendszer architektúra

Hardver és szoftver komponensek

Hardver

Egy rendszer hardver elemeit érdemes úgy méretezni, mint ahogy egy hídépítő mérnök tervezi a hidat. Mivel a költségekkel mindig számolni kell, ezért nem érdemes bizonyos részeit a legjobb és legdrágább anyagokból építeni, míg más részeit olcsóbb, és így gyengébb elemekből. A híd teherbírása a leggyengébb rész teherbírása lesz. Sokkal erősebb hidat lehet építeni, ha valamiféle egyensúlyt keresünk az egyes részek minősége között, és próbáljuk ezt egymáshoz közel tartani és a költségeket ennek megfelelően minimalizálni.

Egy számítógépes rendszer tervezésénél is pontosan ez a helyzet. Törekedni kell tehát az egyensúlyra és úgy méretezni leendő rendszerünket.

Az alapvető hardver komponensek:

• Processzor
• Memória
• I/O alrendszer
• Hálózat

Szoftver

Úgy, mint a számítógépeknek is vannak közös hardver elemei a szoftvereknek is vannak funkcionálisan közös elemeik. Ha az alkalmazásokat szétválasztjuk funkcionális elemekre, jobban megértjük ezek működését.

A legtöbb alkalmazás tartalmazza az alábbi komponenseket:

• Felhasználói felület
• Üzleti logika
• Felhasználói kérések és erőforrás foglalás
• Adat és tranzakció kezelés

Felhasználói felület

A felhasználó ezen a felületen keresztül kommunikál a programmal.

Feladatai:

• Kép megjelenítése
• Adatgyűjtés és kézbesítés az üzleti logikai rétegnek
• Bejegyzéseket érvényesíti
• Navigál az alkalmazás állapotai között

Üzleti logika

Az alapvető logikai egység. Ettől függ, hogy az alkalmazás milyen feladatot lát el. Ha ebben hiba van, annak helyreállítása nagyon költséges is lehet. Procedurális és deklaratív részek alkotják.

Feladatai:

• Adatmodell átültetése relációs sémába
• Kényszerek definiálása a relációs sémában
• Az üzleti logika megvalósítása függvények segítségével

Felhasználó kérések és erőforrás foglalás

Ez a komponens minden alkalmazásban szerepel. Egy több felhasználós rendszerben az erőforrás foglalást elvégzi az adatbázis szerver, vagy az operációs rendszer. Azonban nagyon nagy alkalmazás esetén a rendszer tervezőjének meg kell bizonyosodnia, hogy nagy terhelés esetén is garantálható a normális működés.

Az ide tartozó feladatok:

• Adatbázis-kapcsolat kezelése
• Lekérdezések végrehajtása
• Kliensek kezelése
• Egyensúlyban tartani a felhasználói kéréseket a hardver erőforrások függvényében

Adat és alkalmazás kezelés

Ezért főleg az adatbázis szerver és az operációs rendszer felelős.

Feladatok:

• Egyidejű adathozzáférés garantálása zárak és tranzakciók segítségével
• Optimalizált adathozzáférés indexek és cache segítségével
• Gondoskodni az adatmódosítások logolásáról
• Érvényesíteni az adatokra vonatkozó szabályokat

A szükségleteknek megfelelő helyes rendszer-architektúra beállítása

Meghatározni a helyes rendszer architektúrát nem egyszerű feladat. Sokszor többször át kell gondolni a tervezés különböző fázisaiban. Alapvetően megkülönböztetünk interaktív (pl. árusító rendszerek, email szerverek, web alapú alkalmazások…) és processz alapú (pl. csalás detektáló rendszer, direct mail) rendszert. A legtöbb esetben ez utóbbit könnyebb fejleszteni, mert itt hiányzik a felhasználói felület. Azonban itt a feladat is nehezebb, mert a célok nem annyira tiszták, mint egy felhasználói igényeket kielégítő rendszerben. A tervező mérnökök nincsenek hozzászokva nagy adatmennyiségek kezeléséhez.

A rendszer architektúra meghatározása nem tartozik a determinisztikus dolgok közé. Ahhoz, hogy valaki jó tervező mérnökké váljon, rengeteg tapasztalatra van szükség. Azonban álljon most itt néhány kérdés, melyek megválaszolása elősegítheti a helyes architektúra kialakítását.

Elsődleges kérdések:

• Hány felhasználó fogja használni a rendszert?
  Majdnem minden alkalmazás besorolható az alábbi kategóriák egyikébe.

· Nagyon kevés felhasználó egy keveset használt számítógépen
Ez általában egy felhasználót jelent. A tervezésnél a fő szempont az, hogy ez az egy felhasználó a lehető legjobb hatékonysággal tudja használni az alkalmazást, minimális válaszidővel. Ezeknek az alkalmazásoknak a felhasználói ritkán zavarják egymást és az erőforrás ütközések is minimálisak.

· Közepesen sok és sok felhasználó egy vállalati, osztott alkalmazásban
Ebben az esetben a felhasználók száma limitált és megjósolható, például egy vállalat alkalmazottai. Azonban a megbízhatóság döntő szempont a tervezésnél. A felhasználók közös erőforrást használnak, így nagy terhelésnél is fontos a válaszidő kordában tartása.

· Megszámolhatatlan felhasználó fér a rendszerhez az interneten keresztül
Ennél az alkalmazástípusnál fontos a mérnöki hozzáértés, mert gondosan meg kell tervezni az erőforrások elosztását. Ha elfogy valamelyik hardverkomponens tartaléka, akkor könnyen kialakulhat ’bottleneck’, ami a rendszer instabilitásához vezethet. Az ilyen alkalmazásokhoz szükséges terhelés kiegyenlítés, állapotmentes alkalmazás szerver, és hatékony adatbázis kapcsolat menedzsment.

• Milyen lesz a felhasználói hozzáférés?
  A felhasználói felület megválasztása a web-alapú technológiáktól egészen a saját kliens programig.
• Hol vannak a felhasználók?
  A felhasználók közötti távolság szabja meg bizonyos esetekben, hogy mennyi lehet a késleltetési idő. De a felhasználók helye még azt is befolyásolhatja, hogy melyik napszakban legyen a karbantartás, és mikor legyen feltétlenül elérhető.
• Mekkora a hálózati sebesség?
  A hálózati sebesség nagyban befolyásolja azt, hogy mennyi adatot célszerű küldeni egyszerre a felhasználói felület és az adatbázis szerver között. Ha lassú a sebesség, akkor nem érdemes minden egyes új információt átküldeni, hanem csak tömbösítve, mert akkor nem lesz szétdarabolt a bevitel. Ha pedig gyors a hálózati elérés, amit használunk, akkor megoldható az, hogy a szerver gyorsan reagáljon minden bevitelre.
• Mennyi adathoz férhet hozzá egy felhasználó és ebből mennyi csak olvasható?
  A lekérdezett adatmennyiség kihat a tervezési döntésekre. A tervezőnek meg kell bizonyosodni róla, hogy a válaszidő az adatbázis méretétől nem függ. Ha az alkalmazás jórészt csak lekér adatokat, akkor az adatreplikáció és adat elosztás egy jó megoldás a fő szerver tehermentesítésére (terhelés megosztás).
• Mekkora a maximális megengedhető válaszidő?
  Ezt felhasználója válogatja. El kell döntenünk, hogy aki használni fogja a rendszert, annak milliszekundumos válaszidőre van szüksége, vagy elegendő akár másodperces nagyságrend is.
• Szükség van-e napi 24 órás elérésre?
  Az internetről is elérhető rendszerek számára ez kötelező. Azonban a vállalati rendszerek, melyek csak egy időzónában működnek, elegendőek csak a munkaidő alatt elérhetőnek lenniük. A maradék időben pedig el lehet rajtuk végezni a karbantartási munkákat és átkonfigurálásokat.
• Minden változtatást valós időben kell elvégezni?
  Fontos a tervezéskor eldöntenünk, hogy a felhasználó által kért változtatásokat azonnal végre kell hajtanunk, vagy ráér esetleg később is, aszinkron módon.

Másodlagos kérdések:

• Mekkora lesz az adatbázis?
  Az adatbázis mérete határozza meg a szerver gép erőforrásait. Az olyan szerver, amin nagy adatbázist használunk egy kicsivel nagyobb gépet igényel, mint amekkorára feltétlenül szüksége lenne. Ez azért van, mert az adminisztrációs folyamatok végrehajtási ideje nagyban függ az adatbázis méretétől. Ha nincs elegendő plusz erőforrás, akkor ezek a műveletek nagyon hosszúra is nyúlhatnak.
• Mennyi a szükséges teljesítmény egy művelethez?
• Mik a rendelkezésre állási szükségletek?
• Milyen kompromisszumokat tudunk kötni, ha finanszírozási megszorítások lennének?

Forrás