Netgeymsla sköluð hratt fyrir yfir 1 milljarð ChatGPT‑notenda

Allar vörur OpenAI reiða sig á skjótan og áreiðanlegan aðgang að gögnum, hvort sem einhver skráir sig inn, skoðar Codex-stillingar sínar eða hefur nýtt samtal í ChatGPT. Hver þessara aðgerða getur krafist margra aðskildra gagnauppflettinga áður en varan getur svarað. Ef þessar beiðnir eru hægar virðist varan hæg. Ef beiðnirnar bregðast hættir varan alveg að virka.

Habitat er netgeymsluverkvangurinn sem við byggðum svo vörur OpenAI gætu nálgast nauðsynlegar upplýsingar hratt og örugglega. Habitat afgreiðir nú meira en 70 milljónir beiðna á sekúndu og styður vörur sem yfir einn milljarður manna notar vikulega á nær 40 landsvæðum. Habitat var fyrst sett í loftið til að styðja GPTs á DevDay 2023, upphaflega sem einfalt Python-biðlarasafn tengt einum gagnagrunni. Í dag er þetta flókið dreift kerfi sem afgreiðir meira en 500 petabæti af gögnum.

Það er ekkert áhlaupaverk að byggja og reka innviði í þessu umfangi, en heldur ekki sérstaklega krefjandi. Það sem gerði stöðu okkar einstaka var fordæmalaus hraðinn sem við þurftum að skala á til að mæta gríðarlegri fjölgun notenda og eftirspurn eftir vörum, um leið og við byggðum upp fullþroskaðan verkvang. Kerfisverkfræðingar byggja oft fyrir tífalt umfang og vona að það dugi í nokkur ár meðan þeir undirbúa næstu tíföldun. Hjá okkur hefur umfangið meira en tífaldast milli ára síðustu þrjú árin. Uppbygging og rekstur Habitat hefur því falist í röð taktískra ákvarðana og réttri tímasetningu: að skilja hvern íhlut niður í smæstu atriði til að nýta núverandi tæknistafla til hins ýtrasta, um leið og við vörðumst skorti á geymslu- og reiknigetu til að vinna tíma fyrir grunnfjárfestingar.

Þegar OpenAI óx þurfti Habitat að vaxa með: fyrst að verða nógu áreiðanlegt fyrir rekstrarlega mikilvæga vöruumferð, síðan nógu hratt fyrir notendur um allan heim og loks að geta starfað lipurlega í gríðarlegu umfangi. Þessi færsla er sú fyrri af tveimur um hvernig við sköluðum netgeymslu. Hér segjum við frá þróun Habitat, hvers vegna við breyttum því úr safni í þjónustu og hvernig við teygðum þjónustu skrifaða á Python — óvenjulegu tungumáli fyrir þjónustulag — yfir í áreiðanlegt geymsluverkvangslag.

Í síðari færslu förum við ítarlega yfir hvernig við tryggðum áreiðanleika fjölleigjuhýsingar í stórum skala, lagskipta stefnu okkar til að bæta lestrarafköst og hvernig við sköluðum samstarfið við Azure Cosmos DB til að anna fordæmalausri eftirspurn á áreiðanlegan hátt.

Habitat varð til út frá einfaldri hugmynd: vöruverkfræðingar ættu ekki að þurfa að hafa áhyggjur af gagnagrunnsstjórnun. Habitat var fyrst tekið í notkun til að styðja við GPTs á DevDay 2023. Þá var það lítið Python-safn sem hafði samskipti við aðalþjón ChatGPT og studdi aðeins fáeinar aðgerðir sem undir yfirborðinu kölluðu á samsvarandi aðgerðir í Azure Cosmos DB.

Hlutverk safnsins var að veita vöruteymum einfalda leið til að geyma og sækja gögn án þess að þurfa að ná valdi á undirliggjandi smáatriðum. Habitat sá um nauðsynlegu vinnuna: að greina tegund gagnanna, hvaðan þau ættu að koma eða hvert þau ættu að fara, hvort beiðnin væri heimil og fleira.

Vöruverkfræðingar þurfa ekki að hafa áhyggjur af skemauppflettingu, leiðarstýringu, heimildum, dulkóðun, raðgerð, mótun beiðna eða tengingasöfnun. Þeir þurftu ekki einu sinni að velta fyrir sér hvaðan gögnin kæmu: úr Azure Cosmos DB, skyndiminni eða annars konar geymslu.

Python-safnið virkaði vel og Habitat náði hratt útbreiðslu meðal vöruverkfræðinga hjá OpenAI, þótt engin samræmd miðlæg stefna væri um að hverfa frá sjálfsafgreiðslu í Postgres og Azure Cosmos DB.

Þegar þarfir varanna þróuðust gátu vöruþróunaraðilar jafnvel auðveldlega bætt stuðningi við eiginleika á borð við skyndiminni hjá biðlara, þjöppun eða dulkóðun í sameiginlega safnið.

Um mitt ár 2025 hafði Habitat náð takmörkum sínum sem útfærsla hjá biðlara. Eftir því sem Habitat-lagið varð flóknara og þjónustum OpenAI fjölgaði urðu afturvirkt samhæfar breytingar á samskiptareglum óframkvæmanlegar.

Í einu tilviki vildum við draga úr áhrifasvæði bilunar á einu svæði fyrir mikilvægustu gagnasöfnin með því að flytja þau yfir á Azure Cosmos DB-reikninga sem dreifðust milli svæða. Breytingin krafðist viðbótarleiðarstýringar í biðlaranum, óvirkrar á bak við eiginleikafána, síðan dreifingar til allra biðlara og loks virkjunar fánans.

Það tók marga daga að samræma dreifingu í tugum þjónusta og vinna með hverju teymi að innleiðingunni. Áður en við virkjuðum þetta áttuðum við okkur á að við vildum bæta við skuggakeyrslu til að tryggja að sneiðingarfræðin væri rétt. Það tók tvo daga í viðbót að dreifa henni. Villuleiðrétting þegar við áttuðum okkur á að eitthvað var rangt? Tveir dagar í viðbót. Að lokum vorum við tilbúin að virkja fánann, en þá afturkallaði eitt teymið þjónustu sína af ótengdum ástæðum yfir í eldri, gallaðan biðlara og olli einmitt biluninni sem við höfðum lagt svo hart að okkur við að forðast.

Breytingar á biðlarasafninu kröfðust flókinnar samræmingar milli tuga þjónusta, ferlis sem varð sífellt brothættara, óskilvirkara og viðkvæmara fyrir rekstrarbilunum. Til að draga úr þessari rekstrardreifingu við síðari dreifingar ákváðum við að gera Habitat að sjálfstæðri þjónustu.

Með því að aðskilja geymslurökfræðina í sjálfstæða þjónustu komum við á einum stjórnpunkti fyrir dreifingu, sýnileika og endurbætur á verkvanginum. Í stað þess að halda utan um sundurlausar uppfærslur gátum við innleitt endurbætur miðlægt svo allar vörur OpenAI nytu þeirra strax.

Miðlæg þjónusta veitir okkur einnig einn þrengipunkt þar sem við getum boðið öflugustu grunnvirkni fyrir gagnaöryggi og persónuvernd. Í Habitat-þjónustunni getum við framfylgt aðgangsstýringarstefnum miðlægt, skráð úttektarslóð og takmarkað aðgang að undirliggjandi geymsluauðlindum á borð við Azure Cosmos DB. Habitat gegnir lykilhlutverki í vernd notendagagna og kemur í veg fyrir óheimilan aðgang utanaðkomandi, innri aðila og gervigreindarfulltrúa.

Við vissum að við þyrftum þjónustu en vildum ekki strax færa okkur frá Python, þrátt fyrir viðbótarkostnaðinn sem fylgir því að nota Python í þjónustu. Notkun Python fyrir þjónustu með mikil afköst jók netbið og leiddi til mun meiri CPU- og minniskostnaðar við skölun en keyrsla staðbundins safns. Við gerðum okkur einnig grein fyrir að óhagkvæmni Python yrði óviðunandi við hundraðfalt umfang og því væri endurskrifun að lokum nær óhjákvæmileg.

Við litum þó á þetta sem markvissa tímabundna tækniskuld. Meginmarkmið okkar þá var ekki að hagræða kostnaði eða auðlindanotkun heldur að greiða götu vöruþróunaraðila og tryggja stöðugleika verkvangsins. Með því að sætta okkur tímabundið við afkastaskerðingu Python-þjónustu gátum við forgangsraðað brýnni áskorunum, mótað grunn-API okkar og byggt upp trausta innviði.

Við tókum einnig meðvitaða áhættu í þeirri trú að hröð þróun eigin forritunarlíkana myndi einfalda tæknilegu leiðina síðar. Við gerðum ráð fyrir að þegar nauðsynlegt yrði að færa kerfið að fullu úr Python myndu Codex og GPT gera slíkan flutning raunhæfan. Sú forsenda reyndist að lokum rétt.

Að keyra Habitat sem Python-þjónustu væri ekki ákjósanlegt út frá afköstum en engu að síður nauðsynlegt. Python gerir okkur kleift að vinna hratt, en það þýddi ekki að við gætum horft fram hjá afkastakröfum og sætt okkur við verulega lengri biðtíma. Þegar meðalbeiðni frá notanda kallar á hundruð fyrirspurna í gagnagrunn ræðst upplifun notandans að miklu leyti af þeim hægustu. Reynsla okkar sýnir að helsta áskorunin við að reka Python-þjónustu af þessari stærðargráðu er að halda verstu biðtímunum í skefjum.

Asyncio gerir Python kleift að vinna samtímis úr I/O-bundnu álagi en kemst ekki fram hjá Python GIL og veitir ekki samhliða CPU-vinnslu. Auk framsendingar I/O-þungra beiðna sinnir Habitat mörgum CPU-þungum verkefnum og bakgrunnsverkum: leiðarstýringu, þjöppun, dulkóðun, gátsummum, heilsuprófun niðurstreymisþjónusta, skuggabeiðnum og varabeiðnum.

Þar sem þjónustan sinnir svo mörgum CPU-þungum verkefnum og bakgrunnsverkum getur töf í verkáætlun asyncio auðveldlega orðið ráðandi þáttur í biðtíma hægustu beiðnanna. Áður en við fínstilltum kerfið fyrir fyrstu útgáfu þjónustunnar sáum við í rakningargögnum fyrir beiðnir með p99-biðtíma eða lengri að þótt niðurstreymisgeymslan svaraði hratt stöðvuðust beiðnir oft meðan beðið var eftir að viðkomandi coroutine fengi aftur keyrslutíma til að vinna úr svarinu.

Fyrir Python-þjónustur hjá OpenAI teljum við nauðsynlegt að fylgjast ekki aðeins með hefðbundnum mælingum á nýtingu og mettun minnis, CPU, nets og disks, heldur einnig með asyncio-lykkjunni og álagi hennar og fínstilla í samræmi við það.

Með því að tímasetja bakgrunnsverk reglulega og skrá muninn á væntum og raunverulegum keyrslutíma getum við mælt töf á verkáætlun atburðalykkjunnar í rauntíma með reynslugögnum. Við mikla nýtingu og mörg kostnaðarsöm verk nægir jafnvel hóflegur fjöldi samtímabeiðna á hvert ferli til að valda verulegu tímaflökti, allt að hundruðum millisekúndna og í sumum jaðartilvikum nokkrum sekúndum.

Því látum við hvert ferli aðeins afgreiða fáar samtímabeiðnir en fjölgum Python-vinnsluferlunum gríðarlega.

Við fyrstu útgáfu þjónustunnar komumst við, með greiningu á CPU-notkun þjónustunnar í rekstri, að einni meginorsök mikilla tafa í asyncio (og þar af leiðandi langs biðtíma hjá hægustu beiðnunum): reglulegri úrvinnslu JSON-gagna úr stillingum eiginleikafána í gegnum Statsig (verkfæri sem heldur utan um eiginleikafána og má meðal annars nota til að framkvæma A/B-prófanir).

Sjálfgefið var Statsig stillt til að sækja endurnýjaðar stillingar á hverri mínútu án tímaflökts, og stillingarnar innihéldu allar framleiðslureglur fyrir allar þjónustur. Annars staðar hafði verið ákveðið að keyra allt að átta Python-ferli í hverjum pod til að auka CPU-nýtingu og stytta bið. Samanlagt þýddi þetta að á hverri mínútu kom augnablik þar sem allir vinnsluferlar hvers pods stöðvuðu vinnslu virkra beiðna og vörðu CPU-lotum sínum í að þátta risastóra stillingaskrá.

Lausnin var einföld eftir að CPU-prófílgreiningin leiddi orsökina í ljós: dreifa minni og markvissari stillingum, lengja endurnýjunarbilið og bæta tímaflökti við slík bakgrunnsverk.

Til að halda asyncio-töf lágri er einnig mikilvægt að dreifa beiðnaálagi jafnt milli þjónsferla; án fínstillingar getur tengingasöfnun unnið gegn því.

Með tengingasöfnun hjá biðlara gæti eitt biðlaraferli sem sendir margar samtímabeiðnir aðeins stofnað fáeinar þjónstengingar og því sent allt álag sitt á örfá ferli. Áður en við breyttum álagsjöfnuninni var nýting þjónustunnar mjög breytileg og sum ferli með mest álag afgreiddu 5-10 sinnum fleiri samtímabeiðnir en að meðaltali.

Við uppgötvuðum þetta fyrir tilviljun þegar hluti ferlanna hélt áfram að starfa með skerta afkastagetu löngu eftir álagslotuna, þótt biðlarinn sem hafði yfirhlaðið hluta þjónustunnar hefði verið stöðvaður. Við tókum meira að segja eftir því að ástand þessara ferla versnaði stöðugt og þau fengu sífellt fleiri beiðnir þar til við endurræstum þau. Þegar pod varð yfirhlaðinn olli einhver hegðun því að enn meiri umferð beindist að yfirhlaðna podinu. Þetta var tegund bilunar sem sumir samstarfsmenn okkar þekktu vel úr fyrri störfum: hálfstöðug bilun⁠(opnast í nýjum glugga).

Okkur grunaði að tengingasafnið ætti sök og prófuðum það með því að setja hámark á endurnotkunartíma tenginga. Það takmarkaði skerðinguna og staðfesti að við værum á réttri leið. Frekari rannsókn sýndi að aiohttp TCPConnector í Python notar sjálfgefið LIFO-endurnotkun tenginga: tengingin sem skilaði sér síðast er valin fyrir næstu beiðni. Þetta er yfirleitt skynsamleg sjálfgefin stilling: endurnotkun nýlegra tenginga gerir aukatengingum sem stofnaðar voru vegna álagslotu kleift að renna út vegna aðgerðaleysis og dregur úr kostnaði við að halda þeim við. Í þessu tilviki skapaði hún hálfstöðuga bilun hjá okkur. Í álagslotu skiluðu beiðnir til hægari, yfirhlaðinna þjóna tengingum seinna í safnið og síðari beiðnir völdu þær því oftar, svo umferðin safnaðist smám saman enn frekar á podana sem þegar áttu í erfiðleikum. Með því að breyta tengingasafninu yfir í FIFO-endurnotkun rufum við endurgjafarlykkjuna og drógum jafnframt úr breytileika beiðna í stöðugu ástandi.

Í dag reiðum við okkur að mestu á Istio og Envoy til að sjá um tengingasöfnun og betri álagsjöfnun sem tekur mið af álagi þjóna um alla innviði OpenAI og forðumst þannig vandann alveg.

Ein afleiðing þess að fínstilla fyrir litla asyncio-töf og keyra svo mörg Python-ferli er að mjög auðvelt verður að yfirbuga niðurstreymisþjónustur með gríðarlegum fjölda tenginga (svokallaðri „þrumandi hjörð“).

Venjuleg dagleg dreifing getur valdið verulegu CPU-álagi vegna endurnýjunar tenginga ef hún er ekki stillt til að ganga hægt. Eða tengingaleki getur slegið netið út með því að metta NAT-gáttina. Þessi vandamál eru ekki óalgeng í öðrum þjónustum heldur, en þröskuldurinn lækkar verulega þegar ferlin eru tífalt fleiri. Þá mettast oft nettengdar auðlindir sem biðlarar búast ekki við að þurfa að anna í stöðugu ástandi ef aðeins er miðað við afköst.

Við reiðum okkur einnig á Envoy til að hámarka sameiningu tenginga. Við notum Envoy til að uppfæra HTTP/1-tengingar Python í HTTP/2 svo nýta megi fléttun, safna síðan tengingunum saman og lengja líftíma þeirra. Envoy veitir okkur einnig miðlægan stað til að innleiða hraðatakmarkanir og rofa sem væru síður skilvirkir í hverju sjálfstæðu Python-ferli.

Ein ástæða þess að við gátum skalað Python svona langt var takmarkað API Habitat, sem heldur kostnaði beiðna fyrirsjáanlegum. Í stað þess að leyfa biðlurum að smíða SQL-fyrirspurnir að vild sem gætu leitt til víðtækrar töfluleitar eða samtenginga margra taflna býður Habitat einfalt NoSQL-API. Skortur á öflugu API er meðvituð málamiðlun í hönnun Habitat.

Við fínstillum fyrir einfaldar, fyrirsjáanlegar beiðnir með föstu vinnumagni. Reynsla okkar er að mun auðveldara sé að skala slík kerfi og erfitt að nota þau rangt. Beiðnir með ófyrirsjáanlega dreifingu eru hættulegar í rekstri: þær flækja einangrun og álagsjöfnun og skapa skyndileg stökk í biðtíma sem erfitt er að skala bæði fyrir þjónustuna og biðlara hennar.

Áður en við færðum okkur yfir í Habitat og Azure Cosmos DB voru flest netgögn OpenAI geymd í Postgres. Þá var auðvelt að yfirfara allar breytingar á fyrirspurnum og skemum og ganga úr skugga um að þær hegðuðu sér vel og ynnu með atriðaskráð gögn áður en þær fóru í framleiðslu. Þegar teymið og vörurnar stækkuðu varð þetta fljótt óviðráðanlegt og olli oft bilunum þegar ein ný, kostnaðarsöm fyrirspurn á fjölfarinni leið sló gagnagrunninn út.

Vandinn er kostnaðarójafnvægi: ódýrt og auðvelt er að skrifa SQL-fyrirspurnir sem eru dýrar og erfiðar í keyrslu. Í Habitat komum við í veg fyrir þetta og gerum kostnaðarsamar fyrirspurnir afar augljósar hjá biðlaranum. Engar ótakmarkaðar fyrirspurnir geta yfirhlaðið Habitat, og flóknar samtengingar og grafyfirferðir krefjast þess að vöruteymin vinni hluta erfiðisins, sem stuðlar almennt að skilvirkari hönnun.

Habitat býður NoSQL-API sem byggist á tegundum hluta og tenginga skilgreindum af biðlara og sækir innblástur í TAO⁠(opnast í nýjum glugga). Biðlarar forskilgreina hluti og tengingar og hvernig þau tengjast innbyrðis, en ekki innihald hverrar tegundar. Venslin sem þannig myndast líkjast grafi, en Habitat styður ekki hefðbundnar fyrirspurnir sem rekja sig um grafið, aðrar en fyrirspurnir um beinar tengingar tiltekins hlutar.

Við skiptum grafinu þannig að hver hlutur og tilheyrandi tengingar séu saman í sömu geymslusneið, en reynum ekki markvisst á gagnagrunnsstigi að hafa hluti nálægt fjartengdum hlutum sem tengingarnar vísa á. Þannig má auðveldlega sneiða líkanið fyrir lárétta skölun, en grafyfirferðir eru óskilvirkar þar sem hvert stökk milli hluta getur krafist gagna frá tveimur gjörólíkum Azure Cosmos DB-reikningum í ólíkum svæðum.

Fyrir biðlara með flóknari fyrirspurnaþarfir bjóðum við þó ótengda aukasýn af Habitat í gegnum Rockset. Við notum breytingaföngun gagna (CDC) til að streyma breytingum úr netgeymslunni í einangruð Rockset-tilvik nánast í rauntíma. Hvert biðlarateymi ber ábyrgð á að skala eigið Rockset-tilvik eftir þörfum sínum fyrir flóknar fyrirspurnir.

Þessi uppsetning Rockset skapar viðbótarfyrirstöðu fyrir biðlarana, en við teljum hana rétta málamiðlun núna: einfaldar fyrirspurnir eru sjálfgefnar en undankomuleið er í boði fyrir þá sem þurfa flóknar fyrirspurnir. Þessi hönnun einangrar netgeymsluna okkar frá lestrarþungu greiningar- og leitarálagi.

Með því að fresta endurskrifun úr Python um eitt ár gátum við einbeitt okkur að brýnni og mikilvægari verkefnum á meðan vöxturinn var hvað hraðastur. Nú hafði verkvangurinn náð meiri þroska og vöxturinn hélt áfram að aukast. Þjónustan var jafnframt orðin sú næststærsta hjá OpenAI miðað við fjölda örgjörvakjarna (og sú fjórða stærsta miðað við umfang Envoy). Því var loks kominn tími til að færa sig frá Python. Þegar mest lét gerði Python okkur kleift að afgreiða meira en 20 milljónir beiðna á sekúndu.

Á öðrum ársfjórðungi 2026 gátum við endurskrifað alla þjónustuna í Rust með aðeins tveimur verkfræðingum, Codex og GPT‑5.5. Nýja Rust-þjónustan annast nú 95% framleiðslubeiðna okkar og á næstu vikum munum við hætta alveg að nota Python. Gögn okkar sýna að Rust-þjónustan nýtir CPU sexfalt betur og minni fimmtánfalt betur en Python-útgáfan. Jafnframt er bæði meðalbiðtími og biðtími hægustu beiðnanna mun styttri. Við ætlum að fjalla nánar um það sem við lærðum í síðari bloggfærslu.

Python-þjónustan — og nú Rust-þjónustan — er aðeins einn þáttur Habitat. Í öðrum hluta þessa greinaflokks um hvernig við sköluðum netgeymsluna hratt fyrir meira en einn milljarð ChatGPT‑notenda fjöllum við um geymslulagið og hvernig Habitat afgreiðir meira en 500 petabæti og yfir 70 milljónir beiðna á sekúndu.

Ef þú vilt vinna við háþróuð OLTP-kerfi í gríðarlegum mælikvarða og hefur áhuga á verkfræði af þessu tagi skaltu skoða þessa lausu stöðu í teyminu okkar⁠.