Průvodce dimenzováním cloudového serveru: Kolik CPU, RAM a úložiště?

Volba správné konfigurace cloudového serveru patří k nejdůležitějším rozhodnutím v každém hostingovém projektu. Nadbytečné kapacity znamenají, že každý měsíc platíte za nevyužité zdroje. Nedostatečné kapacity způsobují, že vaše aplikace trpí pomalou odezvou, vypršením časových limitů nebo úplným pádem během špiček. Ani jeden výsledek není pro produkční provoz přijatelný, přesto překvapivě mnoho firem volí velikost serveru podle pocitu, výchozích nastavení dodavatele nebo konfigurace, kterou před třemi lety doporučil nějaký výukový blog.

Finanční dopad nesprávného dimenzování je značný. Naše analýza více než 200 klientských migrací ukazuje, že průměrná firma při konfiguraci serverů bez datově podloženého vedení nadbytečně dimenzuje cloudové zdroje o 35 % až 50 %. U měsíčního účtu 200 eur to znamená 70 až 100 eur vyhozených každý měsíc, přes 800 až 1 200 eur ročně. Naopak servery s nedostatečnou kapacitou způsobují problémy s výkonem, které přímo ovlivňují příjmy. U e-shopů může zvýšení doby načítání stránky o jednu sekundu snížit konverze o 7 %, což je náklad, který daleko převyšuje úsporu z volby menšího serveru.

Správné dimenzování není jednorázové rozhodnutí. Zátěž se vyvíjí s tím, jak aplikace rostou, mění se vzorce návštěvnosti a rozšiřují se funkce. Konfigurace serveru, která byla před půl rokem ideální, může být dnes nedostatečná. Tento průvodce nabízí rámec pro informovaná rozhodnutí o dimenzování při spuštění a jejich úpravy v čase na základě skutečných dat o výkonu. Ať už nasazujete jednoduchý marketingový web nebo složitý aplikační stack, tyto principy vám pomohou alokovat zdroje efektivně.

Počet jader CPU určuje, kolik operací může váš server vykonávat současně. Aplikace zpracovávající mnoho souběžných požadavků, webové servery, API endpointy a zpracování dat v reálném čase těží z vyššího počtu jader. Aplikace provádějące náročné jednovláknové výpočty, kódování videa, vědecké výpočty a určité databázové operace však více profitují z rychlejších jednotlivých jader. Pochopení toho, který vzorec vaše zátěž sleduje, je prvním krokem k dimenzování CPU.

U většiny webových aplikací by se využití CPU mělo při běžné zátěži pohybovat v průměru mezi 30 % a 60 %, s rezervou pro zvládnutí špiček až do 80 %, než výkon začne klesat. Pokud je vaše průměrné využití CPU pod 20 %, pravděpodobně máte nadbytečnou kapacitu a můžete bezpečně snížit velikost instance. Pokud pravidelně překračuje 70 %, měli byste zvážit škálování nahoru nebo ven dříve, než uživatelé pocítí latenci. WordPress web s 50 000 měsíčními návštěvníky obvykle pohodlně běží na 2 vCPU. Node.js API zpracovávající 500 požadavků za sekundu může potřebovat 4 až 8 vCPU v závislosti na složitosti každého požadavku.

Moderní poskytovatelé cloudu nabízejí různé typy CPU optimalizované pro různé zátěže. Instance optimalizované na výpočet poskytují vyšší taktovací frekvence a jsou ideální pro úlohy náročné na CPU. Univerzální instance vyvažují CPU, paměť a síť pro typické webové zátěže. V GRADAX ve výchozím nastavení používáme univerzální instance pro většinu klientských nasazení a instance optimalizované na výpočet doporučujeme jen tehdy, když profilování potvrdí, že hlavním omezením je CPU. Volba správného typu CPU může přinést o 20 % až 30 % lepší výkon při stejné ceně, což za dodatečnou analýzu stojí.

Paměť je často zdrojem, který určuje, zda aplikace běží plynule, nebo padá pod zátěží. Na rozdíl od CPU, který při nasycení může práci zařadit do fronty (což vede k pomalejším odpovědím), nedostatek RAM spouští kernel out-of-memory killer, který procesy náhle ukončí a může shodit celou vaši aplikaci. Z tohoto důvodu doporučujeme dimenzovat RAM s větší bezpečnostní rezervou než CPU, cílte na 50 % až 70 % průměrného využití a ponechte podstatnou rezervu pro špičky a úniky paměti.

Různé aplikační stacky mají velmi odlišné požadavky na paměť. Statický web obsluhovaný Nginxem potřebuje jen 256 MB. PHP WordPress web s objektovou cache a databází na stejném serveru potřebuje 2 až 4 GB. Java Spring Boot aplikace s vestavěnou instancí Elasticsearch může vyžadovat 8 až 16 GB. Node.js aplikace se pohybují někde mezi, obvykle potřebují 1 až 4 GB na proces v závislosti na velikosti datových zpráv a souběžných připojeních. Když server sdílí více služeb, sečtěte jejich jednotlivé požadavky plus 20% rezervu pro operační systém a procesy na pozadí.

Databázové servery si u dimenzování RAM zaslouží zvláštní pozornost. Databáze fungují dramaticky lépe, když se jejich pracovní sada, data, která se aktivně dotazují, vejde celá do paměti. MySQL databáze s 5 GB pracovní sadou na serveru se 4 GB RAM bude neustále číst z disku, což způsobí, že se doby dotazů měřené v milisekundách změní na desítky milisekund nebo více. Stejná databáze s 8 GB RAM udrží pracovní sadu v cache a poskytuje konzistentní čtení pod jednou milisekundou. U vyhrazených databázových serverů doporučujeme jako výchozí bod alokovat 1,5x až 2x velikost pracovní sady v RAM.

Cloudové úložiště se dodává ve třech základních úrovních: NVMe SSD, standardní SSD a blokové úložiště na bázi HDD. NVMe SSD poskytují nejvyšší výkon s rychlostí čtení přesahující 3 000 MB/s a stovkami tisíc náhodných I/O operací za sekundu. Standardní SSD nabízejí rovnováhu mezi výkonem a cenou, obvykle s propustností 500 až 1 000 MB/s. Úložiště na bázi HDD je nejdostupnější, ale přináší výraznou latenci u náhodného čtení, takže je vhodné pouze pro archivní data, logy a sekvenční zátěže, jako jsou zálohy.

Pro dimenzování kapacity úložiště začněte od svého současného objemu dat a naplánujte růst na 12 až 18 měsíců. Typický web na WordPressu s knihovnou médií potřebuje 5 až 20 GB. E-shop s obrázky produktů může potřebovat 50 až 200 GB. SaaS aplikace s obsahem od uživatelů může růst nepředvídatelně a těží z škálovatelného úložiště, které lze rozšířit bez výpadku. Na každém svazku vždy rezervujte alespoň 20 % volného místa, souborové systémy a databáze ztrácejí výkon, jak se blíží kapacitě, a nedostatek místa na disku je jednou z nejčastějších příčin neplánovaných výpadků.

IOPS (Input/Output Operations Per Second) je metrika úložiště, která nejvíce ovlivňuje výkon aplikace, přesto se při dimenzování často přehlíží. Aplikace náročná na databázi může potřebovat 3 000 až 10 000 IOPS pro udržení přijatelného výkonu dotazů. Web s převahou čtecích operací může potřebovat jen 500 IOPS. Mnoho poskytovatelů cloudu váže IOPS na velikost svazku, svazek o velikosti 100 GB může být omezen na 3 000 IOPS, zatímco svazek o velikosti 500 GB získá 15 000. To znamená, že někdy musíte zajistit více úložiště, než potřebujete, jen abyste získali odpovídající IOPS, což je nuance, která zaskočí mnoho uživatelů cloudu při prvním nasazení.

Síťová šířka pásma určuje, kolik dat může váš server odeslat a přijmout za sekundu. U webových aplikací je odchozí šířka pásma obvykle úzkým hrdlem, protože servery odesílají uživatelům mnohem více dat, než přijímají. Stránka o velikosti 2 MB obsluhovaná 100 souběžnými uživateli vyžaduje ve špičce 200 MB/s odchozí šířky pásma. CDN před vaším serverem to výrazně snižuje díky cachování statických souborů na okrajových uzlech, ale dynamický obsah stále musí putovat z vašeho originálního serveru.

Většina poskytovatelů cloudu zahrnuje základní přidělení šířky pásma u každé velikosti instance a účtuje poplatky za překročení tohoto limitu. V GRADAXu naše plány webhostingu zahrnují štědré limity šířky pásma, protože jsme zjistili, že neočekávané poplatky za šířku pásma patří k největším překvapením ve fakturaci pro nováčky v cloudu. Doporučujeme sledovat měsíční spotřebu šířky pásma během prvních tří měsíců a nastavit upozornění na 80 % přiděleného limitu, abyste se vyhnuli šoku z vyúčtování. U webů s velkým množstvím médií nebo aplikací, které nabízejí velké soubory ke stažení, zahrňte náklady na šířku pásma do rozhodování o dimenzování spolu s CPU, RAM a úložištěm.

Síťová latence je stejně důležitá, zejména pro geograficky rozptýlené publikum. Server ve Frankfurtu poskytuje latenci pod 20 ms uživatelům ve střední Evropě, ale 150 ms nebo více uživatelům v Asii a Tichomoří. Pokud vaše publikum zahrnuje více kontinentů, jedna lokalita serveru neposkytne konzistentní zážitek. Nasazení ve více regionech nebo CDN s cachováním na okrajových uzlech je nezbytné. Obvykle doporučujeme začít s jedním regionem nejblíže většině vašich uživatelů a rozšířit se do dalších regionů až tehdy, když výkonnostní data ospravedlní dodatečnou složitost a náklady.

Pro weby na WordPressu s až 100 000 měsíčními návštěvníky doporučujeme začít se 2 vCPU, 4 GB RAM a 40 GB úložiště NVMe SSD. Tato konfigurace pohodlně zvládá WordPress, MySQL, objektovou cache Redis a Nginx s rezervou pro špičky v návštěvnosti. E-shopy na WooCommerce s aktivními sklady by měly přidat 2 GB RAM navíc a zvážit samostatnou databázovou instanci, jakmile návštěvnost přesáhne 200 000 měsíčních návštěvníků nebo katalog produktů překročí 10 000 položek.

Aplikace v Node.js se velmi liší podle své architektury. Jednoduché API v Express.js obsluhující JSON odpovědi běží efektivně na 1 vCPU a 1 GB RAM pro středně velký provoz. Aplikace v Next.js s vykreslováním na straně serveru vyžaduje 2 až 4 vCPU a 2 až 4 GB RAM, protože každé vykreslení je náročné na CPU. Aplikace v reálném čase používající WebSockets potřebují více paměti pro udržení trvalých připojení, počítejte přibližně 10 KB RAM na souběžné připojení, což znamená, že 100 000 souběžných připojení vyžaduje přibližně 1 GB RAM jen pro stav připojení, plus to, co vyžaduje logika aplikace.

E-commerce platformy s dedikovanou serverovou infrastrukturou mají nejnáročnější požadavky kvůli kombinaci dynamického vykreslování stránek, databázových dotazů na katalogy produktů a skladové zásoby, zpracování košíku a pokladny v reálném čase a poskytování obrázků. Středně velký e-shop s 500 000 měsíčními návštěvníky obvykle potřebuje 4 až 8 vCPU, 8 až 16 GB RAM, 100 GB nebo více SSD úložiště a samostatný databázový server s alespoň 8 GB RAM. Během špičkových akcí, jako jsou flash sales nebo sváteční promoakce, se tyto požadavky mohou zdvojnásobit nebo ztrojnásobit, což činí možnosti automatického škálování nezbytnými.

Škálování nahoru (vertikální škálování) znamená přidání více CPU, RAM nebo úložiště k existujícímu serveru. Škálování do šířky (horizontální škálování) znamená přidání více serverů za load balancer. Každý přístup má kompromisy, které by měly ovlivnit vaše rozhodnutí. Škálování nahoru je jednodušší: žádné změny architektury aplikace, žádná konfigurace load balanceru, žádné starosti se správou relací. Dobře funguje pro databáze, monolitické aplikace a zátěže, které je obtížné distribuovat mezi více uzlů.

Škálování do šířky je odolnější a při větším rozsahu nákladově efektivnější. Pokud jeden server v horizontálně škálovaném clusteru selže, zbývající servery absorbují zátěž s minimálním dopadem. Horizontální škálování vám také umožňuje používat menší a levnější instance, které společně poskytují více výpočetního výkonu než jedna velká instance při nižších celkových nákladech. Horizontální škálování však vyžaduje, aby vaše aplikace byla bezstavová nebo aby externalizovala stav relace do sdíleného úložiště, jako je Redis. Vyžaduje také load balancer a přináší složitost v nasazování, logování a ladění.

Naše obecné doporučení je nejprve škálovat nahoru, dokud nedosáhnete přirozeného stropu, obvykle kolem 8 až 16 vCPU a 32 až 64 GB RAM, a teprve poté škálovat do šířky. Tento přístup minimalizuje provozní složitost, dokud je vaše zátěž dostatečně malá, aby se vešla na jeden stroj. Jakmile vertikální škálování přestane stačit, investujte do architektonických změn potřebných pro horizontální škálování, které vám budou dobře sloužit, jak bude provoz dále růst. Kontaktujte náš infrastrukturní tým pro personalizované posouzení dimenzování na základě charakteristik vaší konkrétní zátěže.

Počáteční dimenzování je kvalifikovaný odhad. Správné dimenzování je průběžná praxe úpravy zdrojů na základě skutečných dat o využití. Doporučujeme shromáždit alespoň dva týdny výkonnostních metrik, než provedete úpravy dimenzování, ideálně čtyři až šest týdnů, abyste zachytili týdenní cykly provozu, měsíční fakturační cykly a případné sezónní výkyvy. Mezi klíčové metriky ke sledování patří průměrné a špičkové vytížení CPU, využití paměti a aktivita swapu, doba čekání na disk I/O a síťová propustnost.

Automatizované nástroje pro správné dimenzování mohou analyzovat vzorce využití a doporučit optimalizace. V GRADAXu naše monitorovací platforma označuje instance, kde průměrné vytížení CPU zůstává pod 20 % po více než 14 po sobě jdoucích dní, což naznačuje možné předimenzování. Také upozorňuje, když některý zdroj trvale překročí 75% vytížení, což signalizuje, že by mělo být naplánováno škálování nahoru nebo do šířky dříve, než výkon poklesne. Tato upozornění pomohla našim klientům snížit výdaje na infrastrukturu v průměru o 28 % během prvních šesti měsíců monitorování.

Optimalizace velikosti není jen o snižování nákladů. Stejně důležité je zajistit odpovídající výkon, jak zátěž roste. Server, který před šesti měsíci fungoval bezchybně, může mít dnes problémy, protože databáze narostla, provoz se zvýšil nebo nové funkce přidaly výpočetní režii. Naplánujte čtvrtletní kontroly dimenzování, při nichž zkoumáte trendy využití prostředků a porovnáváte je s metrikami výkonu aplikace, jako je doba odezvy a míra chybovosti. Tento postup zachytí postupné vyčerpávání prostředků dříve, než se projeví jako problémy s výkonem viditelné pro uživatele, a zajistí, že vaše investice do infrastruktury zůstane v souladu se skutečnou poptávkou.