Debesijos serverio talpos parinkimo vadovas: kiek CPU, RAM ir saugyklos?

Teisingo debesijos serverio konfigūracijos pasirinkimas yra vienas svarbiausių sprendimų bet kokiam talpinimo projektui. Pervertinę talpą, kas mėnesį švaistote pinigus į tuščią eilę laikančius išteklius. Nevertinę talpos, jūsų programa kenčia nuo lėtų atsakymo laikų, laiko baigties klaidų arba visiškai sugenda didelio srauto pikų metu. Nei vienas, nei kitas rezultatas nėra priimtinas gamybinei (production) apkrovai, tačiau staigiai daugelis verslų renkasi serverio dydį remdamiesi intuicija, tiekėjo numatytais nustatymais arba tuo, ką prieš trejus metus rekomendavo kokio nors tutorial blogas.

Neteisingo talpos parinkimo finansinis poveikis yra reikšmingas. Analizuodami daugiau nei 200 klientų migracijų, pastebėjome, kad vidutiniškai verslai pervertina debesijos išteklius 35 %–50 %, kai konfigūruoja serverius neturėdami duomenimis grįsto vadovavimo. Esant mėnesinėje sąskaitoje 200 eurų, tai reiškia 70–100 eurų švaistomų kas mėnesį, virš 800–1 200 eurų per metus. Atvirkščiai, per mažos talpos serveriai sukelia našumo problemas, kurios tiesiogiai veikia pajamas. El. prekybos svetainėms viena sekundė padidėjusio puslapio įkėlimo laiko gali sumažinti konversijas 7 %, o ši kaina toli gražu viršija taupumą, gaunant pasirinkus mažesnį serverį.

Tinkamas talpos parinkimas nėra vienkartinis sprendimas. Apkrovos keičiasi augant programoms, kintant srauto modeliams ir plečiantis funkcionalumui. Serverio konfigūracija, kuri buvo tobula prieš šešis mėnesius, šiandien gali būti nepakankama. Šis vadovas pateikia framework'ą informuotiems talpos parinkimo sprendimams priimti paleidimo metu ir juos koreguoti laikui bėgant, remiantis realiais našumo duomenimis. Nesvarbu, ar diegiate paprastą rinkodaros svetainę, ar sudėtingą programų stack'ą, šie principai padės jums efektyviai paskirstyti išteklius.

CPU branduoliai nulemia, kiek operacijų jūsų serveris gali vykdyti vienu metu. Programoms, kurios apdoroja daug lygiagrečių užklausų, web serveriams, API galiniams taškams, realaus laiko duomenų apdorojimui, naudinga didesnis branduolių skaičius. Programoms, kurios atlieka intensyvius vieno branduolio skaičiavimus, vaizdo kodavimui, moksliniams skaičiavimams, tam tikroms duomenų bazės operacijoms, labiau tinka greitesni individualūs branduoliai. Suprasti, kuris iš šių modelių atitinka jūsų apkrovą, yra pirmasis žingsnis parinkant CPU.

Daugeliui web programų CPU naudojimas normalios apkrovos metu turėtų vidutiškai svyruoti tarp 30 % ir 60 %, su rezervu iki 80 %, kad būtų galima išlaikyti našumą srauko pikų metu. Jei vidutinis CPU naudojimas yra mažesnis nei 20 %, greičiausiai esate pervertinę talpą ir galite saugiai ją sumažinti. Jei jis reguliariai viršija 70 %, turėtumėte apsvarstyti mastelio didinimą (scale up) arba horizontalųjį mastelio keitimą (scale out) dar prieš vartotojams patiriant delsimą. WordPress svetainei, aptarnaujančiai 50 000 lankytojų per mėnesį, paprastai pakanka 2 vCPU. Node.js API, apdorojančiai 500 užklausų per sekundę, gali prireikti 4–8 vCPU, priklausomai nuo kiekvienos užklausos sudėtingumo.

Šiuolaikiniai debesijos teikėjai siūlo skirtingus CPU tipus, optimizuotus skirtingoms apkrovoms. Skaičiavimo optimizuoti (compute-optimized) egzemplioriai suteikia didesnius taktinius dažnius ir yra idealūs CPU ribotoms užduotims. Bendrojo naudojimo (general-purpose) egzemplioriai subalansuoja CPU, atmintį ir tinklą tipinėms web apkrovoms. „GRADAX

Atmintis dažnai yra tas išteklius, kuris lemia, ar programa veiks sklandžiai, ar suges esant apkrovai. Skirtingai nei CPU, kuris gali sudėti darbą į eilę būdamas prisotintas (rezultatas, lėtesni atsakymai), atminties trūkumas sukelia kernelio out-of-memory killer veiksmą, kuris staiga nutraukia procesus ir gali nuversti visą jūsų programą. Dėl šios priežasties rekomenduojame parinkti RAM su didesniu saugumo marža nei CPU, siekiant 50 %–70 % vidutinio naudojimo, paliekant solidų rezervą srauko pikams ir atminties nuotėkiams.

Skirtingos programų stack'ai turi labai skirtingus atminties reikalavimus. Statinei svetainei, aptarnaujamai Nginx, pakanka vos 256 MB. PHP WordPress svetainei su objektų podėliavimu (object caching) ir duomenų baze, veikiančia tame pačiame serveryje, reikia 2–4 GB. Java Spring Boot programai su integruotu Elasticsearch egzemplioriumi gali prireikti 8–16 GB. Node.js programos yra kažkur viduryje, paprastai reikalaujančios 1–4 GB vienam procesui, priklausomai nuo duomenų paketų dydžių ir lygiagrečių sujungimų. Kai keli pasidalina serverį, sudėkite jų individualius reikalavimus ir pridėkite 20 % buferį operacinei sistemai bei foniniams procesams.

Duomenų bazių serveriams reikia ypatingo dėmesio parinktant RAM talpą. Duomenų bazės veikia dramatiškai geriau, kai jų darbo aibė (working set), aktyviai užklausiami duomenys, telpa visiškai į atmintį. MySQL duomenų bazė su 5 GB darbo aibe, veikiančioje serveryje su 4 GB RAM, nuolat skaitys iš disko, dėl ko užklausų laikai, kurie matuojami milisekundėmis, taps dešimtimis milisekundžių ar daugiau. Ta pati duomenų bazė su 8 GB RAM palaiko darbo aibę podėliuotą, užtikrindama nuolatinį sub-milisekundinį skaitymą. Specializuotiems duomenų bazių serveriams rekomenduojame kaip pradinį tašką skirti 1,5x–2x darbo aibės dydį RAM.

Debesijos saugykla skirstoma į tris pagrindines kategorijas: NVMe SSD, standartinės SSD ir HDD pagrindu veikiančią blokinę saugyklą. NVMe SSD diskai užtikrina aukščiausią našumą, skaitymo greitis viršija 3 000 MB/s, o atsitiktinių I/O operacijų skaičius siekia šimtus tūkstančių per sekundę. Standartinės SSD diskai pasižymi balansu tarp našumo ir kainos, jų pralaidumas paprastai svyruoja nuo 500 iki 1 000 MB/s. HDD pagrindu veikianti saugykla yra pati prieinamiausia, tačiau ji sukelia reikšmingą delsą atsitiktinio skaitymo atveju, todėl ji tinkama tik archyviniams duomenims, žurnalo įrašams ir sekos darbo krūviams, pavyzdžiui, atsarginėms kopijoms.

Planuojant saugyklos talpą, pradėkite nuo dabartinių duomenų apimties ir prognozuokite augimą per 12–18 mėnesių. Tipinei WordPress svetainei su medijų biblioteka reikia 5–20 GB. E-komercijos platformai su produktų nuotraukomis gali prireikti 50–200 GB. SaaS programinė įranga su vartotojų generuojamais duomenimis gali augti neprognozuojamai, todėl jai naudinga mastelį keičianti saugykla, kuri plečiasi be tiesioginių sustojimų. Visada palikite bent 20% laisvos vietos bet kuriame tūryje, failų sistemos ir duomenų bazės praranda našumą artėdamos prie pilnos apkrovos, o disko vietos išsekimą viena dažniausių netikėtų gedimų priežasčių.

IOPS (Input/Output Operations Per Second) yra saugyklos rodiklis, labiausiai veikiantis programinės įrangos našumą, tačiau jis dažnai ignoruojamas planuojant talpas. Duomenų bazei intensyviai naudojančiai programinei įrangai gali prireikti 3 000–10 000 IOPS, kad būtų išlaikytas priimtinas užklausų našumas. Turiniu turtingai svetainei, kurioje vyrauja skaitymo operacijos, gali pakakti vos 500 IOPS. Daugelis debesijos teikėjų susieja IOPS su tūrio dydžiu: 100 GB tūris gali būti ribojamas iki 3 000 IOPS, o 500 GB tūris gauna 15 000 IOPS. Tai reiškia, kad kartais tenka skirti daugiau saugyklos nei realiai reikia, kad būtų pasiektas adekvatus IOPS lygis, tai niuansas, kuris nustebina daugelį pirmą kartą debesyje dirbančių naudotojų.

Tinklo pralaidumas nulemia, kiek duomenų jūsų serveris gali siųsti ir gauti per sekundę. Web programoms išeinanti pralaiduma dažniausiai tampa „butelio kakleliu“, nes serveriai vartotojams siunčia daug daugiau duomenų, nei gauna. Puslapį, sveriantis 2 MB ir pateikiamas 100 vienalaikių vartotojų, pikiniu metu reikia 200 MB/s išeinančios pralaidumos. CDN prieš jūsų serverį tai dramatiškai sumažina, kachinuodama statinius resursus galiniuose taškuose, tačiau dinaminis turinys vis tiek turi keliauti iš jūsų pagrindinio serverio.

Dauguma debesijos teikėjų įtraukia bazinę pralaidumos rezervaciją į kiekvieno instancijos dydį ir ima papildomus mokesčius už viršijimą. „GRADAX“ mūsų web hosting planai turi dideles pralaidumo rezervacijas, nes pastebėjome, kad netikėti pralaidumo mokesčiai yra viena didžiausių sąskaitų staigmenų debesijos naujokams. Rekomenduojame stebėti mėnesinę pralaidumo sąnaudas pirmuosius tris mėnesius ir nustatyti įspėjimus esant 80 % rezervacijos išnaudotumui, kad išvengtumėte staigių sąskaitų padidėjimų. Turiningoms svetainėms arba programoms, kurios teikia didelių failų atsisiuntimus, pralaidumo kaštus vertinkite kartu su CPU, RAM ir saugykla.

Tinklo delsos taip pat yra labai svarbios, ypač geografiškai išsisklaidžiusiai auditorijai. Serveris Frankfurte užtikrina mažesnę nei 20 ms delsą vartotojams visoje Centrinėje Europoje, tačiau Azijos-Ramiojo vandenyno regione dela siekia 150 ms ar daugiau. Jei jūsų auditorija apima kelias žemynas, vieno serverio vieta negarantuoja nuoseklios patirties. Būtina naudoti kelių regionų diegimą arba CDN su galiniais kachavimais. Paprastai rekomenduojame pradėti nuo vieno regiono, artimiausio daugumai jūsų vartotojų, ir plėstis į kitus regionus tik tada, kai našumo duomenys pateisins sudėtingumo ir kaštų padidėjimą.

WordPress svetainėms, kurių mėnesinis lankomumas neviršija 100 000, rekomenduojame pradėti nuo 2 vCPU, 4 GB RAM ir 40 GB NVMe SSD saugyklos. Ši konfigūracija patogiai tvarko WordPress, MySQL, Redis objektų kachą ir Nginx, palikdama rezervos galimybių lankomumo šuoliams. Aktyvia inventoriumi naudojantys WooCommerce parduotuvės turėtų pridėti dar 2 GB RAM ir apsvarstyti atskirą duomenų bazės instanciją, kai lankomumas viršija 200 000 per mėnesį arba produktų katalogas viršija 10 000 prekių.

Node.js programos labai skiriasi priklausomai nuo architektūros. Paprasta Express.js API, teikianti JSON atsakymus, efektyviai veikia ant 1 vCPU ir 1 GB RAM esant vidutiniam lankomumui. Next.js programa su serverinio renderinimo funkcijomis reikalauja 2–4 vCPU ir 2–4 GB RAM, nes kiekvienas renderinimas yra procesoriui intensyvi operacija. Realiojo laiko programos, naudojantys WebSockets, reikalauja daugiau atminties nuolatiniam ryšiui palaikyti, planuokite apie 10 KB RAM vienam vienalaikiam ryšiui, todėl 100 000 vienalaikių ryšių reikalauja maždaug 1 GB RAM vien ryšio būsenai, plius tai, ko reikalauja pačios programos logika.

E-komercijos platformos su dedikuotos serverių infrastruktūra turi reikliausius reikalavimus dėl dinaminio puslapio renderinimo, duomenų bazių užklausų produktų katalogams ir inventoriui, realiojo laiko krepšelio ir atsiskaitymo apdorojimo bei paveikslėlių teikimo. Vidutinio dydžio e-komercijos svetainei, tvarkančiai 500 000 lankytojų per mėnesį, paprastai reikia 4–8 vCPU, 8–16 GB RAM, 100 GB ar daugiau SSD saugyklos ir atskiro duomenų bazės serverio su bent 8 GB RAM. Pikinių renginių metu, pavyzdžiui, flash pardavimuose ar švenčių akcijose, šie reikalavimai gali padvigubėti arba padidėti trigubai, todėl automatinio mastelio keitimo funkcijos yra būtinos.

Mastelio didinimas vertikaliai (vertical scaling) reiškia daugiau CPU, RAM arba saugyklos pridėjimą prie esamo serverio. Mastelio didinimas horizontaliai (horizontal scaling) reiškia daugiau serverių pridėjimą už balansuotojo apkrovos įrenginio. Kiekvienas požiūris turi kompromisus, kurie turėtų paveikti jūsų sprendimą. Vertikalus mastelio didinimas yra paprastesnis: nereikia keisti programinės įrangos architektūros, konfigūruoti balansuotojo apkrovos ar rūpintis sesijų valdymu. Jis gerai tinka duomenų bazėms, monolitinėms programoms ir darbo krūviams, kurių sunku paskirstyti tarp kelių mazgų.

Horizontalus mastelio didinimas yra atsparesnis ir ekonomiškiau dideliu mastu. Jei vienas horizontally mastelio didinimo klasterio serveris sugenda, likę serveriai perima apkrovą su minimaliu poveikiu. Horizontalus mastelio didinimas taip pat leidžia naudoti mažesnes, pigesnes instancijas, kurios kartu suteikia daugiau skaičiavimo galios nei viena didelė instancija už mažesnę bendrą kainą. Tačiau horizontalus mastelio didinimas reikalauja, kad programa būtų bevalė arba kad sesijos būklė būtų eksportuota į bendrą saugyklą, pvz., Redis. Taip pat reikia balansuotojo apkrovos ir įveda sudėtingumo į diegimus, žurnalų vedimą ir derinimą.

Bendra mūsų rekomendacija yra pirmiausia didinti vertikaliai, kol pasieksite natūralų lubas, paprastai apie 8–16 vCPU ir 32–64 GB RAM, o tada pereiti prie horizontalaus mastelio didinimo. Šis požiūris minimizuoja operacinį sudėtingumą, kol jūsų darbo krūvis dar pakankamai mažas, kad tilptų ant vienos mašinos. Kai persiribojate vertikalaus mastelio didinimo galimybes, investuokite į architektūrinius pokyčius, reikalingus horizontaliam mastelio didinimui, kurie tarnaus gerai toliau augant lankomumui. Susisiekite su mūsų infrastruktūros komanda dėl individualaus talpos vertinimo pagal jūsų specifinius darbo krūvio charakteristikas.

Pradinis talpos parinkimas yra pagrįsta apytikslė verte. Tinkamo dydžio nustatymas yra nuolatinė praktika, reguliuojant išteklius pagal faktinius naudojimo duomenis. Rekomenduojame surinkti bent dvejų savaičių našumo metrikas prieš keisdami talpą, o idealu, keturių iki šešių savaičių, kad užfiksuotumėte savaitinius lankomumo ciklus, mėnesinius apskaitos ciklus ir bet kokius sezoninius pokyčius. Svarbios stebimos metrikos apima vidutinį ir pikinį CPU užimtumą, atminties naudojimą ir mainų veiklą, disko I/O laukimo laiką bei tinklo pralaidumą.

Automatiniai optimalaus dydžio nustatymo įrankiai gali analizuoti naudojimo modelius ir rekomenduoti optimizavimą. „GRADAX“ mūsų stebėjimo platforma pažymi instancijas, kurių vidutinis CPU užimtumas išlieka žemiau 20 % ilgiau nei 14 dienų iš eilės, kas rodo potencialų perteklinį išteklių skyrimą. Ji taip pat įspėja, kai bet kuris išteklys nuolat viršija 75 % užimtumą, signalizuodamas, kad prieš pablogėjant našumui, reikia planuoti mastelio didinimą. Šie įspėjimai padėjo mūsų klientams sumažinti infrastruktūros išlaidas vidutiniškai 28 % per pirmuosius šešis stebėjimo mėnesius.

Tinkamo dydžio nustatymas, tai ne tik kaštų mažinimas. Tai taip pat užtikrina tinkamą našumą didėjant apkrovai. Serveris, kuris puikiai veikė prieš šešis mėnesius, šiandien gali strigti dėl išaugusios duomenų bazės, padidėjusio srauto ar naujų funkcijų sukurtos skaičiavimo apkrovos. Suplanuokite ketvirtines pajėgumų peržiūras: analizuokite resursų naudojimo tendencijas ir lyginkite jas su programinės įrangos našumo metrikomis, pvz., atsako laiku ir klaidų dažniu. Ši praktika leidžia pastebėti nuolatinį resursų senėjimą dar prieš jam pasireiškiant vartotojams kaip našumo problemos ir užtikrina, kad infrastruktūros investicijos atitiktų faktinį poreikį.