Mākoņa servera resursu apjoma rokasgrāmata: cik daudz CPU, RAM un glabātuvju?

Pareizas mākoņa servera konfigurācijas izvēle ir viena no vissvarīgākajām lēmumiem jebkurā hostinga projektā. Pārmērīgi novietojot resursus, katru mēnesi tiek tērēti naudas līdzekļi resursos, kas atrodas neizmantoti. Nepietiekami novietojot resursus, jūsu lietojumprogramma cieš no lēnas reaģēšanas laika, pārraušanās vai pilnīgas avārijas satiksmes pīķu laikā. Neviens no šiem rezultātiem nav pieņemams ražošanas vidē, tomēr pārsteidzošs skaits uzņēmumu izvēlas servera lielumu, balstoties uz intuīciju, piegādātāju noklusējuma vērtībām vai jebkuru konfigurāciju, ko trīs gadus atpakaļ ieteica kāds tehnisks blogposts.

Nepareiza resursu apjoma finansiālā ietekme ir nozīmīga. Mūsu vairāk nekā 200 klientu migrāciju analīze rāda, ka vidējais uzņēmums pārmērīgi novieto mākoņa resursus par 35% līdz 50%, konfigurējot serverus bez datiem balstītas vadlīnijas. Pie mēneša rēķina 200 eiro tas nozīmē 70 līdz 100 eiro tērētu veltīgi katru mēnesi, vairāk nekā 800 līdz 1 200 eiro gadā. Savukārt nepietiekami novietoti serveri rada veiktspējas problēmas, kas tieši ietekmē ieņēmumus. E-komercijas vietnēm vienas sekundes palielināšanās lapas ielādes laikā var samazināt konversiju par 7%, kas ir izmaksa, kas tālu pārsniedz ietaupījumu, izvēloties mazāku serveri.

Pareiza resursu apjoma izvēle nav vienreizējs lēmums. Noslodze mainās, attīstoties lietojumprogrammām, mainoties satiksmes modeļiem un paplašinoties funkciju kopumam. Servera konfigurācija, kas bija ideāla pirms sešiem mēnešiem, šodien var būt nepietiekama. Šī rokasgrāmata nodrošina rāmi informētu lēmumu pieņemšanai resursu apjoma izvēlē starta brīdī un to pielāgošanu nākotnē, balstoties uz reāliem veiktspējas datiem. Vai arī jūs izvietojat vienkāršu mārketinga vietni vai sarežģītu lietojumprogrammu kaudzi, šie principi palīdzēs jums efektīvi sadalīt resursus.

CPU kodoli nosaka, cik operācijas jūsu serveris var izpildīt vienlaicīgi. Lietojumprogrammas, kas apstrādā daudzas vienlaicīgas pieprasījumus, tīmekļa serveri, API galapunkti, reāllaika datu apstrāde, gūst labumu no augstākiem kodolu skaitiem. Lietojumprogrammas, kas veic intensīvas vienvirziena aprēķinus, video kodēšanu, zinātniskus aprēķinus, noteiktas datubāzu operācijas, gūst labumu ātrāku individuālo kodolu dēļ. Prasmes saprast, kurš modelis jūsu noslodzei raksturīga, ir pirmais solis CPU konfigurācijas izvēlē.

Lielākajai daļai tīmekļa lietojumprogrammu CPU izmantošanai vajadzētu vidēji svērt starp 30% un 60% normālas noslodzes laikā, ar rezervi, lai apstrādātu satiksmes pīķus līdz 80% pirms veiktspējas pasliktināšanās. Ja jūsu vidējā CPU izmantošana ir zemāka par 20%, jūs, iespējams, esat pārmērīgi novietojis resursus un droši varat samazināt konfigurāciju. Ja tā regulāri pārsniedz 70%, jums vajadzētu apsvērt iespēju palielināt vai paplašināt resursus, pirms lietotāji piedzīvo aiztures laiku. WordPress vietne, kas apkalpo 50 000 mēneša apmeklētāju, parasti ērti darbojas uz 2 vCPU. Node.js API, kas apstrādā 500 pieprasījumus sekundē, varētu nepieciešam 4 līdz 8 vCPU atkarībā no katra pieprasījuma sarežģītības.

Mūsdienu mākoņa pakalpojumu sniedzēji piedāvā dažādus CPU tipus, kas optimizēti dažādām noslodžēm. Aprēķinu optimizētas instances nodrošina augstākas pulksteņa frekvences un ir ideāli piemērotas CPU intensīvām uzdevumiem. Vispārējās instances līdzsvaro CPU, atmiņu un tīkla savienojumus tipiskām tīmekļa noslodžēm. GRADAX mēs noklusējuma kā vispārējās instances izmantojam lielākajai daļai klientu izvietošanas un iesakām aprēķinu optimizētas tikai tad, ja profilēšana apstiprina, ka CPU ir galvenais barjeru. Pareiza CPU tipa izvēle var nodrošināt 20% līdz 30% labāku veiktspēju tajā pašā cenu līmenī, padarot to vērtīgu papildu analīzi.

Atmiņa bieži ir resurss, kas nosaka, vai lietojumprogramma darbojas gludi vai avārija zem noslodzes. Atšķirībā no CPU, kas var rindoties darbu, kad piesātināts (rezultātā lēnāka reaģēšana), beidzoties RAM, tiek aktivizēts kodola out-of-memory killer, kas pārrauj procesus un var sabrukt visu jūsu lietojumprogrammu. Tāpēc mēs iesakām konfigurēt RAM ar lielāku drošības marginu nekā CPU, mērķis 50% līdz 70% vidējā izmantošana, atstājot ievērojamu rezervi satiksmes pīķiem un atmiņas noplūdēm.

Dažādas lietojumprogrammu kaudzes ir atšķirīgas atmiņas prasības. Statiska vietne, ko servē Nginx, vajag tikpat maz kā 256 MB. PHP WordPress vietne ar objekta kešatmiņu un datubāzi, kas darbojas uz tā paša servera, vajag 2 līdz 4 GB. Java Spring Boot lietojumprogramma ar iebūvētu Elasticsearch instanci var prasīt 8 līdz 16 GB. Node.js lietojumprogrammas atrodas kaut kur pa vidu, parasti vajadzīgs 1 līdz 4 GB uz procesu atkarībā no payload izmēriem un vienlaicīgiem savienojumiem. Kad vairāki pakalpojumi dalās serverī, saskaitiet to individuālās prasības plus 20% buferi operētājsistēmai un fona procesiem.

Datubāzu serveriem vajadzīga īpaša uzmanība RAM konfigurācijai. Datubāzes darbojas dramatiski labāk, kad to strādājošais komplekts, dati, kas tiek aktīvi vaicāti, pilnībā ietilpst atmiņā. MySQL datubāze ar 5 GB strādājošo komplektu, kas darbojas uz servera ar 4 GB RAM, pastāvīgi lasīs no diska, rezultējoties vaicājumu laikos, kas mērāmi milisekundēs, kļūstot desmitiem milisekunžu vai vairāk. Tā pati datubāze ar 8 GB RAM saglabā strādājošo komplektu kešatmiņā, nodrošinot konsekventus sub-milisekunžu lasījumus. Dedicated database servers mēs iesakām piešķirt 1.5x līdz 2x strādājošā komplekta izmēru RAM kā sākumpunktu.

Mākoņkrātuves piedāvā trīs galvenās līmeņus: NVMe SSD, standarta SSD un HDD bāzes bloku krātuvi. NVMe SSD nodrošina augstāko veiktspēju ar lasīšanas ātrumu, kas pārsniedz 3 000 MB/s, un gadījuma rakstura I/O operācijām simtiem tūkstošu sekundē. Standarta SSD piedāvā līdzsvaru starp veiktspēju un izmaksām, parasti nodrošinot 500 līdz 1 000 MB/s caurlaidspēju. Krātuve uz HDD ir vispieejamākā, taču tā ievieš būtisku aizkavi gadījuma rakstura lasīšanai, padarot to piemērotu tikai arhīva datiem, žurnāliem un secīgiem darbu plūsmām, piemēram, dublējumiem.

Krātuves kapacitātes noteikšanai sāciet ar pašreizējo datu apjomu un prognozējiet pieaugumu nākamajos 12 līdz 18 mēnešos. Tipiskai WordPress vietnei ar mediju bibliotēku nepieciešams 5 līdz 20 GB. E-komercijas platformai ar produktu attēliem var būt nepieciešams 50 līdz 200 GB. SaaS lietojumprogrammai ar lietotāju ģenerētiem datiem raksturīga neparedzama augšana, un tai ir izdevīga elastīga krātuve, kas var paplašināties bez dīkstāves. Vienmēr rezervējiet vismaz 20% brīvas vietas jebkurā tomā; failu sistēmas un datubāzes zaudē veiktspēju, tuvojoties pilnam apjomam, un diska vietas trūkums ir viens no biežākajiem neplānotu avāriju cēloņiem.

IOPS (Input/Output Operations Per Second) ir krātuves rādītājs, kas visvairāk ietekmē lietojumprogrammu veiktspēju, taču to bieži ignorē kapacitātes plānošanas laikā. Datubāzēm bagātīgai lietojumprogrammai var būt nepieciešami 3 000 līdz 10 000 IOPS, lai uzturētu pieņemamu vaicājumu veiktspēju. Saturam bagātīgai vietnei, kurā dominē lasīšanas operācijas, var pietikt ar tikai 500 IOPS. Daudzi mākoņu pakalpojumu sniedzēji saista IOPS ar tilpuma izmēru: 100 GB tilpumam var būt ierobežojums 3 000 IOPS, savukārt 500 GB tilpumam tiek piešķirti 15 000. Tas nozīmē, ka dažkārt ir jānodrošina vairāk krātuves nekā nepieciešams, lai iegūtu pietiekamus IOPS, šī nianse pārsteidz daudzus pirmo reizi mākoņ tehnoloģijās strādājošos.

Tīkla joslas platums nosaka, cik daudz datu jūsu serveris var nosūtīt un saņemt sekundē. Tīmekļa lietojumprogrammām izejošā joslas platuma kapacitāte parasti ir „pārejas vieta”, jo serveri sūta daudz vairāk datu lietotājiem, nekā tie saņem. Lapa, kuras izmērs ir 2 MB un ko apkalpo 100 vienlaicīgi lietotāji, pie maksimālās noslodzes prasa 200 MB/s izejošās joslas platuma kapacitāti. CDN jūsu servera priekšā samazina šo slodzi dramatiski, kešatmiņā glabājot statiskos resursus galapunktu vietās, taču dinamiskajiem datiem joprojām ir jāceļo no jūsu primārā servera.

Vairums mākoņu pakalpojumu sniedzēju iekļauj pamata joslas platuma kvotu katrā instances konfigurācijā un piemēro pārmaksas nodevas par pārsniegšanu. GRADAX mūsu tīmekļa hostinga plānos iekļauti plaši joslas platuma kvoti, jo esam novērojuši, ka negaidītas joslas platuma izmaksas ir viena no galvenajām pārsteigumiem rēķinos mākoņu iesācējiem. Mēs iesakām uzraudzīt mēneša joslas platuma patēriņu pirmos trīs mēnešus un iestatīt brīdinājumus, kad tiek sasniegta 80% no kvotas, lai izvairītos no rēķina šoka. Vietnēm vai lietojumprogrammām, kas apkalpo smagus multimediju failus, ņemiet vērā joslas platuma izmaksas plānošanas procesā kopā ar CPU, RAM un krātuvi.

Tīkla aizkave ir tikpat svarīga, it īpaši ģeogrāfiski sadalītai auditorijai. Serveris Frankfurtes centrā nodrošina mazāk nekā 20 ms aizkavi lietotājiem Centrāleiropā, bet 150 ms vai vairāk lietotājiem Āzijas-Pacifikas reģionā. Ja jūsu auditorija aptver vairākus kontinentus, viena atrašanās vieta nenodrošinās konsekventu pieredzi. Daudzreģionu izvietojums vai CDN ar kešatmiņu malējās vietās ir būtisks. Mēs parasti iesakām sākt ar vienu reģionu, kas atrodas vistuvāk lielākajai daļai jūsu lietotāju, un paplašināt uz citiem reģioniem tikai tad, ja veiktspējas dati pamato papildu sarežģītību un izmaksas.

WordPress vietnēm ar līdz 100 000 apmeklējumu mēnesī mēs iesakām sākt ar 2 vCPU, 4 GB RAM un 40 GB NVMe SSD krātuvi. Šī konfigurācija ērti apkalpo WordPress, MySQL, Redis objektu kešatmiņu un Nginx ar rezervi satikmes pīķiem. WooCommerce veikaliem ar aktīvu inventāru vajadzētu pievienot vēl 2 GB RAM un apsvērt atsevišķu datubāzes instanci, kad satiksme pārsniedz 200 000 apmeklējumu mēnesī vai produktu katalogs pārsniedz 10 000 preces.

Node.js lietojumprogrammas atšķiras atkarībā no to arhitektūras. Vienkārša Express.js API, kas apkalpo JSON atbildes, efektīvi darbojas uz 1 vCPU un 1 GB RAM vidējai satiksmei. Next.js lietojumprogramma ar servera pusi renderēšanu prasa 2 līdz 4 vCPU un 2 līdz 4 GB RAM, jo katrs renderēšanas process ir CPU intensīvs. Reāllaika lietojumprogrammas, kas izmanto WebSockets, prasa vairāk atmiņas, lai uzturētu pastāvīgās savienojumus; budžetējiet aptuveni 10 KB RAM uz katru vienlaicīgu savienojumu, tātad 100 000 vienlaicīgu savienojumu prasa aptuveni 1 GB RAM tikai savienojuma stāvoklim, plus tas, ko prasa pašas lietojumprogrammas loģika.

E-komercijas platformām ar dedicētā servera infrastruktūru ir visprasīgākās prasības dinamikas lapu renderēšanas, datubāzu vaicājumu produktiem un inventāram, reāllaika groza un norēķinu apstrādes, kā arī attēlu servisa kombinācijas dēļ. Vidēja izmēra e-komercijas vietnei, kas apkalpo 500 000 apmeklējumu mēnesī, parasti nepieciešami 4 līdz 8 vCPU, 8 līdz 16 GB RAM, 100 GB vai vairāk SSD krātuves un atsevišķs datubāzes serveris ar vismaz 8 GB RAM. Pīķa notikumu laikā, piemēram, flash izpārdošanas vai svtku akcijas, šīs prasības var dubultoties vai tripleties, padarot automātiskās skalēšanas spējas būtiskas.

Vertikālā skalēšana (vertical scaling) nozīmē pievienot vairāk CPU, RAM vai krātuves esošajam serverim. Horizontālā skalēšana (horizontal scaling) nozīmē pievienot vairāk serveru aiz slodzes līdzsvara ierīces. Katrai pieejai ir kompromisi, kas jāņem vērā pieņemot lēmumu. Vertikālā skalēšana ir vienkāršāka: nav nepieciešamas lietojumprogrammas arhitektūras izmaiņas, nav slodzes līdzsvara konfigurācijas, nav sesijas pārvaldības problēmu. Tā labi darbojas datubāzēm, monolītām lietojumprogrammām un darbu plūsmām, kuras ir grūti sadalīt pa vairākiem mezgliem.

Horizontālā skalēšana ir izturīgāka un izdevīgāka lielākos mērogos. Ja viens serveris horizontāli skalotā klasterī sabojājas, atlikušie serveri absorbē slodzi ar minimālu ietekmi. Horizontālā skalēšana arī ļauj izmantot mazākas, lētākas instances, kas kopā nodrošina vairāk aprēķinu jaudas nekā viena liela instance par zemāku kopējām izmaksām. Tomēr horizontālajai skalēšanai ir nepieciešams, lai jūsu lietojumprogramma būtu bezstāvokļa (stateless) vai externalizētu sesijas stāvokli kopīgā krātuvē, piemēram, Redis. Tā arī prasa slodzes līdzsvara ierīci un ievieš sarežģītību izplatīšanā, žurnālos un atkļūdošanā.

Mūsu vispārīgā rekomendācija ir vispirms palielināt vertikāli, līdz tiek sasniegts dabiskais griests, parasti ap 8 līdz 16 vCPU un 32 līdz 64 GB RAM, un pēc tam palielināt horizontāli. Šī pieeja minimizē darbības sarežģītību, kamēr jūsu darba slodze ir pietiekami maza, lai ietilptu vienā mašīnā. Kad esat pārauguši vertikālo skalēšanu, ieguldiet arhitektūras izmaiņās, kas nepieciešamas horizontālajai skalēšanai, kas kalpos jums labi, kamēr satiksme turpinās augt. Sazinieties ar mūsu infrastruktūras komandu, lai saņemtu personalizētu konfigurācijas novērtējumu, balstoties uz jūsu specifiskajām darba slodzes īpašībām.

Sākotnējā konfigurācija ir kvalificēts aplēse. Pareiza resursu pielāgošana (right-sizing) ir nepārtraukta resursu pielāgošana, balstoties uz faktiskajiem lietošanas datiem. Mēs iesakām apkopot vismaz divu nedēļu veiktspējas metrikas pirms konfigurācijas pielāgošanas un ideālā gadījumā četrus līdz sešus mēnešus, lai aptvertu nedēļas satikmes ciklus, mēneša rēķināšanas ciklus un sezonālās svārstības. Galvenās metrikas, kas jāuzraka, ietver vidējo un pīķa CPU izmantošanu, atmiņas lietošanu un swap aktivitāti, disk I/O gaidīšanas laiku un tīkla caurlaidspēju.

Automātiskās pareizas resursu pielāgošanas rīki var analizēt lietošanas modeļus un ieteikt optimizācijas. GRADAX mūsu uzraudzības platforma signalizē par instance, kurās vidējā CPU izmantošana paliek zem 20% vairāk nekā 14 dienas pēc kārtas, kas liecina par iespējamu pārkomplicēšanu. Tā arī brīdina, kad jebkurš resursu konsistenti pārsniedz 75% izmantošanu, signālizējot, ka jāplāno palielināšana vertikāli vai horizontāli, pirms veiktspēja pasliktinās. Šie brīdinājumi ir palīdzējuši mūsu klientiem samazināt infrastruktūras izmaksas par vidēji 28% pirmo sešu mēnešu laikā pēc uzraudzības sākuma.

Pareiza resursu pielāgošana nav tikai izmaksu samazināšana. Tā ir vienlīdz svarīga, lai nodrošinātu pietiekamu veiktspēju, pieaugot slodzei. Serveris, kas darbojās ideāli pirms sešiem mēnešiem, šodien var saskarties ar grūtībām, jo ir pieaudzis datubāzes apjoms, palielinājies trafiks vai tika pievienotas jaunas funkcijas, kas rada papildu aprēķinu slodzi. Ieplānojiet kvartāla pareizas resursu pielāgošanas pārskatīšanas sesijas, kurās analizējat resursu izmantošanas tendences un salīdzināt tās ar lietotnes veiktspējas rādītājiem, piemēram, atbildes laiku un kļūdu procentu. Šī prakse ļauj savlaicīgi noteikt pakāpenisku resursu izsīkšanu, pirms tā izpaužas kā lietotājiem redzamas veiktspējas problēmas, un nodrošina, ka infrastruktūras investīcijas paliek sinhronizētas ar faktisko pieprasījumu.