Izgradba skalabilne cloud infrastrukture za rastuća poduzeća

Kada smo započeli s ponudom managed hostinga i cloud usluga u GRADAX-u, većina naših klijenata imala je predvidljiva radna opterećenja. Web stranica lokalnog restorana dobivala je stabilan promet, možda mali skok vikendom. Portfolio web stranica računovođe gotovo nije utjecala na potrošnju resursa poslužitelja. Rezervirali smo konzervativno, i to je funkcioniralo. No, kako smo primili e-trgovinske brendove, SaaS startupe i medijske kuće, obrasci prometa postali su iznimno nepredvidivi.

Jedan od naših klijenata, rumunjsko tržište mode, proveo je flash rasprodaju koja je generirala 14x njihov normalni promet u manje od devedeset sekundi. Njihov prethodni host se urušio. Sljedećeg dana obratili su nam se tražeći jamstvo da se to više nikad neće dogoditi. Taj razgovor prisilio nas je da preispitamo cijelu filozofiju naše infrastrukture. Više nismo mogli dizajnirati za prosječne vrijednosti, morali smo dizajnirati za ekstremne situacije.

Glavni izazov bio je trojak: nositi se s naglim skokovima prometa bez ručne intervencije, održati razumne troškove tijekom tihih razdoblja i održavati vrijeme odgovora ispod 200 ms za europsku i globalnu publiku. Rješavanje bilo kojeg od ovih problema izolirano je jednostavno. Istovremeno rješavanje sva tri zahtijevalo je fundamentalno drugačiju arhitekturu.

Procijenili smo nekoliko pristupa prije nego što smo se odlučili za naš trenutni stack. Potpuno serverless arhitektura bila je privlačna, ali je uvodila latencije hladnog pokretanja koje su kršile naše ciljeve performansi, posebno za Next.js aplikacije renderirane na poslužitelju na kojima naši klijenti oslanjaju. Tradicionalni postav temeljen na VM-ovima dao nam je kontrolu, ali nedostajala mu je elastičnost koju smo trebali. Došli smo do hibridnog modela: bazni dio namjenskih compute resursa podržan on-demand cloud serverima koji se mogu pokrenuti u roku od četiri sekunde.

Naša kontrolna ravnina radi na Kubernetesu, orkestrirajući radna opterećenja kroz više zona dostupnosti unutar svake regije podatkovnog centra. Aplikacija svakog klijenta je kontejnerizirana sa standardiziranom slikom runtime okruženja koja uključuje naš agent za nadzor, forwarder logova i endpoint za provjeru zdravstvenog stanja. Ova uniformnost omogućuje automatsko skaliranje; svaki kontejner je zamjenjiv, pa orkestrator može dodavati ili uklanjati instance bez brige o specifičnostima okruženja.

Za sloj podataka usvojili smo strategiju višeslojnog pohranjivanja. Vrući podaci žive na NVMe SSD diskovima s replikacijom preko dva čvora. Topli podaci premještaju se na standardne SSD diskove nakon sedam dana. Hladni podaci arhiviraju se u object storage nakon trideset dana. Samo je ovo smanjilo naše troškove pohrane za 40% bez ikakvog primjetnog utjecaja na performanse klijenata.

Automatsko skaliranje zvuči jednostavno u teoriji: kada potražnja poraste, dodajte kapacitet; kada padne, uklonite ga. U praksi su tajming i pragovi iznimno važni. Skalirajte prekasno i korisnici će naići na pogreške. Skalirajte prerano i trošite novac na neiskorištene resurse. Proveli smo tri mjeseca ugađajući naše politike skaliranja prije nego što smo bili dovoljno sigurni da ih pokrenemo u produkciji bez ljudskog nadzora.

Naš sustav koristi prediktivni model skaliranja složen na reaktivne okidače. Prediktivni sloj analizira povijesne obrasce prometa, dan u tjednu, vrijeme u danu, sezonske trendove i poznate događaje poput lansiranja proizvoda ili marketinških kampanja koje klijenti zakazuju putem naše nadzorne ploče. On predviđa kapacitet petnaest minuta prije očekivane potražnje. Reaktivni sloj prati metrike u stvarnom vremenu: iskorištenost CPU-a, pritisak memorije, dubinu reda zahtjeva i P95 latenciju odgovora. Ako bilo koja metrika prijeđe svoj prag, novi kontejneri se pokreću u roku od nekoliko sekundi.

Također smo izgradili prilagođeni mehanizam hlađenja (cooldown). Nakon što skok prometa popusti, ne rušimo odmah dodatni kapacitet. Umjesto toga, zadržavamo ga u konfigurabilnom prozoru (zadano: deset minuta) jer skokovi prometa često dolaze u valovima. Ovo sprječava skupi ciklus ponovnog pokretanja kontejnera gore-dolje tijekom dugotrajnih događaja visokog prometa poput Black Fridayja ili viralnih društvenih mreža.

Ravnoteža opterećenja u GRADAX-u radi na dvije razine. Vanjska razina je globalna anycast mreža koja usmjerava korisnike prema najbližem podatkovnom centru na temelju latencije, a ne samo geografije. Korisnik u Münchenu može biti usmjeren na naš Frankfurt čvor ili naš amsterdamski čvor ovisno o stvarnim uvjetima mreže. Ova se odluka ponovno procjenjuje svakih šezdeset sekundi pomoću aktivnih sondi zdravlja koje se šalju iz svake rubne lokacije.

Unutarnja razina raspoređuje promet po kontejnerima unutar podatkovnog centra. Rano smo odustali od jednostavnog round-robin metoda jer ne uzima u obzir zdravlje kontejnera ili trenutno opterećenje. Naš balancer koristi algoritam ponderiranog najmanjeg broja veza koji uzima u obzir trenutni broj zahtjeva svakog kontejnera, iskorištenost CPU-a i nedavnu stopu pogrešaka. Kontejneri koji imaju poteškoća dobivaju manje zahtjeva, dajući im vremena da se oporave bez da budu potpuno izbačeni iz rotacije.

Također smo implementirali postupno gašenje veza za graciočno zaustavljanje sustava. Kada auto-skaler odluči ukloniti kontejner, prvo prestaje slati nove veze na njega, a zatim čeka do trideset sekundi da postojeći zahtjevi budu dovršeni. Time smo eliminirali 502 pogreške koje su nas mučile u ranijim iteracijama tijekom događaja smanjenja skaliranja.

Cloud infrastruktura može brzo postati skupa, posebno kada radite automatsko skaliranje kroz više regija. Od prvog dana primijenili smo disciplinirani pristup upravljanju troškovima, tretirajući rashode za infrastrukturu kao metriku proizvoda jednako važnu kao i dostupnost (uptime) ili latenciju. Svaka arhitektonska odluka prolazi kroz pregled utjecaja na troškove prije nego što stigne u produkciju.

Naše najveće uštede postignute su pravilnim određivanjem kapaciteta (right-sizing). Izgradili smo alat za analizu koji uzorkuje korištenje resursa kontejnera kroz prozore od četrnaest dana i preporučuje optimalne alokacije CPU-a i memorije. Većina klijenata bila je pretjerano rezervirana za 30-50% na temelju naših početnih procjena. Nakon pravilnog određivanja kapaciteta, smanjili smo bazne troškove računalnih resursa za 35% u cijeloj floti. Također smo pregovarali o sporazumima o rezerviranom kapacitetu s našim pružateljima usluga za bazno radno opterećenje, zaključavajući cijene 45% niže od on-demand cijena.

Za klijente koji žele maksimalnu učinkovitost troškova nudimo "burstable" razinu koja radi na dijeljenoj infrastrukturi tijekom normalnih sati i skalira se na namjenske resurse samo tijekom vrhunaca prometa. Ova razina košta 60% manje od naše standardne ponude i idealna je za tvrtke s predvidljivim razdobljima niskog prometa, poput B2B SaaS proizvoda koji gotovo nemaju upotrebe izvan radnog vremena.

Ne možete upravljati onim što ne možete mjeriti, a u distribuiranom sustavu automatskog skaliranja vidljivost je sve. Izgradili smo naš observability stack oko tri stuba: metrike, logovi i trace-ovi. Svaki kontejner emitira strukturirane metrike u intervalima od pet sekundi koje pokrivaju CPU, memoriju, disk I/O, mrežni throughput, broj zahtjeva, stopu pogrešaka i percentile latencije odgovora. Ovi podaci teku u bazu podataka vremenskog niza koja zadržava visoko rezolutne podatke za sedam dana i downsampalne podatke za trinaest mjeseci.

Distribuirano praćenje (tracing) bio je dio koji je najduže trajao da se ispravno implementira, ali je donio najveću vrijednost. Svaki dolazni zahtjev dobiva ID trace-a koji ga prati kroz load balancer, aplikacijski kontejner, sloj predmemorije i bazu podataka. Kada klijent prijavi sporo učitavanje stranice, možemo povući točan trace i vidjeti točno gdje je vrijeme provedeno. Devet puta od deset, usko grlo je neoptimizirani upit baze podataka ili nedostajući ključ predmemorije, ne infrastruktura.

Naš sustav upozorenja koristi hijerarhijske razine ozbiljnosti povezane s poslovnim utjecajem, a ne samo tehničkim pragovima. U kombinaciji s našim nadzorom sigurnosti web stranica, jedan kontejner koji radi vruće je informativne prirode. Održana stopa pogrešaka iznad 1% u cijeloj floti klijenta je upozorenje. Bilo kakav pad dostupnosti ispod 99,9% u petominutnom prozoru odmah poziva inženjera na dežurstvu. Ovaj pristup smanjio je buku upozorenja za 70% u usporedbi s našim početnim sustavom temeljenim na pragovima.

Nakon osamnaest mjeseci rada ove arhitekture u produkcijskom okruženju, brojke govore same za sebe. Održali smo 99,97% dostupnosti za sve klijentske radne opterećenja, uključujući tijekom tri veća događaja prometa koji su svaki premašili bazu od 50 puta. Platforma je samo u posljednjem kvartu obradila više od 2,8 milijarde zahtjeva, s globalnim P95 vremenom odgovora od 142 milisekunde. Niti jedan klijent nije imao prekid rada zbog neuspjeha skaliranja.

Što se tiče troškova, naši klijenti zajednički štede procijenjenih 40% u usporedbi s ekvivalentnim konfiguracijama kod velikih javnih cloud pružatelja usluga. Sustav automatskog skaliranja spriječio je procijenjeno 180.000 € nepotrebnih troškova računalne snage prošle godine smanjenjem kapaciteta izvan vršnih sati umjesto stalnog rada punim kapacitetom 24/7. Za našeg klijenta na tržištu mode, čija je flash rasprodaja pokrenula cijelu ovu priču, mjesečni račun za infrastrukturu smanjen je za 52% nakon migracije na našu platformu, unatoč tome što obrađuje 3x veći promet nego prije.

Operativna poboljšanja bila su jednako značajna. Prosječno vrijeme detekcije problema s performansama smanjilo se s 12 minuta na manje od 90 sekundi. Prosječno vrijeme rješavanja problema palo je s 45 minuta na 8 minuta. Naš tim infrastrukture, koji je ranije 60% vremena provodio na reaktivnom gašenju požara, sada 80% vremena posvećuje proaktivnim poboljšanjima i razvoju novih funkcija.

Još nismo gotovi. Sljedeća faza naše roadmap-e cloud infrastrukture fokusira se na tri područja: edge computing, planiranje kapaciteta vođen umjetnom inteligencijom i raspoređivanje svjesno o ugljiku. Trenutno testiramo edge compute čvorove u dvanaest dodatnih gradova koji bi omogućili da radna opterećenja osjetljiva na latenciju, poput optimizacije slika i API odgovora, rade bliže krajnjim korisnicima. Rani benchmarkovi pokazuju 40% smanjenje P99 latencije za korisnike koji se nalaze više od 1.000 kilometara od našeg najbližeg data centra.

Što se tiče AI-a, treniramo model za predviđanje kapaciteta na dvije godine povijesnih podataka za sva klientska radna opterećenja. Cilj je predvidjeti obrasce prometa 24 sata unaprijed s dovoljno sigurnosti kako bi se kapaciteti rezervirali prije nastanka pikova, čime se eliminira čak i kratko povećanje latencije koje se događa tijekom reaktivnih događaja skaliranja. Početni rezultati su obećavajući, pri čemu model postiže točnost od 89% u predviđanju dnevnih pikova prometa.

Konačno, istražujemo raspoređivanje svjesno o ugljiku koje bi pomaknulo nehitna radna opterećenja kao što su backups, batch processing i prerendering na vremena kada lokalna električna mreža ima najveći udio obnovljivih izvora energije. Ovo se usklađuje s našim širim angažmanom za održivu infrastrukturu i daje našim ekološki svjesnim klijentima opipljivi metrik na koji se mogu pozvati. Ako želite saznati kako vam ova poboljšanja mogu koristiti, kontaktirajte naš tim. Planiramo implementirati sve tri mogućnosti do kraja 2026. godine.