Alkalmazásod beállítása: Hogyan válaszd ki a legjobb szerverkonfigurációt?

Bevezetés

A technológia és az internet központi szerepet töltenek be a mindennapi, az egyetemi és a szakmai életünkben. Ezért nem meglepő a párhuzamosan létező weboldalak és alkalmazások puszta száma. Ha Ön vállalkozás, akkor szeretne egy kapcsolódó webes platformot. Egy alkalmazás lehetővé teszi, hogy könnyedén értékesítse és eljuttassa szolgáltatásait a célközönségéhez.

Függetlenül attól, hogy miért hoz létre egy webalkalmazást, meg kell határoznia, hogyan építi fel azt. Számos lehetőség áll a rendelkezésére, amikor a(z) legjobb szerverkonfiguráció kiválasztásáról van szó. Az Ön által választott szerverarchitektúra határozza meg, hogyan futtat és kezel mindent a környezetében. Ezért ezt a döntést alapos mérlegelés után kell meghozni.

Hogyan válasszuk ki a megfelelő szerverkonfigurációt

Hogyan döntheti el tehát, hogy melyik architektúra a „megfelelő” az alkalmazása számára? Ehhez először át kell gondolnia, mik a webalkalmazása követelményei. Bizonyos funkciókat be kell építenie ahhoz, hogy az hatékonyan működjön az Ön konkrét használati esetében. Például lehet, hogy egy könnyen skálázható alkalmazásra törekszik. Vagy talán arra van szüksége, hogy az alkalmazása zökkenőmentesen működjön a böngészőkben és a mobileszközökön egyaránt. Ugyanakkor a költségvetése is elsődleges szempont lehet.

Függetlenül attól, hogy mik a követelményei, tudnia kell, hogy egyedi megoldást is létrehozhat az alkalmazásához. Ebben az útmutatóban megvizsgáljuk a különböző szervertípusokat, amelyeket sokan általában használnak a webalkalmazásaikhoz. Beszélni fogunk a különböző használati esetekről, és arról, hogy egy adott konfigurációt mikor a legjobb használni. Hogy segítsünk eldönteni, megfelelő-e az Ön számára, bemutatjuk az egyes szerverarchitektúrák előnyeit és hátrányait is.

1. Minden egyetlen szerveren

Ahogy a név is sugallja, a teljes környezetet egyetlen, egyedi szerverre tölti be. A környezet magában foglalja a webszervert, az alkalmazásszervert, valamint az adatbázis-szervert is. Ez működik például a(z) Linux, Apache, MySQL, és PHP (LAMP) szoftvercsomag-konfiguráción. Követheti az útmutatóinkat arról, hogyan kell telepíteni a LAMP szoftvercsomagot egy Ubuntu szerverre és hogyan kell telepíteni a LAMP szoftvercsomagot CentOS-re.

Mikor érdemes használni:

Ez a fajta elrendezés akkor működik a legjobban, ha kevés az ideje. Egyszerű és gyors a beállítása. Ezért működik jól az egyszerűbb webalkalmazások esetében.

Előnyök:

• Egyszerű, könnyen érthető és megvalósítható.
• A teljes beállítása kevés időt vesz igénybe.

Hátrányok:

• Nem teszi lehetővé a horizontális skálázhatóságot.
• Nagyon keveset nyújt az összetevők elkülönítése terén.
• Az alkalmazás és az adatbázis lényegében ugyanazokért az erőforrásokért versengenek, mivel egyetlen szerveren vannak.
• Ennek eredményeként gyenge teljesítményt tapasztalhat.

2. Különálló adatbázis-szerver

Az egyetlen szerver használatának fő problémája a korlátozott erőforrásokért való versengés. Ez a konfiguráció ezt a problémát hivatott megoldani. Itt az adatbázis-kezelő rendszer, vagyis a DBMS, el van különítve az alkalmazásszervertől. Az adatbázis-szerver egy magánhálózatban található, és saját erőforrásokkal rendelkezik. Ez jobb teljesítményt és nagyobb biztonságot eredményez.

Mikor érdemes használni:

Ismétlem, ha gyors konfigurációt szeretne üzembe helyezni, ezt meglehetősen egyszerű beállítani. Ideális megoldás, ha aggódik amiatt, hogy az adatbázis és az alkalmazás ugyanazokért az erőforrásokért versengenek.

Előnyök:

• Különálló, dedikált rendszererőforrások az alkalmazás és az adatbázis számára egyaránt, beleértve a CPU-t, a memóriát, az I/O-t stb.
• Nagyobb skálázhatósági potenciál mind az alkalmazás-, mind az adatbázis-rétegben.
• Szükség szerint hozzáadhat és eltávolíthat erőforrásokat.
• Ha eltávolítja az adatbázist a nyilvános internetről, a biztonságot is növelheti.

Hátrányok:

• Valamivel összetettebb, mint az egyetlen szerveres konfiguráció.
• A két szerver közötti alacsony sávszélességű vagy nagy késleltetésű hálózati kapcsolat teljesítményproblémákat okozhat.

3. Reverz proxy vagy terheléselosztó

Ez az, ahol a terheléselosztók kerülnek a képbe. A terheléselosztókat jellemzően szerverkörnyezetekben használják a teljesítmény és a megbízhatóság javítására. Ezt a „terhelés elosztásával” érik el; azaz elosztják a munkaterhelést egy szervercsoport tagjai között.

Mikor érdemes használni:

A terheléselosztók rendkívül hasznosak, ha horizontális skálázást kell végrehajtani. A horizontális skálázás alapvetően azt jelenti, hogy több szervert adunk hozzá a környezethez. Alkalmazásrétegű fordított proxyt is használhat, hogy egyszerre több alkalmazást szolgáljon ki egyetlen tartomány és port használatával. HAProxy, Nginx, és Varnish olyan szoftverekre példák, amelyek lehetővé teszik a fordított proxy alapú terheléselosztást.

Előnyök:

• Ha a sorban lévő egyik szerver meghibásodik, a többi szerver kompenzálja a kiesését a munkaterhelés elosztásával.
• Lehetővé teszi a horizontális skálázást a környezet kapacitásának növelése vagy csökkentése érdekében.
• Korlátozza az ügyfélkapcsolatokat is, ami védelmet nyújt a DDOS-támadások ellen.

Hátrányok:

• Ha a rendszererőforrások nem elegendőek, a terheléselosztó korlátozhatja az alkalmazás teljesítményét.
• A megfelelő teljesítmény biztosításához megfelelő konfigurációra van szükség.
• Lényegesen összetettebb, mint az egyetlen szerverből vagy különálló szerverekből álló rendszerek.
• Figyelembe kell venni olyan tényezőket, mint az SSL-termináció és a tartós munkameneteket (sticky sessions) igénylő alkalmazások.
• A terheléselosztók használatának legfőbb aggálya, hogy egyetlen hibapontot (single point of failure) jelentenek. Ez azt jelenti, hogy ha a terheléselosztó meghibásodik, a teljes szolgáltatás leáll.

4. HTTP-gyorsító vagy gyorsítótárazó fordított proxy

Ez egy olyan konfiguráció, amellyel növelheti az alkalmazás tartalmának a felhasználóhoz való eljuttatásának sebességét. Különböző technikákat alkalmaz ennek az időnek a csökkentésére. A legfontosabb az alkalmazásszerver válaszának gyorsítótárazása. A gyorsító elmenti a tartalmat a memóriájába, amikor egy felhasználó először kéri azt. Ezért, amikor a jövőben hasonló kérések érkeznek, gyorsan kiszolgálja a tartalmat anélkül, hogy kapcsolatba lépne az alkalmazásszerverrel. Az Nginx, a Varnish és a Squid mind képesek a HTTP-gyorsításra.

Mikor érdemes használni:

Érthető módon ez a felépítés a legalkalmasabb a felhasználók által nagyon gyakran kért fájlok és tartalmak kiszolgálására. Nagyon jól működik tartalomigényes, dinamikus webalkalmazások esetében is.

Előnyök:

• A gyorsítótárazás és a tömörítés jelentősen növeli az alkalmazás és a kérések feldolgozásának sebességét.
• A CPU terhelésének csökkentése szintén javítja az oldal teljesítményét.
• Ezt fordított proxy terheléselosztóként is használhatja.

Hátrányok:

• Jól be kell hangolnia a legjobb teljesítmény eléréséhez.
• Gyenge teljesítményt tapasztalhat, ha a gyorsítótár-találati arány alacsony.

5. Primary-Replica adatbázis-replikáció

A primary-replica adatbázis-replikációs felépítés jellemzően nagyon hasznos olyan rendszerek esetében, amelyek több olvasást végeznek, mint írást. Például a tartalomkezelő rendszerek (CMS) valóban ki tudják használni az ilyen architektúrákat. A replikációhoz egy elsődleges és egy vagy több replikációs csomópontra van szükség. Ez elosztja az olvasásokat az összes csomópont között. A frissítések csak az elsődleges csomópontra érkeznek.

Mikor érdemes használni:

Mint említettük, a replikációalapú adatbázis-felépítés segít javítani a rendszer olvasási teljesítményét. Használhatja olyan alkalmazásokhoz, mint a CMS.

Előnyök:

• Javítja az adatbázis olvasási teljesítményét, mivel elosztja azt a replikák között.
• Ha az elsődleges csomópontot csak frissítésekre használja, az írási teljesítményt is javíthatja.

Hátrányok:

• Minden olyan alkalmazásnak, amely megpróbál hozzáférni az adatbázishoz, képesnek kell lennie eldönteni, hogy melyik csomópontra küldje a frissítéseket és az olvasási kéréseket.
• Ha az elsődleges replika meghibásodik, a frissítések leállnak. Meg kell oldania a problémát, hogy a frissítések folytatódhassanak.
• Nincs hibatűrő (failover) mechanizmus az elsődleges csomópont esetleges meghibásodásának kezelésére.

A szerverkonfigurációk kombinált használata

Szerencsére arra is van lehetőség, hogy különböző technikákat kombináljon a kívánt eredmény elérése érdekében. Ez azt jelenti, hogy egyetlen környezetben eloszthatja a terhelést az alkalmazásszerverek és a gyorsítótárazó szerverek között, valamint replikálhatja az adatbázist. Ez lehetővé teszi, hogy kihasználja mindkét szerver funkcióit. Ez azonban egyáltalán nem teszi bonyolultabbá vagy problémásabbá a beállítást.

Példa:

Egy példán keresztül próbáljuk meg megérteni az ilyen környezetet:

Egy ilyen környezetben a terheléselosztó a statikus kéréseket a gyorsítótárazó szerverekre küldi. Statikus tartalom többek között a CSS-t, a képeket és a Javascriptet foglalja magában. Minden más típusú tartalomra vonatkozó kérést ehelyett az alkalmazásszerverekre irányít.

Tegyük fel, hogy egy felhasználó valamilyen statikus tartalmat kér a környezettől. A következő fog történni:

• A terheléselosztó először meghatározza, hogy a tartalom cache-hit (gyorsítótár-találat) vagy cache-miss (gyorsítótár-hiány). A cache-hit tartalom jelen van a gyorsítótárban, míg a cache-miss tartalom nincs ott. Ezt a cache-backend ellenőrzésével teszi meg.
• Cache-hit esetén a terheléselosztó elküldi a tartalmat a felhasználónak.
• Cache-miss esetén a gyorsítótár-szerver továbbítja a kérést az alkalmazás háttérrendszerének (backend).
• Az alkalmazás-backend megkeresi és elküldi a tartalmat az adatbázisból.
• A cache-backend megkapja a tartalmat a terheléselosztótól. Ezt a tartalmat gyorsítótárazza is, mielőtt visszaküldené a terheléselosztónak.
• Ez utóbbi ezután továbbítja a választ a felhasználónak.

Másrészt, a következő történik, ha a felhasználó dinamikus tartalmat kér:

• A kérés a felhasználótól érkezik a terheléselosztóhoz.
• Ez a kérés az alkalmazás-backendhez érkezik.
• Az alkalmazás-backend megkeresi a kért tartalmat, és visszaküldi a terheléselosztónak.
• A felhasználó megkapja a tartalmat.

Az ilyen kombinált környezet egyik fő előnye, hogy megbízhatóbb. Nemcsak ez, hanem kiváló teljesítménybeli képességekkel is rendelkezik. Azonban még mindig van két egypontos hibaforrás (single point of failure) – a terheléselosztó és az elsődleges adatbázis-szerver.

Összegzés

Minden egyes szerverbeállítást önállóan is használhat a környezetében. Másrészt akár össze is kombinálhat közülük néhányat, hogy személyre szabott megoldást hozzon létre. Nincs „helyes” válasz. Minden attól függ, hogy milyen funkcionalitást szeretne kinyerni az architektúrából.

Az egyes szerverbeállítások működésével kapcsolatos alapvető ismeretek segítenek meghozni a döntést a saját alkalmazásával kapcsolatban. A legjobb, ha kicsiben és egyszerűen kezdi. Tapasztalatszerzésével folyamatosan növelheti a beállítások összetettségét.

Kellemes számítástechnikát!