Veebisalvesti kiire skaleerimine üle 1 miljardi ChatGPT kasutaja teenindamiseks

Kõik OpenAI tooted sõltuvad kiirest ja töökindlast juurdepääsust andmetele, olgu kasutaja sisse logimas, Codexi seadeid kontrollimas või ChatGPT‑s uut vestlust alustamas. Iga selline toiming võib enne toote vastamist nõuda palju eraldi andmeotsinguid. Kui need päringud on aeglased, tundub ka toode aeglane. Kui need päringud nurjuvad, lakkab toode täielikult töötamast.

Habitat on meie loodud veebisalvestusplatvorm, mis võimaldab OpenAI toodetel vajalikule teabele kiiresti ja töökindlalt juurde pääseda. Habitat töötleb nüüd üle 70 miljoni päringu sekundis ning toetab ligi 40 geograafilises piirkonnas tooteid, mida kasutab nädalas üle miljardi inimese. Habitat käivitati esimest korda GPT‑de toetamiseks DevDay 2023-l lihtsa Pythoni klienditeegina, mis oli ühendatud ühe andmebaasiga. Praegu on see keerukas hajussüsteem, mis teenindab üle 500 petabaidi andmeid.

Sellises mahus taristu rajamine ja käitamine pole lihtne, kuid pole ka iseenesest eriti keeruline. Meie olukorra muutis ainulaadseks enneolematu kiirus, millega pidime hämmastava kasutajakasvu ja tootenõudluse toetamiseks skaleerima ning samal ajal küpset platvormi rajama. Süsteemiinsenerid ehitavad sageli kümnekordse mahu jaoks ja loodavad, et sellest piisab mõneks aastaks, kuni valmistutakse järgmiseks kümnekordseks kasvuks. Meie oleme viimase kolme aasta jooksul kasvanud igal aastal üle kümne korra. Seetõttu on Habitati rajamine ja käitamine tähendanud taktikaliste otsuste jada ning õiget järjestamist: iga komponendi mõistmist madalaima tasemeni, et olemasolevast tehnoloogiapinust maksimum võtta, ning salvestus- ja arvutusvõimsuse nappusega võitlemist, et võita aega põhjalikeks investeeringuteks.

OpenAI kasvades pidi kasvama ka Habitat: esmalt piisavalt töökindlaks, et teenindada missioonikriitilist tooteliiklust, seejärel piisavalt kiireks üleilmsetele kasutajatele ning lõpuks suutma osavalt tohutus mahus töötada. See postitus on veebisalvesti skaleerimist käsitleva kaheosalise sarja esimene osa. Kirjeldame, kuidas Habitat arenes, miks muutsime selle teegist teenuseks ja kuidas kujundasime teeninduspinu jaoks ebatavalises keeles Pythonis kirjutatud teenusest töökindla salvestusplatvormi kihi.

Tulevases postituses kirjeldame üksikasjalikult, kuidas tagasime mitme rentnikuga süsteemi töökindluse suures mahus, milline on meie kihiline lugemisjõudluse optimeerimise strateegia ning kuidas laiendasime koostööd Azure Cosmos DB-ga enneolematu nõudluse töökindlaks teenindamiseks.

Habitat sai alguse lihtsast mõttest: tooteinsenerid ei peaks andmebaaside haldamisele mõtlema. Habitat käivitati esimest korda GPT‑de toetamiseks DevDay 2023-l väikese Pythoni teegina, mis suhtles ChatGPT põhiserveriga. See toetas väikest hulka toiminguid, mis seostati taustal andmebaasirakendusega Azure Cosmos DB.

Teegi ülesanne oli anda tootemeeskondadele lihtne viis andmeid talletada ja hankida, ilma et nad peaksid aluseks olevaid üksikasju põhjalikult tundma. Habitat tegi vajaliku töö ise: määras andmete liigi, lähte- või sihtkoha, kontrollis päringu lubatavust ja palju muud.

Tooteinsenerid ei pea tegelema skeemiotsingu, marsruutimise, autoriseerimise, krüptimise, serialiseerimise, päringute kujundamise ega ühenduste koondamisega. Nad ei pidanud isegi arvestama, kust andmed pärinevad: Azure Cosmos DB-st, vahemäludest või muud liiki salvestitest.

See Pythoni teek töötas hästi ja Habitati kasutuselevõtt OpenAI tooteinseneride seas oli kiire, kuigi iseteeninduslikust Postgresist ja Azure Cosmos DB-st loobumist keskselt ei survestatud.

Tootevajaduste arenedes oli arendajatel lihtne lisada ühisteeki ka kliendipoolse vahemälu, tihendamise või krüptimise tuge.

2025. aasta keskpaigaks oli Habitat kliendipoolse lahendusena jõudnud oma piirideni. Habitati kihi keerukamaks muutudes ja OpenAI teenuste arvu kasvades polnud tagasiühilduvaid protokollimuudatusi enam võimalik teha.

Ühel juhul soovisime vähendada ühe piirkonna katkestuse mõjuala meie kõige kriitilisematele andmekogumitele, viies need üle piirkondlikult hajutatud Azure Cosmos DB kontodele. Muudatus nõudis kliendile täiendava marsruutimisloogika lisamist keelatud funktsioonilipu taha, selle kõigile klientidele juurutamist ja seejärel lipu lubamist.

Kümnete teenuste juurutuste koordineerimine ja iga meeskonnaga koostöös avaldamine võttis päevi. Enne selle lubamist mõistsime, et tahame lisada varjutamise, et kontrollida killustamisloogika õigsust. Ka selle juurutamine võttis veel paar päeva. Ja avastatud vea parandamine? Veel paar päeva. Lõpuks olime valmis lipu lubama, kuid üks meeskond taastas kõrvalistel põhjustel oma teenuse varasema vigase kliendiversiooni, põhjustades just selle katkestuse, mida olime nii püüdlikult vältinud.

Klienditeegi muudatused nõudsid kümnete teenuste keerukat koordineerimist ning see protsess osutus üha hapramaks, ebatõhusamaks ja käitustõrgetele vastuvõtlikumaks. Tulevaste juurutuste käitusliku hargnemise vähendamiseks otsustasime muuta Habitati eraldiseisvaks teenuseks.

Salvestusloogika eraldamisega iseseisvaks teenuseks lõime juurutamise, jälgitavuse ja platvormitäiustuste jaoks ühe keskse juhtimispunkti. Killustatud uuenduste haldamise asemel saime täiustusi keskselt rakendada, nii et neist võitis kohe iga OpenAI toode.

Keskne teenus annab meile ka ühe kontrollpunkti, kus rakendada kõige tugevamaid andmeturbe ja privaatsuse alusmehhanisme. Habitati teenuses saame keskselt jõustada juurdepääsukontrolli reegleid, pidada auditilogi ning piirata juurdepääsu aluseks olevatele salvestusressurssidele, nagu Azure Cosmos DB. Habitat täidab olulist rolli kasutajaandmete kaitsmisel ning väliste, sisemiste ja agentidest osaliste volitamata juurdepääsu takistamisel.

Teadsime, et vajame teenust, kuid ei soovinud veel Pythonist loobuda, kuigi selle kasutamine teenusena tõi kaasa lisakulu. Pythoni kasutamine suure läbilaskega teenuses suurendas võrgulatentsust ning CPU ja mälu skaleerimise kulu võrreldes teegi kohaliku käitamisega. Mõistsime ka, et Pythoni ebatõhusus poleks 100-kordse mahu juures vastuvõetav, mistõttu oli hilisem ümberkirjutamine peaaegu kindel.

Pidasime seda siiski tehnilise võla teadlikuks võtmiseks. Meie peamine eesmärk polnud siis kulude ega ressursside optimeerimine, vaid tootearendajate töö takistuste kõrvaldamine ja platvormi stabiilsus. Nõustudes lühiajaliselt Pythoni teenuse jõudluskompromissidega, saime keskenduda pakilisematele probleemidele, panna paika põhi-API-d ja rajada töökindla taristu.

Tegime ka kaalutletud panuse sellele, et meie enda koodimudelite kiire areng lihtsustab tulevikus tehnilist üleminekut. Panustasime sellele, et kui täielik Pythonist loobumine muutub vajalikuks, teevad Codex ja GPT selle ülemineku teostatavaks. Lõpuks osutus see panus õigeks.

Habitati käitamine Pythoni teenusena polnud jõudluse mõttes optimaalne, kuid oli vajalik valik. Python võimaldab kiiresti tegutseda, kuid see ei tähenda, et võisime ettevaatuse unustada ja märksa suurema latentsusega leppida. Kui keskmine kasutajapäring põhjustab sadu andmebaasipäringuid, tajub kasutaja neist kõige aeglasemat. Leidsime, et sellises mahus Pythoni teenuse käitamise peamine raskus on sabalatentsuste haldamine.

Asyncio aitab Pythonil I/O-põhiseid töökoormusi samaaegselt täita, kuid ei võimalda Pythoni GIL-ist mööda minna ega CPU-paralleelsust saavutada. Lisaks I/O-mahukale päringute vahendamisele täidab Habitat palju CPU-mahukaid ülesandeid ja taustatöid: marsruutimine, tihendamine, krüptimine, kontrollsummade arvutamine, allavooluteenuste tervisekontroll, päringute varjutamine ja dubleerimine.

Kuna teenuses on nii palju CPU-mahukaid töökoormusi ja taustatöid, võib asyncio ajastamisviivitus hõlpsasti kujuneda päringute sabalatentsuse peamiseks osaks. Enne esmakäivituseks häälestamist nägime p99 ja suurema latentsusega päringute jälgedest, et kuigi allavoolusalvesti vastas kiiresti, jäid päringud sageli seisma, oodates vastust töötleva korutiini uuesti ajastamist.

OpenAI Pythoni teenuste puhul on lisaks mälu, CPU, võrgu ja ketta tavapäraste kasutus- ning küllastusnäitajate mõõtmisele ülioluline jälgida asyncio sündmusetsüklit ja selle koormust ning teenust vastavalt häälestada.

Taustatöid korrapäraselt ajastades ning oodatud ja tegeliku käivitusaja erinevust salvestades saame sündmusetsükli ajastamisviivitust reaalajas empiiriliselt mõõta. Suure koormuse ja paljude kulukate ülesannete korral piisab märkimisväärse ajastusvõbeluse tekkeks isegi mõõdukast arvust samaaegsetest päringutest protsessi kohta: viivitus võib ulatuda sadade millisekunditeni ja erandjuhul mitme sekundini.

Seetõttu laseme igal protsessil teenindada vaid väheseid samaaegseid päringuid ja suurendame selle asemel Pythoni tööprotsesside arvu väga ulatuslikult.

Teenuse esmakäivitamisel avastasime töötava teenuse CPU profileerimise abil ühe asyncio suure viivituse ja sellest tuleneva suure sabalatentsuse algpõhjuse: funktsioonilippude konfiguratsioonide perioodiline JSON-i sõelumine Statsigi kaudu. Statsig haldab funktsioonilippe ning võimaldab muu hulgas teha A/B-teste.

Vaikimisi oli Statsig seadistatud uuendatud konfiguratsioone ilma ajastusvõbeluseta iga minut kontrollima ning konfiguratsioon hõlmas kõigi teenuste kõiki tootmisreegleid. Mujal oli tehtud arhitektuuriotsus käitada igas podis kuni kaheksat Pythoni protsessi, et CPU kasutust suurendada ja latentsust vähendada. Koos tähendas see, et igas podis tekkis iga minut hetk, mil kõik tööprotsessid peatasid pooleliolevate päringute töötlemise ja kulutasid CPU tsükleid hoopis hiiglasliku konfiguratsioonifaili sõelumisele.

Kui CPU profileerimine aitas algpõhjuse leida, oli lahendus lihtne: juurutada väiksem sihitud konfiguratsioon, pikendada värskendusintervalli ja lisada sellistele taustatöödele ajastusvõbelust.

Asyncio väikese viivituse säilitamiseks on ülioluline jaotada päringukoormus serveriprotsesside vahel hästi; häälestamata ühenduste koondamine võib sellele hoopis vastu töötada.

Kliendipoolse ühenduste koondamise korral võib palju samaaegseid päringuid tegev kliendiprotsess luua vaid mõne serveriühenduse ja saata seetõttu kogu koormuse vaid mõnele protsessile. Enne koormuse tasakaalustamise kohandamist varieerus meie teenuse kasutus suuresti: mõned äärmuslikud protsessid teenindasid keskmisest 5–10 korda rohkem samaaegseid päringuid.

Avastasime selle juhusliku intsidendi käigus: kuigi peatasime osa teenusest üle koormanud kliendi, püsis osa protsesse halvas seisus veel kaua pärast päringutulva. Tegelikult märkasime, et nende protsesside seisund halvenes kontrollimatult ja nad said üha rohkem päringuid, kuni need taaskäivitasime. Kui pod üle koormati, suunas mingi käitumismuster sellele veel rohkem liiklust. Mõned meeskonnakaaslased tundsid seda tüüpi tõrget varasemast tööst hästi: metastabiilne tõrge⁠(avaneb uues aknas).

Kahtlustasime ühenduste kogumit ja kontrollisime seda, piirates ühenduse maksimaalset taaskasutusaega. See piiras tõepoolest halvenemist ning kinnitas, et uurime õiget suunda. Edasine uurimine näitas, et Pythoni aiohttp TCPConnector kasutab vaikimisi ühenduste LIFO-taaskasutust: järgmise päringu jaoks valitakse viimati tagastatud ühendus. Tavaliselt on see mõistlik vaikevalik: hiljutiste ühenduste taaskasutamine võimaldab päringutulva teenindamiseks loodud lisaühendustel jõudeoleku tõttu aeguda ja vähendab nende haldamise kulu. Meie puhul põhjustas see metastabiilse tõrke. Päringutulva ajal tagastasid aeglasematele ülekoormatud serveritele saadetud päringud ühendused kogumisse hiljem, mistõttu valisid järgnevad päringud neid sagedamini ja koondasid liiklust järk-järgult juba raskustes podidele. Ühenduste kogumi muutmine FIFO-taaskasutusele katkestas selle tagasisideahela ja vähendas ka päringukoormuse erinevust püsiolekus.

Praegu kasutame OpenAI taristus ühenduste koondamiseks ja serverikoormust paremini arvestavaks tasakaalustamiseks peamiselt Istiot ja Envoyd, et seda probleemi täielikult vältida.

Asyncio väikese viivituse nimel häälestamise ja Pythoni protsesside suure arvu üks kõrvalmõju on see, et allavoolusõltuvused võib tohutu ühenduste hulgaga väga kergesti üle koormata. Seda tuntakse „tormijooksuna“.

Tavaline igapäevane juurutus võib põhjustada ühenduste pideva vahetumise tõttu suurt CPU-koormuse kõikumist, kui seda pole aeglaseks häälestatud. Ühenduseleke võib aga NAT-lüüsi küllastades kogu võrgu rivist välja viia. Need probleemid pole haruldased ka teistes teenustes, kuid suurusjärgu võrra rohkem protsesse langetab nende vallandumisläve märgatavalt. Sageli küllastuvad võrguressursid, mille selliseks püsiolekukoormuseks valmistumist ei oska kliendid pelgalt läbilaske põhjal oodata.

Kasutame Envoyd ka ühenduste maksimaalseks koondamiseks. Selle abil viime Pythoni HTTP/1 ühendused multipleksimise kasutamiseks üle HTTP/2-le, koondame need ühendused ja pikendame nende eluiga. Envoy annab meile ka keskse koha sageduspiirangute ja kaitselülitite rakendamiseks, mis oleksid igas eraldiseisvas Pythoni protsessis vähem tõhusad.

Üks põhjus, miks saime Pythoni nii kaugele skaleerida, oli Habitati piiratud API, mis hoiab päringukulu prognoositavana. Selle asemel et lubada klientidel koostada suvalisi SQL-päringuid, mis võivad põhjustada suurte tabelite skannimist või paljude tabelite ühendamist, pakub Habitat lihtsat NoSQL-i API-t. Võimsa API puudumine on Habitati disainis teadlik kompromiss.

Optimeerime lihtsate, prognoositavate ja püsiva töömahuga päringute jaoks. Meie kogemuse järgi on selliseid süsteeme märksa lihtsam skaleerida ning keeruline valesti kasutada. Ettearvamatu hargnemisega päringud on käitamisel ohtlikud: need raskendavad isoleerimist ja koormuse tasakaalustamist ning tekitavad järske latentsushüppeid, millega on raske skaleerida nii teenusel kui ka selle klientidel.

Enne Habitatile ja Azure Cosmos DB-le üleminekut hoiti enamikku OpenAI veebiandmetest Postgresis. Toona oli lihtne kõik päringu- ja skeemimuudatused enne tootmisse juurutamist üle vaadata ning veenduda, et need toimivad hästi ja kasutavad indekseeritud andmeid. Meeskonna ja toodete kasvades muutus see kiiresti juhitamatuks ning põhjustas sageli katkestusi, kus üks uus kulukas päring kriitilisel teel viis andmebaasi rivist välja.

Probleem seisneb kulude ebavõrdsuses: kulukaid ja raskesti käitatavaid SQL-päringuid on odav ja lihtne kirjutada. Habitat väldib seda ja muudab kulukad päringud kliendi poolel äärmiselt ilmseks. Habitatil pole piiramatuid päringuid, mis võiksid selle üle koormata. Keerukad ühendused ja graafi läbimised nõuavad tootemeeskondadelt osa raskest tööst, mis aitab üldiselt eelistada tõhusamaid lahendusi.

Habitat pakub kliendi määratud objekti- ja servatüüpidel põhinevat NoSQL-i API-t, mille eeskujuks on TAO⁠(avaneb uues aknas). Kliendid määravad objektid, servad ja nendevahelised seosed ette, kuid mitte iga tüübi sisu. Tekkivad seosed meenutavad graafi, kuid Habitat ise ei toeta tavapäraseid graafi läbimise päringuid peale konkreetse objekti otseste servade pärimise.

Jaotame graafiku nii, et iga objekt ja selle servad paiknevad koos salvestuskihi partitsioonis, kuid andmebaasikihis ei püüa me objekte teadlikult paigutada kokku kaugobjektidega, millele nende servad osutavad. Tulemuseks on mudel, mida saab horisontaalseks skaleerimiseks hõlpsasti partitsioonida, kuid graafi läbimine on ebatõhus, sest iga objektidevaheline samm võib nõuda andmete hankimist kahest täiesti erinevas piirkonnas asuvast Azure Cosmos DB kontost.

Keerukamate päringuvajadustega klientidele pakume Rockseti kaudu Habitati põhilisest päringuteenindusest eraldatud teisest vaadet. Kasutame muudatuste andmehõivet (CDC), et voogedastada veebisalvesti muudatused peaaegu reaalajas isoleeritud Rockseti eksemplaridesse. Iga kliendimeeskond vastutab oma Rockseti eksemplari skaleerimise eest vastavalt keerukate päringute vajadustele.

Rockseti ettevalmistamine tekitab klientidele lisavaeva, kuid peame seda praegu õigeks kompromissiks: lihtsad päringud on vaikimisi valik, samas kui keerukate päringute vajajatele jääb väljapääs. See lahendus isoleerib meie veebisalvesti lugemismahukatest analüüsi- ja otsingukoormustest.

Pythoni ümberkirjutamise aastane edasilükkamine võimaldas meil hüperkasvu ajal keskenduda pakilisematele ja mõjukamatele probleemidele. Kui platvorm küpses ja kasv üha kiirenes, oli viimaks aeg Pythonist edasi liikuda: tuumade arvu järgi oli see OpenAI suuruselt teine teenus ja Envoy mahu järgi neljas. Tipphetkel aitas Python meil teenindada üle 20 miljoni päringu sekundis.

2026. aasta teises kvartalis suutsime vaid kahe inseneri, Codexi ja GPT‑5.5 abil kogu teenuse Rustis ümber kirjutada. Uus Rusti teenus töötleb nüüd 95% meie tootmispäringutest; lähinädalatel lõpetame Pythoni kasutamise täielikult. Meie andmetel on Rusti teenus Pythoni versioonist kuus korda CPU-tõhusam ja 15 korda mälutõhusam ning selle keskmine ja sabalatentsus on märksa väiksemad. Kavatseme tulevases blogipostituses rohkem õppetunde jagada.

Pythoni ja nüüd Rusti teenus on vaid üks Habitati tahk. Selle sarja teises osas, kus selgitame, kuidas skaleerisime veebisalvestit kiiresti üle miljardi ChatGPT kasutaja teenindamiseks, räägime salvestuskihist ning sellest, kuidas Habitat teenindab üle 500 petabaidi andmeid ja enam kui 70 miljonit päringut sekundis.

Kui soovid töötada tipptasemel mahuga OLTP-süsteemide kallal ja selline inseneritöö sind huvitab, vaata meie meeskonna vaba ametikohta⁠.