Verkkotallennuksen nopea skaalaus yli miljardille ChatGPT‑käyttäjälle

Kaikki OpenAI-tuotteet tarvitsevat nopean ja luotettavan pääsyn dataan, olipa käyttäjä kirjautumassa sisään, tarkistamassa Codex-asetuksiaan tai aloittamassa uutta keskustelua ChatGPT:ssä. Jokainen näistä toimista voi vaatia useita erillisiä tiedonhakuja ennen kuin tuote voi vastata. Jos pyynnöt ovat hitaita, tuote tuntuu hitaalta. Jos pyynnöt epäonnistuvat, tuote lakkaa kokonaan toimimasta.

Habitat on rakentamamme verkkotallennusalusta, jonka avulla OpenAI-tuotteet saavat tarvitsemansa tiedot nopeasti ja luotettavasti. Habitat käsittelee nyt yli 70 miljoonaa pyyntöä sekunnissa lähes 40 maantieteellisellä alueella ja tukee tuotteita, joita yli miljardi ihmistä käyttää viikoittain. Habitat julkaistiin alun perin GPT:iden tueksi DevDay 2023 -tapahtumassa. Se aloitti yksinkertaisena Python-asiakaskirjastona, joka oli yhdistetty yhteen tietokantaan. Nykyään se on monimutkainen hajautettu järjestelmä, joka palvelee yli 500 petatavua dataa.

Tämän mittakaavan infrastruktuurin rakentaminen ja käyttö ei ole helppoa, mutta ei myöskään erityisen haastavaa. Tilanteestamme teki ainutlaatuisen ennennäkemätön skaalausnopeus: meidän oli tuettava valtavaa käyttäjämäärän ja tuotekysynnän kasvua ja rakennettava samalla kypsä alusta. Järjestelmäinsinöörit suunnittelevat usein kymmenkertaista mittakaavaa varten ja toivovat sen riittävän muutamaksi vuodeksi seuraavaa kymmenkertaistumista valmisteltaessa. Meidän tapauksessamme kasvu on ollut yli kymmenkertaista vuodessa kolmen viime vuoden ajan. Siksi Habitatin rakentaminen ja käyttö on ollut sarja taktisia päätöksiä ja tarkkaa vaiheistusta: olemme perehtyneet jokaiseen osaan alimmalla tasolla saadaksemme nykyisestä pinosta kaiken irti ja torjuneet samalla tallennus- ja laskentakapasiteetin pullonkauloja saadaksemme aikaa perusinvestoinneille.

OpenAI:n kasvaessa Habitatin oli kasvettava mukana: ensin sen oli oltava riittävän luotettava kriittiselle tuoteliikenteelle, sitten riittävän nopea maailmanlaajuisille käyttäjille ja lopulta hallittava valtava mittakaava sujuvasti. Tämä kirjoitus on ensimmäinen osa verkkotallennuksemme skaalausta käsittelevästä kaksiosaisesta sarjasta. Kerromme, miten Habitat kehittyi, miksi muutimme sen kirjastosta palveluksi ja miten venytimme palvelinkäytössä epätavallisella Python-kielellä toteutetun palvelun luotettavaksi tallennusalustan kerrokseksi.

Tulevassa kirjoituksessa kerromme tarkemmin, miten toteutimme usean vuokraajan luotettavuuden suuressa mittakaavassa, miten optimoimme lukusuorituskykyä kerroksittain ja miten laajensimme Azure Cosmos DB -yhteistyötämme vastaamaan ennennäkemättömään kysyntään luotettavasti.

Habitat sai alkunsa yksinkertaisesta ajatuksesta: tuoteinsinöörien ei pitäisi joutua miettimään tietokannan hallintaa. Habitat julkaistiin alun perin GPT:iden tueksi DevDay 2023 -tapahtumassa pienenä Python-kirjastona, joka oli yhteydessä ChatGPT:n pääpalvelimeen. Se tuki pientä toimintojoukkoa, joka yhdistettiin taustalla Azure Cosmos DB -tietokantasovellukseen.

Kirjaston tehtävänä oli tarjota tuotetiimeille helppo tapa tallentaa ja hakea dataa ilman taustalla olevien yksityiskohtien hallintaa. Habitat hoiti tarvittavan työn: selvitti datan tyypin, lähteen tai kohteen, pyynnön sallittavuuden ja niin edelleen.

Tuoteinsinöörien ei tarvitse huolehtia skeeman hausta, reitityksestä, valtuutuksesta, salauksesta, sarjallistamisesta, pyyntöjen muotoilusta tai yhteyksien poolauksesta. Heidän ei tarvinnut edes miettiä, mistä data tulee: Azure Cosmos DB:stä, välimuisteista vai muunlaisesta tallennustilasta.

Python-kirjasto toimi hyvin, ja OpenAI:n tuoteinsinöörit omaksuivat Habitatin nopeasti, vaikka keskitetysti ei pyritty pois itsepalveluna käytetyistä Postgresista ja Azure Cosmos DB:stä.

Tuotetarpeiden kehittyessä tuotekehittäjien oli myös helppo lisätä yhteiseen kirjastoon tuki esimerkiksi asiakaspuolen välimuistille, pakkaukselle tai salaukselle.

Vuoden 2025 puoliväliin mennessä Habitat oli saavuttanut asiakaspuolen toteutuksensa rajat. Habitat-kerroksen monimutkaistuessa ja OpenAI:n palvelumäärän kasvaessa taaksepäin yhteensopivista protokollamuutoksista oli tullut mahdottomia.

Halusimme esimerkiksi pienentää yksittäisen aluekatkon vaikutusta kriittisimpiin tietojoukkoihimme siirtämällä ne alueellisesti hajautetuille Azure Cosmos DB -tileille. Muutos edellytti uuden reitityslogiikan lisäämistä asiakkaaseen pois käytöstä kytketyn ominaisuuslipun taakse, sen käyttöönottoa kaikilla asiakkailla ja lopuksi lipun ottamista käyttöön.

Kymmenien palvelujen julkaisujen koordinointi ja käyttöönotto kunkin tiimin kanssa vei päiviä. Ennen käyttöönottoa tajusimme haluavamme varjostaa pyyntöjä varmistaaksemme osituslogiikan oikeellisuuden. Sen käyttöönotto vei taas pari päivää. Entä havaitsemamme virheen korjaus? Taas pari päivää. Lopulta olimme valmiita ottamaan lipun käyttöön, mutta yksi tiimeistä palautti muista syistä palvelunsa aiempaan, virheelliseen asiakasversioon. Tämä aiheutti juuri sen katkon, jonka estämiseksi olimme nähneet paljon vaivaa.

Asiakaskirjaston muutokset vaativat monimutkaista koordinointia kymmenien palvelujen välillä. Prosessi osoittautui yhä hauraammaksi, tehottomammaksi ja alttiimmaksi toimintahäiriöille. Vähentääksemme tulevien julkaisujen toiminnallista hajautumista päätimme tehdä Habitatista oman palvelunsa.

Kun erotimme tallennuslogiikan itsenäiseksi palveluksi, saimme yhden hallintapisteen julkaisuille, havainnoitavuudelle ja alustan parannuksille. Hajanaisten päivitysten hallinnan sijaan pystyimme tekemään parannukset keskitetysti, jolloin jokainen OpenAI-tuote hyötyi niistä heti.

Keskitetty palvelu tarjoaa myös yhden valvontapisteen vahvimmille tietoturvan ja yksityisyyden perusratkaisuille. Habitat-palvelussa voimme valvoa keskitetysti käyttöoikeuskäytäntöjä, tehdä auditointilokitusta ja rajoittaa pääsyä Azure Cosmos DB:n kaltaisiin taustalla oleviin tallennusresursseihin. Habitat on ratkaisevan tärkeä käyttäjätietojen suojaamisessa sekä ulkoisten, sisäisten ja agenttitoimijoiden luvattoman pääsyn estämisessä.

Tiesimme tarvitsevamme palvelun, mutta emme vielä halunneet luopua Pythonista, vaikka sen käyttö palvelussa aiheutti lisärasitetta. Pythonin käyttö suuren suoritustehon palvelussa kasvatti verkkoviivettä sekä CPU- ja muistiskaalauksen kustannuksia verrattuna kirjaston paikalliseen suorittamiseen. Lisäksi tiesimme, etteivät Pythonin tehottomuudet olisi hyväksyttäviä satakertaisessa mittakaavassa, joten uudelleenkirjoitus olisi lähes väistämätön.

Pidimme tätä kuitenkin strategisena teknisen velan ottamisena. Tärkein tavoitteemme ei tuolloin ollut kustannusten tai resurssien optimointi, vaan tuotekehittäjien esteiden poistaminen ja alustan vakaus. Hyväksymällä Python-palvelun suorituskykykompromissit lyhyellä aikavälillä pystyimme keskittymään kiireellisempiin haasteisiin, vakiinnuttamaan keskeiset rajapintamme ja rakentamaan kestävän infrastruktuurin.

Luotimme harkitusti myös siihen, että omien koodausmalliemme nopea kehitys helpottaisi teknistä toteutusta tulevaisuudessa. Uskoimme, että kun täydellinen siirtyminen pois Pythonista tulisi ajankohtaiseksi, Codex ja GPT tekisivät siitä toteuttamiskelpoisen. Olimme lopulta oikeassa.

Habitatin käyttäminen Python-palveluna ei olisi suorituskyvyn kannalta ihanteellista, mutta se oli välttämätön valinta. Python auttaa meitä etenemään nopeasti, mutta emme silti voineet unohtaa varovaisuutta ja hyväksyä merkittävästi suurempia viiveitä. Kun tavallinen käyttäjäpyyntö johtaa satoihin tietokantakutsuihin, käyttäjä huomaa niistä hitaimman. Olemme havainneet, että tämän mittakaavan Python-palvelun suurin haaste on häntäviiveiden hallinta.

Asyncio auttaa Pythonia suorittamaan I/O-painotteisia työkuormia samanaikaisesti, mutta se ei kierrä Pythonin GIL-lukkoa eikä mahdollista CPU-rinnakkaisuutta. I/O-painotteisen pyyntöjen välityksen lisäksi Habitat hoitaa monia CPU-raskaita tehtäviä ja taustatöitä: reititystä, pakkausta, salausta, tarkistussummia, jatkopalvelujen kuntotarkistuksia sekä pyyntöjen varjostusta ja suojaavaa rinnakkaistamista.

Kun palvelussa on näin paljon CPU-raskaita työkuormia ja taustatöitä, asynicion ajoitusviive voi helposti hallita pyyntöjen häntäviivettä. Ennen ensimmäisen julkaisun optimointia havaitsimme p99-viiveen ylittävien pyyntöjen jäljistä, että vaikka jatkotallennus vastasi nopeasti, pyynnöt pysähtyivät usein odottamaan vastausta jäsentävän vuorottelualiohjelman uutta suoritusvuoroa.

OpenAI:n Python-palveluissa muistin, CPU:n, verkon ja levyn tavanomaisten käyttö- ja kyllästymismittareiden lisäksi on ratkaisevan tärkeää seurata asyncio-silmukkaa ja sen kuormitusta sekä säätää järjestelmää sen mukaan.

Ajastamalla taustatehtäviä säännöllisesti ja kirjaamalla odotetun ja toteutuneen suoritusajan eron voimme mitata tapahtumasilmukan ajoitusviivettä empiirisesti reaaliajassa. Suurella käyttöasteella ja monien raskaiden tehtävien aikana jo melko pieni määrä samanaikaisia pyyntöjä prosessia kohden aiheuttaa merkittävää ajoitusvaihtelua: jopa satoja millisekunteja ja joissakin ääritapauksissa useita sekunteja.

Siksi kukin prosessi palvelee vain pientä määrää samanaikaisia pyyntöjä, ja kasvatamme sen sijaan Python-työprosessien määrää erittäin voimakkaasti.

Ensimmäisen julkaisun aikana löysimme tuotantopalvelun CPU-profiloinnilla yhden syyn asynicion suureen viiveeseen ja siitä johtuviin häntäviiveisiin: Statsig jäsensi ominaisuuslippuasetustemme JSON-tiedot säännöllisesti. Statsig on ominaisuuslippujen hallintaan, A/B-testeihin ja muuhun käytettävä työkalu.

Statsig oli oletusarvoisesti määritetty hakemaan päivitetyt asetukset minuutin välein ilman ajoitushajontaa, ja asetukset sisälsivät kaikkien palvelujen kaikki tuotantosäännöt. Muualla oli tehty arkkitehtuuripäätös käyttää kussakin podissa enintään kahdeksaa Python-prosessia CPU:n käyttöasteen nostamiseksi ja viiveiden pienentämiseksi. Yhdessä tämä tarkoitti, että jokaisen podin kaikki työprosessit keskeyttivät kerran minuutissa käynnissä olevien pyyntöjen käsittelyn ja käyttivät CPU-aikansa valtavan asetustiedoston jäsentämiseen.

Kun CPU-profilointi oli auttanut löytämään perussyyn, korjaus oli suoraviivainen: otimme käyttöön pienemmän, kohdennetun asetuskokonaisuuden, pidensimme päivitysväliä ja lisäsimme tällaisiin taustatehtäviin ajoitushajontaa.

Asynicion viiveen pitämiseksi pienenä pyynnöt on myös tasattava hyvin palvelinprosessien kesken. Ilman säätämistä yhteyspoolaus voi toimia tätä vastaan.

Asiakaspuolen yhteyspoolauksessa paljon samanaikaisia pyyntöjä tekevä yksittäinen asiakasprosessi saattaa muodostaa vain muutaman palvelinyhteyden ja kohdistaa siksi kaiken kuormansa vain muutamaan prosessiin. Ennen kuormantasauksen muuttamista palvelumme käyttöaste vaihteli paljon: jotkin ääripään prosessit käsittelivät 5–10 kertaa keskiarvoa enemmän samanaikaisia pyyntöjä.

Havaitsimme tämän sattumalta häiriössä, jossa osa prosesseista pysyi heikentyneenä pitkään liikennepurskeen jälkeen, vaikka palvelumme osaa ylikuormittanut asiakas oli pysäytetty. Prosessien tila itse asiassa heikkeni hallitsemattomasti ja ne saivat yhä enemmän pyyntöjä, kunnes käynnistimme ne uudelleen. Kun podi ylikuormittui, jokin toiminta ohjasi sille yhä enemmän liikennettä. Osa tiimiläisistämme tunsi tämän vikatilaluokan aiemmasta työstään: metastabiili vika⁠(avautuu uudessa ikkunassa).

Epäilimme yhteysvarantoa ja testasimme asiaa rajoittamalla yhteyden uudelleenkäytön enimmäiskestoa. Se hillitsi heikkenemistä ja vahvisti tutkimussuuntamme oikeaksi. Lisätutkimuksissa selvisi, että Pythonin aiohttp TCPConnector käyttää oletusarvoisesti LIFO-yhteyksien uudelleenkäyttöä: seuraavaan pyyntöön valitaan viimeksi palautettu yhteys. Tämä on yleensä järkevä oletus: uusien yhteyksien käyttö antaa purskeliikenteeseen luotujen lisäyhteyksien vanhentua joutilaina ja vähentää niiden ylläpidon rasitetta. Tässä tapauksessa se aiheutti meille metastabiilin vian. Pyyntöpurskeen aikana hitaammille, ylikuormitetuille palvelimille lähetettyjen pyyntöjen yhteydet palautuivat pooliin myöhemmin. Siksi myöhemmät pyynnöt valitsivat niitä useammin ja keskittivät vähitellen lisää liikennettä jo vaikeuksissa oleville podeille. Yhteysvarannon muuttaminen käyttämään FIFO-uudelleenkäyttöä katkaisi takaisinkytkennän ja pienensi myös pyyntömäärän vaihtelua vakaassa tilassa.

Nykyään käytämme OpenAI:n infrastruktuurissa pääasiassa Istioa ja Envoyta yhteyspoolaukseen ja palvelinkuorman paremmin huomioiviin tasausstrategioihin, jolloin vältämme ongelman kokonaan.

Asynicion pientä viivettä varten tehtyjen säätöjen ja Python-prosessien suuren määrän sivuvaikutuksena jatkopalvelut on erittäin helppo hukuttaa valtavaan yhteysmäärään. Ilmiö tunnetaan nimellä ”jyrisevä lauma”.

Tavallinen päivittäinen julkaisu voi aiheuttaa yhteyksien kierrätyksestä merkittävää CPU-kuormituksen vaihtelua, ellei sitä ole säädetty hitaaksi. Yhteysvuoto voi puolestaan kaataa verkon kyllästämällä NAT-yhdyskäytävän. Nämä ongelmat eivät ole harvinaisia muissakaan palveluissa, mutta kymmenkertainen prosessimäärä madaltaa niiden syntymiskynnystä huomattavasti. Se kyllästää usein verkkoresursseja, joita asiakkaat eivät pelkän suoritustehon perusteella odota joutuvansa käsittelemään vakaassa tilassa.

Käytämme Envoyta myös yhteyksien yhdistämisen maksimointiin. Sen avulla päivitämme Pythonin HTTP/1-yhteydet HTTP/2:een hyödyntääksemme multipleksointia, minkä jälkeen poolaamme yhteydet ja pidennämme niiden käyttöikää. Envoy tarjoaa myös keskitetyn paikan toteuttaa nopeusrajoitukset ja virtakatkaisimet, jotka olisivat vähemmän tehokkaita erillisissä Python-prosesseissa.

Pystyimme skaalaamaan Pythonin näin pitkälle osittain Habitatin rajatun rajapinnan ansiosta, sillä se pitää pyyntöjen kustannukset ennakoitavina. Habitat ei anna asiakkaiden muodostaa mielivaltaisia SQL-kyselyjä, jotka voisivat lukea laajoja tauluja tai yhdistää useita tauluja, vaan tarjoaa yksinkertaisen NoSQL-rajapinnan. Tehokkaan rajapinnan puuttuminen on Habitatin suunnittelussa tietoinen kompromissi.

Optimoimme yksinkertaisia, ennakoitavia ja työmäärältään vakioita pyyntöjä varten. Kokemuksemme mukaan tällaisia järjestelmiä on huomattavasti helpompi skaalata ja vaikea käyttää väärin. Ennakoimattomasti haarautuvat pyynnöt ovat toiminnallisesti vaarallisia: ne vaikeuttavat eristystä ja kuormantasausta sekä aiheuttavat äkillisiä viivepiikkejä, joihin sekä palvelun että sen asiakkaiden on vaikea skaalautua.

Ennen siirtymistä Habitatiin ja Azure Cosmos DB:hen suurin osa OpenAI:n verkkodatasta tallennettiin Postgresiin. Tuolloin kaikki kysely- ja skeemamuutokset oli helppo tarkistaa ennen tuotantoon vientiä ja varmistaa, että ne toimivat asianmukaisesti indeksoidulla datalla. Tiimin ja tuotteiden kasvaessa tästä tuli nopeasti hallitsematonta. Yksi uusi, raskas kysely vilkkaalla suorituspolulla saattoi kaataa tietokannan ja aiheutti usein käyttökatkoja.

Ongelma on kustannusten epätasapaino: kalliisti ja vaikeasti suoritettavia SQL-kyselyjä on halpaa ja helppoa kirjoittaa. Habitatissa vältämme tämän ja teemme raskaista kyselyistä erittäin ilmeisiä asiakaspuolella. Habitatia ei voi ylikuormittaa rajaamattomilla kyselyillä. Monimutkaiset liitokset ja graafien läpikäynnit edellyttävät tuotetiimeiltä osan raskaasta työstä, mikä ohjaa kokonaisuutta tehokkaampiin ratkaisuihin.

Habitat tarjoaa asiakkaan määrittämiin objekti- ja kaarityyppeihin perustuvan NoSQL-rajapinnan, jonka esikuvana on TAO⁠(avautuu uudessa ikkunassa). Asiakkaat määrittävät objektit ja kaaret sekä niiden suhteet ennalta, mutta eivät kunkin tyypin sisältöä. Syntyvät suhteet muistuttavat graafia, mutta Habitat ei tue tyypillisiä graafien läpikäyntikyselyjä tietyn objektin suorien kaarien kyselyä lukuun ottamatta.

Osioimme graafin niin, että jokainen objekti ja sen kaaret sijaitsevat samassa tallennustason osiossa. Emme kuitenkaan pyri tietokantatasolla sijoittamaan samaan paikkaan objekteja ja etäobjekteja, joihin niiden kaaret osoittavat. Näin malli on helppo osioida vaakasuuntaista skaalausta varten, mutta graafin läpikäynti on tehotonta, koska yksikin siirtymä objektien välillä voi vaatia noutoja kahdelta täysin eri alueilla sijaitsevalta Azure Cosmos DB -tililtä.

Monimutkaisempia kyselyjä tarvitseville asiakkaille tarjoamme Habitatista myös Rocksetin kautta käytettävän toissijaisen offline-näkymän. Suoratoistamme muutokset verkkotallennuksesta erillisiin Rockset-instansseihin lähes reaaliajassa muutosdatan tallennuksen (CDC) avulla. Kukin asiakastiimi vastaa oman Rockset-instanssinsa skaalaamisesta monimutkaisia kyselytarpeitaan varten.

Rocksetin käyttöönotto aiheuttaa asiakkaillemme lisävaivaa, mutta pidämme sitä tässä vaiheessa oikeana kompromissina: yksinkertaiset kyselyt ovat oletus, mutta monimutkaisia kyselyjä tarvitseville on vaihtoehto. Tämä rakenne eristää verkkotallennuksemme runsaasti lukevista analytiikka- ja hakutyökuormista.

Python-uudelleenkirjoituksen lykkääminen vuodella antoi meille mahdollisuuden keskittyä hyperkasvun aikana kiireellisempiin ja vaikuttavampiin haasteisiin. Alustan kypsyessä ja kasvun yhä kiihtyessä oli lopulta aika siirtyä Pythonista eteenpäin. Palvelumme oli OpenAI:n toiseksi suurin ydinmäärällä mitattuna ja Envoy-laajuudeltaan neljänneksi suurin. Parhaimmillaan Python auttoi meitä käsittelemään yli 20 miljoonaa pyyntöä sekunnissa.

Vuoden 2026 toisella neljänneksellä vain kaksi insinööriä pystyi Codexin ja GPT‑5.5:n avulla kirjoittamaan koko palvelun uudelleen Rustilla. Uusi Rust-palvelu käsittelee nyt 95 prosenttia tuotantopyynnöistämme, ja poistamme Pythonin kokonaan käytöstä lähiviikkoina. Datamme mukaan Rust-palvelu käyttää CPU:ta kuusi kertaa ja muistia 15 kertaa tehokkaammin kuin Python-versio. Myös keskimääräiset viiveet ja häntäviiveet ovat merkittävästi pienempiä. Aiomme jakaa lisää oppeja tulevassa blogikirjoituksessa.

Pythonilla ja nykyään Rustilla toteutettu palvelu on vain yksi Habitatin osa. Yli miljardia ChatGPT‑käyttäjää palvelevan verkkotallennuksemme nopeaa skaalausta käsittelevän sarjan toisessa osassa kerromme tallennuskerroksesta sekä siitä, miten Habitat käsittelee yli 500 petatavua dataa ja yli 70 miljoonaa pyyntöä sekunnissa.

Jos haluat työskennellä edistyneen mittakaavan OLTP-järjestelmien parissa ja tällainen suunnittelu kiinnostaa sinua, tutustu tiimimme avoimeen tehtävään⁠.