Pilvipalvelimen kokoa koskeva opas: Kuinka paljon CPU:tä, RAM-muistia ja tallennustilaa?

Oikean pilvipalvelimen konfiguraation valitseminen on yksi merkittävimmistä päätöksistä missä tahansa hosting-hankkeessa. Jos varaat liikaa, haaskaat rahaa joka kuukausi käyttämättömään kapasiteettiin. Jos varaat liian vähän, sovelluksesi kärsii hitaista vasteajoista, aikakatkoista tai suorista kaatumisista liikennemaksimin aikana. Kumpikaan lopputulos ei ole hyväksyttävä tuotantotyölle, mutta yllättävän monet yritykset valitsevat palvelimen koon sisäisen tunnon, toimittajan oletusarvojen tai jonkin blogikirjoituksen kolmen vuoden takaisen suositelman perusteella.

Väärän kokojen määrityksen taloudellinen vaikutus on merkittävä. Analyysimme yli 200 asiakkaan siirrosta osoittaa, että keskimääräinen yritys varaa pilvipalveluiden resursseja 35–50 % liikaa, kun palvelimia konfiguroidaan ilman dataan perustuvaa ohjausta. 200 euron kuukaskustannuksessa tämä tarkoittaa 70–100 euron hukkaa joka kuukausi, eli yli 800–1 200 euroa vuodessa. Toisaalta ali-varatut palvelimet aiheuttavat suorituskykyongelmia, jotka vaikuttavat suoraan tuloihin. Verkkokaupoissa yhden sekunnin lisäys sivun latausaikaan voi laskea konversioita 7 %, mikä on kustannus, joka ylää säästöt pienemmän palvelimen valitsemisesta.

Oikea kokojen määritys ei ole kertaluonteinen päätös. Työkuormat kehittyvät sovellusten kasvaessa, liikennemallit muuttuvat ja ominaisuusjoukot laajenevat. Palvelinkonfiguraatio, joka oli täydellinen kuusi kuukautta sitten, voi olla tänään riittämätön. Tämä opas tarjoaa viitekehyksen informoitujen kokopäätösten tekemiseen lanseerauksessa ja niiden säätämiseen ajan myötä todellisen suorituskykydatan perusteella. Olipa kyseessä yksinkertainen markkinointisivusto vai monimutkainen sovelluspino, nämä periaatteet auttavat sinua allokoimaan resursseja tehokkaasti.

CPU-ytimet määräävät, kuinka monta operaatiota palvelimesi voi suorittaa samanaikaisesti. Sovellukset, jotka käsittelevät paljon rinnakkaisia pyyntöjä, web-palvelimet, API-päätepisteet ja reaaliaikaisen datankäsittelyn, hyötyvät korkeammista ydinmäärästä. Sovellukset, jotka suorittavat intensiivisiä yksisäikeisiä laskelmia, videon koodausta, tieteellisiä laskelmia tai tiettyjä tietokantojen operaatioita, hyötyvät enemmän nopeammista yksittäisistä ytimistä. Työkuorman seuraavan kuvion ymmärtäminen on ensimmäinen askel CPU:n kokoa määritettäessä.

Useimmille web-sovelluksille CPU-käytön tulisi olla keskimäärin 30–60 % normaalin kuormituksen aikana, jolloin on tilaa käsitellä liikennemaksimieet jopa 80 %:iin ennen suorituskyvyn heikkenemistä. Jos keskimääräinen CPU-käyttö on alle 20 %, olet todennäköisesti yli-varannut ja voit turvallisesti pienentää kokoa. Jos se ylittää säännöllisesti 70 %, sinun tulee harkita skaalaamista ylöspäin tai ulospäin ennen kuin käyttäjät kokevat viiveitä. WordPress-sivusto, joka palvelee 50 000 kuukausittaista kävijää, toimii yleensä mukavasti 2 vCPU:llä. Node.js-API, joka käsittelee 500 pyyntöä sekunnissa, saattaa tarvita 4–8 vCPU:tä pyyntöjen monimutkaisuudesta riippuen.

Nykyiset pilvioperaattorit tarjoavat eri CPU-tyyppejä, jotka on optimoitu eri kuormituksille. Laskentaan optimoidut instanssit tarjoavat korkeampia kellonopeuksia ja ovat ihanteellisia CPU-rajoitteisiin tehtäviin. Yleiskäyttöiset instanssit tasapainottavat CPU:n, muistin ja verkon tyypillisille web-kuormituksille. GRADAX:ssa käytämme oletuksena yleiskäyttöisiä instansseja useimpien asiakkaiden käyttöönottoihin ja suosittelemme laskentaan optimoituja vain, kun profilointi vahvistaa, että CPU on ensisijainen pullonkaula. Oikean CPU-tyypin valinta voi parantaa suorituskykyä 20–30 % samalla hintatasolla, joten ylimääräinen analyysi kannattaa.

Muisti on usein se resurssi, joka määrää sen, ajetaanko sovellus sujuvasti vai kaatuuko se kuormituksen alla. Toisin kuin CPU, joka voi jonottaa työtä ollessaan kyllästetty (tuloksena hitaammat vastaukset), RAM-muistin loppuminen laukaisee kernelin out-of-memory -survaajan, joka keskeyttää prosessit äkillisesti ja voi kaataa koko sovelluksesi. Tästä syystä suosittelemme varaamaan RAM-muistille suuremman turvamarginaalin kuin CPU:lle; tavoitteena 50–70 % keskimääräinen käyttö, jolloin jää huomattavasti tilaa liikennemaksimieille ja muistivuodoille.

Eri sovelluspinoilla on valtavasti erilaiset muistivaatimukset. Nginxin tarjoama staattinen sivusto tarvitsee niin vähän kuin 256 Mt. PHP-WordPress-sivusto, jossa on objektiivälimuisti ja tietokanta samalla palvelimella, tarvitsee 2–4 Gt. Java Spring Boot -sovellus, jossa on upotettu Elasticsearch-instanssi, saattaa vaatia 8–16 Gt. Node.js-sovellukset sijaitsevat jossain välissä, vaatiessaan tyypillisesti 1–4 Gt prosessia kohti kuormakokojen ja rinnakkaisyhteyksien mukaan. Kun useat palvelut jakavat palvelimen, laske niiden yksittäiset vaatimukset yhteen ja lisää 20 % varaus käyttöjärjestelmälle ja taustaprosesseille.

Tietokantapalvelimet vaativat erityistä huomiota RAM-määrän suunnittelussa. Tietokannat toimivat huomattavasti paremmin, kun niiden työjoukko, aktiivisesti haetut tiedot, mahtuu kokonaan muistiin. MySQL-tietokanta, jonka työjoukko on 5 Gt ja joka toimii 4 Gt RAM-muistilla varustetulla palvelimella, lukee jatkuvasti levyltä, jolloin millisekunneissa mitatut kyselyajat kasvavat kymmeniksi millisekunneiksi tai enemmän. Sama tietokanta 8 Gt RAM-muistilla pitää työjoukon välimuistissa, tarjoten johdonmukaiset alle millisekunnin lukuaikat. Dedikoituille tietokantapalvelimille suosittelemme varaamaan 1,5–2 kertaa työjoukon koko RAM-muistiin lähtökohdaksi.

Pilvitallennus jakautuu kolmeen pääluokkaan: NVMe SSD, tavallinen SSD ja HDD-pohjainen lohkovarmuuskopiointi. NVMe-levyt tarjoavat korkeimman suorituskyvyn, lukunopeudet ylittävät 3 000 Mt/s ja satunnaiset I/O-toiminnot ovat satoja tuhansia sekunnissa. Tavalliset SSD-levyt tarjoavat tasapainon suorituskyvyn ja kustannusten välillä, tuottaen tyypillisesti 500–1 000 Mt/s nopeuden. HDD-tallennus on edullisin vaihtoehto, mutta se aiheuttaa merkittävää viivettä satunnaisissa lukuoperaatioissa, joten sitä käytetään vain arkistointidataan, lokitiedostoihin ja peräkkäisiin kuormituksiin kuten varmuuskopioihin.

Aloita tallennuskapasiteetin mitoitus nykyisestä datamäärästäsi ja arvioi kasvua seuraavan 12–18 kuukauden aikana. Tyypilliselle WordPress-sivustolle mediatallinnalla tarvitaan 5–20 Gt. Verkkokauppa, jossa on paljon tuotekuvia, voi vaatia 50–200 Gt. SaaS-sovellus, joka sisältää käyttäjien luomaa dataa, voi kasvaa ennustamattomasti, ja sen eduksi jää skaalautuva tallennus, jota voidaan laajentaa ilman katkoja. Varaa aina vähintään 20 % vapaata tilaa miltä tahansa levyosiolta, tiedostojärjestelmät ja tietokannat hidastuvat kapasiteetin täytyttyä, ja levyn täydellinen loppuminen on yksi yleisimmistä suunnittelemattomien keskeytysten syistä.

IOPS (Input/Output Operations Per Second) on tallennusmittari, jolla on suurin vaikutus sovelluksen suorituskykyyn, mutta se jätetään usein huomiotta mitoitusvaiheessa. Tietokantavetoinen sovellus saattaa vaatia 3 000–10 000 IOPS ylläpitääkseen hyväksyttävän kyselysuorituskyvyn. Sisältöpainotteinen sivusto, jossa valtaosa operaatioista on lukemisia, saattaa tarvitse vain 500 IOPS. Monet pilvipalveluntarjoajat sitovat IOPS-luvut levykokoon: 100 Gt levyssä voi olla rajoitus 3 000 IOPS:iin, kun taas 500 Gt levyssä saa 15 000 IOPS. Tämä tarkoittaa, että joskus sinun on varattava enemmän tallennustilaa kuin todellisuudessa tarvitset saadaksesi riittävät IOPS-luvut, tämä hienovaraisuys yllättää monet pilven ensimmäisen kerran käyttävät.

Verkon kaistanleveys määrää, kuinka paljon dataa palvelimesi voi lähettää ja vastaanottaa sekunnissa. Web-sovelluksissa ulkoiseen kaistanleveyteen törmätään useimmiten pullonkaulana, koska palvelimet lähettävät käyttäjille paljon enemmän dataa kuin mitä ne vastaanottavat. 2 Mt painava sivu, joka palvellaan 100 samanaikaiselle käyttäjälle, vaatii huipputilanteessa 200 Mt/s ulkoista kaistanleveyttä. CDN-palvelin palvelimesi edessä vähentää tätä dramaattisesti välimuistilla staattisten kohteiden säilyttämiseksi reuna-asemilla, mutta dynaaminen sisältö kulkee edelleen alkuperäispalvelimelta.

Useimmat pilvipalveluntarjoajat sisällyttävät peruskaistanlewyssyyn jokaisen instanssikoon yhteydessä ja veloittavat ylimenevästä osasta lisämaksuja. GRADAX:n web-hostaus -palveluissamme on runsaat kaistanleveysmäärät, koska olemme havainneet, että yllättävät kaistanleveysmaksut ovat yksi yleisimmistä laskutusyllätyksistä pilvi-alan aloittelijoille. Suosittelemme seuraamaan kuukausittaista kaistanleveyden käyttöä ensimmäisten kolmen kuukauden ajan ja asettamaan hälytyksen 80 %:n rajalle välttääksesi yllättävät laskut. Mediapainotteisille sivustoille tai sovelluksille, jotka tarjoavat suuria tiedostoja, huomioi kaistanleveyskulut mitoituspäätöksessäsi prosessorin, RAM-muistin ja tallennuksen ohella.

Verkkoviive on yhtä tärkeä, erityisesti maantieteellisesti hajautetuille kohdeyleisöille. Frankfurtissa sijaitseva palvelin tarjoaa alle 20 ms viiveen käyttäjille Keski-Euroopassa, mutta yli 150 ms viiveen Aasian-Tyynenmeren alueen käyttäjille. Jos kohdeyleisösi kattaa useita mantereita, yksittäinen palvelinsijainti ei tarjoa yhdenmukaista kokemusta. Monialueinen käyttöönotto tai CDN-reunavälimuisti on välttämätöntä. Suosittelemme yleensä aloittamaan yhdellä alueella, joka on lähimpänä enemmistöä käyttäjistäsi, ja laajentamaan lisäalueille vasta, kun suorituskykydata oikeuttaa lisämonimutkaisuuden ja kustannukset.

WordPress-sivustoille, joilla on enintään 100 000 kuukausittaista kävijää, suosittelemme aloittamaan 2 vCPU:lla, 4 Gt RAM-muistilla ja 40 Gt NVMe SSD -tallennustilalla. Tämä kokoonpano hoitaa WordPressin, MySQLin, Redis-objektivälimuistin ja Nginxin vaivattomasti, jättäen tilaa liikennehuipuille. WooCommerce-kaupat, joilla on aktiiviset varastot, tulisi varustaa lisä 2 Gt RAM-muistilla ja harkita erillistä tietokanta-instanssia, kun liikenne ylittää 200 000 kuukausittaista kävijää tai tuotevalikoima kasvaa yli 10 000 tuotteen.

Node.js-sovellukset vaihtelevat suuresti arkkitehtuurinsa mukaan. Yksinkertainen Express.js-API, joka tarjoaa JSON-vastauksia, toimii tehokkaasti 1 vCPU:lla ja 1 Gt RAM-muistilla kohtuullisella liikenteellä. Next.js-sovellus, jossa on palvelinpohjainen renderöinti, vaatii 2–4 vCPU:ta ja 2–4 Gt RAM-muistia, koska jokainen renderöinti on prosessointia vaativa operaatio. Reaaliaikaiset sovellukset, jotka käyttävät WebSocketia, tarvitsevat enemmän muistia pysyvien yhteyksien ylläpitämiseen; budjetoi noin 10 kt RAM-muistia kutakin samanaikaista yhteyttä kohti, mikä tarkoittaa, että 100 000 samanaikaista yhteyttä vaatii noin 1 Gt RAM-muistia pelkästään yhteyden tilaan, plus mitä sovelluksen logiikka vaatii.

Omilla palvelimilla toimivat verkkokaupat vaativat eniten resursseja dynaamisen sivujen renderöinnin, tuotevalikoiman ja varaston tietokantakyselyjen, reaaliaikaisen ostoskorin ja kassankäsittelyn sekä kuvien tarjoamisen yhdistelmän vuoksi. Keskikokoisella verkkokaupalla, joka käsittelee 500 000 kuukausittaista kävijää, tarvitaan tyypillisesti 4–8 vCPU:ta, 8–16 Gt RAM-muistia, 100 Gt tai enemmän SSD-tallennusta ja erillinen tietokantapalvelin, jossa on vähintään 8 Gt RAM-muistia. Huipputilanteissa, kuten flash-myynissä tai juhlapyhäkampanjoissa, nämä vaatimukset voivat kaksinkertaistua tai kolminkertaistua, mikä tekee automaattisesta skaalaamisesta välttämätöntä.

Vertikaalinen skaalaus (scale up) tarkoittaa prosessorin, RAM-muistin tai tallennustilan lisäämistä olemassa olevaan palvelimeen. Horisontaalinen skaalaus (scale out) tarkoittaa lisää palvelinten lisäämistä kuormantasaimen taakse. Molemmilla lähestymistavoilla on kompromisseja, jotka vaikuttavat päätökseesi. Vertikaalinen skaalaus on yksinkertaisempaa: sovelluksen arkkitehtuurimuutoksia ei tarvita, kuormantasaajan asetusten tekemistä ei tarvita eikä istunnonhallinnan huolenpitoa. Se toimii hyvin tietokannoille, monolittisille sovelluksille ja kuormituksille, jotka on vaikea jakaa useiden solmujen välille.

Horisontaalinen skaalaus on kestävämpi ja kustannustehokkaampi suurissa mittakaavoissa. Jos yksi horisontaalisesti skaalatussa klusterissa olevista palvelimista epäonnistuu, jäljellä olevat palvelimet absorboivat kuorman minimaalisella vaikutuksella. Horisontaalinen skaalaus mahdollistaa myös pienempien, edullisempien instanssien käytön, jotka yhdessä tarjoavat enemmän laskentatehoa kuin yksi suuri instanssi alhaisemmalla kokonaiskustannuksella. Horisontaalinen skaalaus kuitenkin vaatii sovelluksen olevan tilaton tai istunnon tilan externalisoimisen yhteiseen varastoon kuten Redis. Se vaatii myös kuormantasaajan ja tuo monimutkaisuutta käyttöönottoon, lokitukseen ja vianetsintään.

Yleinen suosituksemme on skaalata pystysuoraan ensin, kunnes saavutetaan luonnollinen katto, tyypillisesti noin 8–16 vCPU:ta ja 32–64 Gt RAM-muistia, ja sen jälkeen skaalata vaakasuoraan. Tämä lähestymistapa minimoi operatiivisen monimutkaisuuden, kunnes kuormitus on tarpeeksi pieni mahtumaan yhdelle koneelle. Kun pystyskaalaus ei enää riitä, investoi horisontaaliseen skaalaukseen tarvittaviin arkkitehtuurimuutoksiin, jotka hyödyttävät sinua, kun liikenne jatkaa kasvuaan. Ota yhteyttä infrastruktuuritiimiimme henkilökohtaisen mitoitusarvion saamiseksi perustuen spesifeihin kuormitusominaisuuksiisi.

Alkuperäinen mitoitus on arvioitu arvamus. Oikea mitoitus on jatkuva prosessi, jossa resursseja säädetään todellisen käyttödatan perusteella. Suosittelemme keräämään vähintään kahden viikon suorituskykymittareita ennen mitoitusmuutosten tekemistä, ja ideali tapauksessa neljästä kuuteen viikkoa viikoittaisten liikennejaksojen, kuukausittaisten laskutusjaksojen ja mahdollisten kausivaihteluiden kuvaamiseksi. Seuratavien avainten mittarien tulee sisältää keskimääräinen ja huippu-CPU-käyttöaste, muistin käyttö ja swap-toiminta, levy-I/O:n odotusaika ja verkon läpäisykyky.

Automaattiset oikeankokoisuustarkistus työkalut voivat analysoida käyttöpatroneja ja suositella optimointeja. GRADAX:n seurantalaitteistomme merkitsee niitä instansseja, joissa keskimääräinen CPU-käyttöaste pysyy alle 20 %:n yli 14 peräkkäisen päivän ajan, mikä viittaa mahdolliseen ylikapasitointiin. Se hälyttää myös, kun mikä tahansa resurssi ylittää consistently 75 %:n käyttöasteen, mikä signaloi, että skaalaus tapahtuma tulisi suunnitella ennen suorituskyvyn heikkenemistä. Nämä hälytykset ovat auttaneet asiakkaitamme vähentämään infrastruktuurikuluja keskimäärin 28 % ensimmäisen kuuden kuukauden seurannan aikana.

Resursojen oikeakokoinen mitoitus ei ole vain kustannusten leikkaamista. Se tarkoittaa yhtä lailla riittävän suorituskyvyn varmistamista, kun kuormitus kasvaa. Palvelin, joka toimi moitteettomasti puoli vuotta sitten, voi nykypäivänä jäädä kiinni, koska tietokanta on kasvanut, liikenne lisääntynyt tai uudet ominaisuudet ovat tuoneet lisälaskentaa. Suorita resurssien tarkastukset neljännesvuosittain: tutki resurssien käyttöasteen trendejä ja vertaa niitä sovelluksen suorituskykymittareihin, kuten vasteaikaan ja virherajaan. Tämä käytäntö havaitsee vähitellen etenevän resurssien ehtymisen ennen kuin se ilmenee käyttäjille näkyvinä suorituskykyongelmina ja varmistaa, että infrastruktuuri-investointisi pysyvät linjassa todellisen kysynnän kanssa.