Cloud szerver méretezési útmutató: Mennyi CPU, RAM és tárhely?

A megfelelő cloud szerver konfiguráció kiválasztása az egyik legfontosabb döntés bármely hostingprojektben. Túlméretezés esetén minden hónapban pénzt pazarol olyan erőforrásokra, amelyek tétlenül állnak. Alulméretezés esetén az alkalmazása lassú válaszidőktől, időtúllépésektől vagy forgalmi csúcsok idején teljes leállásoktól szenved. Egyik kimenetel sem elfogadható éles környezetben, mégis meglepően sok vállalkozás a megérzései, a szállító alapértelmezései vagy egy három évvel ezelőtti oktatóblog ajánlása alapján választja meg a szerver méretét.

A helytelen méretezés pénzügyi hatása jelentős. Több mint 200 ügyféláttelepítés elemzése azt mutatja, hogy az átlagos vállalkozás 35-50%-kal túlméretezi a cloud erőforrásokat, amikor adatvezérelt útmutatás nélkül konfigurál szervereket. Egy 200 eurós havi számlán ez 70-100 euró pazarlást jelent minden hónapban, évente több mint 800-1 200 eurót. Fordítva, az alulméretezett szerverek teljesítményproblémákat okoznak, amelyek közvetlenül befolyásolják a bevételt. Webáruházak esetében az oldalbetöltési idő egy másodperces növekedése 7%-kal csökkentheti a konverziókat, ami messze meghaladja a kisebb szerver választásából származó megtakarítást.

A megfelelő méretezés nem egyszeri döntés. A terhelés fejlődik, ahogy az alkalmazások nőnek, a forgalmi minták változnak és a funkciókészlet bővül. Egy hat hónappal ezelőtt tökéletes szerverkonfiguráció ma már elégtelen lehet. Ez az útmutató keretet ad a megalapozott méretezési döntésekhez induláskor, és azok valós teljesítményadatok alapján történő időbeli kiigazításához. Akár egy egyszerű marketingwebhelyet, akár egy összetett alkalmazáscsomagot telepít, ezek az elvek segítenek az erőforrások hatékony elosztásában.

A CPU-magok határozzák meg, hogy a szerver hány műveletet tud egyszerre végrehajtani. Azok az alkalmazások, amelyek sok egyidejű kérést dolgoznak fel, webszerverek, API-végpontok, valós idejű adatfeldolgozás, a magasabb magszámból profitálnak. Azok az alkalmazások, amelyek intenzív egyszálas számításokat végeznek, videókódolás, tudományos számítások, bizonyos adatbázis-műveletek, inkább a gyorsabb egyedi magokból profitálnak. Annak megértése, hogy az Ön terhelése melyik mintát követi, a CPU-méretezés első lépése.

A legtöbb webalkalmazás esetében a CPU-kihasználtság normál terhelés mellett átlagosan 30% és 60% között legyen, elegendő tartalékkal ahhoz, hogy a forgalmi csúcsokat 80%-ig kezelje, mielőtt a teljesítmény romlik. Ha az átlagos CPU-kihasználtság 20% alatt van, valószínűleg túlméretezett, és biztonságosan csökkentheti a méretet. Ha rendszeresen meghaladja a 70%-ot, érdemes fel- vagy kifelé skálázni, mielőtt a felhasználók késleltetést tapasztalnak. Egy 50 000 havi látogatót kiszolgáló WordPress webhely általában kényelmesen fut 2 vCPU-n. Egy másodpercenként 500 kérést kezelő Node.js API 4–8 vCPU-t igényelhet az egyes kérések összetettségétől függően.

A modern cloud-szolgáltatók különböző, más-más terhelésre optimalizált CPU-típusokat kínálnak. A számításra optimalizált példányok magasabb órajelet biztosítanak, és ideálisak CPU-kötött feladatokhoz. Az általános célú példányok a CPU-t, a memóriát és a hálózatot egyensúlyozzák a tipikus webes terhelésekhez. A GRADAX-nál a legtöbb ügyféltelepítéshez általános célú példányokat használunk alapértelmezésként, és csak akkor javasoljuk a számításra optimalizáltakat, ha a profilozás megerősíti, hogy a CPU a fő szűk keresztmetszet. A megfelelő CPU-típus választása 20–30%-kal jobb teljesítményt nyújthat ugyanazon az áron, ami megéri a plusz elemzést.

A memória gyakran az az erőforrás, amely eldönti, hogy egy alkalmazás zökkenőmentesen fut-e vagy összeomlik terhelés alatt. A CPU-val ellentétben, amely telítettség esetén sorba állíthatja a munkát (lassabb válaszokat eredményezve), a RAM kifogyása aktiválja a kernel out-of-memory killerét, amely hirtelen leállítja a folyamatokat, és az egész alkalmazást leállíthatja. Ezért a RAM-ot nagyobb biztonsági tartalékkal javasoljuk méretezni, mint a CPU-t: célozza az 50–70%-os átlagos kihasználtságot, jelentős tartalékot hagyva a forgalmi csúcsokra és memóriaszivárgásokra.

A különböző alkalmazáscsomagok memóriaigénye nagyon eltérő. Egy Nginx által kiszolgált statikus webhelynek akár 256 MB is elegendő. Egy PHP WordPress webhelynek objektum-gyorsítótárral és ugyanazon a szerveren futó adatbázissal 2–4 GB-ra van szüksége. Egy beágyazott Elasticsearch példányt futtató Java Spring Boot alkalmazás 8–16 GB-ot igényelhet. A Node.js alkalmazások valahol a kettő között vannak, jellemzően 1–4 GB-ot igényelnek folyamatonként a hasznos adatok méretétől és az egyidejű kapcsolatoktól függően. Ha több szolgáltatás osztozik egy szerveren, adja össze az egyedi igényeiket, plusz 20% tartalékot az operációs rendszernek és a háttérfolyamatoknak.

Az adatbázisszerverek különös figyelmet érdemelnek a RAM-méretezésnél. Az adatbázisok drámaian jobban teljesítenek, ha a munkakészletük, az aktívan lekérdezett adatok, teljes egészében elfér a memóriában. Egy 5 GB-os munkakészletű MySQL adatbázis, amely 4 GB RAM-mal rendelkező szerveren fut, folyamatosan a lemezről olvas, aminek következtében a milliszekundumban mért lekérdezési idők tíz milliszekundumra vagy többre nőnek. Ugyanez az adatbázis 8 GB RAM-mal a munkakészletet gyorsítótárban tartja, következetes szubmilliszekundumos olvasásokat nyújtva. Dedikált adatbázisszerverek esetében a munkakészlet méretének 1,5–2-szeresét javasoljuk RAM-ban elkülöníteni kiindulópontként.

A felhőalapú tárolás három fő szinten érhető el: NVMe SSD, szabványos SSD és HDD-alapú blokk-tárolás. Az NVMe SSD-k nyújtják a legnagyobb teljesítményt, az olvasási sebesség meghaladja a 3 000 MB/s-ot, a véletlenszerű I/O műveletek száma pedig másodpercenként a százezres nagyságrendet is elérheti. A szabványos SSD-k egyensúlyt kínálnak a teljesítmény és a költség között, jellemzően 500–1 000 MB/s átviteli sebességet nyújtanak. A HDD-alapú tárolás a legkedvezőbb árú, de jelentős késleltetést vezet be a véletlenszerű olvasásoknál, így csak archiválási adatokhoz, naplókhoz és szekvenciális munkaterhelésekhez, például biztonsági mentésekhez alkalmas.

A tárolókapacitás méretezésénél induljon ki a jelenlegi adatmennyiségéből, és tervezze meg a növekedést 12–18 hónapra előre. Egy tipikus WordPress oldal médiatárral 5–20 GB-ot igényel. Egy webshop termékképekkel 50–200 GB-ot igényelhet. Egy SaaS alkalmazás felhasználók által generált tartalommal kiszámíthatatlanul növekedhet, és előnyére válik a skálázható tárolás, amely leállás nélkül bővíthető. Minden köteten hagyjon legalább 20% szabad helyet, a fájlrendszerek és adatbázisok teljesítménye ugyanis a kapacitás közeledtével romlik, és a lemezterület elfogyása az egyik leggyakoribb oka a nem tervezett leállásoknak.

Az IOPS (Input/Output Operations Per Second, azaz másodpercenkénti bemeneti/kimeneti műveletek) az a tárolási mérőszám, amely a legnagyobb hatással van az alkalmazás teljesítményére, a méretezés során mégis gyakran figyelmen kívül marad. Egy adatbázis-igényes alkalmazás 3 000–10 000 IOPS-ot igényelhet az elfogadható lekérdezési teljesítmény fenntartásához. Egy tartalomban gazdag, túlnyomórészt olvasási műveleteket végző oldalnak akár 500 IOPS is elegendő lehet. Sok felhőszolgáltató az IOPS-t a kötet méretéhez köti: egy 100 GB-os kötet 3 000 IOPS-ra lehet korlátozva, míg egy 500 GB-os kötet 15 000 IOPS-ot kap. Ez azt jelenti, hogy néha a szükségesnél több tárolót kell kiépítenie pusztán azért, hogy elegendő IOPS-hoz jusson, ez az árnyalat sok első alkalommal felhőt használó ügyfelet ér váratlanul.

A hálózati sávszélesség határozza meg, hogy a szerver másodpercenként mennyi adatot tud küldeni és fogadni. Webalkalmazások esetében jellemzően a kimenő sávszélesség a szűk keresztmetszet, mivel a szerverek jóval több adatot küldenek a felhasználóknak, mint amennyit fogadnak. Egy 2 MB méretű oldal 100 egyidejű felhasználónak kiszolgálva csúcsidőben 200 MB/s kimenő sávszélességet igényel. A szerver elé helyezett CDN ezt drasztikusan csökkenti azáltal, hogy a statikus erőforrásokat peremhálózati helyeken gyorsítótárazza, a dinamikus tartalomnak azonban továbbra is az eredeti szerverről kell eljutnia a felhasználóhoz.

A legtöbb felhőszolgáltató minden példánymérethez alap sávszélesség-keretet biztosít, és e fölött túlhasználati díjat számít fel. A GRADAX-nál a web hosting csomagjaink bőséges sávszélesség-keretet tartalmaznak, mert azt tapasztaltuk, hogy a váratlan sávszélesség-díjak jelentik az egyik legnagyobb számlázási meglepetést a felhőt használók körében. Javasoljuk, hogy az első három hónapban figyelje a havi sávszélesség-fogyasztását, és a keret 80%-ánál állítson be riasztást a számlázási sokkok elkerülése érdekében. Médiaigényes oldalak vagy nagy fájletöltéseket kiszolgáló alkalmazások esetében a sávszélesség költségét a CPU, a RAM és a tároló mellett szintén vegye figyelembe a méretezési döntésnél.

A hálózati késleltetés ugyanilyen fontos, különösen a földrajzilag elosztott közönség esetében. Egy frankfurti szerver 20 ms alatti késleltetést nyújt a közép-európai felhasználóknak, az ázsiai-csendes-óceáni térségben élőknek azonban 150 ms-ot vagy annál többet. Ha a közönsége több kontinensen oszlik el, egyetlen szerverhelyszín nem fog következetes élményt nyújtani. A több régiós telepítés vagy a peremhálózati gyorsítótárazást végző CDN elengedhetetlen. Jellemzően azt javasoljuk, hogy kezdjen egyetlen, a felhasználói bázis többségéhez legközelebb eső régióval, és csak akkor bővítse további régiókkal, ha a teljesítményadatok indokolják a többletkomplexitást és -költséget.

A legfeljebb 100 000 havi látogatót fogadó WordPress oldalakhoz 2 vCPU-val, 4 GB RAM-mal és 40 GB NVMe SSD tárolóval érdemes kezdeni. Ez a konfiguráció kényelmesen kezeli a WordPress-t, a MySQL-t, a Redis objektum-gyorsítótárat és az Nginx-et, tartalék kapacitással a forgalmi csúcsokra. Az aktív készlettel rendelkező WooCommerce áruházaknál további 2 GB RAM-mal kell számolni, és érdemes külön adatbázis-példányt fontolóra venni, amint a forgalom meghaladja a 200 000 havi látogatót, vagy a termékkatalógus meghaladja a 10 000 tételt.

A Node.js alkalmazások architektúrájuktól függően nagyon eltérőek lehetnek. Egy egyszerű, JSON válaszokat kiszolgáló Express.js API mérsékelt forgalom mellett 1 vCPU-val és 1 GB RAM-mal hatékonyan fut. A szerveroldali renderelést végző Next.js alkalmazás 2–4 vCPU-t és 2–4 GB RAM-ot igényel, mivel minden renderelés CPU-igényes. A WebSocketeket használó valós idejű alkalmazásoknak több memóriára van szükségük az állandó kapcsolatok fenntartásához: számoljon körülbelül 10 KB RAM-mal egyidejű kapcsolatonként, ami azt jelenti, hogy 100 000 egyidejű kapcsolat nagyjából 1 GB RAM-ot igényel pusztán a kapcsolat állapotára, plusz amit az alkalmazáslogika megkövetel.

A dedikált szerver infrastruktúrával működő e-kereskedelmi platformok követelményei a legigényesebbek, mivel a dinamikus oldalrenderelés, a termékkatalógusokra és a készletre vonatkozó adatbázis-lekérdezések, a valós idejű kosár- és fizetési folyamatok, valamint a képek kiszolgálása együttesen jelentkeznek. Egy közepes méretű, 500 000 havi látogatót kiszolgáló webshop jellemzően 4–8 vCPU-t, 8–16 GB RAM-ot, 100 GB vagy annál több SSD-tárolót, valamint legalább 8 GB RAM-mal rendelkező külön adatbázis-szervert igényel. Az olyan csúcsidőszakokban, mint az akciós vásárok vagy az ünnepi promóciók, ezek a követelmények megduplázódhatnak vagy megháromszorozódhatnak, ami elengedhetetlenné teszi az automatikus skálázási képességeket.

A vertikális skálázás (felfelé skálázás) azt jelenti, hogy több CPU-t, RAM-ot vagy tárolót adunk egy meglévő szerverhez. A horizontális skálázás (kifelé skálázás) azt jelenti, hogy több szervert helyezünk egy terheléselosztó mögé. Mindkét megközelítésnek megvannak a maga kompromisszumai, amelyeket érdemes figyelembe venni a döntésnél. A vertikális skálázás egyszerűbb: nem igényel alkalmazásarchitektúra-módosítást, terheléselosztó-konfigurációt vagy munkamenet-kezelési aggályokat. Jól működik adatbázisok, monolitikus alkalmazások és nehezen elosztható munkaterhelések esetében.

A horizontális skálázás nagyobb léptékben ellenállóbb és költséghatékonyabb. Ha egy horizontálisan skálázott klaszterben egy szerver meghibásodik, a többi szerver minimális hatással veszi át a terhelést. A horizontális skálázás lehetővé teszi kisebb, olcsóbb példányok használatát is, amelyek együttesen alacsonyabb összköltség mellett nagyobb számítási teljesítményt nyújtanak, mint egyetlen nagy példány. A horizontális skálázás azonban megköveteli, hogy az alkalmazás állapotmentes legyen, vagy a munkamenet-állapotot külső, megosztott tárolóba, például Redisbe helyezze. Emellett terheléselosztót igényel, és bonyolultságot vezet be a telepítésbe, a naplózásba és a hibakeresésbe.

Általános javaslatunk, hogy először vertikálisan skálázzon, amíg el nem ér egy természetes plafont, jellemzően 8–16 vCPU és 32–64 GB RAM körül, majd térjen át a horizontális skálázásra. Ez a megközelítés minimalizálja az üzemeltetési bonyolultságot, amíg a munkaterhelése elég kicsi ahhoz, hogy egyetlen gépen elférjen. Amint kinövi a vertikális skálázást, fektessen be a horizontális skálázáshoz szükséges architektúraváltásokba, amelyek a forgalom további növekedésével is jól szolgálják majd. Vegye fel a kapcsolatot infrastruktúra-csapatunkkal a konkrét munkaterhelés-jellemzőin alapuló személyre szabott méretezési felmérésért.

A kezdeti méretezés egy megalapozott becslés. A méretoptimalizálás az a folyamatos gyakorlat, amelynek során a tényleges használati adatok alapján igazítjuk a erőforrásokat. Javasoljuk, hogy a méretezési módosítások előtt legalább két hét teljesítménymetrikát gyűjtsön, ideális esetben négy-hat hetet, hogy rögzítse a heti forgalmi ciklusokat, a havi számlázási ciklusokat és az esetleges szezonális ingadozásokat. A nyomon követendő kulcsfontosságú metrikák közé tartozik az átlagos és csúcs CPU-kihasználtság, a memóriahasználat és a swap-tevékenység, a lemez I/O várakozási idő és a hálózati átviteli sebesség.

Az automatizált méretoptimalizáló eszközök képesek elemezni a használati mintákat és optimalizálási javaslatokat tenni. A GRADAX-nál a monitorozási platformunk megjelöli azokat a példányokat, amelyeknél az átlagos CPU-kihasználtság több mint 14 egymást követő napon 20% alatt marad, ami túlméretezésre utal. Riasztást küld akkor is, ha bármely erőforrás kihasználtsága tartósan meghaladja a 75%-ot, jelezve, hogy a teljesítmény romlása előtt vertikális vagy horizontális skálázást kell tervezni. Ezek a riasztások segítettek ügyfeleinknek átlagosan 28%-kal csökkenteni az infrastruktúra-költségeket a monitorozás első hat hónapján belül.

A méretezés nem csak a költségek csökkentéséről szól. Ugyanilyen fontos a megfelelő teljesítmény biztosítása a növekvő terhelés mellett. Egy szerver, amely hat hónappal ezelőtt tökéletesen működött, ma már küszködhet, mert megnőtt az adatbázis, nőtt a forgalom, vagy az új funkciók számítási többletterhet jelentenek. Tervezzen negyedéves méretezési felülvizsgálatokat, amelyeken megvizsgálja az erőforrás-kihasználtság trendjeit, és összehasonlítja azokat az alkalmazás teljesítménymutatóival, például a válaszidővel és a hibaaránnyal. Ez a gyakorlat elkapja a fokozatos erőforrás-kimerülést, mielőtt az a felhasználók számára érzékelhető teljesítményproblémákként jelentkezne, és biztosítja, hogy infrastruktúra-befektetése összhangban maradjon a tényleges igényekkel.