Az online tárhely gyors skálázása több mint 1 milliárd ChatGPT‑felhasználó kiszolgálására

Minden OpenAI-termék gyors és megbízható adathozzáférésre támaszkodik, akár bejelentkezik valaki, ellenőrzi a Codex beállításait, vagy új beszélgetést indít a ChatGPT‑ben. A termék válasza előtt mindegyik művelet számos különálló adatlekérést igényelhet. Ha ezek a kérések lassúak, a termék is lassúnak érződik. Ha ezek a kérések meghiúsulnak, a termék teljesen leáll.

A Habitat az az online tárolási platform, amelyet azért építettünk, hogy az OpenAI termékei gyorsan és megbízhatóan hozzáférjenek a szükséges információkhoz. A Habitat ma már másodpercenként több mint 70 millió kérést kezel, és közel 40 földrajzi régióban támogatja a hetente több mint 1 milliárd ember által használt termékeket. A Habitatot először a GPT‑k támogatására vezettük be a 2023-as DevDay eseményen, egyszerű, egyetlen adatbázishoz kapcsolódó ügyféloldali Python-könyvtárként. Mára összetett, elosztott rendszerré vált, amely több mint 500 petabájtnyi adatot szolgál ki.

Ilyen léptékű infrastruktúrát építeni és üzemeltetni nem egyszerű feladat, de önmagában nem is különösebben nehéz. Helyzetünket az tette egyedivé, hogy példátlan ütemben kellett skáláznunk a rendkívüli felhasználói növekedés és termékigény kiszolgálásához, miközben egy kiforrott platformot is kiépítettünk. A rendszermérnökök gyakran tízszeres léptékre terveznek, remélve, hogy az néhány évig kitart, miközben felkészülnek a következő tízszeres növekedésre. Mi az elmúlt három év mindegyikében több mint tízszeresére nőttünk. A Habitat építése és üzemeltetése ezért taktikai döntések és gondos ütemezés sorozata volt: minden összetevőt a legalsó szintig megértettünk, hogy a lehető legtöbbet hozzuk ki meglévő rendszerünkből, miközben elhárítottuk a tárolási és számítási kapacitás szűkösségét, időt nyerve az alapvető beruházásokhoz.

Az OpenAI növekedésével a Habitatnak is fejlődnie kellett: először az üzletileg kritikus termékforgalomhoz szükséges megbízhatóságot, majd a globális felhasználókhoz szükséges sebességet kellett elérnie, végül pedig képessé kellett válnia az óriási lépték gördülékeny kezelésére. Ez a bejegyzés az online tárhely skálázásáról szóló kétrészes sorozat első része. Bemutatjuk, hogyan fejlődött a Habitat, miért alakítottuk könyvtárból szolgáltatássá, és hogyan fejlesztettünk egy kiszolgálórendszerekben szokatlan nyelven – Pythonban – írt szolgáltatásból megbízható tárolásiplatform-réteget.

Egy későbbi bejegyzésben részletesen bemutatjuk, hogyan tettük nagy léptékben megbízhatóvá a több-bérlős működést, milyen többrétegű stratégiával optimalizáltuk az olvasási teljesítményt, és hogyan skáláztuk az Azure Cosmos DB-vel való együttműködésünket a példátlan igény megbízható kezelésére.

A Habitat egy egyszerű ötletből indult ki: a termékmérnököknek ne kelljen adatbázis-kezeléssel foglalkozniuk. A Habitatot először a GPT‑k támogatására vezettük be a 2023-as DevDay eseményen, a ChatGPT fő kiszolgálójával kommunikáló kis Python-könyvtárként. Néhány műveletet támogatott, amelyek a háttérben az adatbázis-alkalmazás, az Azure Cosmos DB műveleteire képeződtek le.

A könyvtár feladata az volt, hogy a termékcsapatok az alapul szolgáló részletek elsajátítása nélkül, egyszerűen tárolhassák és kérhessék le az adatokat. A Habitat elvégezte a szükséges munkát: meghatározta az érintett adatok típusát, azt, hogy honnan érkezzenek vagy hová kerüljenek, engedélyezett-e a kérés, és így tovább.

A termékmérnököknek nem kellett a sémakereséssel, az útválasztással, az engedélyezéssel, a titkosítással, a szerializálással, a kérések formálásával vagy a kapcsolatcsoportokkal foglalkozniuk. Még azt sem kellett mérlegelniük, honnan érkeznek az adatok: az Azure Cosmos DB-ből, gyorsítótárakból vagy más típusú tárhelyről.

Ez a Python-könyvtár jól működött, és a Habitat gyorsan elterjedt az OpenAI termékmérnökei körében, noha központilag nem ösztönöztük őket arra, hogy elhagyják az önkiszolgáló Postgrest és Azure Cosmos DB-t.

A termékigények fejlődésével a termékfejlesztők könnyen bővíthették a közös könyvtárat olyan funkciók támogatásával, mint az ügyféloldali gyorsítótárazás, a tömörítés vagy a titkosítás.

2025 közepére a Habitat ügyféloldali megvalósítása elérte a korlátait. Ahogy a Habitat rétege összetettebbé vált, az OpenAI szolgáltatásainak száma pedig nőtt, a visszafelé kompatibilis protokollmódosítások kivitelezhetetlenné váltak.

Egy alkalommal a legkritikusabb adathalmazainkat régiónként elosztott Azure Cosmos DB-fiókokba akartuk áttelepíteni, hogy csökkentsük egyetlen régió leállásának hatókörét. Ehhez további, funkciójelző mögött letiltott útválasztási logikát kellett bevezetnünk az ügyfélbe, gondoskodnunk kellett arról, hogy minden ügyfélnél megjelenjen, majd engedélyeznünk kellett a funkciójelzőt.

A telepítések összehangolása több tucat szolgáltatás és csapat között napokig tartott. Az engedélyezés előtt rájöttünk, hogy árnyékolást is szeretnénk bevezetni a particionálási logika helyességének ellenőrzésére. Ennek bevezetése újabb néhány napot vett igénybe. És az időközben felismert hiba javítása? Újabb néhány nap. Végül készen álltunk a jelző engedélyezésére, de az egyik csapat egy ettől független okból visszaállította szolgáltatását egy korábbi, hibás ügyfélverzióra, és ezzel éppen azt az üzemzavart okozta, amelynek elkerüléséért annyit dolgoztunk.

Az ügyfélkönyvtár módosításai több tucat szolgáltatás összetett összehangolását igényelték; ez a folyamat egyre törékenyebbé, kevésbé hatékonnyá és üzemeltetési hibákra hajlamosabbá vált. A jövőbeli telepítések üzemeltetési szétágazásának csökkentéséhez úgy döntöttünk, hogy a Habitatot önálló szolgáltatássá alakítjuk.

A tárolási logika önálló szolgáltatásba szervezésével egyetlen központi vezérlési pontot hoztunk létre a telepítésekhez, a megfigyelhetőséghez és a platform fejlesztéséhez. A széttagolt frissítések kezelése helyett központilag vezethettük be a fejlesztéseket, így minden OpenAI-termék azonnal részesülhetett az előnyökből.

A központosított szolgáltatás egyetlen ellenőrzési pontot is biztosít a legerősebb adatbiztonsági és adatvédelmi alapfunkciókhoz. A Habitat szolgáltatásban központilag érvényesíthetjük a hozzáférés-vezérlési szabályokat, auditnaplózást végezhetünk, és korlátozhatjuk a mögöttes tárolási erőforrások, például az Azure Cosmos DB elérését. A Habitat kulcsszerepet játszik a felhasználói adatok védelmében, valamint a külső, belső és ügynök jellegű szereplők jogosulatlan hozzáférésének megakadályozásában.

Tudtuk, hogy szolgáltatásra van szükségünk, de egyelőre nem akartunk elhagyni a Pythont, még a szolgáltatásként jelentkező többletterhelése ellenére sem. A Python használata egy nagy adatátviteli egységű szolgáltatáshoz a könyvtár helyi futtatásához képest növelte a hálózati késleltetést, valamint jelentős CPU- és memóriaskálázási költségekkel járt. Azt is felismertük, hogy százszoros léptékben a Python hatékonysága már elfogadhatatlan lenne, így szinte biztosan át kell majd írnunk a rendszert.

Ezt azonban a technikai adósság tudatos, stratégiai vállalásának tekintettük. Elsődleges célunk ekkor nem a költségek vagy az erőforrások optimalizálása volt, hanem a termékfejlesztők előtt álló akadályok elhárítása és a platform stabilizálása. A Python-szolgáltatás teljesítménybeli kompromisszumainak rövid távú elfogadásával előtérbe helyezhettük a sürgetőbb kihívásokat, kialakíthattuk alapvető API-jainkat, és robusztus infrastruktúrát építhettünk ki.

Arra is tudatosan fogadtunk, hogy saját kódolási modelljeink gyors fejlődése a jövőben leegyszerűsíti majd a technikai átállást. Arra számítottunk, hogy mire szükségessé válik a Python teljes elhagyása, a Codex és a GPT megvalósíthatóvá teszi az átállást. Ez a fogadás végül bejött.

A Habitat Python-szolgáltatásként való futtatása teljesítmény szempontjából nem volt optimális, de szükséges döntésnek bizonyult. A Python lehetővé teszi a gyors haladást, de ettől még nem lehettünk óvatlanok, és nem fogadhattunk el érdemben rosszabb késleltetést. Ha egy átlagos felhasználói kérés több száz adatbázishívást eredményez, a felhasználó a leglassabb hívás késleltetését érzékeli. Tapasztalataink szerint egy ilyen léptékű Python-szolgáltatás működtetésének fő kihívása az eloszlás szélén jelentkező késleltetések kezelése.

Az asyncio segít a Pythonnak az I/O-korlátos munkaterhelések párhuzamos kezelésében, de nem kerüli meg a Python GIL-jét, és nem biztosít CPU-párhuzamosságot. Az I/O-igényes kérésproxyzás mellett a Habitat számos CPU-igényes feladatot és háttérfolyamatot kezel: útválasztást, tömörítést, titkosítást, ellenőrzőösszeg-számítást, az alsóbb rétegek állapot-ellenőrzését, kérésárnyékolást és fedezeti kéréseket.

A sok CPU-igényes munkaterhelés és háttérfeladat miatt az asyncio ütemezési késleltetése könnyen uralhatja a kérések szélső késleltetését. Az első szolgáltatásindítás előtti hangolás során a p99-es vagy annál nagyobb késleltetésű kérések nyomkövetéseiben azt láttuk, hogy bár az alsóbb tárolóréteg gyorsan válaszolt, a kérések gyakran elakadtak, amíg a válasz feldolgozásáért felelős korutin ismét sorra nem került.

Az OpenAI Python-szolgáltatásainál a memória-, CPU-, hálózat- és lemezhasználat szokásos kihasználtsági és telítettségi mutatói mellett elengedhetetlen az asyncio eseményhurok terheltségének figyelése és az ennek megfelelő hangolás.

A háttérfeladatok rendszeres ütemezésével, valamint a várt és a tényleges végrehajtási idő különbségének rögzítésével valós időben, empirikusan mérhetjük az eseményhurok ütemezési késleltetését. Nagy kihasználtság és sok költséges feladat mellett már folyamatonként viszonylag kevés egyidejű kérés is jelentős, akár több száz ezredmásodperces, szélsőséges esetben pedig több másodperces ütemezési ingadozást okozhat.

Ezért minden folyamatban csak kevés egyidejű kérést szolgálunk ki, helyette pedig jelentősen megnöveljük a Python-munkafolyamatok számát.

A szolgáltatás első bevezetésekor élő CPU-profilozással megtaláltuk a nagy asyncio-késleltetés – és az ebből fakadó magas szélső késleltetés – egyik kiváltó okát: a funkciójelző-konfigurációink rendszeres JSON-feldolgozását a Statsigen keresztül. A Statsig funkciójelzőket kezel, továbbá A/B tesztek és más feladatok futtatására használható.

Alapértelmezés szerint a Statsig percenként, időbeli szórás nélkül kérte le a frissített konfigurációt, amely minden szolgáltatás összes éles környezeti szabályát tartalmazta. Ettől függetlenül olyan architekturális döntés született, hogy podonként legfeljebb 8 Python-folyamat fusson a nagyobb CPU-kihasználtság és az alacsonyabb késleltetés érdekében. E kettő együtt azt jelentette, hogy percenként minden podnál eljött egy pillanat, amikor az összes munkafolyamat leállt a folyamatban lévő kérések feldolgozásával, és CPU-idejét egy óriási konfigurációs fájl elemzésére fordította.

Miután a CPU-profilozás segítségével azonosítottuk a kiváltó okot, a megoldás egyszerű volt: kisebb, célzott konfigurációt vezettünk be, meghosszabbítottuk a frissítési időközt, és időbeli szórást adtunk az ilyen háttérfeladatokhoz.

Az alacsony asyncio-késleltetés fenntartásához elengedhetetlen a kérések megfelelő elosztása a kiszolgálófolyamatok között; hangolás nélkül a kapcsolatcsoportok ennek éppen az ellenkezőjét érhetik el.

Ügyféloldali kapcsolatcsoport esetén egy sok egyidejű kérést indító ügyfélfolyamat esetleg csak néhány kiszolgálókapcsolatot hoz létre, így teljes terhelését mindössze néhány folyamatra irányítja. A terheléselosztás módosítása előtt szolgáltatásunk kihasználtsága széles tartományban szóródott: egyes szélső folyamatok az átlagosnál 5–10-szer több egyidejű kérést szolgáltak ki.

Erre egy véletlen incidens során derült fény: bár leállítottuk a szolgáltatásunk egy részét túlterhelő ügyfelet, bizonyos folyamatok állapota még jóval a forgalmi csúcs után is leromlott maradt. Sőt, azt vettük észre, hogy e folyamatok állapota öngerjesztő módon tovább romlott, és újraindításukig egyre több kérést kaptak. Ha egy pod túlterhelődött, valamilyen működés még több forgalmat rögzített rá. Ezt a hibatípust néhány csapattársunk korábbi munkájából már jól ismerte: metastabil meghibásodás⁠(új ablakban nyílik meg).

A kapcsolatcsoportot gyanítottuk, ezért korlátoztuk a kapcsolatok újrafelhasználásának maximális időtartamát. Ez valóban mérsékelte a romlást, és megerősítette, hogy jó irányban vizsgálódunk. A további vizsgálat feltárta, hogy a Python aiohttp TCPConnector alapértelmezés szerint LIFO-alapon használja újra a kapcsolatokat: a következő kéréshez a legutóbb visszatért kapcsolatot választja. Ez általában észszerű alapértelmezés: a friss kapcsolatok újrafelhasználása lehetővé teszi, hogy a forgalmi csúcs kezelésére létrehozott további kapcsolatok tétlenségi időtúllépéssel megszűnjenek, csökkentve fenntartásuk többletterhét. Ebben az esetben azonban metastabil meghibásodást okozott. Egy forgalmi csúcs során a lassabb, túlterhelt kiszolgálókhoz küldött kérések kapcsolatai később tértek vissza a csoportba, ezért a későbbi kérések gyakrabban választották őket, és fokozatosan még több forgalmat összpontosítottak a már nehézségekkel küzdő podokra. A kapcsolatcsoport FIFO-alapú újrafelhasználásra módosítása megszakította ezt a visszacsatolási hurkot, és még az állandósult állapotban mért kérésszórást is csökkentette.

Ma az OpenAI infrastruktúrájában jellemzően az Istióra és az Envoyra támaszkodunk a kapcsolatcsoportok és a kiszolgálók terhelését jobban figyelembe vevő elosztási stratégiák biztosításához, így teljesen elkerüljük ezt a problémát.

Az alacsony asyncio-késleltetésre hangolás és a rengeteg Python-folyamat egyik mellékhatása, hogy a kapcsolatok óriási számával rendkívül könnyű túlterhelni az alsóbb függőségeket – ezt „dübörgő csordának” nevezik.

Egy szokásos napi telepítés – ha nincs kellően lassúra hangolva – jelentős CPU-ingadozást okozhat a kapcsolatok folyamatos cserélődése miatt. Egy kapcsolatszivárgás pedig a NAT-átjáró telítésével leállíthatja a hálózatot. Más szolgáltatásoknál sem ritkák ezek a problémák, ám a nagyságrenddel több folyamat jelentősen csökkenti a kiváltási küszöböt. Emiatt gyakran olyan hálózati erőforrások telítődnek, amelyek ekkora állandósult terhelésére az ügyfelek pusztán az adatátviteli egység alapján nem számítanak.

A kapcsolatok maximális összevonásához is az Envoyra támaszkodunk. Segítségével a Python HTTP/1-kapcsolatait HTTP/2-re frissítjük, hogy kihasználjuk a multiplexelést, majd csoportosítjuk ezeket a kapcsolatokat, és meghosszabbítjuk az élettartamukat. Az Envoy központi helyet biztosít a sebességkorlátozók és megszakítók megvalósításához is, amelyek külön-külön minden önálló Python-folyamatban kevésbé lennének hatékonyak.

A Python ilyen mértékű skálázását részben a Habitat korlátozott API-ja tette lehetővé, amely kiszámíthatóvá teszi a kérések költségét. A Habitat nem engedi, hogy az ügyfelek tetszőleges SQL-lekérdezéseket állítsanak össze, amelyek nagy táblák teljes átvizsgálását vagy sok táblát érintő összekapcsolásokat eredményezhetnek; ehelyett egyszerű NoSQL API-t kínál. A nagy teljesítményű API hiánya tudatos kompromisszum a Habitat kialakításában.

Az egyszerű, kiszámítható, állandó munkamennyiséget igénylő kérésekre optimalizálunk. Tapasztalataink szerint ezek a rendszerek sokkal könnyebben skálázhatók, és nehéz őket hibásan vagy nem rendeltetésszerűen használni. A kiszámíthatatlan szétágazású kérések üzemeltetési szempontból veszélyesek: megnehezítik az elkülönítést és a terheléselosztást, valamint olyan hirtelen késleltetésnövekedést okoznak, amelyre a szolgáltatás és ügyfelei is nehezen skálázhatók.

Mielőtt áttértünk a Habitatra és az Azure Cosmos DB-re, az OpenAI online adatainak többségét Postgresben tároltuk. Akkoriban még könnyű volt minden lekérdezés- és sémamódosítást ellenőrizni, hogy megfelelően működjön, és indexelt adatokon fusson, mielőtt éles környezetbe került. A csapat és a termékek növekedésével ez gyorsan kezelhetetlenné vált, és gyakran okozott üzemzavart, amikor egyetlen új, költséges lekérdezés egy kritikus útvonalon leállította az adatbázist.

A probléma a költségek aránytalansága: olcsó és egyszerű olyan SQL-lekérdezést írni, amelynek futtatása költséges és nehéz. A Habitatban ezt elkerüljük, és a költséges lekérdezéseket rendkívül szembetűnővé tesszük az ügyféloldalon. Nincsenek korlátlan lekérdezések, amelyek túlterhelhetnék a Habitatot, a bonyolult összekapcsolások és gráfbejárások pedig a termékcsapatokra hárítják a munka egy részét, ami összességében hatékonyabb kialakításra ösztönöz.

A Habitat az ügyfelek által meghatározott objektum- és éltípusokra épülő, a TAO⁠(új ablakban nyílik meg) által ihletett NoSQL API-t kínál. Az ügyfelek előre meghatározzák az objektumokat, az éleket és azok kapcsolatait, de az egyes típusok tartalmát nem. Az így létrejövő kapcsolatok gráfra hasonlítanak, de a Habitat egy adott objektum közvetlen éleinek lekérdezésén kívül nem támogatja a szokásos gráfbejárási lekérdezéseket.

A gráfot úgy particionáljuk, hogy minden objektum és a hozzá tartozó élek ugyanabba a tárolási szintű partícióba kerüljenek, de adatbázisszinten nem törekszünk tudatosan arra, hogy az objektumok az éleik által hivatkozott távoli objektumokkal együtt legyenek elhelyezve. Így a modell könnyen particionálható a horizontális skálázhatósághoz, a gráfbejárás azonban nem hatékony, mert az objektumok közötti bármely lépéshez két, teljesen különböző régióban tárolt Azure Cosmos DB-fiókból is le kell kérni adatokat.

Az összetettebb lekérdezéseket igénylő ügyfeleknek biztosítjuk a Habitat Rockseten keresztül elérhető, offline másodlagos nézetét. Változásadat-rögzítéssel (CDC) közel valós időben továbbítjuk az online tárhely módosításait elkülönített Rockset-példányokba. Minden ügyfélcsapat maga felel saját Rockset-példányának az összetett lekérdezési igényeihez igazodó skálázásáért.

A Rockset kiépítése többletterhet ró ügyfeleinkre, de jelenleg ezt tartjuk a megfelelő kompromisszumnak: az egyszerű lekérdezések az alapértelmezettek, miközben az összetett lekérdezéseket igénylőknek alternatívát kínálunk. Ez a kialakítás elszigeteli online tárhelyünket az olvasásigényes analitikai és keresési munkaterhelésektől.

A Pythonban írt rendszer átírásának egyéves elhalasztása lehetővé tette, hogy a rendkívül gyors növekedés során sürgősebb és nagyobb hatású kihívásokra összpontosítsunk. Ahogy a platform érettebbé vált, növekedésünk pedig tovább gyorsult, a Habitat magszám alapján az OpenAI második legnagyobb szolgáltatásává vált – Envoy-lábnyom alapján pedig a negyedikké –, így végre elérkezett az idő a Python leváltására. Csúcspontján a Python másodpercenként több mint 20 millió kérés kiszolgálását tette lehetővé.

2026 második negyedévében mindössze 2 mérnökkel, a Codex és a GPT‑5.5 segítségével a teljes szolgáltatást át tudtuk írni Rustra. Az új Rust-szolgáltatás már az éles kéréseink 95%-át kezeli; a következő hetekben teljesen kivezetjük a Pythont. Adataink szerint a Rust-szolgáltatás hatszor hatékonyabban használja a CPU-t és tizenötször hatékonyabban a memóriát, mint a Python-verzió, miközben az átlagos és a szélső késleltetése is lényegesen alacsonyabb. Egy későbbi blogbejegyzésben további tanulságokat osztunk majd meg.

A Pythonban – most pedig Rustban – írt szolgáltatás csak a Habitat egyik oldala. A több mint 1 milliárd ChatGPT‑felhasználó kiszolgálására gyorsan felskálázott online tárhelyünkről szóló sorozat második részében bemutatjuk a tárolási réteget, valamint azt, hogyan szolgál ki a Habitat több mint 500 petabájtnyi adatot és másodpercenként több mint 70 millió kérést.

Ha szívesen dolgoznál élvonalbeli léptékű OLTP-rendszereken, és érdekel az ilyen jellegű mérnöki munka, tekintsd meg a csapatunknál meghirdetett állást⁠.