Hitro razširjanje spletne shrambe za več kot milijardo uporabnikov ChatGPT

Vsak izdelek OpenAI je odvisen od hitrega in zanesljivega dostopa do podatkov, naj gre za prijavo uporabnika, preverjanje nastavitev Codexa ali začetek novega pogovora v ChatGPT. Vsako od teh dejanj lahko zahteva številna ločena iskanja podatkov, preden se izdelek lahko odzove. Če so te zahteve počasne, se tudi izdelek zdi počasen. Če te zahteve spodletijo, izdelek povsem preneha delovati.

Habitat je platforma za spletno shranjevanje, ki smo jo zgradili, da lahko izdelki OpenAI hitro in zanesljivo dostopajo do potrebnih informacij. Habitat zdaj obdeluje več kot 70 milijonov zahtev na sekundo in v skoraj 40 geografskih regijah podpira izdelke, ki jih vsak teden uporablja več kot milijarda ljudi. Habitat smo prvič uvedli za podporo GPT‑jem na DevDay 2023, sprva kot preprosto odjemalsko knjižnico Python, povezano z eno podatkovno zbirko. Danes je to zapleten porazdeljeni sistem, ki zagotavlja več kot 500 petabajtov podatkov.

Gradnja in upravljanje infrastrukture v takšnem obsegu nista preprosta, vendar tudi ne posebej zahtevna. Naš položaj je bil edinstven zaradi hitrosti brez primere, s katero smo morali širiti sistem, da bi podprli osupljivo rast števila uporabnikov in povpraševanja po izdelkih, hkrati pa razvijali zrelo platformo. Sistemski inženirji pogosto gradijo za desetkratni obseg in upajo, da bo rešitev zdržala nekaj let, medtem ko se pripravljajo na naslednjo desetkratno rast. Pri nas je obseg zadnja tri leta vsako leto zrasel za več kot desetkrat. Gradnja in upravljanje Habitata sta zato potekala kot zaporedje taktičnih odločitev: vsako komponento smo razumeli do najnižje ravni in iz obstoječega sklada iztisnili čim več, hkrati pa preprečevali pomanjkanje shranjevalnih in računalniških zmogljivosti ter tako pridobivali čas za temeljne naložbe.

Z rastjo OpenAI je moral rasti tudi Habitat: najprej je postal dovolj zanesljiv za kritični promet izdelkov, nato dovolj hiter za uporabnike po vsem svetu in nazadnje dovolj prilagodljiv za učinkovito delovanje v ogromnem obsegu. Ta objava je prva v dvodelni seriji o razširjanju spletne shrambe. Predstavili bomo razvoj Habitata, razloge za njegovo preoblikovanje iz knjižnice v storitev ter način, kako smo storitev v jeziku, ki se redko uporablja za strežniške sisteme – Pythonu – razširili v zanesljivo platformno plast za shranjevanje.

V prihodnji objavi bomo podrobno predstavili, kako smo zagotovili zanesljivost večnajemniškega okolja v velikem obsegu, naš večplastni pristop k optimizaciji branja in širitev sodelovanja z Azure Cosmos DB za zanesljivo obvladovanje povpraševanja brez primere.

Habitat je nastal iz preproste zamisli: inženirjem izdelkov se ne bi smelo biti treba ukvarjati z upravljanjem podatkovnih zbirk. Habitat smo prvič uvedli za podporo GPT‑jem na DevDay 2023 kot majhno knjižnico Python, ki je komunicirala z glavnim strežnikom ChatGPT. Podpirala je majhen nabor operacij, ki so se v ozadju preslikale v podatkovno zbirko Azure Cosmos DB.

Naloga knjižnice je bila ekipam izdelkov omogočiti preprosto shranjevanje in pridobivanje podatkov brez obvladovanja podrobnosti osnovnega sistema. Habitat je opravil vse potrebno: ugotovil vrsto podatkov, njihov izvor ali cilj, dovoljenost zahteve in drugo.

Inženirjem izdelkov se ni bilo treba ukvarjati z iskanjem shem, usmerjanjem, avtorizacijo, šifriranjem, serializacijo, oblikovanjem zahtev in združevanjem povezav. Sploh jim ni bilo treba razmišljati, od kod prihajajo podatki: iz Azure Cosmos DB, predpomnilnikov ali drugih vrst shrambe.

Knjižnica Python je dobro delovala in Habitat se je med inženirji izdelkov v OpenAI hitro uveljavil, čeprav ni bilo usklajene osrednje pobude za opustitev samopostrežnih sistemov Postgres in Azure Cosmos DB.

Ko so se potrebe izdelkov razvijale, so lahko razvijalci izdelkov v skupno knjižnico preprosto dodali podporo za funkcije, kot so odjemalsko predpomnjenje, stiskanje ali šifriranje.

Do sredine leta 2025 je Habitat kot odjemalska rešitev dosegel svoje meje. Ker je plast Habitat postajala vse bolj zapletena, število storitev OpenAI pa je naraščalo, nazaj združljive spremembe protokola niso bile več izvedljive.

V nekem primeru smo želeli omejiti posledice izpada posamezne regije za najpomembnejše nabore podatkov tako, da bi jih preselili v skupino regionalno porazdeljenih računov Azure Cosmos DB. Za to spremembo smo morali v odjemalca dodati usmerjevalno logiko, skrito za onemogočeno funkcijsko zastavico, jo uvesti pri vseh odjemalcih in nato zastavico omogočiti.

Usklajevanje uvedb v več deset storitvah in sodelovanje z vsako ekipo je trajalo več dni. Pred omogočanjem smo ugotovili, da želimo dodati senčenje zahtev, da bi preverili pravilnost logike razdeljevanja. Tudi uvajanje tega je trajalo še nekaj dni. Popravek napake, ko smo ugotovili, da nekaj ni pravilno? Še nekaj dni. Nazadnje smo bili pripravljeni omogočiti zastavico, vendar je ena od ekip zaradi nepovezanih razlogov svojo storitev povrnila na starejšo različico z okvarjenim odjemalcem in povzročila prav izpad, ki smo ga tako prizadevno preprečevali.

Spremembe odjemalske knjižnice so zahtevale zapleteno usklajevanje več deset storitev, ta postopek pa je postajal vse bolj krhek, neučinkovit in dovzeten za operativne napake. Da bi pri prihodnjih uvedbah zmanjšali to operativno razpršenost, smo se odločili Habitat pretvoriti v samostojno storitev.

Z ločitvijo logike shranjevanja v samostojno storitev smo vzpostavili enotno nadzorno točko za uvedbe, opazljivost in izboljšave platforme. Namesto upravljanja razdrobljenih posodobitev smo lahko izboljšave uvedli centralno in z njimi takoj koristili vsakemu izdelku OpenAI.

Centralizirana storitev nam zagotavlja tudi eno samo nadzorno točko za najmočnejše temeljne mehanizme varnosti in zasebnosti podatkov. V storitvi Habitat lahko centralno uveljavljamo pravilnike za nadzor dostopa, izvajamo revizijsko beleženje in omejujemo dostop do osnovnih virov shranjevanja, kot je Azure Cosmos DB. Habitat ima ključno vlogo pri varovanju uporabniških podatkov in preprečevanju nepooblaščenega dostopa zunanjih, notranjih in agentskih akterjev.

Vedeli smo, da potrebujemo storitev, vendar še nismo želeli opustiti Pythona, čeprav kot storitev prinaša dodatne režijske stroške. Uporaba Pythona za storitev z visoko prepustnostjo je v primerjavi z lokalnim izvajanjem knjižnice povečala omrežno zakasnitev ter stroške razširjanja CPE in pomnilnika. Poleg tega smo vedeli, da neučinkovitost Pythona pri 100-kratnem obsegu ne bo sprejemljiva, zato je bil poznejši prepis skoraj neizogiben.

Vendar smo to razumeli kot strateško sprejet tehnični dolg. Naš glavni cilj tedaj ni bila optimizacija stroškov ali virov, temveč odprava ovir za razvijalce izdelkov in zagotovitev stabilnosti platforme. S kratkoročnim sprejetjem kompromisov pri zmogljivosti storitve Python smo se lahko posvetili nujnejšim izzivom, vzpostavili temeljne API-je in zgradili robustno infrastrukturo.

Premišljeno smo stavili tudi na to, da bo hiter napredek naših modelov za programiranje v prihodnje poenostavil tehnično izvedbo. Stavili smo, da bosta Codex in GPT do takrat, ko bo popoln prehod s Pythona nujen, omogočila izvedbo te selitve. Ta stava se je nazadnje izkazala za pravilno.

Izvajanje Habitata kot storitve Python z vidika zmogljivosti ni bilo optimalno, vendar je bilo nujno. Python nam omogoča hitro delo, vendar to ne pomeni, da smo lahko odmislili previdnost in sprejeli občutno daljše zakasnitve. Ko povprečna uporabniška zahteva sproži več sto klicev podatkovne zbirke, uporabnik občuti najpočasnejšega. Ugotovili smo, da je glavni izziv izvajanja storitve Python v tem obsegu obvladovanje zakasnitev na repu porazdelitve.

Asyncio Pythonu pomaga sočasno izvajati vhodno-izhodne obremenitve, ne zaobide pa Pythonovega GIL-a in ne omogoča vzporednega izvajanja v CPE. Habitat poleg posredovanja vhodno-izhodno zahtevnih zahtev opravlja številne naloge, ki močno obremenjujejo CPE, in opravila v ozadju: usmerjanje, stiskanje, šifriranje, izračun kontrolnih vsot, preverjanje zdravja odvisnih storitev, senčenje in varovalno podvajanje zahtev.

Ob tolikšnem številu opravil, zahtevnih za CPE, in opravil v ozadju lahko zakasnitev razporejanja asyncio zlahka prevlada v zakasnitvi zahtev na repu porazdelitve. Pred uglaševanjem za prvi zagon storitve smo v sledeh zahtev z zakasnitvijo p99 ali več opazili, da se je odvisna shramba hitro odzvala, zahteve pa so pogosto zastale med čakanjem, da razporejevalnik znova zažene ustrezno korutino za razčlenitev odgovora.

Pri storitvah Python v OpenAI poleg standardnih meritev izkoriščenosti in nasičenosti pomnilnika, CPE, omrežja in diska nujno spremljamo tudi zanko asyncio in njeno obremenjenost ter sistem ustrezno uglasimo.

Z rednim razporejanjem opravil v ozadju in beleženjem razlike med pričakovanim in dejanskim časom izvedbe lahko v realnem času empirično merimo zakasnitev razporejanja dogodkovne zanke. Pri visoki izkoriščenosti in številnih zahtevnih opravilih že zmerno število sočasnih zahtev na proces povzroči precejšnje nihanje razporejanja, ki doseže več sto milisekund, v nekaterih skrajnih primerih pa več sekund.

Zato vsak proces obdeluje le malo sočasnih zahtev, namesto tega pa močno povečamo število delovnih procesov Python.

Ob prvem zagonu storitve smo s sprotnim profiliranjem CPE odkrili enega od temeljnih vzrokov za veliko zakasnitev asyncio in posledično velike zakasnitve na repu: redno razčlenjevanje konfiguracij funkcijskih zastavic JSON prek Statsiga, orodja za upravljanje funkcijskih zastavic, izvajanje testov A/B in drugo.

Statsig je bil privzeto nastavljen tako, da je brez časovnega zamika vsako minuto preveril posodobljene konfiguracije, konfiguracija pa je vsebovala vsa produkcijska pravila vseh storitev. Drugje smo sprejeli arhitekturno odločitev, da v vsakem podu izvajamo do osem procesov Python, s čimer bi povečali izkoriščenost CPE in zmanjšali zakasnitve. Skupaj je to pomenilo, da so vsako minuto vsi delovni procesi v vsakem podu za trenutek prekinili obdelavo tekočih zahtev in cikle CPE namenili razčlenjevanju ogromne konfiguracijske datoteke.

Ko nam je profiliranje CPE pomagalo odkriti temeljni vzrok, je bila rešitev preprosta: uvedli smo manjšo namensko konfiguracijo, podaljšali interval osveževanja in takšnim opravilom v ozadju dodali časovni zamik.

Za kratko zakasnitev asyncio je nujno tudi dobro uravnoteženje zahtev med strežniškimi procesi; brez uglaševanja lahko združevanje povezav deluje prav nasprotno.

Pri odjemalskem združevanju povezav lahko en odjemalski proces, ki pošilja veliko sočasnih zahtev, vzpostavi le peščico povezav s strežniki in zato vso obremenitev usmeri le v peščico procesov. Pred prilagoditvijo uravnoteženja obremenitve se je izkoriščenost naše storitve močno razlikovala, saj so nekateri procesi na repu obdelovali od pet- do desetkrat več sočasnih zahtev od povprečja.

To smo po naključju odkrili ob incidentu, ko je del procesov ostal močno prizadet še dolgo po sunku prometa, čeprav smo ustavili odjemalca, ki je preobremenjeval del storitve. Opazili smo celo nenadzorovano slabšanje teh procesov, saj so prejemali vse več zahtev, dokler jih nismo znova zagnali. Ko se je pod preobremenil, je neko vedenje nanj priklepalo še več prometa. Nekateri sodelavci so to vrsto okvare dobro poznali iz prejšnjega dela: metastabilna okvara⁠(odpre se v novem oknu).

Posumili smo na zalogo povezav in domnevo preizkusili z omejitvijo najdaljšega trajanja ponovne uporabe povezav. To je res omejilo slabšanje in potrdilo smer naše preiskave. Nadaljnja preiskava je pokazala, da Pythonov aiohttp TCPConnector privzeto znova uporablja povezave po načelu LIFO: za naslednjo zahtevo izbere nazadnje vrnjeno povezavo. To je običajno smiselna privzeta nastavitev: ponovna uporaba nedavnih povezav omogoča, da dodatne povezave, ustvarjene za sunke prometa, ob nedejavnosti potečejo, kar zmanjša režijske stroške njihovega vzdrževanja. V tem primeru je povzročila metastabilno okvaro. Med sunkom zahtev so počasnejši preobremenjeni strežniki pozneje vračali povezave v zalogo, zato so jih naslednje zahteve izbirale pogosteje in postopoma kopičile vse več prometa na podih, ki so že imeli težave. S spremembo zaloge povezav na ponovno uporabo FIFO smo prekinili to povratno zanko in zmanjšali tudi razpršenost zahtev v stabilnem stanju.

Danes se v infrastrukturi OpenAI večinoma zanašamo na Istio in Envoy, ki zagotavljata združevanje povezav in boljše strategije uravnoteženja glede na obremenitev strežnikov, s čimer se težavi povsem izognemo.

Stranski učinek uglaševanja za kratko zakasnitev asyncio in velikega števila procesov Python je, da lahko odvisne sisteme zelo hitro preplavimo z ogromnim številom povezav, kar imenujemo »stampedo zahtev«.

Običajna dnevna uvedba lahko, če je ne nastavimo dovolj počasi, zaradi nenehnega zapiranja in vzpostavljanja povezav povzroči precejšnja nihanja obremenitve CPE. Uhajanje povezav pa lahko zaradi nasičenja prehoda NAT onesposobi omrežje. Takšne težave niso redke niti pri drugih storitvah, vendar red velikosti več procesov močno zniža prag njihovega nastanka in pogosto nasiči omrežne vire, za katere odjemalci ob upoštevanju zgolj prepustnosti ne pričakujejo, da jih bodo morali obvladovati v stabilnem stanju.

Na Envoy se zanašamo tudi za čim večje združevanje povezav. Z njim povezave HTTP/1 iz Pythona nadgradimo na HTTP/2, da izkoristimo multipleksiranje, nato pa te povezave združimo in podaljšamo njihovo življenjsko dobo. Envoy nam zagotavlja tudi osrednje mesto za omejevanje hitrosti in odklopnike, ki bi bili v vsakem samostojnem procesu Python manj učinkoviti.

Python smo lahko razširili tako daleč tudi zaradi omejenega API-ja Habitata, ki ohranja stroške zahtev predvidljive. Namesto da bi odjemalcem omogočal sestavljanje poljubnih poizvedb SQL, ki bi lahko povzročile obsežno pregledovanje tabel ali združevanje številnih tabel, Habitat ponuja preprost API NoSQL. Odsotnost zmogljivega API-ja je zavesten kompromis v zasnovi Habitata.

Optimizirati želimo preproste in predvidljive zahteve s stalnim obsegom dela. Po naših izkušnjah je takšne sisteme bistveno lažje razširjati, težko pa jih je napačno zasnovati ali zlorabiti. Zahteve z nepredvidljivim razvejanjem so operativno nevarne: otežujejo izolacijo in uravnoteženje obremenitve ter povzročajo nenadne skoke zakasnitve, ki jih je težko obvladovati tako za storitev kot za njene odjemalce.

Pred prehodom na Habitat in Azure Cosmos DB je bila večina spletnih podatkov OpenAI shranjena v Postgresu. Takrat je bilo pred uvedbo v produkcijo preprosto pregledati vse spremembe poizvedb in shem ter preveriti, ali se ustrezno obnašajo in uporabljajo indeksirane podatke. Z rastjo ekipe in izdelkov je to hitro postalo neobvladljivo in pogosto povzročalo izpade, saj je lahko ena sama nova draga poizvedba na pogosto uporabljeni poti onesposobila podatkovno zbirko.

Težava je v nesorazmerju stroškov: drage in težko izvedljive poizvedbe SQL je mogoče napisati poceni in preprosto. V Habitatu se temu izognemo, drage poizvedbe pa so odjemalcu povsem očitne. Ni neomejenih poizvedb, ki bi lahko preobremenile Habitat, zapletena združevanja in prehode po grafih pa od ekip izdelkov zahtevajo del zahtevnejšega dela, kar spodbuja učinkovitejše zasnove.

Habitat ponuja API NoSQL, zasnovan okoli vrst objektov in povezav, ki jih določijo odjemalci, po zgledu sistema TAO⁠(odpre se v novem oknu). Odjemalci vnaprej določijo objekte, povezave in njihove medsebojne odnose, ne pa vsebine posamezne vrste. Nastala razmerja spominjajo na graf, vendar Habitat ne podpira običajnih poizvedb za prehajanje po grafu, razen poizvedovanja po neposrednih povezavah določenega objekta.

Graf razdelimo tako, da so vsak objekt in njegove povezave skupaj v particiji na ravni shrambe, vendar objektov na ravni podatkovne zbirke ne poskušamo načrtno združiti z oddaljenimi objekti, na katere kažejo njihove povezave. Tako je model mogoče preprosto razdeliti za vodoravno razširljivost, prehajanje po grafu pa je neučinkovito, saj lahko vsak korak med objektoma zahteva pridobivanje podatkov iz dveh povsem različnih računov Azure Cosmos DB v različnih regijah.

Odjemalcem z zahtevnejšimi potrebami po poizvedovanju ponujamo tudi sekundarni pogled Habitata brez povezave, dostopen prek Rockseta. Z zajemanjem sprememb podatkov (CDC) spremembe iz spletne shrambe skoraj v realnem času pretakamo v izolirane primerke Rockseta. Vsaka odjemalska ekipa mora svoj primerek Rockseta prilagoditi obsegu zahtevnih poizvedb.

Zagotavljanje Rockseta odjemalcem prinaša dodatne ovire, vendar menimo, da je to trenutno pravi kompromis: preproste poizvedbe so privzete, tisti, ki potrebujejo zahtevne, pa imajo izhod v sili. Ta zasnova našo spletno shrambo izolira od analitičnih in iskalnih obremenitev z veliko branja.

Ker smo prepis Pythona odložili za eno leto, smo se lahko med izjemno hitro rastjo osredotočili na nujnejše in pomembnejše izzive. Ko je platforma dozorela, rast pa se je še pospeševala, je storitev postala druga največja v OpenAI po številu jeder in četrta po obsegu uporabe Envoya, zato je končno napočil čas za opustitev Pythona. Na vrhuncu nam je Python pomagal obdelati več kot 20 milijonov zahtev na sekundo.

V drugem četrtletju 2026 smo s samo dvema inženirjema, Codexom in GPT‑5.5 celotno storitev prepisali v Rust. Nova storitev Rust zdaj obdeluje 95 % naših produkcijskih zahtev; v prihodnjih tednih bomo Python povsem opustili. Naši podatki kažejo, da je storitev Rust šestkrat učinkovitejša pri uporabi CPE in petnajstkrat učinkovitejša pri uporabi pomnilnika kot različica Python, obenem pa ima bistveno krajše povprečne zakasnitve in zakasnitve na repu. Več spoznanj nameravamo predstaviti v prihodnji objavi.

Storitev Python, zdaj Rust, je le eden od vidikov Habitata. V drugem delu te serije o hitrem razširjanju spletne shrambe za več kot milijardo uporabnikov ChatGPT bomo predstavili plast shrambe ter pojasnili, kako Habitat zagotavlja več kot 500 petabajtov podatkov in obdela več kot 70 milijonov zahtev na sekundo.

Če želite delati na sistemih OLTP v prelomnem obsegu in vas zanima takšno inženirstvo, si oglejte prosto delovno mesto v naši ekipi⁠.