Skaalautuva pilviinfrastruktuuri kasvaville yrityksille

Kun GRADAX aloitti hallinnoidun hostingin ja pilvipalveluiden tarjoamisen, suurin osa asiakkaistamme käytti ennustettavia kuormituksia. Paikallisen ravintalan verkkosivusto sai tasaisen liikenteen, ehkä pienen piikin viikonloppuisin. Tilintarkastajan portfoliosivusto ei juurikaan kuluttanut palvelimen resursseja. Varasimme infrastruktuurin konservatiivisesti, ja se toimi. Kun kuitenkin otimme asiakkaidemme joukkoon verkkokauppamerkkejä, SaaS-startupeja ja median julkaisijoita, liikennemallit muuttuivat äärimmäisen ennustamattomiksi.

Yksi asiakkaistamme, romanialainen muotimarkkinapaikka, järjesti flash-myynnin, joka tuotti 14-kertaisen normaalin liikennemäärän alle sadassakymmenessä sekunnissa. Heidän edellinen hosting-palveluntarjoajansa petti. He tulivat meille seuraavana päivänä pyytämään takuuta, että tätä ei koskaan tapahtuisi uudelleen. Tämä yksittäinen keskustelu pakotti meidät harkitsemaan koko infrastruktuurifilosofiamme uudelleen. Emme enää voineet suunnitella keskiarvojen varaan, meidän täytyi suunnitella ääritapauksille.

Keskeinen haaste oli kolmijakoinen: käsitellä äkillisiä liikennemäärän piikkejä ilman manuaalista puuttumista, pitää kustannukset kohtuullisina hiljaisina aikoina ja ylläpitää alle 200 ms:n vasteaikoja eurooppalaisille ja globaaleille yleisöille. Minkä tahansa näistä ratkaiseminen erillään on suoraviivaista. Kaikkien kolmen samanaikainen ratkaiseminen vaati perusteellisesti erilaisen arkkitehtuurin.

Arvioimme useita lähestymistapoja ennen nykyistä teknologia-alustaamme. Täysin serverless-arkkitehtuuri oli houkutteleva, mutta se toi mukanaan kylmän käynnistyksen viiveitä, jotka rikkoivat suorituskykyvaatimuksiamme, erityisesti asiakkaistemme luottamien Next.js-sovellusten kohdalla. Perinteinen VM-perustainen asetus antoi meille kontrollin, mutta siinä puuttui tarvitsemamme joustavuus. Päädyimme hybridi-malliin: peruskuorman omistettuun laskentaan perustuva ratkaisu, jota tukee tarpeen mukaan pilvipalvelin -pooli, joka voidaan käynnistää alle neljässä sekunnissa.

Ohjauskenttämme (control plane) toimii Kubernetesin avulla, joka orkestroi kuormituksia useiden saatavuusvyöhykkeiden välillä jokaisessa datakeskusalueessa. Jokaisen asiakkaan sovellus on konttoitu standardoidulla ajoituskuvalle, joka sisältää seuranta-agenttimme, logien eteenpäinsyöttäjän ja terveydentilatarkistuspisteen. Tämä yhdenmukaisuus mahdollistaa automaattisen skaalauksen: jokainen kontti on vaihdettava, joten orkestraattori voi lisätä tai poistaa instansseja huolehtimatta ympäristökohtaisista erikoispiirteistä.

Datakerroksessa hyödynsimme porrastettua tallennusstrategiaa. Kuumadata sijaitsee NVMe SSD-asemilla, joissa replikointi tapahtuu kahden solmun välillä. Lämmin data siirtyy standardi-SSD:lle seitsemän päivän jälkeen. Kylmädata arkistoidaan objektitallejsoon kolmekymmentä päivää myöhemmin. Tämä vähensi tallennuskustannuksiamme 40 % ilman havaittavaa vaikutusta asiakassuorituskykyyn.

Automaattinen skaalaus kuulostaa teoriassa yksinkertaiselta: kun kysyntä kasvaa, lisätään kapasiteettia; kun se laskee, vähennetään sitä. Käytännössä ajoituksella ja kynnysarvoilla on valtava merkitys. Liian myöhään skaalattaessa käyttäjät kohtaavat virheitä. Liian aikaisin skaalattaessa rahaa palaa käyttämättömiin resursseihin. Käytimme kolme kuukautta skaalauskäytäntöjemme hienosäätöön ennen kuin uskalsimme ajaa niitä tuotannossa ilman ihmisen valvontaa.

Järjestelmämme käyttää ennakoivaa skaalausmallia reaktiivisten hälytysten päällä. Ennakoiva kerros analysoi historiallista liikennettä, viikonpäivää, vuorokaudenaikaa, kausiluonteisia trendejä ja tunnettuja tapahtumia, kuten tuotelanseerauksia tai markkinointikampanjoita, jotka asiakkaat aikatauluttavat hallintapaneelimme kautta. Se varaa kapasiteettia viisitoista minuuttia ennen odotettua kysyntää. Reaktiivinen kerros seuraa reaaliaikaisia mittareita: CPU-käyttöä, muistipainetta, pyyntöjonon syvyyttä ja P95-vasteen latenssia. Jos mikä tahansa mittari ylittää rajansa, uusia kontteja käynnistetään muutaman sekunnin kuluessa.

Rakensimme myös räätälöidyn jäähtymismekanismin. Kun kuormapiikki laantuu, emme purka ylimääräistä kapasiteettia välittömästi. Sen sijaan pidämme sen käytössä määritettävän ajan (oletus: kymmenen minuuttia), koska liikennepiikit tulevat usein aaltoina. Tämä estaa konttien toistuvan ja kalliin käynnistyksen ja pysäytyksen kestäviä korkean liikenteen tapahtumia, kuten Black Fridayta tai sosiaalisen median virallisia hetkiä.

GRADAXin kuormantasaus toteutetaan kahdessa kerroksessa. Ulompi kerros on globaali anycast-verkko, joka ohjaa käyttäjät lähimpään datakeskukseen latenssin perusteella, ei vain maantieteellisen sijainnin perusteella. Münchenissä oleva käyttäjä saattaa ohjata Frankfurtin solmuun tai Amsterdamin solmuun reaaliaikaisten verkko-olosuhteiden mukaan. Tämä päätös arvioidaan uudelleen joka kuudeskymmenes sekunti aktiivisilla terveydentilatarkistusprobeilla, jotka lähetetään jokaisesta reunasijainnista.

Sisempi kerros jakaa liikenteen konttien välillä datakeskuksen sisällä. Luopuimme varhain yksinkertaisesta round-robin-jakelusta, koska se ei ota huomioon konttien terveydentilaa tai nykyistä kuormitusta. Tasaimemme käyttää painotettua vähiten yhteyksiä -algoritmia, joka huomioi kunkin kontin nykyisen pyyntömäärän, CPU-käytön ja viimeaikaisen virheradan. Kontit, jotka kamppailevat, saavat vähemmän pyyntöjä, mikä antaa niille aikaa toipua ilman, että ne vedetään kokonaan kierrosta pois.

Toteutimme myös yhteyksien tyhjennyksen (connection draining) sujuvia sammutuksia varten. Kun automaattinen skaalaa poistaa kontin, se ensin lopettaa uusien yhteyksien lähettämisen sille ja odottaa sitten jopa kolmekymmentä sekuntia, kunnes olemassa olevat pyynnöt valmistuvat. Tämä eliminoi 502-virheet, jotka vaivasivat aiempia versioitamme skaalausalentamisessa.

Pilvi-infrastruktuuri voi kallistua nopeasti, erityisesti kun ajat automaattista skaalausta useilla alueilla. Otimme kurinalaisen lähestymistavan kustannushallintaan alusta asti, kohdellen infrastruktuurikuluja tuotemittarina, joka on yhtä tärkeä kuin käyttökatve tai latenssi. Jokainen arkkitehtuuripäätös käy läpi kustannusvaikutusten arvioinnin ennen tuotantoon pääsyä.

Suurimmat säästöt tulivat oikeasta mitoittamisesta (right-sizing). Rakensimme analytyökalun, joka ottaa näytteitä konttien resurssikäytöstä neljäntoista päivän ikkunoiden aikana ja suosittelee optimaalisia CPU- ja muistijakojia. Useimmat asiakkaat olivat yli-varustettuja 30–50 % alkuperäisten arvioidemme perusteella. Oikean mitoittamisen jälkeen vähensimme peruskuorman laskentakustannuksia 35 % koko flottaassa. Neuvottelimme myös varattua kapasiteettisopimusta ylävirran tarjoajiemme kanssa peruskuormalle, lukiten hinnat 45 % alempina kuin tilapäishinnat.

Asiakkaille, jotka haluavat maksimaalisen kustannustehokkuuden, tarjoamme "burstable"-tason, joka toimii jaetussa infrastruktuurissa normaaleina aikoina ja skaalautuu omiin resursseihin vain huippuhetkillä. Tämä taso on 60 % halvempi kuin vakiotarjousmme ja sopii hyvin yrityksille, joilla on ennustettavia matalan liikenteen jaksoja, kuten B2B-SaaS-tuotteet, jotka eivät käytännössä saa liikennettä työaikojen ulkopuolella.

Et voi hallita sitä, mitä et voi mitata, ja hajautetussa automaattisessa skaalausjärjestelmässä näkyvyys on kaikkea. Rakensimme havainnollisuusalustamme kolmen pilarin ympärille: mittarit, lokit ja jäljitteet (traces). Jokainen kontti lähettää rakenteellisia mittareita viiden sekunnin välein kattamaan CPU:n, muistin, levy-I/O:n, verkon läpimenoajan, pyyntömäärän, virheradan ja vaste-latenssin prosenttipisteet. Nämä virtaavat aikasarvatietokantaan, joka säilyttää korkearesoluutioista dataa seitsemän päivän ajan ja alih Näytettyä dataa kolmetoista kuukautta.

Hajautettu jäljitys (distributed tracing) oli osa, joka vei pisimmän ajan saada toimimaan, mutta toi eniten arvoa. Jokaiseen sisään tulevaan pyyntöön liitetään trace ID, joka seuraa sitä load balancerin, sovelluskontin, välimuistikerroksen ja tietokannan kautta. Kun asiakas ilmoittaa hitaista sivun latauksista, voimme vetää esiin tarkan trace:n ja nähdä tarkasti, missä aikaa kului. Yhdeksän kertaa kymmenestä pullonkaula on optimoimaton tietokantakysely tai puuttuva välimuistiavain, ei infrastruktuuri.

Hälytysjärjestelmämme käyttää porrastettuja vakavuustasoja, jotka on sidottu liiketoiminnan vaikutuksiin, ei vain teknisiin rajoihin. Yhdistettynä verkkoturvaseurantaan yksi kuuma kontti on informatiivinen. Jatkunut virherata yli 1 % asiakkaan flottaassa on varoitus. Mikä tahansa saatavuuden lasku alle 99,9 % viiden minuutin ikkunassa hälyttää vuorossa olevan insinöörin välittömästi. Tämä lähestymistapa vähensi hälytysmelua 70 % verran alkuperäisestä rajaehto-perustaisesta järjestelmästämme.

Kahdeksantoista kuukautta tämän arkkitehtuurin tuotantokäytön jälkeen luvut puhuvat puolestaan. Ylläpidimme 99,97 %:n käyttöaikaa kaikissa asiakastyökuormissa, mukaan lukien kolmen merkittävän liikennetapahtuman aikana, joista jokainen ylitti 50-kertaisen peruskuorman. Alusta käsitteli yli 2,8 miljardia pyyntöä vain viimeisellä neljänneksellä, ja globaali P95-vastausaika oli 142 millisekuntia. Yksikään asiakas ei kokenut keskeytystä skaalauskatojen vuoksi.

Kustannusten osalta asiakkaamme säästävät yhteensä arviolta 40 % verrattuna vastaaviin konfiguraatioihin suurilla julkisilla pilvipalveluntarjoajilla. Automaattinen skaalaus esti arviolta 180 000 euron tarpeettomat laskutusmenot viime vuonna skaalaamalla resursseja alas ruuhka-aikojen ulkopuolella sen sijaan, että palvelinta olisi ajettu täydellä teholla ympäri vuorokauden. Muodin verkkokauppa-asiakkaamme, jonka kiireellinen alennusmyynti käynnisti koko matkamme, infrastruktuurilaskunsa kuukausitasolla pieneni 52 %:n verran siirryttyämme alustallemme, vaikka liikenne kasvoi kolminkertaiseksi aiempaan nähden.

Toiminnalliset parannukset olivat yhtä merkittäviä. Suorituskykyongelmien havaitsemiseen kuluneen keskimääräisen ajan (MTTD) väheni 12 minuutista alle 90 sekuntiin. Korjaamiseen kuluneen keskimääräisen ajan (MTTR) väheni 45 minuutista 8 minuuttiin. Infrastruktiotiimimme, joka aiemmin käytti 60 % ajastaan reaktiiviseen palomiespelaamiseen, käyttää nyt 80 % ajastaan proaktiivisiin parannuksiin ja uusien ominaisuuksien kehittämiseen.

Emme ole vielä valmiit. Pilviinfrastruktuurimme seuraava vaihe keskittyy kolmeen alueeseen: reunalaskenta, tekoälyyn perustuva kapasiteetin suunnittelu ja hiilijalanjälkeä huomioiva ajoitus. Testaamme tällä hetkellä reunalaskentapisteitä kahdellatoista lisäkaupungissa, jotka mahdollistavat viiveherkät työkuormat, kuten kuvien optimoinnin ja API-vastaukset, suorittamisen lähempänä pääkäyttäjiä. Varhaiset benchmark-tulokset osoittavat 40 %:n vähennyksen P99-viiveessä käyttäjille, jotka sijaitsevat enemmän kuin 1 000 kilometrin päässä lähimmästä datakeskuksestamme.

Tekoälyn saralla koulutamme kapasiteetin ennustusmallia kahden vuoden historiallisten tietojen perusteella kaikista asiakastyökuormista. Tavoitteena on ennustaa liikennemalleja 24 tuntia etukäteen riittävällä varmuudella, jotta kapasiteetti voidaan varata ennen huippukuormia, mikä eliminoi jopa lyhyet viiveen nousut reaktiivisessa skaalauksessa. Alustulokset ovat lupaavia; malli saavuttaa 89 %:n tarkkuuden seuraavan päivän huippuliikenteen ennustamisessa.

Viimeiseksi tutkimme hiilijalanjälkeä huomioivaa ajoitusta, joka siirtää kiireettömät työkuormat kuten varmuuskopiot, eräajot ja esikäsittelyn ajankohtiin, jolloin paikallisessa sähköverkossa on suurin osa uusiutuvasta energiasta. Tämä vastaa sitoumustamme kestävään infrastruktuuriin ja antaa ympäristötietoisille asiakkaillemme konkreettisen mittarin, johon he voivat viitata. Jos haluat oppia, miten nämä parannukset hyödyttävät liiketoimintaasi, ota yhteyttä tiimiimme. Aiomme ottaa kaikki kolme toimintoa käyttöön ennen vuoden 2026 loppua.