Alkalmazások méretezése a felhasználók száma alapján

A legjobb, ami egy alkalmazás esetén megtörténhet a siker. Áldás és átok lehet a fejlesztők számára. Foglalkozás a leállásokkal, magas rendelkezésre állással és skálázással. Az alábbiakban bemutatjuk a webes alkalmazások méretezését, ahogy a felhasználók száma növekszik.

Általános szerverbeállítások a webes alkalmazás méretezéséhez

Az általunk használt mérés „egyidejű felhasználó”, azaz minden felhasználó egyszerre éri el a webes alkalmazást. Ez különbözik a támogatott felhasználók számától (ami magasabb is lehet), mivel valószínűtlen, hogy minden felhasználó egyszerre éri el az alkalmazást. Ugyanakkor a ”párhuzamos felhasználó” -t fogjuk használni, mivel könnyebben magyarázható.

1. Helyi host (1 felhasználó)

Te vagy az egyetlen, aki az alkalmazást használja a localhoston. A méretezés miatt nem kell aggódni.

2. Egyetlen szerver (2–9 párhuzamos felhasználó)

Ön és kollégái, barátai az egyetlen felhasználók eddig. Minden nagyszerű egyetlen kiszolgálóval mindaddig, amíg olyan webszervert használ, amely olyan eseménymodellt használ, mint az Nginx. A NodeJS természetéből adódóan eseményvezérelt és nem blokkoló I/O modellt használ. Ez azt jelenti, hogy nem blokkolja egyetlen kéréssel a szervert, hanem kezeli az összes kérést és válaszol azokra, amint az adatbázisból vagy szolgáltatásból származó adatok elérhetőek.
Az alkalmazás az idő nagy részében az adatbázisra vagy a fájlrendszerre vár. De időközben több kérést is kezelhet.

Az alkalmazásnak most (single app)-nak kell lennie, és ez rendben van így. Nincs szükség az infrastruktúra bonyolítására, amigy a szolgáltatást csak néhany felhasznaló veszi igánybe. Ha a felhasználók hibákat jelentenek, sajnos a változások végrehajtásakor a szerver frissítése közben az alkalmazás rövid ideig elérhetetlenné válik.

Az adott alkalmazás erőforrásigényétől függően már 1 CPU/ 1 GB RAM-tól.

Az „Single Server Setup¨ a legegyszerűbb. A webalkalmazás és az adatbázis azonos erőforrásokkal rendelkezik (CPU, Memória RAM, I / O).

3. Vertical scaling (10–99 egyidejű felhasználó)

Felhasználói egyszerre elkezdenek kattintani a webalkalmazás linkjére, és mintegy 100 felhasználót szerez.

Előfordulhat, hogy a kérelmek hosszabb ideig tartnak, és a dolgok lassabbak lesznek. Nagyobb kiszolgálóra van szüksége! Ezt vertikális méretezésnek hívják. A függőleges lépték azt jelenti, hogy egyetlen szerver hardverét tovább kell bővíteni több erőforrással, például gyorsabb processzorral, több RAM-mal, HDD-vel, I / O-val.

Frissíthet Cloud VPSx2 szerverünkre vagy azzal egyenértékűre (2 CPU / 4 GB RAM).

További előnye a több CPU-magnak, hogy futtathatjuk a NodeJS két példányát, és a terhelést eloszthatjuk közöttük az Nginx segítségével. Az alkalmazás több példánya már azt jelenti, hogy nulla állásidőt érhetünk el karbantartáskor vagy frissítéskor. Az egyik kiszolgálót frissítheti, míg a másik folyamatosan kiszolgálja a kéréseket. Például leállítja az 1. szervert, közben a 2. szerver továbbra is kiszolgálja a kérést. A frissítés után újraindítjuk az 1. kiszolgálót, és leállítjuk a 2. kiszolgálót frissítéshez. Végül egyetlen kérést sem veszítünk el, és az alkalmazás teljesen frissítve van.

Ez a beállítás az előzőhöz képest számos előnnyel jár:

• A Nginx gondoskodik a felhasználói kérésekről és két funkciót is ellát: gondoskodik a statikus fájlok kiszolgálásáról és fordított proxy. Önmagában kiszolgálja az összes statikus fájlt (CSS, JS, Képek) anélkül, hogy terhelné a webalkalmazást. De am kérelmeket, amelyhez az alkalmazásra van szükség, átirányítja, ezt nevezzük fordított proxynak.
• Nulla állásidő frissítés esetén.

4. Horizontal Scaling (100 - 999 egyidejű felhasználó)

Ezen a ponton valószínűleg a szűk keresztmetszet az adatáramlás és az adatbázis. Az adatbázis lassabban reagál. Folytathatjuk a bővítést nagyobb, erőssebb szerverre pl. az általunk kínált Large szerverre (4 CPU / 16 GB RAM). A 4 CPU azt jelenti, hogy több példányban is lehet az adatbázis vagy az alkalmazás. Ezt vízszintes méretezésnek nevezzük.

Van olyan pont, ahol a függőleges méretezés már nem költséghatékony.

A függőleges méretezés felvet egy másik problémát: az összes tojás egy kosárban van. Ha a szerver leáll, akkor az alkalmazás is! Ugyanakkor a vízszintes méretezés megfelelően konfigurálva redundációt és üzembiztosabb működést eredményez.

Ezen a ponton célszerűbb a vízszintes skálázást választani a függőlegessel szemben. A következő szűk keresztmetszet ez esetben valószínűleg az adatbázis lesz.

A következőket tudjuk tenni:

• Az adatbázis áthelyezése egy másik szerverre, és ettől a ponttól kezdve lehetőség nyílik, hogy az adatbázis kiszolgálót függetlenül méretezzük az alkalmazást kiszolgáló erőforrásoktól
• Lehetőség van hozzáadni adatbázis gyorsítótárat, amennyiben szükséges.
• Mivel az alkalmazás (Node.js) nagyon hatékony, az idő nagy részében a kiszolgáló az adatbázis által szolgáltatott adatokra vár. Tehát a legnagyobb torlódást a hálózat átviteli korlátai okozzák. Megfelelő beállításokkal elérhető, hogy megfeleljen a 100 - 999 felhasználói tartománynak.

5. Multi-szerver (1,000+ egyidejű felhasználó)

10,000 felhasználó kiszolgálásának érdekében az előző konfigurációnkat a következő módokon fejleszthetjük:

• Load Balancer alkalmazása
• Több rendelkezésre állási zónát hasznalhatunk, földrajzilag szeparálva ezzel felhasználóinkat
• Kiszervezhetjük a statikus fájlaink (JavaScript, CSS, képek, videók, stb) kiszolgálását külső szerverre vagy CDN szolgáltatásra.

Számos előnye van annak, ha az adatbázist az alkalmazástól eltérő kiszolgálón található:

• Az alkalmazás és az adatbázis nem harcol ugyanazon erőforrásokért.
• Az egyes rétegeket (app, db) függetlenül méretezhetjük az igényeknek megfelelően.

A hátránya, hogy ez összetettebb tervezést és fenntartást, és a helyes konfigurálás nagyobb szakértelmet igényel. Ezen kívül, mivel az alkalmazás és az adatbázis nem azonos szervertartományban van, problémák merülhetnek fel a hálózati késleltetés vagy a sávszélesség korlátai miatt is. A kiszolgáló teljesítmény tovább növelhető alacsony késleltetésű és nagy sebességű kapcsolatokkal rendelkező magánhálózatok (VPC) használatával.

6. Microservices (100 000+ egyidejű felhasználó)

Eddig vertikális és vízszintes méretezést használtunk fel, elválasztottuk a webalkalmazásokat az adatbázis-példányoktól, és több régióba telepítettük. Ugyanakkor egyetlen kód alapú voltunk, amely kezeli az összes kérést az alkalmazásban. Alkalmazásunkat kisebb részekre bonthatjuk és szükség szerint méretezhetjük az így leválasztott szolgáltatásokat (továbbiakban mikroszolgáltatásokat). Elérkezünk a monolittól a mikroszolgáltatások világába.

Ideje széttördelni a webalkalmazásunk monolitját, és azt több kisebb és független komponensre (mikroszolgáltatások / SOA) bontani, amelyek kiszolgálóit függetlenül méretezhetünk egymástól. Ezt a lépést nem szükséges egyszerre megtennünk az összes komponensükre vonatkozóan, hanem idővel kiszervezzük az erőforrás igényes szolgáltatásokat a fő alkalmazásunkból. Később a terheléselosztót is használhatjuk a forgalom átirányításához az új kis szolgáltatásokhoz a fő alkalmazás helyett.
Például szükség szerint függetlenül méretezhetők: Felhasználók, Termékkatalógus és Megrendelések. A mikroszolgáltatások további előnye, hogy feloszthatjuk az adatbázist is.

7. Automatizálás (1 000 000+ párhuzamos felhasználó)

Automatizálás, amennyire csak lehet. Az infrastruktúra egyre jobban növekszik. Van db replikánk és szétosztottuk a táblákat, vízszintes méretezés, több régió és multi-AZ, és automatikus skálázás.

Magas szintű rendelkezésre állás, több régióban Ezen a ponton a skálázás érdekében csak a további szerver példányokat kell hozzáadnunk, és a forgalom forrása alapján elosztjuk az elérhetőségi zónákat és régiókat. Ha észreveszi, hogy jelentős forgalom érkezik Ausztráliából és Németországból, talán eljött az ideje, hogy az alkalmazásunkat elérhetővé tegyük ott is.

Automatikus méretezés Hiábavaló lenne, ha kiszolgálóinkat mindig a csúcskapacitásra hangolnánk. A felhasználói forgalomnak vannak csúcsai (például fekete péntek) és völgyek (például hajnal 4 órakor). Többféle módszer áll rendelkezésre, hogy infrastruktúránk alkalmazkodjon a forgalmi feltételekhez. Ezzel komoly mértékben optimalizálhatók infrastruktúránk üzemeltetési költsége.