Skaleeritava pilveinfrastruktuuri loomine kasvavatele ettevõtetele

Kui GRADAXis hakkasime pakkuma haldatud hostimist ja pilveteenuseid, käitas enamik meie kliente ennustatava koormusega rakendusi. Kohaliku restorani veebisaidil oli stabiilne liiklus, võib-olla väike tõus nädalavahetustel. Kontori raamatupidaja portfooliosait kasutas serveriressursse minimaalselt. Varustasime ressursse konservatiivselt ja see töötas. Kuid kui hakkasime kaasama e-kaubanduse brände, SaaS-startupe ja meediaväljaandeid, muutus liikluse muster äärmuslikult ennustamatuks.

Üks meie kliente, Rumeenia moepood, korraldas flash-müügi, mis tõukas liikluse tavalisest 14 korda rohkemaks vähem kui üheksakümne sekundiga. Nende eelmine hostija ei suutnud seda taluda. Nad tulid meile järgmisel päeval küsimaga garantiid, et see ei kordu kunagi uuesti. See üks vestlus sundis meid läbi mõtlema kogu infrastruktuuri filosoofia. Me ei saanud enam disainida keskmiste põhjal, me pidime disainima äärmuste jaoks.

Põhiline väljakutse oli kolmeharuline: taluda järsku liikluse tõusu ilma käsikäivitamiseta, hoida kulud mõistlikud vaiksetel perioodidel ja säilitada alla 200 ms vastusajad Euroopa ja globaalsete lugejate jaoks. Ühe neist eraldi lahendada on lihtne. Kõigi kolme samaaegne lahendamine nõudis fundamentaalselt erinevat arhitektuuri.

Hinnaldasime enne praeguse tehnoloogiavaliku tegemist mitut lähenemisviisi. Täielikult serverivaba arhitektuur oli ahvatlev, kuid tekitas "cold-start" viivitusi, mis rikkusid meie jõudlusnõudeid, eriti serveripoolse renderdamisega Next.js rakenduste puhul, millele meie kliendid tuginevad. Traditsiooniline VM-põhine seade andis meile kontrolli, kuid puudus sellelt paindlikkus, mida me vajame. Saime hakkama hübriidmudeliga: baasena pühendatud arvutusvõimsus, mida toetavad vajadusel pilveserverite pulgad, mis saab käivituda vähem kui nelja sekundiga.

Meie juhtimisplaani (control plane) töötab Kubernetes, mis orkestreerib töökoormusi mitmes saadavusvööndis iga andmekeskuse piirkonna sees. Iga kliendi rakendus on konteinrisse pakitud standardiseeritud runtime'iga pilt, mis sisaldab meie monitooringu agenti, logide edastajat ja tervisekontrolli lõpppunkti. See ühtsus võimaldab auto-skaleerimist: iga container on vahetatav, nii et orkestraator saab lisada või eemaldata instance'i muretsemata keskkonnaspetsiifiliste nüansside pärast.

Andmekihi jaoks võtsime kasutusele kihtsalvestuse strateegia. Kuumad andmed asuvad NVMe SSD-del, replitseerituna kahe sõlme vahel. Soojad andmed liiguvad standardsetele SSD-dele pärast seitse päeva. Külmad andmed arhiveeritakse objektsalvestusse pärast kolmkümmend päeva. See vähendas meie salvestuskulusid 40% ilma kliendi jõudlusele märgatava mõjuta.

Automaatne skaleerimine tundub teoorias lihtne: kui nõudlus kasvab, lisa võimsust; kui see langeb, eemalda seda. Praktikas on ajastus ja lävendid ülimalt olulised. Liiga hilja skaleerides tabavad kasutajaid vead. Liiga vara skaleerides kulutate raha jõudeolevate ressursside peale. Veedetsime kolm kuud oma skaleerimispoliitikate häälestamisele, enne kui olime piisavalt kindlad, et neid tootmises ilma inimliku järelevalveta käitada.

Meie süsteem kasutab prognoosivat skaleerimismudelit, mis on kihistatud reageerivate käivitajate peale. Prognoosiv kiht analüüsib ajaloolist liiklust, nädalapäeva, ööpäeva aega, hooajalisi trende ja teadaolevaid sündmusi nagu tootelanšid või turunduskampaaniad, mida kliendid ajakavastavad meie dashboardi kaudu. See varustab mahutit viieteistkümne minuti enne oodatud nõudlust. Reageeriv kiht jälgib reaalajas meetrikaid: CPU kasutust, mälerõhku, päringute järjekorra sügavust ja P95 vastusviivitust. Kui ükski meetrika ületab oma läve, kerivad uued containerid sekunditega sisse.

Ehitasime ka kohandatud jahutusperioodi mehhanismi. Pärast tipu taandumist ei eemalda me lisavõimsust koheselt. Hoiame seda konfigureeritava akna jooksul (vaikimisi: kümme minutit), sest liikluse tipud tulevad sageli lainetena. See takistab kulukat containerite pidevat sisse- ja väljalülitamist pikaajaliste kõrge liikluse sündmuste ajal, nagu Black Friday või viirussotsiaalmeedia momendid.

Koormuse jaotamine GRADAX-is toimub kahes kihis. Välimine kiht on globaalne anycast-võrk, mis suunab kasutajad lähimasse andmekeskusesse viivituse põhjal, mitte ainult geograafia põhjal. Kasutaja Münchenis võib olla suunatud meie Frankfurdi sõlme või Amsterdami sõlme, sõltuvalt reaalajas võrgustingimustest. See otsus tehakse uuesti läbi iga kuuskümmend sekundit aktiivsete tervisekontrollide abil, mida saadetakse igast servipunktist.

Sisemine kiht jaotab liikluse konteinerite vahel ühes andmekeskuses. Loobusime varakult lihtsast ringkäigu (round-robin) algoritmist, kuna see ei arvesta konteineri tervist ega praegust koormust. Meie tasakaalustaja kasutab kaalutud vähimate ühenduste algoritmi, mis võtab arvesse iga konteineri praegust päringute arvu, CPU kasutust ja hiljutist veamäära. Konteinerid, mis kannatavad, saavad vähem päringuid, andes neile aega taastumiseks ilma täielikult rotatsioonist välja võtmata.

Samuti implementeerisime ühenduste äravoolu (connection draining) sujuvaks sulgemiseks. Kui auto-skaler otsustab konteineri eemaldada, peatab see esmalt uute ühenduste saatmise sellesse ja ootab kuni kolmkümmend sekundit, et olemasolevad päringud lõpetada. See elimineeris 502 vead, mis vaevatasid meie varasemaid iteratsioone skaleerimise vähendamise sündmuste ajal.

Pilveinfrastruktuur võib kalliks minna kiiresti, eriti kui teostate auto-skaleerimist mitmes piirkonnas. Võtsime distsiplineeritud lähenemise kuluhaldusele esimesest päevast, käsitledes infrastruktuuri kulu tootemetrina, mis on sama oluline nagu tööaeg või viivitus. Iga arhitektuurse otsuse läbib kulumõju analüüs enne tootmisse jõudmist.

Suurimad säästud tulid ressursi õigest mahust (right-sizing). Ehitasime analüüsitööriista, mis proovib konteineri ressursside kasutamist neliteistpäevaste akende jooksul ja soovitab optimaalseid CPU ja mälu eraldusi. Enamik kliente olid algselt hinnangute põhjal ülevarustatud 30–50%. Pärast ressursi mahu kohandamist vähendasime baasarvutusvõimsuse kulusid 35% üle terve floti. Samuti sõlmisime reserveeritud mahulepinguid meie ülemiste tarnijatega baaskoormuse jaoks, lukustades hinnad 45% allpool hetkelist hindamist.

Klientidele, kes soovivad maksimaalset kuluefektiivsust, pakume "burstable" taset, mis töötab jagatud infrastruktuuril tavatundidel ja skaleerub pühendatud ressurssidele ainult tipuperioodidel. See tase maksab 60% vähem kui meie standardne pakkumine ja on ideaalne ettevõtetele, kellel on ennustatavad madala liikluse perioodid, nagu B2B SaaS tooted, mis näevad peaaegu mingit kasutust väljaspool tööaega.

Te ei saa hallata seda, mida te ei saa mõõta, ja hajutatud auto-skaleerimissüsteemis on nähtavus kõige olulisem. Ehitasime meie jälgitavussüsteemi (observability stack) kolme sambaga: meetrikad, logid ja jäljed. Iga konteiner emiteerib struktureeritud meetrikaid viiesekundiliste intervallidega, mis katavad CPU-d, mälu, disk I/O, võrgu läbilaskevõimet, päringute arvu, vea määra ja vastusviivituse protsentuaale. Need voolavad ajaseeria andmebaasi, mis hoiab kõrge resolutsiooniga andmeid seitse päeva ja allproovitud andmeid kolmteist kuud.

Distribueeritud jälgimine (distributed tracing) oli osa, mis võttis kõige kauem õigeks saamiseks, kuid andis kõige suuremat väärtust. Iga sissetulev päring saab trace ID, mis järgneb selle läbi load balanceri, rakenduse konteineri, puhverkihi ja andmebaasi. Kui klient teatab aeglasedest lehekülgede laadimistest, saame tõsta täpse trace ja näha täpselt, kus aega kulutati. Üheksa korda kümnest on bottlenecks optimeerimata andmebaasi päring või puuduv cache võti, mitte infrastruktuur.

Meie häirete süsteem kasutab tasandatud tõsidusastmeid, mis on seotud ärimõjuga, mitte ainult tehniliste lävedega. Kombineerituna meie veebisaidi turvalisuse monitooringuga on üks konteiner, mis töötab kuumalt, informatiivne. Püsiv vea määr üle 1% üle kliendi floti on hoiatus. Mis tahes tööaja langus alla 99,9% viie minuti aknas helistab hädaolukorra insenerile koheselt. See lähenemine vähendas häirete müra 70% võrra võrreldes meie algse lävepõhise süsteemiga.

Pärast kaheksateist kuud kestnud tootmisjärku käitamist räägivad numbrid iseenda. Hoidsime 99,97% tööaja üle kõigi klientide koormuste, sealhulgas kolme suure liiklussündmuse ajal, mis ületasid baaskoormust 50 korda. Platvorm töötles viimases kvartalis üksi üle 2,8 miljardi päringu, globaalse P95 vastusajaga 142 millisekundit. Ühelgi kliendil ei tekkinud skaleerimisveade tõttu seisakuid.

Kuluosalt säästavad meie kliendid kokku hinnanguliselt 40% võrreldes samaväärsete konfiguratsioonidega suurte avalike pilvepakkujate juures. Automaatne skaleerimissüsteem hoidis mullu ära hinnanguliselt 180 000 euro väärtuses tarbetuid arvutuslikke kulusid, vähendades ressursse madala koormuse ajal hoopis pideva täiskoormuse asemel. Meie moepoe kliendi puhul, kelle kiirmüük alguse andis sellele kogu teekonnale, langes igakuine infrastruktuuri arve pärast üleminekut meie platvormile 52%, kuigi ta teenindas 3 korda rohkem liiklust kui varem.

Operatiivsed parandused olid sama olulised. Tuvastamise keskmine aeg (MTTD) jõudlusprobleemidele langes 12 minutilt alla 90 sekundi. Parandamise keskmine aeg (MTTR) langes keskmiselt 45 minutilt 8 minutile. Meie infrastruktuurimeeskond, mis varem veetis 60% ajast reageerivate häirete likvideerimisega, veedab nüüd 80% ajast proaktiivsetele parandustöödele ja uute funktsioonide arendamisele.

Me pole veel lõpetanud. Järgmine etapp meie pilvinfrastruktuuri teekonnas keskendub kolmele valdkonnale: servaarvutamine, AI-põhine mahuplaneerimine ja süsinikuteadlik ajastamine. Testime praegu servaarvutuse sõlmi kaheteistkümnes lisalinnas, mis võimaldaks latentsuse suhtes tundlikke koormusi, nagu pildioptimeerimine ja API vastused, käivitada lõppkasutajatest lähemal. Varajased mõõtmised näitavad P99 latentsuse vähenemist 40% kasutajate jaoks, kes asuvad rohkem kui 1000 kilomeetri kaugusel meie lähimast andmekeskusest.

AI-valdkonnas treenime mahuprognoosimise mudelit kahe aasta pikkuse ajaloolise andmestiku põhjal üle kõigi klientide koormuste. Eesmärk on ennustada liiklusmustreid 24 tundi ette piisava kindlusega, et varuda ressursse enne tippe, kõrvaldades isegi lühiajalise latentsuse suurenemise, mis toimub reageeriva skaleerimise sündmuste käigus. Esialgsed tulemused on paljutõotavad, saavutades mudel 89% täpsusega järgmise päeva tipuliikluse ennustamisel.

Lõpuks uurime süsinikuteadlikku ajastust, mis nihutaks mittekriitilisi koormusi, nagu varukoopiad, partii töötlemine ja eelrenderdamine aegadesse, mil kohalik elektrivõrk sisaldab taastuvenergia suurimat osa. See sobib meie laiemate jätkusuutliku infrastruktuuri pühendumusega ja annab keskkonnateadlikele klientidele konkreetse meetri, millele nad viidata saavad. Kui soovite teada, kuidas need parandused teie äri kasuks töötavad, võtke meiega ühendust. Ootame kõigi kolme funktsiooni väljatoomist enne 2026. aasta lõppu.