Pilveserveri mahutavuse juhend: kui palju CPU-d, RAM-i ja salvestusruumi?

Õige pilveserveri konfiguratsiooni valik on üks kõige olulisemaid otsuseid igas hostingu projektis. Ülevarustage ja raiskate iga kuu raha ressurssidel, mis seisavad kasutuseta. Alavarustage ja kannatab teie rakendus aeglase vastusaja, ajapiirangute või täieliku kokkuvarisemise all liikluse tipphetkedel. Mõlemat tulemust ei saa tootmiskoormuse puhul aktsepteerida, kuid üllatavalt paljud ettevõtted valivad serveri suuruse intuitsiooni, tarnija vaikeväärtuste või selle konfiguratsiooni põhjal, mille kolm aastat tagasi soovitas mingi õpetuse blogi.

Valesti määratud mahutavuse finantsmõju on märkimisväärne. Meie üle 200 kliendi üleviimise analüüs näitab, et keskmine ettevõte varustab pilveseuruseid 35–50% võrra üle, kui konfigureerib servereid ilma andmetele tugineva juhendamiseta. 200 eurose kuuarve juures tähendab see 70–100 eurot kuus, üle 800–1200 euro aastas. Vastupidiselt põhjustavad alavarustatud serverid jõuprobleeme, mis mõjutavad otse tulu. E-poe saitide puhul võib ühe sekundi pikkune lehtlaadimise aja suurenemine konversioone vähendada 7%, mis on kulu, mis ületab kaugelt säästu väiksema serveri valimisest.

Õige mahutavus ei ole ühekordne otsus. Koormused muutuvad koos rakenduste kasvuga, liiklusmustrite nihkumisega ja funktsioonikomplektide laienemisega. Serverikonfiguratsioon, mis oli kuus kuud tagasi ideaalne, võib olla täna ebapiisav. See juhend pakub raamistikku informeeritud mahutavusotsuste tegemiseks käivitusel ja nende kohandamiseks aja jooksul tegelike jõunäitajate põhjal. Olgu teie eesmärgiks lihtsa turundussaidi või keeruka rakenduste kihi käivitamine, aitavad need põhimõtted ressursse tõhusalt jagada.

CPU tuumad määravad, kui palju operatsioone saab teie server korraga täita. Rakendused, mis töötlevad palju paralleelseid päringuid, veebiserverid, API lõpped, reaalajas andmetöötlus, saavad kasu suuremast tumaarvust. Rakendused, mis teevad intensiivseid ühetuumalisi arvutusi, video kodeerimine, teaduslikud arvutused, teatud andmebaasi operatsioonid, saavad rohkem kasu kiiremad individuaalsetest tuumadest. Teie koormuse mustrit mõistmine on esimene samm CPU mahutavuse määramisel.

Enamikul veebirakendustel peaks CPU kasutus olema normaalse koormuse all keskmiselt 30–60%, jättes ruumi liikluse tipphetkede talumiseks kuni 80%-ni enne jõu halvenemist. Kui teie keskmine CPU kasutus on alla 20%, olete tõenäoliselt ülevarustatud ja saate ohutult mahutavust vähendada. Kui see ületab regulaarselt 70%, peaksite kaaluma skaleerimist ülespoole või välja enne, kui kasutajad kogevad viivitust. WordPressi sait, mis teenindab 50 000 külastajat kuus, töötab tavaliselt mugavalt 2 vCPU-ga. Node.js API, mis haldab 500 päringut sekundis, võib vajada 4–8 vCPU-d, sõltuvalt iga päringu keerukusest.

Kaasaegsed pilvetarnijad pakuvad erinevaid CPU tüüpe, mis on optimeeritud erinevate koormuste jaoks. Arvutusvõimsusele optimeeritud eksemplarid pakuvad kõrgemat taktkiirust ja on ideaalsed CPU-keskseteks ülesanneteks. Üldotstarbelised eksemplarid tasakaalustavad CPU-d, mälu ja võrguühendust tüüpiliste veebi koormuste jaoks. GRADAX-is kasutame vaikimisi enamasti klientide käivitusteks üldotstarbelisi eksemplare ja soovitame arvutusvõimsusele optimeeritud eksemplare ainult siis, kui profiilimine kinnitab, et CPU on peamine kitsaskoht. Õige CPU tüübi valimine võib anda 20–30% paremat jõudlust samal hinnatasemel, mistõttu tasub täiendava analüüsi peale minna.

Mälu on sageli ressurss, mis määrab, kas rakendus töötab sujuvalt või kukub koormuse all kokku. Erinevalt CPU-st, mis võib küllastumisel tööd järjekorda panna (tuleneb aeglasemad vastused), RAM-i puudumine aktiveerib tuuma out-of-memory killeri, mis lõpetab protsessid järsult ja võib viia terve rakenduse kokkuvariseni. Sellepärast soovitame RAM-i mahutavust määrata suurema turvalisuse marginaaliga kui CPU-l, sihtides 50–70% keskmist kasutust, jättes olulise ruumi liikluse tipphetkedele ja mälu leketele.

Erinevatel rakenduste stackidel on mälu nõudmistes tohutuid erinevusi. Staatiline sait, mida teenindab Nginx, vajab nii vähe kui 256 MB. PHP WordPressi sait objekti vahemälu ja sama serveril jooksva andmebaasiga vajab 2–4 GB. Java Spring Boot rakendus sisseehitatud Elasticsearchi instantsiga võib vajada 8–16 GB. Node.js rakendused jäävad vahele, tavaliselt vajades 1–4 GB protsessi kohta, sõltuvalt payloadide suurustest ja paralleelsetest ühendustest. Kui mitmed teenused jagavad serverit, liitke nende individuaalsed nõudmised ja lisage 20% puhver operatsioonisüsteemi ja taustaprotsesside jaoks.

Andmebaasiserverid vajavad RAM-i mahutavuse määramisel erilist tähelepanu. Andmebaasid toimivad dramaatiliselt paremini, kui nende töökomplekt, andmed, mida aktiivselt päritakse, mahub täielikult mällu. MySQL andmebaas 5 GB töökomplektiga, mis töötab serveril 4 GB RAM-iga, loeb pidevalt diskilt, mille tulemusena muutuvad millisekundites mõõdetud päringuajad kümneteks millisekunditeks või enam. Sama andmebaas 8 GB RAM-iga hoiab töökomplekti vahemälu all, pakkudes järjekindlalt sub-millisekundilisi lugemisi. Pühendatud andmebaasiserverite puhul soovitame eraldada 1,5–2x töökomplekti suurus RAM-ina alguspunktina.

Pilvesalvestus jaguneb kolmeks põhiklassiks: NVMe SSD, tavaline SSD ja kõvakettapõhine plokkmaht. NVMe SSD-d pakuvad kõrgeimat jõudlust, lugemiskiirusega üle 3 000 MB/s ja juhuslike I/O operatsioonide arvuga sadu tuhandeid sekundis. Tavalised SSD-d pakuvad tasakaalu jõudluse ja hinna vahel, pakkudes tavaliselt 500–1 000 MB/s läbilaskevõimet. Kõvakettapõhine salvestus on kõige soodsam, kuid toob kaasa märkimisväärse viivituse juhuslike lugemiste puhul, mistõttu sobib see ainult arhiivandmete, logide ja järjekindlate töökoormuste (nt varundamine) jaoks.

Salvestusmahute planeerimisel lähtuge oma praegusest andmemahust ja prognoosige kasvu 12–18 kuu perspektiivis. Tüüpiline WordPressi sait meediakoguga vajab 5–20 GB. E-pood tootepiltidega võib vajada 50–200 GB. SaaS-rakendus, mis sisaldab kasutajate poolt loodud sisu, võib kasvada ettearvamatult ning sellele sobib skaleeruv salvestus, mida saab laiendada ilma seisakuteta. Järgige reeglit: jätke igale mahuks vähemalt 20% vaba ruumi, sest failisüsteemid ja andmebaasid aeglustuvad mahutavuse piirile lähenedes ning diskiruumi lõppemine on üks levinumaid ootamatute katkestuste põhjuseid.

IOPS (Input/Output Operations Per Second ehse sisend-/väljundoperatsioonid sekundis) on salvestusmõõt, millel on suurim mõju rakenduse jõudlusele, kuid seda jäetakse planeerimisel sageli tähelepanuta. Andmebaasipõhise rakenduse puhul võib olla vaja 3 000–10 000 IOPSi, et tagada vastuvõetav päringute kiirus. Sisupõhises saidis, kus toimub peamiselt lugemist, võib piisata vaid 500 IOPSist. Paljud pilvepakkujad seovad IOPS-i mahu suurusega: 100 GB suurune mahu võib olla piiratud 3 000 IOPSiga, samas kui 500 GB suurune mahu saab 15 000 IOPSi. See tähendab, et mõnikord tuleb eraldada rohkem salvestusruumi, kui tegelikult vaja, et saavutada piisavad IOPS-id, nüanss, mis üllatab paljusid pilvekogemustega algajaid.

Võrgulaius määrab, kui palju andmeid teie server saab ja saadab sekundis. Veebirakenduste puhul on väljuv laiusribatrafik tavaliselt hoidla, kuna serverid saadavad kasutajatele oluliselt rohkem andmeid, kui neid vastu võtavad. Lehekülg, mille suurus on 2 MB ja mida serveeritakse 100 paralleelsele kasutajale, nõuab tipuhetkel 200 MB/s väljuvat laiusribat. CDN (sisu jagamise võrgustik) serveri ees vähendab seda drastiliselt, vahetades staatilisi ressursse otspunktides, kuid dünaamiline sisu peab siiski liikuma teie päritoluserverist.

Enamik pilvepakkujaid sisaldab baaslaiusriba eraldist koos iga instantsi suurusega ja võtab lisatasu selle piiri ületamisel. GRADAX-is on meie veebimajutus plaanidest lai laiusribaluba, sest oleme täheldanud, et ootamatud laiusribatasud on pilvekogemustega klientide seas üks suurimaid arve üllatusi. Soovitame jälgida oma kuist laiusribatarbimist esimese kolme kuu jooksul ja seada häire 80% eraldusest, et vältida ootamatuid arve. Meediakasutajate saitide või rakenduste puhul, mis teenindavad suuri faililaadimisi, kaasake laiusribakulu hindamisel CPU, RAM-i ja salvestusega sama prioriteediga.

Võrguviivitus on sama oluline, eriti geograafiliselt hajutatud sihtrühmade puhul. Frankfurti asuv server annab keskmises Euroopas kasutajatele alla 20 ms viivituse, kuid Aasia-Okeaania kasutajatele 150 ms või rohkem. Kui teie sihtrühm hõlmab mitut mandrit, ei suuda üksainus serveriasukoht tagada ühtlast kogemust. Mitme regiooni paigutus või CDN otspunkti vahetusega on hädavajalik. Soovitame alustada ühest regioonist, mis on enamiku teie kasutajate jaoks kõige lähemal, ja laieneda lisaregioonidesse alles siis, kui jõudlusandmed õigustavad lisakompleksust ja kulu.

WordPressi saitide puhul kuni 100 000 külastuseni kuus soovitame alustada 2 vCPU-ga, 4 GB RAM-iga ja 40 GB NVMe SSD salvestusega. See konfiguratsioon haldab WordPressi, MySQLi, Redis objektipuhvetit ja Nginxi mugavalt, jättes ruumi liikluse tõusudeks. WooCommerce poed aktiivse inventuuriga peaksid lisama veel 2 GB RAM-i ja kaaluma eraldi andmebaasi instantsi, kui liiklus ületab 200 000 külastust kuus või tootekataloog ületab 10 000 elementi.

Node.js rakendused varieeruvad sõltuvalt nende arhitektuurist. Lihtne Express.js API, mis teenindab JSON-vastuseid, töötab efektiivselt 1 vCPU ja 1 GB RAM-iga mõõduka liikluse korral. Next.js rakendus serveripoolse renderdamisega nõuab 2–4 vCPU-d ja 2–4 GB RAM-i, kuna iga renderdamine on protsessorimahukas. Reaalajas rakendused, mis kasutavad WebSocketsi, vajavad rohkem mälu püsivate ühenduste hoidmiseks; planeerige ligikaudu 10 KB RAM-i per paralleelne ühendus, mis tähendab, et 100 000 paralleelset ühendust nõuab umbes 1 GB RAM-i ainult ühenduse oleku hoidmiseks, pluss kõik, mida rakenduse loogika nõuab.

E-poodidel, millel on pühendatud serveri infrastruktuur, on kõige nõudlikumad nõuded dünaamilise lehekülje renderdamise, andmebaasipäringute tootekataloogi ja inventuuri jaoks, reaalajas ostukorvi ja maksmise töötlemise ning piltide serveerimise kombinatsiooni tõttu. Keskmise suurusega e-pood, mis haldab 500 000 külastust kuus, vajab tavaliselt 4–8 vCPU-d, 8–16 GB RAM-i, 100 GB või rohkem SSD salvestust ja eraldi andmebaasiserverit, millel on vähemalt 8 GB RAM-i. Tipphetkedel, nagu flash-müük või pühade reklaamid, võivad need nõuded kahekordistuda või kolmekordistuda, muutes automaatse skaleerimisvõime hädavajalikuks.

Üles skaalamine (vertikaalne skaalamine) tähendab olemasolevale serverile rohkem CPU-d, RAM-i või salvestust lisamist. Välja skaalamine (horisontaalne skaalamine) tähendab rohkemate serverite lisamist koormusbalaansi taha. Mõlemal meetodil on kompromisse, mis peaksid teie otsust mõjutama. Üles skaalamine on lihtsam: ei vaja rakenduse arhitektuuri muutmist, koormusbalaansi konfigureerimist ega sessioonihalduse muretsee. See sobib hästi andmebaaside, monoliitsete rakenduste ja töökoormuste jaoks, mida on keeruline mitme sõlme vahel jaotada.

Välja skaalamine on suuremas mastaabis vastupidavam ja kuluefektiivsem. Kui horisontaalselt skaalitud klastris üks serveritest rikneb, neelavad ülejäänud serverid koormuse minimaalse mõjuga. Horisontaalne skaalamine võimaldab teil kasutada väiksemaid, odavamaid instance, mis kokku pakuvad rohkem arvutusvõimsust kui üks suur instants madalama kogukuluga. Siiski nõuab horisontaalne skaalamine, et teie rakendus oleks olekuta või eksportiks sessiooni oleku jagatud salvestusse nagu Redis. See nõuab ka koormusbalaansit ja toob kaasa kompleksust paigutustes, logimises ja silumises.

Meie üldine soovitus on alustada vertikaalse skaalimisega, kuni jõutakse loomuliku piirini, tavaliselt umbes 8–16 vCPU ja 32–64 GB RAM juures, ning seejärel minna horisontaalsele skaalimisele. See lähenemine minimeerib operatiivse keerukuse seni, kuni teie töökoormus on piisavalt väike, et mahuda ühele serverile. Kui vertikaalne skaalimine enam ei piisa, investeerige horisontaalse skaalimise jaoks vajalikud arhitektuurimuutused, mis teenivad teid hästi ka liikluse jätkusuunalise kasvu korral. Võtke ühendust meie infrastruktuuri meeskonnaga, et saada isiklik hinnang teie konkreetse töökoormuse omaduste põhjal.

Algne planeering on haritud hinnang. Ressursi optimeerimine on pidev protsess, milles kohandatakse ressursse tegeliku tarbimisandmete põhjal. Soovitame koguda vähemalt kaks nädalat jõudlusmeetrikaid enne suuruse kohandamist ja ideaalis nelja kuni kuue nädala, et haarata ära nädalased liiklusringid, kuised arve tsüklid ja hooajalised muutused. Peamised jälgitavad meetrikad hõlmavad keskmist ja tipulist CPU kasutust, mälu tarbimist ja swap-tegevust, disk I/O ooteaega ning võrgu läbilaskevõimet.

Automaatsed optimeerimistööriistad saavad analüüsida tarbimismustreid ja soovitada parandusi. GRADAX-is märgib meie jälgimise platvorm instantsid, kus keskmine CPU kasutus jääb alla 20% rohkem kui 14 järjestikuse päeva jooksul, mis viitab potentsiaalsele üleplaneerimisele. See hoiatab ka siis, kui ükski ressurss ületab järjekindlalt 75% kasutust, signaalina, et üles- või väljaskaalamine tuleks planeerida enne jõudluse halvenemist. Need hoiatused on aidanud meie klientidel vähendada infrastruktuuri kulusid keskmiselt 28% esimese kuue kuu jooksul jälgimist.

Ressursi optimeerimine ei ole pelgalt kulude kärpimine. Sama oluline on tagada piisav jõudlus töökoormuse kasvades. Server, mis kuus kuud tagasi töötas ideaalselt, võib tänapäeval kannatada, kuna andmebaas on kasvanud, liiklus suurenenud või uued funktsioonid on arvutuslikku koormust juurde toonud. Planeeri kvartaalne ülevaade ressursikasutuse trendidest ja võrdle neid rakenduse jõudlusmääradega, nagu vastusaeg ja veemäär. See praktika aitab avastada järkjärgulise ressursi ammendumise enne, kui see avaldub kasutajatele nähtava jõudluse probleemina, ning tagab, et sinu infrastruktuuri investeeringud jäävad kooskõlla tegeliku nõudlusega.