Výstavba škálovateľnej cloudovej infraštruktúry pre rastúce firmy

Keď sme v spoločnosti GRADAX začali ponúkať spravovaný hosting a cloudové služby, väčšina našich klientov prevádzkovala predvídateľné záťaže. Webová stránka miestnej reštaurácie mala stabilnú návštevnosť, prípadne malú špičku cez víkend. Portfólio účtovníka takmer nezvyšovalo využitie serverových zdrojov. Provisionovali sme konzervatívne a fungovalo to. Keď sme však prijímali e-commerce značky, SaaS startupy a mediálne vydavateľstvá, vzorce prevádzky sa stali extrémne nepredvídateľnými.

Jeden z našich klientov, rumunský módny trhový portál, usporiadal bleskovú výpredaj, ktorý za menej ako deväťdesiat sekúnd zvýšil ich bežnú prevádzku o 14-krát. Ich predchádzajúci hostingový poskytovateľ podľahol tlaku. Nasledujúci deň k nám prišli s požiadavkou na záruku, že sa to už nikdy neopakuje. Táto jediná konverzácia nás prinútila premyslieť si celú filozofiu našej infraštruktúry. Už sme nemohli navrhovať systém pre priemerné hodnoty, museli sme navrhovať pre extrémne situácie.

Hlavnou výzvou bolo tri vecí: zvládnuť náhle špičky prevádzky bez manuálneho zásahu, udržať náklady primerané počas obdobií ticha a udržiavať odozvu nižšiu ako 200 ms pre európske aj globálne publikum. Riešenie ktorejkoľvek z týchto problémov izolovane je jednoduché. Ich súčasné riešenie si vyžiadalo fundamentálne odlišnú architektúru.

Pred tým, než sme sa rozhodli pre náš aktuálny stack, zhodnotili sme niekoľko prístupov. Plne serverless architektúra bola lákavá, ale zaviedla latencie pri studenom spúšťaní (cold-start), ktoré porušovali naše ciele výkonu, najmä pri server-rendered aplikáciách Next.js, na ktorých naši klienti závisia. Tradičné nastavenie založené na virtuálnych strojoch nám dávalo kontrolu, ale chýbala mu elasticita, ktorú sme potrebovali. Dospeli sme k hybridnému modelu: základňa vyhradeného výpočtu podporovaná poolmi cloudových serverov na požiadanie, ktoré sa dokážu spustiť za menej ako štyri sekundy.

Náš riadiaci plán (control plane) beží na Kubernetes, ktorý orchestruje pracovné záťaže naprieč viacerými zónami dostupnosti v rámci každého regiónu dátového centra. Aplikácia každého klienta je kontajnerizovaná so štandardizovaným runtime obrazom, ktorý obsahuje náš monitorovací agent, forwarder logov a endpoint pre health check. Táto uniformita umožňuje automatické škálovanie, každý kontajner je zameniteľný, takže orchestrátor môže pridávať alebo odoberať inštancie bez obáv o prostredie špecifické chyby.

Pre dátovú vrstvu sme prijali stratégiu tierovaného úložiska. Horúca data (hot data) žijú na NVMe SSD diskoch s replikáciou medzi dvoma uzlami. Teplá data (warm data) sa po siedmich dňoch presúvajú na štandardné SSD disky. Studené data (cold data) sa po tridsiatich dňoch archivujú do object storage. Toto samo o sebe znížilo naše náklady na úložisko o 40 % bez akéhokoľvek vnímateľného dopadu na výkon klientov.

Automatické škálovanie znie v teórii jednoducho: keď dopyt rastie, pridáte kapacitu; keď klesá, odoberiete ju. V praxi však načasovanie a prahové hodnoty mimoriadne záležia. Ak škálujete príliš neskoro, používatelia narazia na chyby. Ak škálujete príliš skoro, míňate peniaze na nevyužívané zdroje. Strávili sme tri mesiace ladením našich politík škálovania, kým sme boli dostatočne sebavedomí na to, aby sme ich spustili v produkcii bez ľudského dohľadu.

Náš systém používa prediktívny model škálovania nadväzujúci na reakčné spúšťače. Prediktívna vrstva analyzuje historické vzorce prevádzky, deň v týždni, čas dňa, sezónne trendy a známe udalosti, ako sú spustenia produktov alebo marketingové kampane, ktoré klienti plánujú cez náš dashboard. Kapacitu pred-provisionuje pätnásť minút pred očakávaným dopytom. Reaktívna vrstva sleduje metriky v reálnom čase: využitie CPU, tlak pamäte, hĺbku fronty požiadaviek a latenciu odozvy P95. Akákoľvek metrika prekročiaci svoj prah spustí vytvorenie nových kontajnerov do niekoľkých sekúnd.

Taktiež sme vyvinuli vlastný mechanizmus cooldown (ochladzovania). Po ustúpení špičky okamžite neodstraňujeme nadbytočnú kapacitu. Namiesto toho ju držíme v konfigurovateľnom okne (predvolene: desať minút), pretože špičky prevádzky často prichádzajú vo vlnách. To zabraňuje nákladnému kolotaju opakovaného spúšťania a zastavovania kontajnerov počas dlhotrvajúcich vysokozáťažových udalostí, ako je Black Friday alebo virálne momenty na sociálnych sieťach.

Vyvažovanie záťaže v GRADAX funguje na dvoch vrstvách. Vonkajšia vrstva je globálna anycast sieť, ktorá smeruje používateľov do najbližšieho dátového centra na základe latencie, nie len geografickej polohy. Používateľ v Mníchove môže byť smerovaný na náš node vo Frankfurte alebo Amsterdame v závislosti od aktuálnych sieťových podmienok. Toto rozhodnutie sa prehodnocuje každých šesťdesiat sekúnd pomocou aktívnych health probe zaslaných z každej edge lokality.

Vnútorná vrstva rozdeľuje prevádzku medzi kontajnery v rámci dátového centra. Čoskoro sme sa vzdali jednoduchého round-robin, pretože nezohľadňuje stav kontajnera ani aktuálnu záťaž. Náš balancer používa algoritmus weighted least-connections, ktorý berie do úvahy aktuálny počet požiadaviek, využitie CPU a nedávnu mieru chýb každého kontajnera. Kontajnery, ktoré majú problémy, dostávajú menej požiadaviek, čo im dáva čas na zotavenie bez toho, aby boli úplne vyradené z rotácie.

Taktiež sme implementovali connection draining pre hladké ukončovanie. Keď auto-scaler rozhodne o odstránení kontajnera, najprv prestane posielať nové pripojenia a následne čaká až tridsať sekúnd na dokončenie existujúcich požiadaviek. Tým sme eliminovali chyby 502, ktoré nás trápili v skorších iteráciách počas škálovania nadol.

Cloudová infraštruktúra môže rýchlo drahnuť, najmä keď prevádzkujete automatické škálovanie naprieč viacerými regiónmi. Od prvého dňa sme pristupovali k manažmentu nákladov disciplinovane, považujúc výdavky na infraštruktúru za produktovú metriku rovnako dôležitú ako uptime alebo latencia. Každé architektonické rozhodnutie prechádza review dopadu na náklady pred tým, než dosiahne produkciu.

Naše najväčšie úspory prinieslo right-sizing (správne dimenzovanie). Vytvorili sme analytický nástroj, ktorý vzorkuje využitie zdrojov kontajnerov v štrnáctidňových oknách a odporúča optimálne alokácie CPU a pamäte. Väčšina klientov bola podľa našich počiatočných odhadov over-provisionovaná o 30-50 %. Po right-sizing sme znížili základné výpočtové náklady o 35 % naprieč flotilou. Taktiež sme vyjednali dohody o reserved capacity s našimi upstream poskytovateľmi pre základnú záťaž, čím sme si zamkli sadzby o 45 % nižšie ako pri on-demand cenách.

Pre klientov, ktorí chcú maximálnu efektívnost nákladov, ponúkame "burstable" tier, ktorý beží na zdieľanej infraštruktúre počas bežných hodín a škáluje sa na vyhradené zdroje len počas špičkových období. Tento tier stojí o 60 % menej ako naša štandardná ponuka a je ideálny pre firmy s predvídateľnými obdobiami nízkej prevádzky, ako sú B2B SaaS produkty, ktoré takmer nevykazujú aktivitu mimo pracovných hodín.

Nemôžete spravovať to, čo nemôžete merať, a v distribuovanom systéme automatického škálovania je viditeľnosť všetkým. Našu observability stack postavili okolo troch pilierov: metriky, logy a trace. Každý kontajner emituje štruktúrované metriky v päťsekundových intervaloch pokrývajúce CPU, pamäť, disk I/O, sieťový throughput, počet požiadaviek, mieru chýb a percentily odozvy latencie. Tieto údaje prúdia do time-series databázy, ktorá uchováva vysokorozlíšené dáta sedem dní a downsampleované dáta trinásť mesiacov.

Distributed tracing bola tá časť, ktorá trvala najdlhšie, kým správne fungovala, ale priniesla najviac hodnoty. Každá prichádzajúca požiadavka dostáva trace ID, ktoré ju sprevádza cez load balancer, aplikačný kontajner, cache vrstvu a databázu. Keď klient hlási pomalé načítanie stránok, môžeme si vytiahnuť presný trace a presne vidieť, kde bol čas strávený. Deväťkrát z desiatych je bottleneckom neoptimalizovaný databázový query alebo chýbajúci cache key, nie infraštruktúra.

Náš alertovací systém používa tierované úrovne závažnosti viazané na business dopad, nie len technické prahy. V kombinácii s našim monitorovaním bezpečnosti webových stránok je jeden horúci kontajner informatívny. Udržaná miera chýb nad 1 % naprieč flotilou klienta je varovaním. Akýkoľvek pokles dostupnosti pod 99,9 % počas päťminútového okna okamžite page-on-call inžinierovi. Tento prístup znížil alert noise o 70 % v porovnaní s naším počiatočným systémom založeným na prahoch.

Po osemnástich mesiacoch prevádzky tejto architektúry v produkčnom prostredí čísla hovoria za všetko. Udržali sme 99,97 % dostupnosti naprieč všetkými pracovnými záťažami klientov, vrátane troch významných udalostí s vysokým provozom, ktoré presiahli päťnásobok základnej záťaže. Platforma spracovala len v poslednom štvrťroku viac ako 2,8 miliardy požiadaviek so svetovým P95 časom odozvy 142 milisekúnd. Žiadny klient nezaznamenal výpadok spôsobený zlyhaním škálovania.

Pokiaľ ide o náklady, naši klienti spoločne ušetria približne 40 % v porovnaní s ekvivalentnými konfiguráciami na veľkých verejných cloudových poskytovateľoch. Systém automatického škálovania minulý rok zabránil odhadovaným 180 000 € zbytočných výdavkov na výpočtový výkon tým, že počas mimopikových hodín znížil kapacitu namiesto neustáleho behu na plný výkon 24/7. Pre nášho klienta z módného trhu, ktorého flash sale inicioval celý tento proces, klesol mesačný účet za infraštruktúru po migrácii na našu platformu o 52 %, hoci obsluhoval trojnásobný provoz oproti predchádzajúcemu obdobiu.

Prevádzkové zlepšenia boli rovnako významné. Priemerný čas detekcie problémov s výkonom sa skrátil z 12 minút na menej ako 90 sekúnd. Priemerný čas riešenia (MTTR) klesol z 45 minút na 8 minút. Náš tím infraštruktúry, ktorý doteraz venoval 60 % času reakčnému haseniu požiarov, teraz trávi 80 % času proaktívnymi zlepšeniami a vývojom nových funkcií.

Nie sme hotoví. Ďalšia fáza našej cesty rozvoja cloudovej infraštruktúry sa zameriava na tri oblasti: okrajové výpočty (edge computing), plánovanie kapacity riadené umelou inteligenciou a plánovanie citlivé na uhlíkovú stopu. V súčasnosti testujeme okrajové výpočtové uzly v dvanástich ďalších mestách, ktoré umožnia spúšťanie latenciu citlivých pracovných záťaží, ako je optimalizácia obrázkov a odpovede API, bližšie ku koncovým používateľom. Počiatočné benchmarky ukazujú 40 % zníženie P99 latencie pre používateľov nachádzajúcich sa viac ako 1 000 kilometrov od najbližšieho dátového centra.

V oblasti AI trénujeme model predpovedania kapacity na dvoch rokoch historických dát naprieč všetkými pracovnými záťažami klientov. Cieľom je predpovedať vzorce provozu 24 hodín vopred s dostatočnou istotou, aby sme mohli dopredu pripraviť kapacitu pred vznikom špičiek a eliminovali aj krátky nárast latencie, ku ktorému dochádza pri reakčnom škálovaní. Počiatočné výsledky sú sľubné, pričom model dosiahol 89 % presnosť pri predpovedaní špičkového provozu na nasledujúci deň.

Nakoniec skúmame plánovanie citlivé na uhlíkovú stopu, ktoré by presunulo neakútne pracovné záťaže, ako sú zálohovanie, dávkové spracovanie a predbežné renderovanie, do období, keď má miestna elektrická sieť najvyšší podiel obnoviteľných zdrojov energie. To ladí s našim širším záväzkom k udržateľnej infraštruktúre a dáva našim environmentálne uvedomelým klientom hmatateľnú metriku, na ktorú sa môžu odvolávať. Ak chcete zistiť, ako vám tieto zlepšenia môžu pomôcť, kontaktujte náš tím. Očakávame, že všetky tri schopnosti nasadíme pred koncom roku 2026.