Príručka určovania veľkosti cloudového servera: Koľko CPU, RAM a úložiska?

Výber správnej konfigurácie cloudového servera je jedným z najvýznamnejších rozhodnutí v akomkoľvek projektoch hostingu. Ak prekročíte kapacity, každý mesiac miniete peniaze na zdroje, ktoré stoja nečinne. Ak nedostatočne dimenzujete, vaša aplikácia trpí pomalými odozvami, časovými limitmi alebo úplnými výpadkami počas špičiek prevádzky. Žiadny z týchto výsledkov nie je prijateľný pre produkčnú záťaž, napriek tomu mnoho firiem volí veľkosť servera na základe pocitu, predvolených nastavení poskytovateľa alebo konfigurácie, ktorú odporučil blogový tutorial pred tromi rokmi.

Finčný dopad nesprávneho dimenzovania je významný. Naša analýza viac ako 200 migrácií klientov ukázala, že priemerná firma nadimenzuje cloudové zdroje o 35 % až 50 %, keď konfiguruje servery bez vedenia založeného na dátach. Pri mesačnej faktúre 200 eur to predstavuje 70 až 100 eur minutých každý mesiac, viac ako 800 až 1 200 eur ročne. Naopak, nedostatočne dimenzované servery spôsobujú problémy s výkonom, ktoré priamo ovplyvňujú príjmy. Pre e-commerce stránky môže jednosekundové zvýšenie času načítania stránky znížiť konverzie o 7 %, čo je náklad, ktorý ďaleko prevyšuje úspory z výberu menšieho servera.

Správne dimenzovanie nie je jednorazové rozhodnutie. Záťaže sa vyvíjajú, ako rastú aplikácie, menia sa vzorce prevádzky a rozširujú sady funkcií. Konfigurácia servera, ktorá bola pred šiestimi mesiacmi dokonalá, môže byť dnes nedostatočná. Táto príručka poskytuje rámec pre informované rozhodnutia o dimenzovaní pri spustení a ich úpravách v čase na základe reálnych údajov o výkone. A či nasadzujete jednoduchý marketingový web alebo komplexný zásobník aplikácií, tieto princípy vám pomôžu efektívne alokovať zdroje.

Počet jadier CPU určuje, koľko operácií môže váš server vykonávať súčasne. Aplikácie, ktoré spracúvajú veľa súbežných požiadaviek, webové servery, endpointy API, spracovanie dát v reálnom čase, profitujú z vyššieho počtu jadier. Aplikácie, ktoré vykonávajú intenzívne výpočty s jedným vláknom, kódovanie videa, vedecké výpočty, určité databázové operácie, profitujú skôr z rýchlejších jednotlivých jadier. Pochopenie toho, ktorý vzor nasleduje vaša záťaž, je prvým krokom pri dimenzovaní CPU.

Pre väčšinu webových aplikácií by sa využitie CPU malo pri bežnej záťaži pohybovať medzi 30 % a 60 %, s rezervou na zvládnutie špičiek prevádzky až po 80 % pred tým, než dôjde k zhoršeniu výkonu. Ak je vaše priemerné využitie CPU pod 20 %, pravdepodobne máte nadmernú kapacitu a môžete bezpečne znížiť veľkosť. Ak pravidelne presahuje 70 %, mali by ste zvážiť škálovanie nahor alebo von predtým, než používatelia zaznamenajú oneskorenie. Web WordPress obsluhujúci 50 000 návštevníkov mesačne zvyčajne pohodlne beží na 2 virtuálnych CPU. API Node.js spracúvajúce 500 požiadaviek za sekundu môže potrebovať 4 až 8 virtuálnych CPU v závislosti od zložitosti každej požiadavky.

Moderní cloudoví poskytovatelia ponúkajú rôzne typy CPU optimalizované pre rôzne záťaže. Inštancie optimalizované pre výpočty poskytujú vyššie taktovacie frekvencie a sú ideálne pre úlohy viazané na CPU. Všeobecne účelové inštancie vyvažujú CPU, pamäť a sieťovanie pre typické webové záťaže. V spoločnosti GRADAX predvolene používame všeobecne účelové inštancie pre väčšinu nasadení klientov a odporúčame optimalizované inštancie pre výpočty len vtedy, keď profilovanie potvrdí, že CPU je hlavným úzkym hrdlom. Výber správneho typu CPU môže priniesť o 20 % až 30 % lepší výkon pri rovnakej cenovej hladine, čo stojí za dodatočnú analýzu.

Pamäť je často zdroj, ktorý určuje, či aplikácia beží plynulo, alebo spadne pod záťažou. Na rozdiel od CPU, ktorý môže radit práce, keď je nasýtený (čo má za následok pomalšie odozvy), nedostatok RAM spustí kernelový proces „out-of-memory killer“, ktorý náhle ukončí procesy a môže priniesť do kolapsu celú vašu aplikáciu. Z tohto dôvodu odporúčame dimenzovať RAM s väčšou bezpečnostnou rezervou ako CPU, cieľom je priemerné využitie 50 % až 70 %, pričom sa ponechá dostatočná rezerva na zvládnutie špičiek prevádzky a únikov pamäte.

Rôzne aplikačné zásobníky majú diametrálne odlišné požiadavky na pamäť. Statický web obsluhovaný Nginxom potrebuje tak málo ako 256 MB. PHP web WordPress s objektovým cachingom a databázou bežiacou na tom istom servere potrebuje 2 až 4 GB. Aplikácia Java Spring Boot s integrovanou inštanciou Elasticsearch môže vyžadovať 8 až 16 GB. Aplikácie Node.js sa pohybujú niekde medzi tým, zvyčajne vyžadujú 1 až 4 GB na proces v závislosti od veľkostí payloadov a súbežných pripojení. Keď viaceré služby zdieľajú jeden server, pripočítajte ich individuálne požiadavky plus 20% rezervu pre operačný systém a pozadí procesy.

Databázové servery si vyžadujú osobitnú pozornosť pri dimenzovaní RAM. Databázy fungujú dramaticky lepšie, keď sa ich pracovná sada, údaje, ktoré sú aktívne dotazované, zmestia celkom do pamäte. MySQL databáza s 5 GB pracovnou sadou bežiaca na serveri s 4 GB RAM bude neustále čítať z disku, čo má za následok, že časy dotazov merané v milisekundách sa stanú desiatkami milisekúnd alebo viac. Tá istá databáza s 8 GB RAM udržiava pracovnú sadu v cache, čo zabezpečuje konzistentné časy pod milisekundu. Pre dedikované databázové servery odporúčame ako východiskový bod alokovať 1,5x až 2x veľkosť pracovnej sady v RAM.

Cloudové úložisko sa delí na tri hlavné úrovne: NVMe SSD, štandardné SSD a blokové úložisko založené na HDD. Disky NVMe SSD poskytujú najvyšší výkon s rýchlosťami čítania presahujúcimi 3 000 MB/s a stovkami tisíc náhodných operácií I/O za sekundu. Štandardné SSD ponúkajú rovnováhu medzi výkonom a cenou, zvyčajne s priepustnosťou 500 až 1 000 MB/s. Úložisko založené na HDD je najlacnejšie, ale zavádza významnú latenciu pri náhodnom čítaní, preto je vhodné len na archívne dáta, logy a sekvenciálne pracovné záťaže, ako sú zálohy.

Pri určovaní kapacity úložiska začnite aktuálnym objemom dát a prognózou rastu na obdobie 12 až 18 mesiacov. Typická WordPress stránka s knižnicou médií potrebuje 5 až 20 GB. E-commerce platforma s obrázkami produktov môže vyžadovať 50 až 200 GB. Aplikácia SaaS s obsahom generovaným používateľmi môže rásť nepredvídateľne a prospeje jej škálovateľné úložisko, ktoré sa rozširuje bez prerušenia prevádzky. Vždy si rezervujte aspoň 20 % voľného miesta na každom svazku; súborové systémy a databázy degradujú vo výkone, keď sa blížia k plnej kapacite, a vyčerpanie diskového priestoru je jednou z najčastejších príčin neplánovaných výpadkov.

IOPS (Input/Output Operations Per Second) je metrika úložiska, ktorá má najväčší vplyv na výkon aplikácie, no pri dimenzovaní sa často prehliada. Aplikácia náročná na databázové operácie môže potrebovať 3 000 až 10 000 IOPS pre udržanie prijateľného výkonu dotazov. Stránka s obsahom, kde prevažujú operácie čítania, môže potrebovať len 500 IOPS. Mnoho cloudových poskytovateľov viaže IOPS na veľkosť svazka; 100GB sväzok môže byť obmedzený na 3 000 IOPS, zatiaľ čo 500GB sväzok dostane 15 000 IOPS. To znamená, že niekedy musíte alokovať viac úložiska, než skutočne potrebujete, aby ste dosiahli primerané IOPS, čo je detail, ktorý často prekvapí prvých používateľov cloudu.

Sieťová šírka pásma určuje, koľko dát môže váš server odoslať a prijať za sekundu. Pri webových aplikáciách je typickým úzkym hrdlom odchádzajúca šírka pásma, pretože servery odosielajú používateľom oveľa viac dát, než prijímajú. Stránka o veľkosti 2 MB obsluhovaná 100 súbežným používateľom vyžaduje pri špičke 200 MB/s odchádzajúcej šírky pásma. CDN pred vaším serverom toto množstvo dramaticky zníži cacheovaním statických aktív na okrajových lokalitách, dynamický obsah však stále musí putovať z vášho originálneho servera.

Väčšina cloudových poskytovateľov zahŕňa do základnej šírky pásma každého typu inštancie a účtuje poplatky za prekročenie tohto limitu. Spoločnosť GRADAX má v našich plánoch webového hostingu dostatočné limity šírky pásma, pretože sme pozorovali, že neočakávané poplatky za šírku pásma patria medzi najčastejšie prekvapenia v fakturácii pre nových používateľov cloudu. Odporúčame monitorovať mesačnú spotrebu šírky pásma počas prvých troch mesiacov a nastaviť upozornenie pri 80 % vašej alokácie, aby ste sa vyhli šoku z faktúry. Pri stránkach s ťažkým mediálnym obsahom alebo aplikáciách, ktoré poskytujú veľké súbory na stiahnutie, započítajte náklady na šírku pásma do rozhodovania o dimenzovaní spolu s CPU, RAM a úložiskom.

Sieťová latencia je rovnako dôležitá, najmä pre geograficky rozptýlenú cieľovú skupinu. Server vo Frankfurte poskytuje latenciu pod 20 ms používateľom naprieč strednou Európou, ale 150 ms alebo viac používateľom v Ázii a Tichom oceáne. Ak vaši používatelia zasahujú viaceré kontinenty, jedno umiestnenie servera neposkytne konzistentný zážitok. Viacregionálne nasadenie alebo CDN s okrajovým cacheovaním je nevyhnutné. Zvyčajne odporúčame začať s jedným regiónom najbližším väčšine vašej používateľskej základne a rozšíriť ho o ďalšie regióny až vtedy, keď údaje o výkone odôvodnia pridanú komplexitu a náklady.

Pre WordPress stránky s až 100 000 návštevníkov mesačne odporúčame začať s 2 jadrami vCPU, 4 GB RAM a 40 GB úložiskom NVMe SSD. Táto konfigurácia pohodlne zvládne WordPress, MySQL, Redis object cache a Nginx s rezervou na špičky premávky. Obchody WooCommerce s aktívnymi inventármi by mali pridať ďalšie 2 GB RAM a zvážiť samostatnú inštanciu databázy, ak premávka presiahne 200 000 návštevníkov mesačne alebo katalóg produktov prekročí 10 000 položiek.

Aplikácie Node.js sa výrazne líšia podľa architektúry. Jednoduché API Express.js poskytujúce JSON odpovede beží efektívne na 1 jadre vCPU a 1 GB RAM pri strednej premávke. Aplikácia Next.js so server-side renderingom vyžaduje 2 až 4 jadrá vCPU a 2 až 4 GB RAM, pretože každý render je náročný na CPU. Reálne aplikácie využívajúce WebSockets potrebujú viac pamäte na udržiavanie trvalých pripojení; počítajte približne 10 KB RAM na jedno súčasné pripojenie, čo znamená, že 100 000 súbežných pripojení vyžaduje približne 1 GB RAM len pre stav pripojenia, plus všetko, čo vyžaduje logika aplikácie.

E-commerce platformy s dedikovanou serverovou infraštruktúrou majú najnáročnejšie požiadavky kvôli kombinácii dynamického vykresľovania stránok, databázových dotazov na katalógy produktov a inventár, spracovania košíka a pokladne v reálnom čase a poskytovania obrázkov. Stredne veľký e-shop obsluhujúci 500 000 návštevníkov mesačne zvyčajne potrebuje 4 až 8 jadier vCPU, 8 až 16 GB RAM, 100 GB alebo viac SSD úložiska a samostatný databázový server s aspoň 8 GB RAM. Počas špičkových udalostí, ako sú bleskové výpredaje alebo sviatočné akcie, sa tieto požiadavky môžu zdvojnásobiť alebo trojnásobiť, čo robí schopnosť automatického škálovania nevyhnutnou.

Škálovanie nahor (vertikálne škálovanie) znamená pridanie viac CPU, RAM alebo úložiska do existujúceho servera. Škálovanie von (horizontálne škálovanie) znamená pridanie ďalších serverov za load balancer. Každý prístup má kompromisy, ktoré by mali ovplyvniť vaše rozhodnutie. Škálovanie nahor je jednoduchšie: žiadne zmeny architektúry aplikácie, žiadna konfigurácia load balancera, žiadne obavy o správu session. Funguje dobre pre databázy, monolitické aplikácie a pracovné záťaže, ktoré je ťažké distribuovať medzi viacero uzlov.

Škálovanie von je odolnejšie a nákladovo efektívnejšie pri väčších mierkach. Ak jeden server v horizontálne škálovanom klastru zlyhá, zvyšné servery absorbujú záťaž s minimálnym dopadom. Horizontálne škálovanie vám tiež umožňuje používať menšie, lacnejšie inštancie, ktoré kolektívne poskytujú viac výpočtového výkonu ako jedna veľká inštancia pri nižšej celkovej cene. Horizontálne škálovanie však vyžaduje, aby bola vaša aplikácia stateless alebo aby externalizovala stav session do zdieľaného úložiska, ako je Redis. Tiež vyžaduje load balancer a zavádza komplexitu v nasadeniach, loggingu a ladení.

Naše všeobecné odporúčanie je škálovať najprv nahor, kým nedosiahnete prirodzený strop, zvyčajne okolo 8 až 16 jadier vCPU a 32 až 64 GB RAM, a potom škálovať von. Tento prístup minimalizuje operačnú komplexitu, pokiaľ je vaša pracovná záťaž dostatočne malá na to, aby sa zmestila na jeden stroj. Až keď prekročíte možnosti vertikálneho škálovania, investujte do zmien architektúry potrebných pre horizontálne škálovanie, čo sa vám bude hodiť, keď premávka bude ďalej rásť. Kontaktujte náš tím infraštruktúry pre personalizované posúdenie dimenzovania na základe charakteristík vašej konkrétnej pracovnej záťaže.

Počiatočné dimenzovanie je vzdelaný odhad. Správne dimenzovanie je pokračujúca prax úprav zdrojov na základe údajov o skutočnom využívaní. Odporúčame zbierať aspoň dva týždne výkonových metrík pred úpravami dimenzovania a ideálne štyri až šesť týždňov, aby ste zachytili týždenné cykly premávky, mesačné fakturačné cykly a akékoľvek sezónne variácie. Kľúčové metriky na sledovanie zahŕňajú priemerné a špičkové využitie CPU, využitie pamäte a aktivitu swapu, čas čakania na disk I/O a sieťovú priepustnosť.

Automatizované nástroje na správne dimenzovanie môžu analyzovať vzory využívania a odporúčať optimalizácie. V spoločnosti GRADAX naša monitoringová platforma označuje inštancie, kde priemerné využitie CPU zostáva pod 20 % po dobu viac ako 14 po sebe idúcich dní, čo naznačuje potenciálne nadmerné alokovanie. Upozorňuje aj na prípady, kedy akýkoľvek zdroj konzistentne presahuje 75 % využitia, čo signalizuje, že by sa malo naplánovať škálovanie nahor alebo von, skôr než dôjde k degradácii výkonu. Tieto upozornenia pomohli našim klientom znížiť náklady na infraštruktúru v priemere o 28 % počas prvých šiestich mesiacov monitorovania.

Prispôsobenie kapacít nie je len o znižovaní nákladov. Je rovnako dôležité zabezpečiť dostatočný výkon, keď sa pracovné záťaže zvyšujú. Server, ktorý pred šiestimi mesiacmi fungoval bez problémov, môže dnes zaostávať, pretože databáza rástla, zvýšil sa prevádzka alebo nové funkcie pridali výpočtovú záťaž. Naplánujte si kvartálne prehľady prispôsobenia kapacít, kde skontrolujete trendy využitia zdrojov a porovnáte ich s metrikami výkonu aplikácií, ako sú doba odozvy a miera chýb. Táto prax zachytí postupné vyčerpanie zdrojov, kým sa neprejaví ako problémy s výkonom pre používateľov, a zabezpečí, že investície do infraštruktúry zostanú v súlade so skutočnou potrebou.