Vodnik za dimenzioniranje oblakov: koliko CPU, RAM in pomnilnika?

Izbira pravilne konfiguracije oblaka je ena najpomembnejših odločitev v vsakem projektu gostovanja. Če pretiravate, vsak mesec zapravljate denar za vire, ki stojijo prazni. Če premalo dimenzionirate, vaša aplikacija trpi zaradi počasnih odzivnih časov, časovnih omejitev ali popolnega sesutja med pikami prometa. Nobenega od teh izidov ni mogoče sprejeti za proizvodno obremenitev, kljub temu pa veliko podjetij izbere velikost strežnika na podlagi intuicije, privzetih nastavitev ponudnika ali konfiguracije, ki jo je pred tremi leti priporočil blog.

Finančni vpliv napačnega dimenzioniranja je znaten. Naša analiza več kot 200 selitev strank kaže, da povprečno podjetje pretirava z oblakom za 35 % do 50 %, ko konfigurira strežnike brez vodstva, utemeljenega na podatkih. Pri mesečnem računu v višini 200 evrov to predstavlja 70 do 100 evrov zapravljenih vsak mesec, kar pomeni več kot 800 do 1.200 evrov na leto. Nasprotno pa premalo dimenzionirani strežniki povzročajo težave s performanso, ki neposredno vplivajo na prihodke. Za e-trgovinske strani lahko enosekundno povečanje časa nalaganja strani zmanjša konverzije za 7 %, kar je strošek, ki daleč presega prihranke pri izbiri manjšega strežnika.

Pravilno dimenzioniranje ni enkratna odločitev. Obremenitve se spreminjajo, ko rastejo aplikacije, se spreminjajo vzorci prometa in se širi nabor funkcij. Konfiguracija strežnika, ki je bila pred šestimi meseci popolna, je morda danes neučinkovita. Ta vodnik zagotavlja okvir za sprejemanje informiranih odločitev o dimenzioniranju ob zagonu in njihovo prilagajanje s časom na podlagi dejanskih podatkov o performansah. Ne glede na to, ali uvajate preprost marketinški site ali kompleksno aplikacijsko kupolo, vam bodo ta načela pomagala učinkovito dodeljevati vire.

Jedra CPU določajo, koliko operacij lahko vaš strežnik izvaja hkrati. Aplikacije, ki obdelujejo veliko sočasnih zahtevkov, spletni strežniki, končne točke API, obdelava podatkov v realnem času, imajo koristi od večjega števila jeder. Aplikacije, ki izvajajo intenzivne enonitne izračune, kodiranje videa, znanstvene izračune, določene operacije baz podatkov, imajo večjo korist od hitrejših posameznih jeder. Razumevanje tega, kateremu vzorcu sledi vaša obremenitev, je prvi korak pri dimenzioniranju CPU.

Za večino spletnih aplikacij bi moral biti povprečni izkoristek CPU med 30 % in 60 % pod normalno obremenitvijo, s prostim prostorom za obvladovanje pik prometa do 80 %, preden se zmogljivost poslabša. Če je vaš povprečni izkoristek CPU pod 20 %, verjetno pretiravate z zmogljivostmi in bi lahko varno zmanjšali paket. Če redno presega 70 %, morate razmisliti o povečanju ali širjenju infrastrukture, preden uporabniki občutijo zamude. Spletna stran WordPress, ki oskrbuje 50.000 obiskovalcev na mesec, običajno udobno teče na 2 vCPU. Node.js API, ki obdela 500 zahtevkov na sekundo, morda potrebuje 4 do 8 vCPU, odvisno od kompleksnosti vsakega zahtevka.

Sodobni ponudniki oblakov ponujajo različne vrste procesorjev, optimizirane za različne obremenitve. Inštanca, optimizirane za izračune, zagotavljajo višje urejene frekvence in so idealne za naloge, ki so omejene z procesorjem. Splošne namenske inštanca uravnotežijo procesor, pomnilnik in omrežje za tipične spletne obremenitve. V GRADAX privzeto uporabljamo splošne namenske inštanca za večino namestitev strank in priporočamo optimizirane za izračune le, če profiliranje potrdi, da je procesor glavna ovira. Izbira prave vrste procesorja lahko prinese 20 % do 30 % boljšo zmogljivost pri isti cenovni točki, zato se dodatna analiza povrne.

Pomnilnik je pogosto vir, ki določa, ali aplikacija teče gladko ali se sesuje pod obremenitvijo. Za razliko od procesorja, ki lahko ustvari čakalne vrste opravil, ko je zasičen (kar rezultira v počasnejših odzivih), pomanjkanje RAM sproži jedrov mehanizem za izklop zaradi pomanjkanja pomnilnika, ki nenadoma zaključi procese in lahko onesposobi celotno aplikacijo. Zato priporočamo dimenzioniranje RAM z večjo varnostno margino kot pri procesorju, ciljno povprečno izkoriščenost 50 % do 70 %, kar pušča znaten prosti prostor za pike prometa in uhajanje pomnilnika.

Različni aplikacijski skladi imajo drastično različne zahteve po pomnilniku. Statična spletna stran, ki jo streže Nginx, potrebuje le 256 MB. PHP spletna stran WordPress z objektnim predpomnjenjem in bazo podatkov, ki teče na istem strežniku, potrebuje 2 do 4 GB. Java Spring Boot aplikacija z vgrajenim primerkom Elasticsearch morda potrebuje 8 do 16 GB. Node.js aplikacije so nekje med njima, običajno potrebujejo 1 do 4 GB na proces, odvisno od velikosti podatkovnih paketov in sočasnih povezav. Ko več storitev deli strežnik, seštejte njihove individualne zahteve plus 20 % rezervo za operacijski sistem in ozadjske procese.

Strežniki baz podatkov zaslužijo posebno pozornost pri dimenzioniranju RAM. Baze podatkov delujejo dramatično bolje, ko se njihov delovni nabor, podatki, ki se aktivno poizvedujejo, popolnoma prilega v pomnilnik. MySQL baza podatkov z delovnim naborom 5 GB, ki teče na strežniku z 4 GB RAM, bo stalno brala z diska, kar rezultira v časih poizvedovanj, ki merjeni v milisekundah postanejo desetina milisekund ali več. Enaka baza podatkov z 8 GB RAM ohranja delovni nabor v predpomnilniku, kar zagotavlja dosledne branja pod milisekundo. Za namenske strežnike baz podatkov priporočamo dodelitev 1,5- do 2-kratne velikosti delovnega nabora v RAM kot izhodišče.

Oblačna shramba je razdeljena v tri glavne stopnje: NVMe SSD, standardni SSD in blok shramba na osnovi HDD. NVMe SSD-ji zagotavljajo najvišjo zmogljivost s hitrostmi branja, ki presegajo 3.000 MB/s, ter naključnimi operacijami I/O v stotisočih na sekundo. Standardni SSD-ji ponujajo ravnovesje med zmogljivostjo in stroški, običajno z pretočnostjo med 500 in 1.000 MB/s. Shramba na osnovi HDD je najbolj cenovno ugodna, vendar uvaja znatno zakasnitev pri naključnem branju, zato je primerna le za arhivske podatke, dnevnike in zaporedne obremenitve, kot so varnostne kopije.

Pri določanju kapacitete shrambe začnite s trenutnim obsegom podatkov in napovedujte rast v naslednjih 12 do 18 mesecih. Tipična spletna stran WordPress z medijsko knjižnico potrebuje 5 do 20 GB. E-trgovinska platforma s slikami izdelkov lahko potrebuje 50 do 200 GB. Aplikacija SaaS z uporabniško generirano vsebino se lahko nepredvidljivo širi in ima korist od skalabilne shrambe, ki se lahko povečuje brez izpada sistema. Vedno rezervirajte vsaj 20 % prostora na vsaki enoti; datotečni sistemi in baze podatkov izgubljajo zmogljivost, ko se približujejo polni kapaciteti, poraba celotnega diskovnega prostora pa je eden najpogostejših vzrokov za nepričakovane izpade.

IOPS (operacije vhoda/izhoda na sekundo) je metrika shrambe, ki najbolj vpliva na zmogljivost aplikacije, vendar jo pri načrtovanju pogosto spregledamo. Aplikacija, ki je močno odvisna od baz podatkov, morda potrebuje 3.000 do 10.000 IOPS za ohranjanje sprejemljive zmogljivosti poizvedb. Vsebinsko bogata spletna stran z večinoma bralnimi operacijami morda potrebuje le 500 IOPS. Številni ponudniki oblaka povezujejo IOPS z velikostjo enote; 100 GB enota je morda omejena na 3.000 IOPS, medtem ko 500 GB enota prejme 15.000. To pomeni, da morate včasih nameniti več shrambe, kot dejansko potrebujete, samo da dosežete zadostne IOPS, kar je podrobnost, ki preseneti mnoge prve uporabnike oblaka.

Mrežna pasovna širina določa, koliko podatkov lahko vaš strežnik pošlje in prejme na sekundo. Za spletne aplikacije je pasovna širina za pošiljanje podatkov navzven običajno ovira, saj strežniki uporabnikom pošljejo veliko več podatkov, kot jih prejmejo. Stran, ki tehta 2 MB in je postrežena 100 hkratnim uporabnikom, zahteva 200 MB/s pasovne širine navzven v vrhu obremenitve. CDN pred vašim strežnikom to drastično zmanjša z predpomnjenjem statičnih virov na robovih omrežja, vendar dinamična vsebina še vedno potuje od vašega izvornega strežnika.

Večina ponudnikov oblaka vključuje osnovno alokacijo pasovne širine za vsako velikost instance in zaračunava pristojbine za presežek čez to mejo. Pri GRADAX naši načrti gostovanja spletnih strani vključujejo obilne dovoljenja za pasovno širino, ker smo opazili, da so nepričakovani stroški pasovne širine med glavnimi presenečenji pri računih za nove uporabnike oblaka. Priporočamo spremljanje mesečne porabe pasovne širine v prvih treh mesecih in opozorilo pri 80 % vaše alokacije, da se izognete nenadnim skokom stroškov. Za spletne strani z veliko medijev ali aplikacije, ki strežejo velika prenosa datotek, upoštevajte stroške pasovne širine pri odločitvi o dimenzioniranju skupaj s CPU, RAM in shrambo.

Mrežna zakasnitev je enako pomembna, zlasti za geografsko razpršeno občinstvo. Strežnik v Frankfurtu zagotavlja zakasnitev pod 20 ms uporabnikom po srednji Evropi, a 150 ms ali več uporabnikom v Aziji in Pacifiku. Če vaše občinstvo zajema več celin, ena lokacija strežnika ne bo zagotovila dosledne izkušnje. Večregijska namestitev ali CDN z robnim predpomnjenjem sta nujna. Običajno priporočamo začetek z eno regijo, ki je najbližje večini vaše uporabniške baze, in širjenje na dodatne regije le, če podatki o zmogljivosti utemeljujejo dodano kompleksnost in stroške.

Za spletne strani WordPress z do 100.000 mesečnih obiskovalcev priporočamo začetek z 2 vCPU, 4 GB RAM in 40 GB shrambe NVMe SSD. Ta konfiguracija udobno obravnava WordPress, MySQL, predpomnilnik Redis in Nginx z rezervo za prometne vrhunce. Trgovine WooCommerce z aktivnimi zalihami bi morale dodati še 2 GB RAM in razmisliti o ločeni instanci baze podatkov, ko promet preseže 200.000 mesečnih obiskovalcev ali katalog izdelkov preseže 10.000 elementov.

Aplikacije Node.js se močno razlikujejo glede na njihovo arhitekturo. Preprosta API Express.js, ki strežuje odgovore JSON, učinkovito deluje na 1 vCPU in 1 GB RAM za zmerno obremenitev. Aplikacija Next.js z izvajanjem na strežniku zahteva 2 do 4 vCPU in 2 do 4 GB RAM, ker je vsako upodabljanje zahtevno za CPU. Aplikacije v realnem času, ki uporabljajo WebSockets, potrebujejo več pomnilnika za vzdrževanje trajnih povezav; proračunirajte približno 10 KB RAM na hkrato povezavo, kar pomeni, da 100.000 hkratnih povezav zahteva približno 1 GB RAM samo za stanje povezave, plus vse, kar zahteva logika aplikacije.

E-trgovinske platforme z namenskimi strežniškimi infrastrukturnimi rešitvami imajo najbolj zahtevne zahteve zaradi kombinacije dinamičnega upodabljanja strani, poizvedb baze podatkov za kataloge izdelkov in zalog, obdelave vozička in plačila v realnem času ter strežbanja slik. Srednje velika e-trgovinska stran, ki obravnava 500.000 mesečnih obiskovalcev, običajno potrebuje 4 do 8 vCPU, 8 do 16 GB RAM, 100 GB ali več SSD shrambe in ločen strežnik baze podatkov z vsaj 8 GB RAM. Med vrhunskimi dogodki, kot so bliskovite prodaje ali praznične promocije, se te zahteve lahko podvojijo ali potrojijo, kar naredi funkcije samodejnega skaliranja nujne.

Povečanje zmogljivosti (navpično skaliranje) pomeni dodajanje več CPU, RAM ali shrambe obstoječemu strežniku. Razširitev sistema (vodoravno skaliranje) pomeni dodajanje več strežnikov za uravnotežilcem obremenitve. Vsak pristop ima kompromise, ki bi morali vplivati na vašo odločitev. Povečanje zmogljivosti je preprostejše: brez sprememb arhitekture aplikacije, brez konfiguracije uravnotežilca obremenitve, brez skrbi za upravljanje sej. Dobro deluje za baze podatkov, monolitne aplikacije in obremenitve, ki jih je težko porazdeliti med več vozlišč.

Razširitev sistema je bolj odporna in stroškovno učinkovita pri večjih lestvicah. Če en strežnik v vodoravno skaliranem klasterju odpove, preostali strežniki absorbirajo obremenitev z minimalnim vplivom. Vodoravno skaliranje vam tudi omogoča uporabo manjših, cenejših instanc, ki skupaj zagotavljajo več računske moči kot en sam velik strežnik pri nižjih skupnih stroških. Vendar pa vodoravno skaliranje zahteva, da je vaša aplikacija brez stanja ali da zunanjost stanja seje prenese v skupni predpomnilnik, kot je Redis. Prav tako zahteva uravnotežilec obremenitve in uvaja kompleksnost v namestitvah, beleženje dogodkov in odpravljanje napak.

Naša splošna priporočila so, da najprej povečate zmogljivost, dokler ne dosežete naravne meje, običajno okoli 8 do 16 vCPU in 32 do 64 GB RAM, in nato razširite sistem. Ta pristop minimizira operativno kompleksnost, dokler je vaša obremenitev majhna in se prilega na en stroj. Ko prekoračite navpično skaliranje, vlagajte v spremembe arhitekture, potrebne za vodoravno skaliranje, kar vam bo dobro služilo, ko bo promet nadaljeval rasti. Kontaktirajte našo infrastrukturno ekipo za osebno oceno dimenzioniranja glede na specifične značilnosti vaše obremenitve.

Začetno dimenzioniranje je izobražena ocena. Pravilno dimenzioniranje je stalna praksa prilagajanja virov na podlagi dejanskih podatkov o uporabi. Priporočamo zbiranje vsaj dveh tednov meril zmogljivosti pred spreminjanjem dimenzij in idealno štiri do šest tednov, da zajmete tedenske cikle prometa, mesečne obračunske cikle in morebitne sezonske variacije. Ključna metrika za spremljanje vključujejo povprečno in vrhunsko zasedenost CPU, uporabo pomnilnika in aktivnost zamenjave, čas čakanja na vhod/izhod diska in mrežno pretočnost.

Samodejna orodja za pravilno dimenzioniranje lahko analizirajo vzorce uporabe in priporočajo optimizacije. Pri GRADAX naša platforma za spremljanje označi instance, kjer povprečna zasedenost CPU ostane pod 20 % več kot 14 zaporednih dni, kar kaže na potencialno prekomerno namensko dodelitev. Prav tako opozori, kadar kateri koli vir dosledno presega 75 % zasedenosti, kar signalizira, da bi bilo treba načrtovati dogodek povečanja ali razširitve, preden se zmogljivost poslabša. Ta opozorila so našim strankam pomagala zmanjšati stroške infrastrukture za povprečno 28 % v prvih šestih mesecih spremljanja.

Prilagajanje virov ni le o zniževanju stroškov. Enako pomembno je zagotoviti ustrezno zmogljivost, ko se obremenitve povečujejo. Strežnik, ki je bil pred šestimi meseci popolnoma stabilen, lahko danes zaostaja zaradi rasti baze podatkov, večjega prometa ali novih funkcij, ki dodajo izračunsko obremenitev. Načrtujte četrtletne preglede prilagajanja virov, kjer analizirate trende izkoriščenosti virov in jih primerjajte s kazalniki zmogljivosti aplikacij, kot so čas odziva in stopnja napak. Ta praksa pravočasno zazna postopno izčrpavanje virov, preden se kažejo v vidnih težavah uporabnikov, ter zagotavlja, da so naložbe v infrastrukturo usklajene z dejansko povpraševanjem.