Vodič za određivanje veličine cloud poslužitelja: Koliko CPU-a, RAM-a i pohrane?

Odabir pravilne cloud server konfiguracije jedna je od najvažnijih odluka u bilo kojem hosting projektu. Ako pretjerate s kapacitetom, mjesečno bacate novac na resurse koji stoje neiskorišteni. Ako premalo optimirate, vaša aplikacija pati od sporih vremena odgovora, vremenskih ograničenja ili potpunih prekida rada tijekom skokova prometa. Nijedan ishod nije prihvatljiv za produkcijsko opterećenje, no iznenađujući broj tvrtki bira veličinu poslužitelja na temelju intuicije, zadanih postavki pružatelja ili konfiguracije koju je prije tri godine preporučio neki tutorial blog.

Financijski utjecaj pogrešnog određivanja veličine značajan je. Naša analiza više od 200 migracija klijenata pokazala je da prosječna tvrtka pretjeruje s cloud resursima za 35% do 50% kada konfigurira poslužitelje bez vođenja podacima. Na mjesečnom računu od 200 eura to predstavlja 70 do 100 eura izgubljenih mjesečno, preko 800 do 1.200 eura godišnje. Suprotno tome, nedovoljno optimizirani poslužitelji uzrokuju probleme s performansama koji izravno utječu na prihode. Za e-trgovine, povećanje vremena učitavanja stranice za jednu sekundu može smanjiti konverzije za 7%, što je trošak koji daleko premašuje uštede od odabira manjeg poslužitelja.

Pravilno određivanje veličine nije jednokratna odluka. Opterećenja se mijenjaju kako aplikacije rastu, obrasci prometa se pomiču, a skupine funkcija se šire. Konfiguracija poslužitelja koja je bila savršena prije šest mjeseci možda je danas neučinkovita. Ovaj vodič pruža okvir za donošenje informiranih odluka o veličini pri lansiranju i njihovo prilagođavanje tijekom vremena na temelju stvarnih performansi. Bilo da deployate jednostavnu marketinšku stranicu ili složenu aplikacijsku stogu, ovi principi pomoći će vam učinkovito raspodijeliti resurse.

Broj CPU jezgri određuje koliko operacija vaš poslužitelj može izvršavati istovremeno. Aplikacije koje obrađuju mnogo istovremenih zahtjeva, web poslužitelji, API endpointi i obrada podataka u stvarnom vremenu imaju koristi od većeg broja jezgri. Aplikacije koje izvode intenzivne jednothreadove izračune, kodiranje videa, znanstvene kalkulacije ili određene baze podataka, više koriste brže pojedinačne jezgre. Razumijevanje obrasca rada vašeg opterećenja prvi je korak u određivanju veličine CPU-a.

Kod većine web aplikacija iskorištenost CPU-a trebala bi prosječno biti između 30% i 60% pod normalnim opterećenjem, uz rezervu kapaciteta za rukovanje skokovima prometa do 80% prije nego što performanse počnu padati. Ako je prosječna iskorištenost CPU-a ispod 20%, vjerojatno imate pretjerano velike kapacitete i možete sigurno smanjiti specifikacije. Ako redovito prelazi 70%, trebali biste razmotriti povećanje ili širenje kapaciteta prije nego što korisnici osjete kašnjenje. WordPress stranica koja opslužuje 50.000 mjesečnih posjetitelja obično stabilno radi na 2 vCPU-a. Node.js API koji obrađuje 500 zahtjeva u sekundi može zahtijevati 4 do 8 vCPU-a ovisno o složenosti svakog zahtjeva.

Moderni cloud pružatelji nude različite vrste CPU-a optimizirane za različita opterećenja. Instance optimizirane za izračun (compute-optimized) pružaju više brzine taktiranja i idealne su za zadatke vezane uz CPU. Opće namjene instance balansiraju CPU, memoriju i mrežu za tipična web opterećenja. U GRADAX-u po defaultu koristimo instance opće namjene za većinu klijentskih deployanja i preporučujemo instance optimizirane za izračun samo kada profiliranje potvrdi da je CPU glavna uska grla. Odabir prave vrste CPU-a može donijeti 20% do 30% bolje performanse na istoj cijeni, što opravdava dodatnu analizu.

Memorija je često resurs koji određuje hoće li aplikacija glatko raditi ili će se srušiti pod opterećenjem. Za razliku od CPU-a, koji može čekati rad kada je zasićen (što rezultira sporijim odgovorima), nedostatak RAM-a aktivira kernelov out-of-memory killer, koji naglo terminira procese i može srušiti cijelu aplikaciju. Iz tog razloga preporučujemo određivanje veličine RAM-a s većom sigurnosnom marginom nego kod CPU-a, ciljajte na 50% do 70% prosječnu iskorištenost, ostavljajući značajan prostor za skokove prometa i curenje memorije.

Različite aplikacijske stuge imaju drastično različite zahtjeve za memoriju. Statička stranica koju poslužuje Nginx treba samo 256 MB. PHP WordPress stranica s object cachingom i bazom podataka koja radi na istom poslužitelju treba 2 do 4 GB. Java Spring Boot aplikacija s ugrađenom Elasticsearch instancom može zahtijevati 8 do 16 GB. Node.js aplikacije nalaze se negdje između, obično zahtijevajući 1 do 4 GB po procesu ovisno o veličini payloada i istovremenim vezama. Kada više usluga dijeli poslužitelj, zbrojte njihove pojedinačne zahtjeve plus 20% rezerve za operativni sustav i pozadinske procese.

Poslužitelji baza podataka zaslužuju posebnu pažnju pri određivanju veličine RAM-a. Baze podataka rade znatno bolje kada se njihov radni skup, podaci koji se aktivno upituju, stane u potpunosti u memoriju. MySQL baza podataka s radnim skupom od 5 GB koja radi na poslužitelju s 4 GB RAM-a stalno čita s diska, zbog čega vremena upita koja se mjeru u milisekundama postaju desetcima milisekundi ili više. Ista baza podataka s 8 GB RAM-a zadržava radni skup u predmemoriji, isporučujući dosljedna čitanja u sub-milisekundama. Za namjenske poslužitelje preporučujemo dodjeljivanje 1,5x do 2x veličine radnog skupa u RAM-u kao početnu točku.

Cloud pohrana dijeli se na tri glavne razine: NVMe SSD, standardni SSD i pohrana blokova temeljena na HDD-u. NVMe SSD-ovi pružaju najvišu izvedbu s brzinama čitanja većima od 3.000 MB/s i stotinama tisuća nasumičnih operacija ulaza/izlaza (I/O) u sekundi. Standardni SSD-ovi nude balans između izvedbe i troškova, obično postižući propusnost od 500 do 1.000 MB/s. Pohrana temeljena na HDD-u najpovoljnija je opcija, ali uvodi značajno kašnjenje za nasumična čitanja, što je čini prikladnom samo za arhivske podatke, zapise dnevnika i sekvencijalna opterećenja poput sigurnosnih kopija.

Za procjenu kapaciteta pohrane krenite od trenutnog opsega podataka i projekcije rasta tijekom 12 do 18 mjeseci. Tipična WordPress stranica s bibliotekom medija treba 5 do 20 GB. E-trgovinska platforma sa slikama proizvoda može zahtijevati 50 do 200 GB. SaaS aplikacija s korisnički generiranim sadržajem može nekontrolirano rasti i koristi se od skalabilne pohrane koja se može proširiti bez prekida rada. Uvijek rezervirajte najmanje 20% slobodnog prostora na svakom volumenu; datotečni sustavi i baze podataka degradiraju izvedbu kako se približavaju punom kapacitetu, a nedostatak diskovnog prostora jedan je od najčešćih uzroka neočekivanih prekida rada.

IOPS (Operacije ulaza/izlaza u sekundi) metrika je pohrane koja najviše utječe na izvedbu aplikacije, no često se zanemaruje tijekom planiranja kapaciteta. Aplikacija intenzivno korištena za baze podataka možda će trebati 3.000 do 10.000 IOPS-a za održavanje prihvatljive izvednosti upita. Stranica bogata sadržajem s uglavnom operacijama čitanja možda će trebati samo 500 IOPS-a. Mnogi pružatelji oblaka povezuju IOPS s veličinom volumena; volumen od 100 GB može biti ograničen na 3.000 IOPS-a, dok volumen od 500 GB dobiva 15.000. To znači da ponekad morate rezervirati više prostora za pohranu nego što vam je stvarno potrebno isključivo kako biste osigurali adekvatne IOPS-ove, što je nijansa koja mnoge početnike u oblaku iznenadi.

Mrežna širina pojasa određuje koliko podataka vaš poslužitelj može slati i primati u sekundi. Za web aplikacije vanjska širina pojasa obično je usko grlo jer poslužitelji šalju znatno više podataka korisnicima nego što ih primaju. Stranica teška 2 MB poslana istovremeno 100 korisnika zahtijeva 200 MB/s vanjske širine pojasa u vršnim trenucima. CDN ispred vašeg poslužitelja drastično smanjuje ovo opterećenje predajom statičkih resursa na rubnim lokacijama, no dinamički sadržaj i dalje mora putovati od vašeg izvornog poslužitelja.

Većina pružatelja oblaka uključuje osnovnu alokaciju širine pojasa s veličinom svake instance i naplaćuje naknade za prekomjernu potrošnju izvan tog limita. U GRADAX-u naši planovi web hostinga uključuju velikodušne limite širine pojasa jer smo uočili da su neočekivane naknade za širinu pojasa jedan od glavnih iznenađenja na računu za nove korisnike oblaka. Preporučamo praćenje mjesečne potrošnje širine pojasa tijekom prva tri mjeseca i postavljanje upozorenja na 80% vaše alokacije kako biste izbjegli neočekivane troškove. Za stranice bogate medijima ili aplikacije koje poslužuju velike datoteke za preuzimanje, uračunajte troškove širine pojasa u svoju procjenu kapaciteta uz CPU, RAM i pohranu.

Mrežno kašnjenje jednako je važno, posebno za geografski distribuiranu publiku. Poslužitelj u Frankfurtu isporučuje kašnjenje manje od 20 ms korisnicima širom srediње Europe, ali 150 ms ili više korisnicima u Aziji i Pacifiku. Ako vaša publika obuhvaća više kontinenata, jedna lokacija poslužitelja neće pružiti dosljedno iskustvo. Višeregionska implementacija ili CDN s predmemoriranjem na rubu nužni su. Obično preporučujemo početak s jednom regijom najbližom većini vaše korisničke baze i proširenje na dodatne regije samo kada podaci o izvedbi opravdavaju dodanu složenost i trošak.

Za WordPress stranice s do 100.000 mjesečnih posjeta preporučujemo početak s 2 vCPU-a, 4 GB RAM-a i 40 GB NVMe SSD pohrane. Ova konfiguracija udobno obrađuje WordPress, MySQL, Redis predmemoriju objekata i Nginx s rezervom za prometne pikove. WooCommerce trgovine s aktivnim zalihama trebale bi dodati dodatnih 2 GB RAM-a i razmotriti zasebnu instancu baze podataka jednom kada promet prijeđe 200.000 mjesečnih posjeta ili katalog proizvoda premaši 10.000 stavki.

Node.js aplikacije značajno variraju ovisno o njihovoj arhitekturi. Jednostavni Express.js API koji poslužuje JSON odgovore učinkovito radi na 1 vCPU-u i 1 GB RAM-a za umjeren promet. Next.js aplikacija s renderiranjem na strani poslužitelja zahtijeva 2 do 4 vCPU-a i 2 do 4 GB RAM-a jer je svako renderiranje zahtjevno za CPU. Stvarnovremene aplikacije koje koriste WebSokete trebaju više memorije za održavanje trajnih veza; budžetirajte otprilike 10 KB RAM-a po istovremenoj vezi, što znači da 100.000 istovremenih veza zahtijeva otprilike 1 GB RAM-a samo za stanje veze, plus ono što zahtijeva logika aplikacije.

E-trgovinske platforme s namjenskom poslužiteljskom infrastrukturom imaju najzahtjevnije zahtjeve zbog kombinacije dinamičkog renderiranja stranica, upita baze podataka za kataloge proizvoda i zaliha, obrade košarice i plaćanja u stvarnom vremenu te posluživanja slika. Srednja e-trgovinska stranica koja obrađuje 500.000 mjesečnih posjeta obično treba 4 do 8 vCPU-a, 8 do 16 GB RAM-a, 100 GB ili više SSD pohrane i zaseban poslužitelj baze podataka s najmanje 8 GB RAM-a. Tijekom vrhunskih događaja poput flash prodaje ili blagdanskih promocija ti se zahtjevi mogu udvostručiti ili utrostručiti, što čini mogućnosti automatskog skaliranja nužnima.

Skaliranje prema gore (vertikalno) znači dodavanje više CPU-a, RAM-a ili pohrane postojećem poslužitelju. Skaliranje prema van (horizontalno) znači dodavanje više poslužitelja ispred balancera opterećenja. Svaki pristup ima kompromise koji treba uzeti u obzir pri donošenju odluke. Skaliranje prema gore je jednostavnije: nema promjena u arhitekturi aplikacije, nema konfiguracije balancera opterećenja, nema brige o upravljanju sesijama. Dobro funkcionira za baze podataka, monolitne aplikacije i radna opterećenja koja je teško distribuirati na više čvorova.

Skaliranje prema van otpornije je i isplativije na većim razinama. Ako jedan poslužitelj u horizontalno skaliranom klasteru otkaže, preostali poslužitelji apsorbiraju opterećenje s minimalnim utjecajem. Horizontalno skaliranje također vam omogućuje korištenje manjih, jeftinijih instanci koje zajedno pružaju više računalne snage od jedne velike instance uz niži ukupni trošak. Međutim, horizontalno skaliranje zahtijeva da vaša aplikacija bude bez stanja ili da eksternizira stanje sesije u zajedničku pohranu poput Redis-a. Također zahtijeva balancer opterećenja i uvodi složenost u implementacije, dnevnike i otklanjanje pogrešaka.

Naša opća preporuka je prvo skalirati prema gore dok ne dosegnete prirodni plafon, obično oko 8 do 16 vCPU-a i 32 do 64 GB RAM-a, a zatim skalirati prema van. Ovaj pristup minimizira operativnu složenost dok je vaše radno opterećenje dovoljno malo da stane na jedan stroj. Kada nadmašite mogućnosti vertikalnog skaliranja, investirajte u promjene arhitekture potrebne za horizontalno skaliranje, što će vam dobro poslužiti kako promet nastavi rasti. Kontaktirajte naš tim infrastrukture za personaliziranu procjenu kapaciteta temeljenu na specifičnim karakteristikama vašeg radnog opterećenja.

Početno planiranje kapaciteta je obrazovana procjena. Pravilno planiranje (right-sizing) je stalna praksa prilagodbe resursa na temelju stvarnih podataka o korištenju. Preporučujemo prikupljanje najmanje dva tjedna metričkih podataka o izvedbi prije donošenja prilagodbi kapaciteta, a idealno četiri do šest tjedana kako biste uhvatili tjedne cikluse prometa, mjesečne cikluse fakturiranja i bilo kakve sezonske varijacije. Ključne metrike za praćenje uključuju prosječnu i vršnu zauzetost CPU-a, korištenje memorije i aktivnost zamjene, vrijeme čekanja diskovnog I/O-a i mrežnu propusnost.

Alati za automatizirano pravilno planiranje mogu analizirati obrasce korištenja i preporučiti optimizacije. U GRADAX-u naša platforma za praćenje označava instance gdje prosječna zauzetost CPU-a ostaje ispod 20% više od 14 uzastopnih dana, što ukazuje na potencijalno prekomjerno rezerviranje. Također upozorava kada bilo koji resurs dosljedno prelazi 75% zauzetosti, signalizirajući da treba planirati događaj skaliranja prema gore ili prema van prije nego što izvedba degradira. Ova upozorenja pomogla su našim klijentima smanjiti troškove infrastrukture u prosjeku za 28% unutar prvih šest mjeseci praćenja.

Prilagodba kapaciteta nije samo o smanjenju troškova. Podjednako je važno osigurati adekvatnu performansu kako se opterećenja povećavaju. Poslužitelj koji je prije šest mjeseci radio savršeno, danas može imati problema jer je baza podataka narasla, promet porastao ili su nove značajke dodale računalni teret. Planirajte kvartalne preglede prilagodbe kapaciteta u kojima analizirate trendove iskorištenja resursa i uspoređujete ih s metrikama performansi aplikacije, poput vremena odziva i stope pogrešaka. Ova praksa otkriva postupno iscrpljivanje resursa prije nego što se manifestira kao problemi s performansama vidljivi korisnicima i osigurava da ulaganje u infrastrukturu ostane usklađeno sa stvarnim potrebama.