Skalijuojamos debesų infrastruktūros kūrimas augančioms įmonėms

Kai pradėjome teikti valdomą talpinimą ir debesų paslaugas GRADAX, dauguma mūsų klientų naudojo numatomus krūvius. Vietinio restorano svetainę lankydavo pastovus srautas, galbūt nedidelis padidėjimas savaitgaliais. Buhalterio portfolijo svetainė beveik neapkraudavo serverio išteklių. Mes rezervavome išteklius atsargiai, ir tai veikė. Tačiau prisijungus e-prekybos prekės ženklams, SaaS startuoliams ir žiniasklaidos portalams, srauto modeliai tapo itin neprognozuojami.

Vienas iš mūsų klientų, Rumunijos mados turgvietė, surengė „flash sale“ akciją, kuri per devyniasdešimt sekundžių sugeneravo 14 kartų daugiau srauto nei įprastai. Jų ankstesnis hoster'is nesulaužė. Kitą dieną jie kreipėsi į mus prašydami garantijos, kad to niekada nebebūtų. Šis pokalbis privertė mus persvarstyti visą infrastruktūros filosofiją. Nebeturėjome projektuoti pagal vidurkius, turėjome projektuoti pagal ekstremalus scenarijus.

Pagrindinis uždavinys buvo trijų dalių: valdyti staigius srauto šuolius be rankinio kišimosi, išlaikyti priimtinus kaštus ramybės laikotarpiu ir užtikrinti mažesnę nei 200 ms atsako laiką Europos bei pasaulio vartotojams. Spręsti bet kurį iš šių uždavinių atskirai yra paprasta. Visus tris išspręsti vienu metu reikalavo esmingai kitokios architektūros.

Prieš pasirinkdami dabartinę technologijų stack'ą, įvertinome kelias alternatyvas. Pilnai serverless architektūra viliojo, tačiau sukėlė „cold-start“ delsą, kuri pažeidžia mūsų našumo tikslus, ypač server-rendered Next.js programoms, nuo kurių priklausomi mūsų klientai. Tradicinis VM pagrindu sukurtas setup'as suteikė kontrolę, bet neturėjo elastingumo, kurio mums reikėjo. Sustojome prie hibridinio modelio: bazinis dedikuotas skaičiavimas, paremtas paklausos debesijos serverių pulkais, kurie gali būti paleisti per mažiau nei keturias sekundes.

Mūsų valdymo plokštė veikia Kubernetes aplinkoje, koordinuodama krūvius keliuose prieinamumo zonose kiekviename duomenų centro regione. Kiekvieno kliento programa konteinerizuota su standartizuotu vykdymo vaizdu, kuriame įtraukti mūsų stebėjimo agentas, žurnalų perdavimo agentas ir sveikatos patikros endpoint'as. Šis vienodumas leidžia taikyti automatinį mastelio keitimą: kiekvienas konteineris yra keičiamas, todėl orkestratorius gali pridėti arba pašalinti egzempliorius nerizikuodamas dėl specifinių aplinkos niuansų.

Duomenų sluoksniui adoptavome daugiapakopę saugojimo strategiją. Karšti duomenys saugomi NVMe SSD diskuose su replikacija tarp dviejų mazgų. Šilti duomenys perkelti į standartinius SSD diskus po septynių dienų. Šalti duomenys archyvuoja į objektinį saugyklą po trisdešimties dienų. Tai vienintelis veiksnys sumažino mūsų saugojimo kaštus 40 %, nepadarant jokio pastebimo poveikio klientų našumui.

Automatinis mastelio keitimas teoriškai skamba paprastai: kai paklausa auga, pridėti pajėgumų; kai krenta, juos sumažinti. Praktiškai laikas ir slenksčiai turi milžinišką reikšmę. Jei padidinsite per vėlai, vartotojai susidurs su klaidomis. Jei padidinsite per anksti, išleisite pinigus tuščiai veikiantiems ištekliams. Tris mėnesius derinome savo mastelio keitimo taisykles, kol įgijome pakankamai pasitikėjimo, kad galėtume jas naudoti produkcinėje aplinkoje be žmogaus priežiūros.

Mūsų sistema naudoja prognozinio mastelio keitimo modelį, papildytą reaktyviais triggeriais. Prognozinis sluoksnis analizuoja istorinius srauto modelius, savaitės dieną, paros laiką, sezonines tendencijas ir žinomus įvykius, pvz., produktų paleidimus ar rinkodaros kampanijas, kurias klientai planuoja per mūsų skydelį. Jis iš anksto paruošia kapacitetą prieš dvidešimt penkias minutes iki numatomo poreikio. Reaktyvusis sluoksnis stebi realaus laiko metrikas: CPU naudojimą, atminties slėgį, užklausų eilės gylį ir P95 atsako latenciją. Jei bet kuri metrika viršija savo ribą, nauji konteineriai paleidžiami per kelias sekundes.

Taip pat sukūrėme specialų aušinimo mechanizmą. Po srauto šuolio nuslopimo mes nedelsdami neatsijungiame papildomo kapaciteto. Vietoj to, jį išlaikome konfigūruojamu laiku (numatytasis: dešimt minučių), nes srauto šuoliai dažnai ateina bangomis. Tai neleidžia brangiai kainuojančio nuolatinio konteinerių paleidimo ir sustabdymo ciklo, kai vyksta ilgesni aukšto srauto įvykiai, kaip „Juodojo penktadienio“ akcijos ar viralūs socialinių tinklų momentai.

Apkrovos balansas GRADAX veikia dviem sluoksniais. Išorinis sluoksnis yra globalus anycast tinklas, nukreipiantis vartotojus į artimiausią duomenų centrą pagal latenciją, o ne tik geografiją. Vartotojas Miunchene gali būti nukreiptas į mūsų Frankfurto arba Amsterdamo mazgą, priklausomai nuo realaus laiko tinklo sąlygų. Šis sprendimas peržiūrimas kas šešiasdešimt sekundžių naudojant aktyvias sveikatos zondavimo užklausas iš kiekvieno krašto lokacijos.

Vidinis sluoksnis paskirsto srautą tarp konteinerių duomenų centre. Anksti atsisakėme paprasto round-robin metodo, nes jis neatsižvelgia į konteinerio sveikatą arba dabartinį krūvį. Mūsų balansas naudoja svorinį mažiausių ryšių algoritmą, kuris įvertina kiekvieno konteinerio dabartinį užklausų skaičių, CPU naudojimą ir neseniai fiksuotą klaidų rodiklį. Konteineriai, kurie susiduria su sunkumais, gauna mažiau užklausų, leisdami jiems atsistatyti nebūdami visiškai pašalinti iš rotacijos.

Taip pat įdiegėme ryšių nutekėjimą (connection draining) sklandžiam išjungimui. Kai auto-scaler'is nusprendžia pašalinti konteinerį, jis pirmiausia nustoja siųsti naujas jungtis, o tada palaukia iki trisdešimt sekundžių, kol baigsis esamos užklausos. Tai pašalino 502 klaidas, kurios vargino mūsų ankstesnes iteracijas mažinant mastelį.

Debesijos infrastruktūra gali greitai tapti brangi, ypač kai taikote automatinį mastelio keitimą keliuose regionuose. Nuo pirmos dienos taikėme disciplinuotą kaštų valdymą, traktuodami infrastruktūros išlaidas kaip produkto metriką, svarbią tiek, kaip ir prieinamumas arba latencija. Kiekvienas architektūros sprendimas prieš patekdamas į produkciją praeina kaštų poveikio peržiūrą.

Didžiausias taupymas kilo iš teisingo išteklių priskyrimo (right-sizing). Sukūrėme analizės įrankį, kuris imčia konteinerio išteklių naudojimą per keturiolikos dienų langus ir rekomenduoja optimalų CPU ir atminties priskyrimą. Dauguma klientų buvo per daug aprūpinti ištekliais, 30–50 % daugiau nei mūsų pradiniai įverčiai. Po teisingo priskyrimo sumažinome bazinius skaičiavimo kaštus 35 % visoje flotilėje. Taip pat derėjome dėl rezervuoto kapaciteto susitarimų su mūsų tiekėjais baziniam krūviui, užfiksuodami kainas 45 % žemiau nei paklausos kainų.

Klientams, norintiems maksimalaus kaštų efektyvumo, siūlome „burstable“ paketą, kuris normaliomis valandomis veikia bendroje infrastruktūroje ir mastelis keičiasi į dedikuotus išteklius tik pikinėmis periodais. Šis paketas kainuoja 60 % pigiau nei standartinis pasiūlymas ir yra idealus verslui su numatomais žemo srauto periodais, pvz., B2B SaaS produktams, kurie beveik neturi naudojimo už darbo valandų ribų.

Negalite valdyti to, ko negalite išmatuoti, o pasiskirstytoje auto-scaling sistemoje matomumas yra viskas. Sukūrėme stebėsenos stack'ą aplink tris stulpus: metrikas, žurnalus ir sekas. Kiekvienas konteineris emituoja struktūruotas metrikas penkių sekundžių intervalais, apimančias CPU, atmintį, disko I/O, tinklo pralaidumą, užklausų skaičių, klaidų rodiklį ir atsako latencijos percentiles. Jos teka į laiko serijų duomenų bazę, kuri išsaugo aukštos rezoliucijos duomenis septynias dienas ir downsampintus duomenis trylika mėnesių.

Pasiskirstyta sekimo (distributed tracing) funkcija užtruko ilgiausiai, tačiau davė didžiausią vertę. Kiekviena įeinanti užklausa gauna sekos ID, kuris seka ją per apkrovos balancerį, programos konteinerį, talpyklos sluoksnį ir duomenų bazę. Kai klientas praneša apie lėtus puslapio įkrovimus, galime iškviet tikslią seką ir pamatyti, kur būtent buvo praleista laikas. Devynis iš dešimties kartų butleneck'as yra neoptimizuotas duomenų bazės užklausos arba trūkstantis cache raktas, ne infrastruktūra.

Mūsų perspėjimų sistema naudoja pakopinius sunkumo lygius, susietus su verslo poveikiu, o ne tik techninėmis ribomis. Kombinuota su mūsų svetainės saugumo stebėjimu, vieno konteinerio perkaitimas yra informacinio pobūdžio. Pastovus klaidų rodiklis virš 1 % viso kliento flotilėje yra įspėjimas. Bet koks prieinamumo kritimas žemiau 99,9 % penkių minučių lange nedelsiant informuoja budinčio inžinieriaus. Šis požiūris sumažino perspėjimų triukšmą 70 %, palyginti su pradine ribų pagrindu sukurta sistema.

Praėjus aštuoniolikai mėnesių šios architektūros eksploatavimo gamyboje, skaičiai kalba patys už save. Visose klientų apkrovose išlaikėme 99,97 % veikimo laiką, įskaitant tris didelius srauto įvykius, kurių kiekvienas viršijo bazinį krūtį 50 kartų. Per pastarąjį ketvirtį platforma apdorojo daugiau nei 2,8 mlrd. užklausų, o pasaulinis P95 atsako laikas buvo 142 milisekundės. Joks klientas nepatyrė neveiklumo dėl mastelio keitimo klaidų.

Kainodara: mūsų klientai bendrai taupo apie 40 %, palyginti su analogiškomis konfigūracijomis didžiuosiuose viešosios debesijos teikėjams. Automatinio mastelio keitimo sistema pernai neleido praleisti apie 180 000 € nereikalingų skaičiavimo išteklių išlaidų, sumažindama resursus neaktyviomis valandomis, o ne palaikydama maksimalią apkrovą visą parą. Mados rinkos klientui, kurio „flash“ pardavimai pradėjo šią kelionę, mėnesinė infrastruktūros sąskaita sumažėjo 52 % persikėlus į mūsų platformą, nepaisant to, kad srautas padidėjo 3 kartus.

Veiklos pagerinimai taip pat buvo reikšmingi. Vidutinis laiko tarpas iki problemų aptikimo sumažėjo nuo 12 minučių iki mažiau nei 90 sekundžių. Vidutinis laiko tarpas iki sprendimo nukrito nuo 45 minučių iki 8 minučių. Mūsų infrastruktūros komanda, kuri anksčiau 60 % laiko skyrė reakcijai į kritines situacijas, dabar 80 % laiko skiria proaktyviems patobulinimams ir naujų funkcijų kūrimui.

Mes nesustojame. Kitas mūsų debesijos infrastruktūros plano etapas sutelktas į tris sritis: krašto skaičiavimus (edge computing), dirbtinio intelekto pagrindu paremtą talpos planavimą ir anglies kiekį atsižvelgiančią tvarkaraštį. Šiuo metu testuojame kraito skaičiavimo mazgus dvylikoje papildomų miestų, kurie leis jautriems vėlavimui darbams, pvz., vaizdų optimizavimui ir API atsakymams, vykti arčiau galutinių naudotojų. Ankstyvi benchmark rezultatai rodo 40 % P99 vėlavimo sumažėjimą naudotojams, esantiems daugiau nei 1 000 km atstumu nuo artimiausio mūsų duomenų centro.

Dirbtinio intelekto srityje mokome talpos prognozavimo modelį remdamiesi dvejų metų istoriniais duomenimis apie visas klientų apkrovas. Tikslas, 24 valandas iš anksto numatyti srauto modelius su pakankamu pasitikėjimu, kad būtų galima iš anksto paruošti talpą prieš prasidedant pikams, taip pašalinant net trumpalaikius vėlavimo padidėjimus, atsirandančius reaktyviai didinant mastelį. Pradiniai rezultatai yra pažadūs: modelis pasiekia 89 % tikslumą prognozuodamas kitos dienos pikinę apkrovą.

Galiausiai nagrinėjame anglies kiekį atsižvelgiančią tvarkaraštį, kuris nekilniosioms užduotims, kaip atsarginės kopijos, partiniai procesai ir išankstinis renderinimas, perkeltų į tas valandas, kai vietinė elektros tinklo dalis turi didžiausią atsinaujinančios energijos procentą. Tai atitinka mūsų platesnį įsipareigojimą tvariai infrastruktūrai ir suteikia aplinkosaugai jautriems klientams matomą metriką, į kurią jie gali remtis. Jei norite sužinoti, kaip šie patobulinimai gali naudingi jūsų verslui, susisiekite su mūsų komanda. Planuojame įdiegti visas tris funkcijas iki 2026 m. pabaigos.