Gradnja skalabilne oblak infrastrukture za rastoča podjetja

Ko smo pri GRADAXu začeli ponujati upravljano gostovanje in storitve v oblaku, so imela večina naših strank predvidljive obremenitve. Spletna stran lokalne restavracije je dobivala stabilen promet, morda majhen vzpon ob koncu tedna. Portfeljska spletna stran računovodja skoraj ni obremenila virov strežnika. Zagotavljali smo zmogljivost konservativno in to je delovalo. A ko smo pridobili e-trgovske blagovne znamke, zagoni SaaS in medijske hiše, so se vzorci prometa postali izjemno nepredvidljivi.

Ena od naših strank, romunska modna tržnica, je izvedla flash prodajo, ki je povzročila 14-kratnik njihovega običajnega prometa v manj kot devetdesetih sekundah. Njihov prejšnji gostitelj je popustil. Naslednji dan so nas kontaktirali in prosili za zagotovilo, da se to nikoli več ne bo zgodilo. Ta pogovor nas je prisilil, da premislimo o celotni filozofiji naše infrastrukture. Več nismo mogli načrtovati za povprečja, morali smo načrtovati za skrajnosti.

Glavni izziv je bil trojen: obvladovati nenadne prometne vrhunce brez ročnega posredovanja, ohranjati razumne stroške med tišimi obdobji in vzdrževati čase odziva pod 200 ms za evropsko in globalno občinstvo. Rešitev katere koli od teh težav izolirano je preprosta. Hkratna rešitev vseh treh pa je zahtevala temeljno drugačno arhitekturo.

Preden smo se odločili za trenutno tehnologijo, smo ovrednotili več pristopov. Popolnoma serverless arhitektura je bila privlačna, a je uvedla zamude hladnega zagona, ki so kršile naše cilje glede zmogljivosti, še posebej za Next.js aplikacije s strežniškim upodabljanjem, na katerih naše stranke temeljijo. Tradicionalna nastavitev na osnovi VM nam je dala nadzor, a je manjkala elastičnost, ki smo jo potrebovali. Pristopili smo k hibridnemu modelu: osnova namenskih računalnikov, ki jo podpirajo paketi oblak strežnikov po potrebi, ki se lahko vklopijo v manj kot štirih sekundah.

Naša kontrolna raven teče na Kubernetesu, ki orkestrira obremenitve prek več con dostopnosti v vsaki regiji podatkovnega centra. Aplikacija vsakega stranka je containerizirana s standardizirano sliko runtime, ki vključuje naš agent za spremljanje, napredek dnevnika in končno točko zdravja. Ta enotnost omogoča samodejno skaliranje; vsak container je zamenljiv, zato orkestrator lahko doda ali odstrani instance brez skrbi za specifične lastnosti okolja.

Za podatkovno plast smo sprejeli strategijo slojevitega shranjevanja. Vroči podatki živijo na NVMe SSD-jih z replikacijo prek dveh vozlišč. Topli podatki se po sedmih dneh preselijo na standardne SSD-je. Hladni podatki se arhivirajo v objekt shrambo po tridesetih dneh. To samo po sebi je znižalo naše stroške shranjevanja za 40 % brez opaznega vpliva na zmogljivost strank.

Samodejno skaliranje se v teoriji sliši preprosto: ko povpraševanje naraste, dodamo zmogljivost; ko upade, jo odstranimo. V praksi sta časovna usklajenost in postavljanje mejnih vrednosti izjemno pomembna. Če skalirate prepozno, uporabniki naletijo na napake. Če skalirate prezgodaj, zapravljate denar za neizkoriščene vire. Tri mesece smo uglaševali naše politike skaliranja, preden smo bili dovolj prepričani, da jih lahko v produkciji izvajamo brez človeškega nadzora.

Naš sistem uporablja model prediktivnega skaliranja, ki ga nadgrajujejo reaktivni sprožilci. Prediktivna plast analizira zgodovinske vzorce prometa, dan v tednu, čas dneva, sezonske trende in znane dogodke, kot so lansiranje izdelkov ali tržne kampanje, ki jih stranke načrtujejo prek naše nadzorne plošče. Kapaciteto predpripravi petnajst minut pred pričakovano povpraševanjem. Reaktivna plast spremlja metrike v realnem času: zasedenost CPU, pritisk pomnilnika, globino čakalne vrstice zahtevek in zakasnitev odziva P95. Če katera koli metrika preseže prag, se novi containerji vklopijo v nekaj sekundah.

Zgradili smo tudi prilagojen mehanizem ohlajanja. Ko se vrhunec umiri, takoj ne rušimo dodatne kapacitete. Namesto tega jo držimo v konfigurabilnem oknu (privzeto: deset minut), ker prometni vrhunci pogosto prihajajo v valovih. To preprečuje dragoceno menjavanje ponovnega zagona containerjev gor in dol med trajnimi dogodki visokega prometa, kot sta Black Friday ali viralni trenutki na družbenih medijih.

Uravnoteženje bremen pri GRADAX deluje na dveh ravneh. Zunanja raven je globalna anycast mreža, ki usmerja uporabnike v najbližji podatkovni center glede na zakasnitev, ne le geografsko. Uporabnik v Münchnu je lahko usmerjen v naše vozlišče v Frankfurtu ali Amsterdamu glede na dejanske pogoje omrežja. To odločitev ponovno ovrednotimo vsakih šestdeset sekund z aktivnimi sondami zdravja, ki se pošljejo iz vsakega robnega mesta.

Notranja raven porazdeli promet med vsebnike znotraj podatkovnega centra. Zgodaj smo odstopili od preprostega krožnega razporeda, ker ne upošteva zdravja vsebnikov ali trenutne obremenitve. Naš uravnoteževalnik uporablja algoritem tehtanih najmanj povezav, ki upošteva trenutno število zahtevkov vsakega vsebnika, zasedenost CPU in nedavno stopnjo napak. Vsebniki, ki imajo težave, prejmejo manj zahtevkov, kar jim daje čas za okrevanje, ne da bi bili popolnoma izvzeti iz rotacije.

Implementirali smo tudi postopno prekinjanje povezav za gladka zapiranja. Ko avtomatski skaliralec odloči odstraniti vsebnik, najprej ustavi pošiljanje novih povezav nanj, nato pa počaka do trideset sekund, da obstoječe zahteve dokončajo. To je odpravilo napake 502, ki so nas mučile v prejšnjih iteracijah med dogodki zmanjševanja obsega.

Oblak infrastruktura se lahko hitro draži, še posebej, ko samodejno skalirate prek več regij. Od prvega dne smo sledili discipliniranemu pristopu k upravljanju stroškov, obravnavali porabo infrastrukture kot metriko izdelka, enako pomembno kot dosegljivost ali zakasnitev. Vsaka arhitekturna odločitev gre skozi pregled vpliva na stroške, preden pride v proizvodnjo.

Največje prihranke smo dosegli z ustreznim nastavljanjem velikosti. Zgradili smo analitsko orodje, ki vzorči porabo virov vsebnikov v oknih štirinajstih dni in priporoča optimalne alokacije CPU in pomnilnika. Večina strank je bila po naših prvotnih ocenah prevelikih za 30–50 %. Po pravilnem nastavljanju velikosti smo znižali stroške baznega računalništva za 35 % v celotni floti. Pogajali smo se tudi o pogodbah o rezervirani kapaciteti z našimi dobavitelji za bazno obremenitev, s čimer smo zaklenili cene za 45 % nižje od cen po potrebi.

Za stranke, ki želijo maksimalno učinkovitost stroškov, ponujamo "prebojno" stopnjo, ki teče na skupni infrastrukturi med običajnimi urami in se skalira do namenskih virov le med vrhunskimi obdobji. Ta stopnja stane 60 % manj kot naša standardna ponudba in je idealna za podjetja z predvidljivimi nizkimi prometnimi obdobji, kot so B2B SaaS izdelki, ki skoraj nimajo uporabe zunaj poslovnih ur.

Ne morete upravljati tistega, kar ne morete meriti, in v distribuiranem sistemu samodejnega skaliranja je vidnost vse. Našo kupolo opazljivosti smo zgradili okoli treh stebrov: metrik, dnevnikov in sledi. Vsak vsebnik oddaja strukturirane metrike v intervalih petih sekund, ki pokrivajo CPU, pomnilnik, disk I/O, omrežno propustnost, število zahtevkov, stopnjo napak in odstotke zakasnitve odziva. Ti tokovi v časovno vrstico baze podatkov, ki hrani visoločene podatke za sedem dni in zmanjšane podatke za trinajst mesecev.

Distribuirano sledenje je bilo del, ki je zahteval največ časa za pravilno izvedbo, a je prinesel največ vrednosti. Vsaka vhodna zahteva prejme ID sledi, ki jo spremlja skozi uravnoteževalnik bremen, aplikacijski container, plast predpomnilnika in bazo podatkov. Ko stranka prijavi počasno nalaganje strani, lahko prikličemo točno sled in vidimo, kje je bil porabljen čas. Devetkrat od desetih je ovira neoptimirana poizvedba v bazi podatkov ali manjkajoč ključ predpomnilnika, ne infrastruktura.

Naš sistem opozarjanja uporablja stopnje resnosti, povezane z poslovnim vplivom, ne le tehničnimi pragovi. V kombinaciji z našim varnostnim spremljanjem spletnih mest je en sam vsebnik, ki deluje vroče, informativen. Vztrajna stopnja napak nad 1 % v celotni floti stranke je opozorilo. Vsak padec dosegljivosti pod 99,9 % v petminutnem oknu takoj pokliče inženirja na dežurstvu. Ta pristop je zmanjšal šum opozoril za 70 % v primerjavi z našim začetnim sistemom, ki temelji na pragovih.

Po osamnaestih mesecih delovanja te arhitekture v proizvodnem okolju številke govorijo same za sebe. Vzdrževali smo 99,97-odstotno dosegljivost pri vseh obremenitvah strank, vključno med tremi večjimi prometnimi dogodki, ki so vsak presegli petkratnik osnovne obremenitve. Platforma je v zadnjem četrtletju sama obravnavala več kot 2,8 milijarde zahtevkov s povprečnim časom odziva P95 na globalni ravni 142 milisekund. Nobena stranka ni doživela izpada zaradi napak pri skaliranju.

Na strani stroškov naše stranke skupaj prihranijo ocenjenih 40 % v primerjavi z ekvivalentnimi konfiguracijami pri velikih javnih ponudnikih oblaka. Samodejni sistem za skaliranje je lani preprečil nepotrebne stroške izračunovalnih zmogljivosti v višini ocenjenih 180.000 evrov tako, da je med nedeljskimi urami zmanjšal obremenitev namesto da bi deloval polno obremenitev 24/7. Za našo stranko, spletno trgovsko platformo za modo, katere blagovna akcija je sprožila celoten proces, se je mesečni račun za infrastrukturo po selitvi na našo platformo znižal za 52 %, kljub temu da je obravnaval trikrat več prometa kot prej.

Operativne izboljšave so bile prav tako pomembne. Povprečni čas zaznave težav s performansami se je zmanjšal z 12 minut na manj kot 90 sekund. Povprečni čas reševanja je padel z 45 minut na 8 minut. Naša ekipa infrastrukture, ki je prej 60 % časa porabila za reaktivno gašenje požarov, zdaj 80 % časa namenja proaktivnim izboljšavam in razvoju novih funkcij.

Še nismo končali. Naslednja faza našega načrta za oblakovno infrastrukturo se osredotoča na tri področja: robno računalništvo, načrtovanje kapacitet na podlagi umetne inteligence in urnike, ki upoštevajo ogljično stopnjo. Trenutno testiramo robne izračunske vozlišča v dvanajstih dodatnih mestih, ki bi omogočila, da so obremenitve, občutljive na zakasnitev, kot so optimizacija slik in odgovori API-ja, izvajane bližje končnim uporabnikom. Zgodnji benchmarki kažejo 40-odstotno zmanjšanje zakasnitve P99 za uporabnike, ki so oddaljeni več kot 1.000 kilometrov od najbližjega podatkovnega centra.

Na področju umetne inteligence treniramo model za napovedovanje kapacitet na podlagi dveh let zgodovinskih podatkov za vse obremenitve strank. Cilj je napovedati vzorce prometa 24 ur vnaprej z dovolj visoko zanesljivostjo, da lahko predprovisioniramo kapacitete pred nastopom vrhov, s čimer se odpravi celo kratko povečanje zakasnitve, ki se pojavi med dogodki reaktivnega skaliranja. Začetni rezultati so obetavni, saj model dosega 89-odstotno natančnost pri napovedovanju jutranjih prometnih vrhov.

Nazadnje raziskujemo tudi urnike, ki upoštevajo ogljično stopnjo, kar bi omogočilo premik nenujnih obremenitev, kot so varnostne kopije, paketno obdelavo in predpredstavljanje, na čase, ko lokalna električna mreža ima največji delež obnovljivih virov energije. To se ujema z našim širšim zavezništvom k trajnostni infrastrukturi in našim okoljsko ozaveščenim strankam daje merljiv kazalnik, na katerega se lahko sklicujejo. Če želite izvedeti, kako vam lahko te izboljšave koristijo, stopite v stik z našo ekipo. Vse tri zmogljivosti pričakujemo vpeljati do konca leta 2026.