Skálázható felhőinfrastruktúra építése növekvő vállalkozások számára

Amikor elkezdtünk menedzselt tárhelyet és felhőszolgáltatásokat kínálni a GRADAX-nál, ügyfeleink többsége kiszámítható terheléssel dolgozott. Egy helyi étterem weboldala egyenletes forgalmat kapott, esetleg hétvégén egy kisebb csúcsot. Egy könyvelő portfólióoldala alig mozdította meg a szervererőforrásokat. Óvatosan méreteztük az erőforrásokat, és ez működött. De ahogy e-kereskedelmi márkákat, SaaS startupokat és médiacégeket vontunk be, a forgalmi minták teljesen kiszámíthatatlanná váltak.

Az egyik ügyfelünk, egy román divatpiac, olyan villámakciót indított, amely kilencven másodperc alatt a normál forgalom 14-szeresét hozta. A korábbi szolgáltatójuk összeomlott. Másnap hozzánk jöttek, és garanciát kértek arra, hogy ez soha többé nem fordulhat elő. Ez az egyetlen beszélgetés arra késztetett minket, hogy teljesen újragondoljuk az infrastruktúra-filozófiánkat. Már nem az átlagra tervezhettünk, a szélsőségekre kellett terveznünk.

A fő kihívás háromrétű volt: kezelni a hirtelen forgalmi csúcsokat manuális beavatkozás nélkül, ésszerű szinten tartani a költségeket a csendes időszakokban, és 200 ms alatti válaszidőt fenntartani az európai és globális közönség számára. Ezek bármelyikének önálló megoldása egyszerű. Mindhárom egyidejű megoldása alapvetően más architektúrát igényelt.

Több megközelítést értékeltünk, mielőtt a jelenlegi technológiai stack mellett döntöttünk. A teljesen szerver nélküli architektúra csábító volt, de hidegindítási késleltetéseket vezetett be, amelyek megsértették a teljesítménycéljainkat, különösen azoknál a szerveroldalon renderelt Next.js alkalmazásoknál, amelyekre ügyfeleink támaszkodnak. A hagyományos VM-alapú felállás kontrollt adott, de hiányzott belőle a szükséges rugalmasság. Végül egy hibrid modell mellett döntöttünk: dedikált számítási kapacitás alapvonal, amelyet igény szerinti felhőszerver poolok támogatnak, amelyek négy másodperc alatt elindíthatók.

Vezérlősíkunk Kubernetesen fut, és a munkaterheléseket az egyes adatközponti régiókon belüli több rendelkezésre állási zóna között hangolja össze. Minden ügyfél alkalmazása szabványosított futtatókörnyezeti image-be van csomagolva, amely tartalmazza monitorozó ügynökünket, a naplótovábbítót és az állapotellenőrzési végpontot. Ez az egységesség teszi lehetővé az automatikus skálázást: minden konténer felcserélhető, így az orchestrator környezetspecifikus sajátosságok nélkül adhat hozzá vagy távolíthat el példányokat.

Az adatréteghez többszintű tárolási stratégiát vezettünk be. A forró adatok NVMe SSD-ken élnek, két csomópont közötti replikációval. A meleg adatok hét nap után standard SSD-kre kerülnek. A hideg adatok harminc nap után objektumtárolóba archiválódnak. Ez önmagában 40%-kal csökkentette tárolási költségeinket, anélkül hogy az ügyfelek teljesítményében bármi észlelhető változás történt volna.

Az automatikus skálázás elméletben egyszerűnek hangzik: ha nő a kereslet, adjunk hozzá kapacitást; ha csökken, vegyük el. A gyakorlatban az időzítés és a küszöbértékek óriási szerepet játszanak. Ha túl későn skálázunk, a felhasználók hibákba futnak. Ha túl korán, pénzt égetünk el kihasználatlan erőforrásokra. Három hónapot töltöttünk a skálázási szabályzataink hangolásával, mire elég magabiztosak lettünk ahhoz, hogy emberi felügyelet nélkül futtassuk őket éles környezetben.

Rendszerünk prediktív skálázási modellt használ a reaktív triggerekre építve. A prediktív réteg elemzi a történelmi forgalmi mintákat, a hét napját, a napszakot, a szezonális trendeket és az ismert eseményeket, például a termékbevezetéseket vagy marketingkampányokat, amelyeket az ügyfelek az irányítópultunkon keresztül ütemeznek. A várható igény előtt tizenöt perccel előre biztosítja a kapacitást. A reaktív réteg valós idejű metrikákat figyel: CPU-kihasználtság, memórianyomás, kérésisor hossza és P95 válaszidő. Ha bármelyik metrika átlépi a küszöbértékét, másodperceken belül új konténerek indulnak el.

Egyedi lehűlési mechanizmust is építettünk. Miután egy csúcs lecseng, nem bontjuk le azonnal a többletkapacitást. Ehelyett egy konfigurálható időablakig (alapértelmezés: tíz perc) megtartjuk, mert a forgalmi csúcsok gyakran hullámokban érkeznek. Ez megakadályozza a konténerek ismételt fel- és leállításának költséges ingadozását olyan tartósan nagy forgalmú események során, mint a Black Friday vagy a vírusként terjedő közösségi média pillanatok.

A terheléselosztás a GRADAX-nál két szinten működik. A külső szint egy globális anycast hálózat, amely a felhasználókat a késleltetés alapján irányítja a legközelebbi adatközpontba, nem csupán a földrajzi elhelyezkedés szerint. Egy müncheni felhasználó a valós idejű hálózati viszonyoktól függően a frankfurti vagy az amszterdami csomópontunkba kerülhet. Ezt a döntést hatvan másodpercenként újraértékeljük az egyes edge-helyekről küldött aktív állapotpróbák segítségével.

A belső szint az adatközponton belüli konténerek között osztja el a forgalmat. Korán elhagytuk az egyszerű round-robin megoldást, mert az nem veszi figyelembe a konténerek állapotát vagy aktuális terhelését. Terheléselosztónk súlyozott legkevesebb kapcsolat algoritmust használ, amely figyelembe veszi az egyes konténerek aktuális kérésszámát, CPU-kihasználtságát és friss hibaarányát. A küszködő konténerek kevesebb kérést kapnak, így időt nyernek a helyreállásra anélkül, hogy teljesen kikerülnének a rotációból.

A zökkenőmentes leállítás érdekében kapcsolatleürítést is bevezettünk. Amikor az automatikus skálázó úgy dönt, hogy eltávolít egy konténert, először leállítja az új kapcsolatok küldését felé, majd legfeljebb harminc másodpercet vár a meglévő kérések befejezésére. Ez megszüntette azokat az 502-es hibákat, amelyek a korábbi iterációinkat sújtották a leépítési események során.

A felhőinfrastruktúra gyorsan drágává válhat, különösen akkor, ha több régióban futtat automatikus skálázást. Az első naptól fegyelmezett módon kezeltük a költségeket, és az infrastruktúra-költést ugyanolyan fontos termékmutatóként kezeltük, mint az üzemidőt vagy a késleltést. Minden architektúrai döntés költséghatás-vizsgálaton esik át, mielőtt éles környezetbe kerül.

A legnagyobb megtakarítást a megfelelő méretezés hozta. Építettünk egy elemzőeszközt, amely tizennégy napos időablakokban mintavételezi a konténerek erőforrás-használatát, és optimális CPU- és memória-allokációt javasol. Az eredeti becsléseink alapján az ügyfelek többsége 30-50%-kal túlméretezett volt. A megfelelő méretezés után az alap számítási költségeket 35%-kal csökkentettük a teljes flottán. Ezenkívül fenntartott kapacitási megállapodásokat tárgyaltunk az upstream szolgáltatóinkkal az alap terhelésre, ami 45%-kal az igény szerinti árazás alatti díjakat rögzített.

Azoknak az ügyfeleknek, akik maximális költséghatékonyságot szeretnének, kínálunk egy „burstable” szintet, amely normál munkaidőben megosztott infrastruktúrán fut, és csak csúcsidőszakokban skálázódik dedikált erőforrásokra. Ez a szint 60%-kal kevesebbe kerül, mint a standard ajánlatunk, és ideális azoknak a vállalkozásoknak, amelyeknél kiszámíthatóan alacsony forgalmú időszakok vannak, például a B2B SaaS termékeknek, amelyeket gyakorlatilag nem használnak munkaidőn kívül.

Nem tudod kezelni azt, amit nem tudsz mérni, és egy elosztott automatikus skálázási rendszerben a láthatóság minden. Megfigyelhetőségi stackünket három pillér köré építettük: metrikák, naplók és nyomkövetések. Minden konténer öt másodperces időközönként strukturált metrikákat bocsát ki, amelyek lefedik a CPU-t, a memóriát, a lemez I/O-t, a hálózati átvitelt, a kérésszámot, a hibaarányt és a válaszidő percentiliseit. Ezek egy idősoros adatbázisba folynak, amely hét napig nagy felbontású adatokat, tizenhárom hónapig pedig leskálázott adatokat tárol.

Az elosztott nyomkövetés volt az a rész, amelynek helyes megvalósítása tartott a legtovább, de a legtöbb értéket hozta. Minden bejövő kérés kap egy trace ID-t, amely végigköveti a terheléselosztón, az alkalmazáskonténeren, a gyorsítótár-rétegen és az adatbázison. Amikor egy ügyfél lassú oldalbetöltést jelent, elő tudjuk hívni a pontos nyomkövetést, és pontosan látjuk, hol telt az idő. Tízből kilenc esetben a szűk keresztmetszet egy nem optimalizált adatbázis-lekérdezés vagy egy hiányzó gyorsítótár-kulcs, nem az infrastruktúra.

Riasztási rendszerünk üzleti hatáshoz kötött, többszintű súlyossági szinteket használ, nem csupán technikai küszöbértékeket. A weboldal-biztonsági monitorozásunkkal kombinálva egyetlen túlterhelt konténer csak tájékoztató jellegű. Az ügyfél flottáján 1% feletti tartós hibaarány figyelmeztetés. Bármely 99,9% alá eső rendelkezésre állás egy ötperces időablakban azonnal riasztja az ügyeletes mérnököt. Ez a megközelítés 70%-kal csökkentette a riasztási zajt a kezdeti küszöbérték-alapú rendszerünkhöz képest.

Miután tizennyolc hónapig futtattuk ezt az architektúrát éles környezetben, a számok magukért beszélnek. 99,97%-os rendelkezésre állást tartottunk fenn az összes ügyfélterhelés esetében, beleértve három nagy forgalmi eseményt is, amelyek mindegyike meghaladta az alapterhelés 50-szeresét. A platform csak az elmúlt negyedévben több mint 2,8 milliárd kérést kezelt le, globális P95 válaszidővel 142 milliszekundum. Egyetlen ügyfél sem tapasztalt leállást skálázási hibák miatt.

A költségek oldalán ügyfeleink összesen becsléseink szerint 40%-ot takarítanak meg a nagy nyilvános felhőszolgáltatók egyenértékű konfigurációihoz képest. Az automatikus skálázó rendszer tavaly becsléseink szerint 180 000 eurónyi felesleges számítási költést előzött meg azzal, hogy a csendesebb órákban lekapcsolt, ahelyett hogy a nap 24 órájában teljes gőzzel futott volna. Divatpiaci ügyfelünknél, akinek a villámakciója elindította ezt az egész folyamatot, a havi infrastruktúraszámla 52%-kal csökkent a platformunkra való átállás után, annak ellenére, hogy háromszor több forgalmat kezel, mint korábban.

Az üzemeltetési fejlesztések ugyanilyen jelentősek voltak. A teljesítményproblémák észlelésének átlagos ideje 12 percről 90 másodperc alá csökkent. A megoldás átlagos ideje 45 percről átlagosan 8 percre esett vissza. Infrastruktúracsapatunk, amely korábban idejének 60%-át tűzoltó jellegű hibaelhárításra fordította, most idejének 80%-át proaktív fejlesztésekre és új funkciók kidolgozására szánja.

Még nem végeztünk. Felhőinfrastruktúra-ütemtervünk következő szakasza három területre összpontosít: edge computing, AI-vezérelt kapacitástervezés és szén-dioxid-tudatos ütemezés. Jelenleg tizenkét további városban tesztelünk edge számítási csomópontokat, amelyek lehetővé tennék, hogy a késleltetésre érzékeny terhelések, például a képek optimalizálása és az API-válaszok közelebb fussanak a végfelhasználókhoz. A korai mérések 40%-os P99 késleltetéscsökkenést mutatnak azon felhasználók esetében, akik több mint 1000 kilométerre vannak a legközelebbi adatközpontunktól.

Az AI területén egy kapacitás-előrejelző modellt tanítunk két év történelmi adatán, az összes ügyfélterhelésre kiterjedően. A cél az, hogy 24 órával előre jelezzük a forgalmi mintázatokat, elegendő biztonsággal ahhoz, hogy a csúcsok előtt előre biztosítsuk a kapacitást, ezáltal még azt a rövid késleltetésnövekedést is kiküszöbölve, amely a reaktív felskálázási események során jelentkezik. A kezdeti eredmények ígéretesek: a modell 89%-os pontosságot ér el a másnapi csúcsforgalom előrejelzésében.

Végül egy szén-dioxid-tudatos ütemezést vizsgálunk, amely a nem sürgős terheléseket, például a mentéseket, a kötegelt feldolgozást és az előzetes renderelést olyan időpontokra tolná, amikor a helyi villamosenergia-hálózatban a legnagyobb a megújuló energia aránya. Ez összhangban van a fenntartható infrastruktúra iránti szélesebb elkötelezettségünkkel, és kézzelfogható mérőszámot ad a környezettudatos ügyfeleinknek, amelyre hivatkozhatnak. Ha szeretné megtudni, hogyan lehetnek ezek a fejlesztések az Ön vállalkozása hasznára, vegye fel a kapcsolatot csapatunkkal. Várhatóan mindhárom képességet 2026 vége előtt bevezetjük.