Tiešsaistes krātuves strauja mērogošana vairāk nekā 1 miljardam ChatGPT lietotāju

Ikviens OpenAI produkts ir atkarīgs no ātras un uzticamas piekļuves datiem – gan tad, kad lietotājs piesakās, pārbauda Codex iestatījumus vai sāk jaunu sarunu ChatGPT. Pirms produkts var atbildēt, katrai no šīm darbībām var būt vajadzīgi daudzi atsevišķi datu uzmeklējumi. Ja šie pieprasījumi ir lēni, arī produkts šķiet lēns. Ja šie pieprasījumi neizdodas, produkts pilnībā pārstāj darboties.

Habitat ir mūsu izveidotā tiešsaistes krātuves platforma, kas OpenAI produktiem ļauj ātri un uzticami piekļūt vajadzīgajai informācijai. Habitat tagad apstrādā vairāk nekā 70 miljonus pieprasījumu sekundē, nodrošinot produktus, kurus gandrīz 40 ģeogrāfiskajos reģionos ik nedēļu izmanto vairāk nekā miljards cilvēku. Habitat pirmoreiz tika palaists GPT atbalstam DevDay 2023, sākot kā vienkārša klienta puses Python bibliotēka, kas savienota ar vienu datubāzi. Šodien tā ir sarežģīta dalīta sistēma, kas apkalpo vairāk nekā 500 petabaitu datu.

Šāda mēroga infrastruktūras izveide un ekspluatācija nav vienkārša, tomēr pati par sevi nav arī īpaši sarežģīta. Mūsu situāciju unikālu padarīja nepieredzētais mērogošanas temps: vienlaikus bija jāatbalsta satriecošs lietotāju un produktu pieprasījuma pieaugums un jāveido nobriedusi platforma. Sistēmu inženieri bieži būvē desmitkārtīgam mērogam un cer, ka tas izturēs vairākus gadus, kamēr viņi gatavojas nākamajam desmitkārtīgajam pieaugumam. Mūsu gadījumā pēdējos trīs gadus ikgadējais pieaugums ir pārsniedzis desmit reizes. Tāpēc Habitat izveide un ekspluatācija ir bijusi taktisku lēmumu un pareizas secības virkne: izprast katru komponentu viszemākajā līmenī, lai maksimāli izmantotu esošo tehnoloģiju kopu, un vienlaikus novērst krātuves un skaitļošanas jaudas trūkumu, iegūstot laiku fundamentāliem ieguldījumiem.

OpenAI augot, bija jāaug arī Habitat: vispirms tai bija jākļūst pietiekami uzticamai kritiski svarīgai produktu datplūsmai, pēc tam pietiekami ātrai lietotājiem visā pasaulē un visbeidzot – spējīgai veikli darboties milzīgā mērogā. Šis raksts ir pirmais divdaļīgā sērijā par mūsu tiešsaistes krātuves mērogošanu. Šajā rakstā pastāstīsim, kā attīstījās Habitat, kāpēc bibliotēku pārvērtām par pakalpojumu un kā Python valodā – pakalpojumu tehnoloģiju kopām netipiskā valodā – rakstītu pakalpojumu izveidojām par uzticamu krātuves platformas slāni.

Nākamajā rakstā detalizēti aprakstīsim, kā panācām vairāklietotāju vides uzticamību lielā mērogā, kāda ir mūsu slāņveida lasīšanas veiktspējas optimizācijas stratēģija un kā mērogojām sadarbību ar Azure Cosmos DB, lai uzticami apkalpotu nepieredzētu pieprasījumu.

Habitat radās no vienkāršas idejas: produktu inženieriem nebūtu jādomā par datubāzu pārvaldību. Habitat pirmoreiz tika palaists GPT atbalstam DevDay 2023 kā neliela Python bibliotēka, kas mijiedarbojās ar ChatGPT galveno serveri. Tā atbalstīja nelielu darbību kopu, kas fonā tika sasaistīta ar datubāzes lietojumprogrammu Azure Cosmos DB.

Bibliotēkas uzdevums bija sniegt produktu komandām vienkāršu datu glabāšanas un izgūšanas veidu, neliekot apgūt pamatā esošās nianses. Habitat paveica visu nepieciešamo: noteica iesaistīto datu veidu, to avotu vai galamērķi, pieprasījuma atļaujamību un citus aspektus.

Produktu inženieriem nav jāraizējas par shēmas uzmeklēšanu, maršrutēšanu, autorizāciju, šifrēšanu, serializāciju, pieprasījumu formēšanu un savienojumu pūliem. Viņiem pat nebija jādomā, no kurienes nāk dati — no Azure Cosmos DB, kešatmiņām vai cita veida krātuves.

Šī Python bibliotēka darbojās labi, un OpenAI produktu inženieri strauji ieviesa Habitat, lai gan centralizēti netika veicināta atteikšanās no patstāvīgi pārvaldīta Postgres un Azure Cosmos DB.

Attīstoties produktu vajadzībām, produktu izstrādātāji koplietojamajai bibliotēkai varēja viegli pievienot arī atbalstu tādām funkcijām kā kešošana klienta pusē, saspiešana vai šifrēšana.

Līdz 2025. gada vidum Habitat bija sasniegusi klienta puses risinājuma robežas. Habitat slānim kļūstot sarežģītākam un pieaugot OpenAI pakalpojumu skaitam, atpakaļsaderīgas protokola izmaiņas vairs nebija īstenojamas.

Kādā gadījumā vēlējāmies mazināt viena reģiona darbības pārtraukuma ietekmi uz vissvarīgākajām datu kopām, migrējot tās uz reģionāli sadalītu Azure Cosmos DB kontu kopu. Lai veiktu šīs izmaiņas, klientā bija jāievieš papildu maršrutēšanas loģika, kas sākotnēji atspējota ar funkcijas karodziņu, jānodrošina tās ieviešana visiem klientiem un pēc tam jāiespējo karodziņš.

Izvietošanas koordinēšana desmitiem pakalpojumu un sadarbība ar katru komandu prasīja vairākas dienas. Pirms funkcijas iespējošanas sapratām, ka vēlamies ieviest ēnošanu, lai pārliecinātos par dalīšanas loģikas pareizību. Arī tās ieviešana prasīja vēl pāris dienu. Kļūdas labojums tam, ko atklājām par nepareizu? Vēl pāris dienu. Beidzot bijām gatavi iespējot karodziņu, taču viena komanda nesaistītu iemeslu dēļ atjaunoja sava pakalpojuma iepriekšējo versiju ar kļūdainu klientu, izraisot tieši to darbības pārtraukumu, no kura tik ļoti centāmies izvairīties.

Klienta bibliotēkas izmaiņām bija vajadzīga sarežģīta koordinācija desmitiem pakalpojumu, un šis process kļuva arvien trauslāks, neefektīvāks un uzņēmīgāks pret darbības kļūmēm. Lai turpmākās izvietošanas laikā mazinātu šo operacionālo izvērsumu, nolēmām pārvērst Habitat par atsevišķu pakalpojumu.

Nodalot krātuves loģiku atsevišķā pakalpojumā, izveidojām vienotu kontroles punktu izvietošanai, novērojamībai un platformas uzlabojumiem. Sadrumstalotu atjauninājumu pārvaldības vietā varējām uzlabojumus ieviest centralizēti, nekavējoties sniedzot priekšrocības visiem OpenAI produktiem.

Centralizēts pakalpojums mums sniedz arī vienotu kontroles punktu visstingrāko datu drošības un privātuma pamatmehānismu nodrošināšanai. Habitat pakalpojumā varam centralizēti piemērot piekļuves kontroles politikas, veikt audita reģistrēšanu un ierobežot piekļuvi tādiem krātuves resursiem kā Azure Cosmos DB. Habitat ir izšķiroša nozīme lietotāju datu aizsardzībā un ārēju, iekšēju un aģentu izraisītu nesankcionētas piekļuves mēģinājumu novēršanā.

Mēs zinājām, ka mums vajadzīgs pakalpojums, taču vēl nevēlējāmies atteikties no Python, lai gan tā izmantošana pakalpojumā radīja papildu slodzi. Python izmantošana augstas caurlaidspējas pakalpojumā palielināja tīkla latentumu un radīja ievērojamas CPU un atmiņas mērogošanas izmaksas salīdzinājumā ar lokālu bibliotēkas izpildi. Turklāt sapratām, ka 100 reižu lielākā mērogā Python neefektivitāte nebūtu pieņemama, tāpēc pakalpojuma pārrakstīšana nākotnē šķita gandrīz neizbēgama.

Tomēr mēs to uzskatījām par stratēģiski uzņemtu tehnisko parādu. Tolaik mūsu galvenais mērķis nebija izmaksu vai resursu optimizācija, bet gan šķēršļu novēršana produktu izstrādātājiem un platformas stabilitātes panākšana. Īstermiņā pieņemot Python pakalpojuma veiktspējas kompromisus, varējām pievērsties steidzamākiem izaicinājumiem, nostiprināt galvenās API un izveidot robustu infrastruktūru.

Mēs arī apzināti paļāvāmies uz to, ka mūsu programmēšanas modeļu straujā attīstība nākotnē vienkāršos tehnisko pāreju. Mēs likām uz to, ka brīdī, kad būs pilnībā jāatsakās no Python, Codex un GPT padarīs šo migrāciju īstenojamu. Galu galā šī likme attaisnojās.

Habitat darbināšana Python pakalpojuma veidā veiktspējas ziņā nebija optimāla, taču tā bija nepieciešama izvēle. Python ļauj mums virzīties ātri, taču tas nenozīmē, ka varējām atmest piesardzību un samierināties ar būtiski lielāku latentumu. Ja vidējs lietotāja pieprasījums izraisa simtiem datubāzes izsaukumu, lietotājs izjūt tieši lēnāko no tiem. Esam secinājuši, ka galvenais izaicinājums, darbinot Python pakalpojumu šādā mērogā, ir galējo latentumu pārvaldība.

Asyncio palīdz Python vienlaicīgi izpildīt ievadizvades noslogojumus, taču neļauj apiet Python GIL un nodrošināt paralēlu CPU darbu. Papildus intensīvai ievadizvades pieprasījumu starpniekošanai Habitat veic daudz CPU ietilpīgu pienākumu un fona uzdevumu: maršrutēšanu, saspiešanu, šifrēšanu, kontrolsummu aprēķināšanu, pakārtoto sistēmu veselības pārbaudes, pieprasījumu ēnošanu un dublēšanu.

Tā kā mūsu pakalpojumā ir tik daudz CPU ietilpīgu noslogojumu un fona uzdevumu, asyncio plānošanas aizkave var viegli kļūt par galveno galējā pieprasījumu latentuma cēloni. Pirms sākotnējās pakalpojuma palaišanas optimizācijas pieprasījumu trasējumos ar p99 un lielāku latentumu redzējām: lai gan pakārtotā krātuve atbildēja ātri, pieprasījumi bieži iestrēga, gaidot, kad atbildīgā korutīna tiks atkal ieplānota atbildes parsēšanai.

OpenAI Python pakalpojumiem līdztekus standarta atmiņas, CPU, tīkla un diska izmantojuma noslodzes un piesātinājuma rādītājiem ir ārkārtīgi svarīgi pārraudzīt arī asyncio ciklu un tā noslodzi un pēc tam attiecīgi veikt optimizāciju.

Periodiski ieplānojot fona uzdevumus un reģistrējot starpību starp paredzēto un faktisko izpildes laiku, varam empīriski un reāllaikā izmērīt notikumu cikla plānošanas aizkavi. Pie lielas noslodzes un daudziem dārgiem uzdevumiem pat neliels vienlaicīgu pieprasījumu skaits vienā procesā rada ievērojamas plānošanas svārstības – līdz pat simtiem milisekunžu un dažos robežgadījumos vairākām sekundēm.

Tāpēc katrs process apkalpo tikai nelielu skaitu vienlaicīgu pieprasījumu, bet mēs ievērojami palielinām Python darbinieku procesu skaitu.

Sākotnējās pakalpojuma palaišanas laikā, profilējot CPU dzīvajā sistēmā, atklājām vienu lielās asyncio aizkaves un no tās izrietošā lielā galējā latentuma pamatcēloni: mūsu funkciju karodziņu konfigurāciju periodisku JSON parsēšanu ar Statsig – rīku funkciju karodziņu pārvaldībai, A/B testiem un citām vajadzībām.

Pēc noklusējuma Statsig ik minūti un bez nejaušas laika nobīdes pārbaudīja atjauninātās konfigurācijas, turklāt konfigurācijā bija ietverti visi visu pakalpojumu produkcijas noteikumi. Citviet tika pieņemts arhitektūras lēmums katrā podā darbināt līdz astoņiem Python procesiem, lai panāktu lielāku CPU izmantojumu un mazāku latentumu. Kopā tas nozīmēja, ka ik minūti pienāca brīdis, kad visi poda darbinieki pārtrauca izpildē esošo pieprasījumu apstrādi un CPU ciklus veltīja milzīga konfigurācijas faila parsēšanai.

Kad CPU profilēšana palīdzēja noteikt problēmas pamatcēloni, risinājums bija vienkāršs: ieviest mazāku, mērķētu konfigurāciju, pagarināt atsvaidzināšanas intervālu un šādiem fona uzdevumiem pievienot nejaušu laika nobīdi.

Lai uzturētu mazu asyncio aizkavi, ir arī ārkārtīgi svarīgi labi līdzsvarot pieprasījumu slodzi starp servera procesiem; bez atbilstošas optimizācijas savienojumu pūli var darboties pretēji šim mērķim.

Izmantojot savienojumu pūlu klienta pusē, viens klienta process, kas vienlaicīgi veic daudz pieprasījumu, var izveidot tikai dažus servera savienojumus un tāpēc visu slodzi nosūtīt tikai dažiem procesiem. Pirms slodzes līdzsvarošanas pielāgošanas mūsu pakalpojumā bija ļoti atšķirīgs izmantojums: daži galējie procesi apkalpoja 5–10 reižu vairāk vienlaicīgu pieprasījumu nekā vidēji.

To nejauši atklājām incidentā, kad pat pēc tā klienta apturēšanas, kurš pārslogoja daļu pakalpojuma, daļas procesu darbība saglabājās traucēta vēl ilgi pēc datplūsmas uzplūda. Patiesībā pamanījām, ka šo procesu stāvoklis nekontrolējami pasliktinājās un tie saņēma arvien vairāk pieprasījumu, līdz tos restartējām. Kad pods tika pārslogots, kāds mehānisms tam piesaistīja vēl lielāku datplūsmu. Daži mūsu komandas biedri no iepriekšējā darba labi pazina šādu kļūmju klasi: metastabilu kļūmi⁠(atveras jaunā logā).

Mums radās aizdomas par savienojumu pūlu, un mēs tās pārbaudījām, ierobežojot savienojumu maksimālo atkārtotas izmantošanas ilgumu. Tas tiešām ierobežoja stāvokļa pasliktināšanos un apstiprināja izmeklēšanas virzienu. Turpmākā izmeklēšanā atklājās, ka Python aiohttp TCPConnector pēc noklusējuma savienojumus atkārtoti izmanto LIFO secībā: nākamajam pieprasījumam tiek atlasīts visnesenāk atgrieztais savienojums. Parasti tas ir saprātīgs noklusējums: neseno savienojumu atkārtota izmantošana ļauj papildu savienojumiem, kas izveidoti datplūsmas uzplūda apkalpošanai, dīkstāves laikā noilgt un tā mazina to uzturēšanas slodzi. Šajā gadījumā tas izraisīja metastabilu kļūmi. Pieprasījumu uzplūda laikā pieprasījumi lēnākiem un pārslogotiem serveriem vēlāk atgrieza savienojumus pūlā, tāpēc turpmākie pieprasījumi tos atlasīja biežāk un arvien vairāk datplūsmas koncentrējās uz jau pārslogotajiem podiem. Pārveidojot savienojumu pūlu atkārtotai izmantošanai FIFO secībā, pārtraucām šo atgriezenisko saiti un samazinājām arī pieprasījumu svārstības stabilā režīmā.

Pašlaik visā OpenAI infrastruktūrā lielākoties paļaujamies uz Istio un Envoy, kas nodrošina savienojumu pūlus un labākas slodzes līdzsvarošanas stratēģijas, kurās ņemta vērā serveru noslodze, tā pilnībā novēršot šo problēmu.

Viena no optimizācijas mazai asyncio aizkavei un lielā Python procesu skaita blakusparādībām ir iespēja ļoti viegli pārslogot pakārtotās atkarības ar milzīgu savienojumu skaitu – tā dēvēto “dārdošo baru”.

Parasta ikdienas izvietošana, ja vien tā nav iestatīta lēna, savienojumu cikliskas nomaiņas dēļ var izraisīt būtiskas CPU noslodzes svārstības. Savukārt savienojumu noplūde var apturēt tīklu, piesātinot NAT vārteju. Šādas problēmas nav retas arī citos pakalpojumos, taču par kārtu lielāks procesu skaits ievērojami pazemina to rašanās slieksni un bieži piesātina ar tīklu saistītus resursus, kuru apstrādei klienti, spriežot tikai pēc caurlaidspējas stabilā režīmā, nav gatavojušies.

Izmantojam Envoy arī savienojumu apvienošanas maksimizēšanai. Ar to jauninām Python HTTP/1 savienojumus uz HTTP/2, lai izmantotu multipleksēšanu, pēc tam apvienojam šos savienojumus pūlā un pagarinām to darbības laiku. Envoy mums nodrošina arī centralizētu vietu ātruma ierobežojumu un automātisko slēdžu ieviešanai, kas katrā atsevišķā Python procesā būtu mazāk efektīvi.

Viens no iemesliem, kāpēc varējām mērogot Python tik tālu, bija Habitat ierobežotā API, kas ļauj prognozēt pieprasījumu izmaksas. Tā vietā, lai klientiem ļautu veidot patvaļīgus SQL vaicājumus, kas varētu izraisīt lielu tabulu skenēšanu vai daudzu tabulu savienošanu, Habitat piedāvā vienkāršu NoSQL API. Jaudīgas API neesamība ir apzināts Habitat konstrukcijas kompromiss.

Mēs cenšamies optimizēt vienkāršus, prognozējamus un nemainīga darba apjoma pieprasījumus. Mūsu pieredze liecina, ka šādas sistēmas ir ievērojami vieglāk mērogot un tajās ir grūti kļūdīties vai tās izmantot nepareizi. Pieprasījumi ar neprognozējamu izvērsumu ir bīstami ekspluatācijā: tie apgrūtina izolāciju un slodzes līdzsvarošanu, kā arī rada straujus latentuma lēcienus, kuriem grūti pielāgot gan pakalpojumu, gan tā klientus.

Pirms pārejas uz Habitat un Azure Cosmos DB lielākā daļa OpenAI tiešsaistes datu glabājās Postgres. Tolaik pirms izmaiņu ieviešanas produkcijā bija viegli pārskatīt visus vaicājumus un shēmas izmaiņas, lai pārliecinātos, ka tie darbojas korekti un izmanto indeksētus datus. Komandai un produktiem augot, tas ātri kļuva nepārvaldāms un bieži izraisīja darbības pārtraukumus, kad viens jauns un dārgs vaicājums intensīvi izmantotā ceļā apturēja datubāzi.

Problēma ir izmaksu nelīdzsvarotībā: ir lēti un viegli uzrakstīt SQL vaicājumus, kuru izpilde ir dārga un sarežģīta. Habitat no tā izvairāmies un klienta pusē ļoti uzskatāmi parādām dārgus vaicājumus. Nav neierobežotu vaicājumu, kas varētu pārslogot Habitat, bet sarežģīti savienojumi un grafa šķērsošana prasa produktu komandām paveikt daļu smagā darba, tā kopumā veicinot efektīvākus risinājumus.

Habitat piedāvā NoSQL API, kas veidota ap klientu definētiem objektu un šķautņu tipiem un iedvesmota no TAO⁠(atveras jaunā logā). Klienti iepriekš definē objektus un šķautnes, kā arī to savstarpējās attiecības, bet ne katra tipa saturu. Iegūtās attiecības līdzinās grafam, taču pats Habitat neatbalsta tipiskus grafa šķērsošanas vaicājumus, izņemot konkrēta objekta tiešo šķautņu vaicāšanu.

Mēs sadalām šo grafu tā, lai katrs objekts un tā šķautnes atrastos vienā krātuves līmeņa nodalījumā, taču datubāzes līmenī apzināti nemēģinām kopā izvietot objektus un attālos objektus, uz kuriem norāda to šķautnes. Tādējādi modelis ir viegli sadalāms horizontālai mērogošanai, taču grafa šķērsošana ir neefektīva, jo katram solim starp objektiem var būt jāielādē dati no diviem pilnīgi atšķirīgiem Azure Cosmos DB kontiem dažādos reģionos.

Klientiem ar sarežģītākām vaicājumu vajadzībām piedāvājam arī Habitat bezsaistes sekundāro skatu, kas pieejams, izmantojot Rockset. Izmantojam datu izmaiņu tveršanu (CDC), lai gandrīz reāllaikā straumētu izmaiņas no tiešsaistes krātuves uz izolētām Rockset instancēm. Katra klienta komanda pati atbild par savas Rockset instances mērogošanu sarežģīto vaicājumu vajadzībām.

Šāda Rockset nodrošināšana klientiem rada papildu sarežģījumus, taču pašlaik uzskatām to par pareizo kompromisu: vienkārši vaicājumi ir noklusējums, bet tiem, kam vajadzīgi sarežģīti vaicājumi, ir pieejama alternatīva. Šis risinājums izolē mūsu tiešsaistes krātuvi no lasīšanas ietilpīgām analītikas un meklēšanas slodzēm.

Atliekot Python risinājuma pārrakstīšanu uz gadu, straujās izaugsmes laikā varējām pievērsties steidzamākiem un nozīmīgākiem izaicinājumiem. Platformai nobriestot un izaugsmei turpinot paātrināties, kā arī Habitat kļūstot par otru lielāko OpenAI pakalpojumu pēc kodolu skaita un ceturto pēc Envoy tvēruma, beidzot bija pienācis laiks atteikties no Python. Sasniedzot maksimumu, Python mums palīdzēja apkalpot vairāk nekā 20 miljonus pieprasījumu sekundē.

2026. gada otrajā ceturksnī tikai divi inženieri ar Codex un GPT‑5.5 palīdzību spēja visu pakalpojumu pārrakstīt Rust valodā. Jaunais Rust pakalpojums tagad apstrādā 95 % mūsu produkcijas pieprasījumu; tuvākajās nedēļās pilnībā pārtrauksim Python versijas izmantošanu. Mūsu dati rāda, ka Rust pakalpojums izmanto CPU sešreiz un atmiņu 15 reižu efektīvāk nekā Python versija, turklāt tam ir ievērojami mazāks vidējais un galējais latentums. Nākamajā emuāra rakstā plānojam dalīties ar papildu atziņām.

Python – un tagad Rust – pakalpojums ir tikai viena Habitat daļa. Šīs sērijas otrajā daļā par to, kā strauji mērogojām tiešsaistes krātuvi vairāk nekā viena miljarda ChatGPT lietotāju apkalpošanai, stāstīsim par krātuves slāni un to, kā Habitat apkalpo vairāk nekā 500 petabaitu datu un 70 miljonus pieprasījumu sekundē.

Ja vēlies strādāt ar OLTP sistēmām robežšķirtnes mērogā un tevi interesē šāda veida inženierija, apskati šo vakanci mūsu komandā⁠.