Škálovatelná cloudová infrastruktura pro rostoucí firmy

Když jsme v GRADAX začali nabízet managed hosting a cloudové služby, většina našich klientů provozovala předvídatelné zátěže. Webové stránky místní restaurace měly stabilní návštěvnost, možná malý nárůst o víkendech. Portfolio web účetního sotva pohnul se serverovými prostředky. Kapacity jsme dimenzovali konzervativně a fungovalo to. Jak jsme ale onboardovali e-shopy, SaaS startupy a mediální domy, vzorce návštěvnosti se staly divoce nepředvídatelnými.

Jeden z našich klientů, rumunské módní tržiště, spustil flash sale, který během devadesáti sekund přivedl čtrnáctinásobek běžné návštěvnosti. Jejich předchozí hosting to nezvládl. Druhý den přišli s žádostí o garanci, že se to už nikdy nestane. Právě tento jediný rozhovor nás donutil přehodnotit celou naši filozofii infrastruktury. Už jsme nemohli navrhovat řešení pro průměr, museli jsme navrhovat pro extrémy.

Základní výzva měla tři roviny: zvládnout náhlé špičky v návštěvnosti bez ručního zásahu, udržet přiměřené náklady v obdobích klidu a zachovat dobu odezvy pod 200 ms pro evropské i globální publikum. Vyřešit kteroukoli z nich samostatně je snadné. Vyřešit všechny tři současně vyžadovalo zásadně odlišnou architekturu.

Před rozhodnutím o současném stacku jsme zvažovali několik přístupů. Plně serverless architektura byla lákavá, ale přinesla latence při cold startu, které porušovaly naše výkonnostní cíle, zejména u serverově renderovaných aplikací Next.js, na které se naši klienti spoléhají. Tradiční řešení postavené na VM nám dávalo kontrolu, ale chyběla mu elasticita, kterou jsme potřebovali. Zvolili jsme hybridní model: základ z dedikovaného výkonu podpořený fondy cloudových serverů na vyžádání, které se spustí za méně než čtyři sekundy.

Náš control plane běží na Kubernetes a orchestruje zátěže napříč několika zónami dostupnosti v rámci každé regionální lokality datového centra. Aplikace každého klienta je kontejnerizovaná se standardizovaným runtime image, který obsahuje našeho monitorovacího agenta, log forwarder a endpoint pro health check. Právě tato jednotnost umožňuje automatické škálování, každý kontejner je zaměnitelný, takže orchestrátor může přidávat nebo odebírat instance, aniž by řešil zvláštnosti konkrétního prostředí.

Pro datovou vrstvu jsme zvolili vrstvenou strategii úložiště. Horká data leží na NVMe SSD s replikací mezi dvěma nody. Teplá data se po sedmi dnech přesouvají na standardní SSD. Studená data se po třiceti dnech archivují do objektového úložiště. Jen toto snížilo naše náklady na úložiště o 40 % bez jakéhokoli znatelného dopadu na výkon u klientů.

Automatické škálování zní teoreticky jednoduše: když poptávka roste, přidáme kapacitu; když klesá, odebereme ji. V praxi však načasování a prahové hodnoty nesmírně záleží. Při pozdním škálování narazí uživatelé na chyby. Při příliš časném škálování zbytečně utrácíte za nevyužité prostředky. Strávili jsme tři měsíce laděním našich pravidel škálování, než jsme si byli jisti, že je můžeme provozovat v produkci bez lidského dohledu.

Náš systém používá prediktivní model škálování navrstvený na reaktivní spouštěče. Prediktivní vrstva analyzuje historické vzorce návštěvnosti, den v týdnu, denní dobu, sezónní trendy a známé události, jako jsou uvedení produktů nebo marketingové kampaně, které si klienti plánují přes náš dashboard. Kapacitu předpřipravuje patnáct minut před očekávanou poptávkou. Reaktivní vrstva sleduje metriky v reálném čase: vytížení CPU, tlak na paměť, hloubku fronty požadavků a P95 latence odezvy. Pokud kterákoli metrika překročí svůj práh, nové kontejnery se spustí během několika sekund.

Postavili jsme také vlastní mechanismus cooldownu. Poté, co špička opadne, okamžitě nerušíme kapacitu navíc. Místo toho ji držíme po konfigurovatelné okno (výchozí: deset minut), protože špičky v návštěvnosti často přicházejí ve vlnách. To zabraňuje nákladnému kolísání, kdy se kontejnery během přetrvávajících období vysoké zátěže, jako je Black Friday nebo virální momenty na sociálních sítích, opakovaně spouštějí a vypínají.

Vyvažování zátěže v GRADAX probíhá ve dvou vrstvách. Vnější vrstva tvoří globální anycastová síť, která směruje uživatele do nejbližšího datového centra na základě latence, nikoliv pouze geografické polohy. Uživatel z Mnichova může být směrován k našemu uzlu ve Frankfurtu nebo Amsterdamu v závislosti na aktuálních podmínkách sítě. Toto rozhodnutí je přehodnocováno každých šedesát sekund pomocí aktivních health probe zasílaných z každého okrajového místa.

Vnitřní vrstva distribuuje provoz mezi kontejnery uvnitř datového centra. Od jednoduchého round-robin jsme ustoupili již brzy, protože nezohledňuje stav kontejnerů ani aktuální zátěž. Náš balancer používá algoritmus váženého nejmenšího počtu spojení, který zohledňuje aktuální počet požadavků, vytížení CPU a nedávnou míru chyb jednotlivých kontejnerů. Kontejnery, které mají potíže, dostávají méně požadavků, což jim dává čas se zotavit, aniž by byly zcela vyřazeny z rotace.

Implementovali jsme také connection draining pro plynulé vypínání. Když auto-scaler rozhodne o odebrání kontejneru, nejprve do něj přestane posílat nová spojení a poté čeká až třicet sekund na dokončení stávajících požadavků. Tím jsme eliminovali chyby 502, které provázely naše dřívější iterace při snižování kapacity.

Cloudová infrastruktura může rychle zdražit, zejména když provozujete automatické škálování napříč několika regiony. Od prvního dne jsme ke správě nákladů přistupovali disciplinovaně a výdaje na infrastrukturu považujeme za produktovou metriku stejně důležitou jako dostupnost nebo latence. Každé architektonické rozhodnutí prochází před nasazením do produkce revizí dopadu na náklady.

Největší úspory přineslo správné dimenzování. Vytvořili jsme analytický nástroj, který vzorkuje využití prostředků kontejnerů ve čtrnáctidenních oknech a doporučuje optimální alokaci CPU a paměti. Většina klientů byla podle našich prvotních odhadů předimenzována o 30–50 %. Po správném dimenzování jsme snížili základní náklady na výpočetní výkon o 35 % napříč celou flotilou. S našimi nadřazenými poskytovateli jsme také vyjednali dohody o rezervované kapacitě pro základní zátěž, čímž jsme si zajistili sazby o 45 % nižší než ceny na vyžádání.

Klientům, kteří chtějí maximální nákladovou efektivitu, nabízíme tarif „burstable“, který běží na sdílené infrastruktuře v běžných hodinách a na dedikované prostředky se škáluje jen ve špičkách. Tento tarif stojí o 60 % méně než naše standardní nabídka a je ideální pro firmy s předvídatelnými obdobími nízké zátěže, jako jsou B2B SaaS produkty, které mimo pracovní dobu téměř nevykazují žádné využití.

Nemůžete řídit to, co nemůžete měřit, a v distribuovaném systému s automatickým škálováním je viditelnost klíčová. Naši observability stack jsme postavili na třech pilířích: metrikách, logách a tracech. Každý kontejner vysílá strukturované metriky v pětisekundových intervalech pokrývající CPU, paměť, disk I/O, síťovou propustnost, počet požadavků, míru chyb a percentily latence odezvy. Ty proudí do time-series databáze, která uchovává data s vysokým rozlišením po sedm dní a downsamplovaná data po třináct měsíců.

Distribuované trasování bylo tou částí, jejíž zprovoznění trvalo nejdéle, ale přineslo největší hodnotu. Každý příchozí požadavek získá trace ID, které ho provází přes load balancer, aplikační kontejner, cache vrstvu a databázi. Když klient nahlásí pomalé načítání stránek, můžeme si vyžádat přesný trace a vidět, kde přesně se čas spotřeboval. V devíti z deseti případů je úzkým hrdlem neoptimalizovaný databázový dotaz nebo chybějící cache klíč, nikoliv infrastruktura.

Náš systém upozornění používá vrstvené úrovně závažnosti vázané na dopad na byznys, nejen na technické prahy. V kombinaci s naším monitoringem zabezpečení webu je jeden kontejner běžící na vysoké zátěži pouze informativní. Přetrvávající míra chybovosti nad 1 % napříč flotilou klienta je varování. Jakýkoli pokles dostupnosti pod 99,9 % v pětiminutovém okně okamžitě vyvolá stránkování pohotovostního inženýra. Tento přístup snížil šum upozornění o 70 % ve srovnání s naším původním systémem založeným na prahových hodnotách.

Po osmnácti měsících provozu této architektury v produkci mluví čísla za sebe. Udrželi jsme 99,97% dostupnost u všech klientských zátěží, a to i během tří velkých provozních špiček, z nichž každá přesáhla základní zátěž více než 50krát. Platforma zvládla jen v posledním čtvrtletí přes 2,8 miliardy požadavků s globální dobou odezvy P95 142 milisekund. Ani jeden klient nezaznamenal výpadek kvůli selhání škálování.

Co se týče nákladů, naši klienti ušetří odhadem 40 % ve srovnání s ekvivalentními konfiguracemi u velkých veřejných poskytovatelů cloudu. Systém automatického škálování zabránil loni vzniku zbytečných nákladů na výpočetní výkon ve výši odhadovaně 180 000 € tím, že mimo špičku snižoval výkon, místo aby běžel naplno 24/7. U našeho klienta z oblasti módního tržiště, jehož flash sale celou tuhle cestu odstartoval, klesl měsíční účet za infrastrukturu po migraci na naši platformu o 52 %, přestože zvládá 3krát větší provoz než dříve.

Provozní zlepšení byla stejně významná. Střední doba detekce výkonnostních problémů klesla z 12 minut na méně než 90 sekund. Střední doba vyřešení klesla v průměru ze 45 minut na 8 minut. Náš infrastrukturní tým, který dříve trávil 60 % času hašením požárů, nyní tráví 80 % času proaktivními vylepšeními a vývojem nových funkcí.

Ještě nejsme u konce. Další fáze našeho plánu rozvoje cloudové infrastruktury se zaměřuje na tři oblasti: edge computing, plánování kapacity řízené umělou inteligencí a plánování zohledňující uhlíkovou stopu. Momentálně testujeme edge výpočetní uzly ve dvanácti dalších městech, které by umožnily spouštět na latenci citlivé zátěže, jako je optimalizace obrázků a odpovědi API, blíže koncovým uživatelům. První měření ukazují snížení latence P99 o 40 % u uživatelů vzdálených více než 1 000 kilometrů od našeho nejbližšího datového centra.

V oblasti umělé inteligence trénujeme model pro předpověď kapacity na dvou letech historických dat ze všech klientských zátěží. Cílem je předpovídat provozní vzorce 24 hodin dopředu s dostatečnou spolehlivostí, abychom kapacitu předpřipravili ještě před vznikem špiček a odstranili i to krátké zvýšení latence, k němuž dochází při reaktivním navyšování výkonu. První výsledky jsou slibné, model dosahuje 89% přesnosti při předpovědi špičkového provozu na následující den.

A konečně zkoumáme plánování zohledňující uhlíkovou stopu, které by přesunulo neurgentní zátěže, jako jsou zálohy, dávkové zpracování a předrenderování, do časů, kdy má místní elektrická síť nejvyšší podíl obnovitelné energie. To je v souladu s naším širším závazkem k udržitelné infrastruktuře a dává našim ekologicky uvědomělým klientům hmatatelný ukazatel, na který se mohou odvolat. Pokud se chcete dozvědět, jak mohou tato vylepšení prospět vašemu podnikání, ozvěte se našemu týmu. Všechny tři možnosti plánujeme nasadit do konce roku 2026.