Hitro širjenje spletne hrambe za več kot milijardo uporabnikov ChatGPT (II. del)

Vsi produkti OpenAI potrebujejo hiter in zanesljiv dostop do podatkov, ki ga zagotavlja naša platforma za shranjevanje Habitat. Več kot milijardi uporabnikov v 40 geografskih regijah se mora odzivati v milisekundah. Naša infrastruktura se je znašla pred izjemnim izzivom: podpreti skokovito rast in nove primere uporabe ter hkrati še naprej izboljševati zanesljivost, zmogljivost in hitrost razvoja produktov. Za rešitev tega izziva smo morali na novo premisliti zasnovo in upravljanje naše platforme za spletno shranjevanje. Nenehno smo tehtali kompromise po naslednjem zaporedju: najprej doseči zadostno zanesljivost za kritični promet produktov, nato zadostno hitrost za uporabnike po svetu in nazadnje učinkovito delovati v izjemno velikem obsegu.

Ta dvodelna serija pojasnjuje, kako smo Habitat iz preproste odjemalske knjižnice in podatkovne zbirke razvili v globalno porazdeljeno platformo za shranjevanje, ki omogoča dostop do več kot 500 petabajtov podatkov. I. del se je osredotočal na razvoj Habitata iz odjemalca v Pythonu v storitev. Opisal je tudi tehnike, s katerimi smo storitev na osnovi Pythona razširili daleč prek meja, ki bi jih mnogi imeli za praktično izvedljive.

V tej objavi, II. delu, opisujemo, kako smo razširili osnovno komponento za shranjevanje: Azure Cosmos DB. S tesnim sodelovanjem z ekipo Azure smo razvili izvedljiv večnajemniški pristop s skupno upravljanimi vsebniki, ki zagotavlja odlično zmogljivost branja v velikem obsegu po vsem svetu.

Z rastjo podjetij infrastrukturne ekipe pogosto preidejo z upravljanja enonajemniških sistemov na večnajemniške. Enonajemniška zasnova, pri kateri vsaka ekipa za posamezen del produkta vzdržuje lasten sistem, omejuje obseg posledic napak ter omogoča jasne meje odgovornosti in izolacijo obremenitev. Z rastjo ekip in obsega produktov postane takšno upravljanje drago. Pri enonajemniški zasnovi je vsaka produktna ekipa odgovorna za načrtovanje zmogljivosti, kar pogosto vodi v občutno preveliko dodeljevanje virov.

Večnajemniška zasnova pa nadzor prepušča osrednji ekipi za podatkovne zbirke, ki ima več znanja in izkušenj z dodeljevanjem virov. Toda večnajemniška zasnova prinaša svoje težave, denimo moteče sosede, ko en najemnik porabi neobičajno velik delež virov na škodo drugih.

Pri Habitatu smo morali pretehtati vse te kompromise, da bi zasnovali zanesljiv in učinkovit sistem za shranjevanje v velikem obsegu. Danes je Habitat večnajemniška plast podatkovnih zbirk za številne produkte OpenAI. Do tega smo prišli po krožni poti: od enega večnajemniškega vsebnika Azure Cosmos DB prek ločenih enonajemniških zalednih vsebnikov nazaj k privzeti uporabi večnajemniškega vsebnika. Pri večnajemniški zasnovi Habitata smo še na začetku. Podpiramo veliko različnih primerov uporabe, a smo lahko naložbe na tem področju odložili, ker smo povsod, kjer je bilo mogoče, izkoristili vgrajene osnovne gradnike Azure Cosmos DB.

Preden opišemo našo pot z Azure Cosmos DB, še nekaj osnov:

• Račun Azure Cosmos DB določa nabor vsebnikov in pravilnik podvajanja

• Vsakemu vsebniku je dodeljena določena prepustnost v enotah zahtev na sekundo (RU/s)

• Podatki v vsakem vsebniku so shranjeni z običajnim razdeljevanjem po določenem logičnem particijskem ključu, z dokumentiranimi omejitvami prostora in prepustnosti na logični particijski ključ

• Azure Cosmos DB razporeja logične particijske ključe med manjše število zalednih fizičnih particij. Te razdeli na več fizičnih particij, ko količina shranjenih podatkov preseže prag ali ko vsebnik potrebuje več fizičnih particij za zagotavljanje dodeljene prepustnosti

Sprva smo prepuščali vso obremenitev odjemalcev in se za povratno omejevanje zanašali na navedeno omejitev 10 tis. RU/s na logični particijski ključ. Na začetku smo v vsakem računu uporabljali tudi samo en privzeti vsebnik Azure Cosmos DB. To je delovalo dovolj dobro, vendar se je izkazalo za problematično iz več razlogov:

Zaradi zgodnjih odločitev pri zasnovi API-ja smo izbiro logičnih particijskih ključev prepustili neposredno odjemalcem. Zato se pri različnih primerih uporabe produktov pogosto pojavljajo trki na pogosto uporabljenih particijskih ključih, kot sta user_id in workspace_id. Ker so za te primere uporabe veljale skupne omejitve Azure Cosmos DB na istih logičnih particijskih ključih, je zasnova omejevala skupno prepustnost za posameznega uporabnika.

Pred prehodom na Habitat in Azure Cosmos DB smo pri razširjanju Postgresa pogosto naleteli na težavo: množica zahtev zelo aktivne organizacije ali za zelo obremenjen ključ – torej en najemnik z nesorazmerno veliko obremenitvijo – je lahko onesposobila celotno podatkovno zbirko. Veliko skupnega truda smo vložili v predpomnjenje teh ključev in uvedbo mehanizma zakupov ob zgrešitvah v predpomnilniku, da posledična obremenitev ne bi preplavila zaledne podatkovne zbirke.

Čeprav dokumentirane omejitve količine podatkov in prepustnosti veljajo za logične particijske ključe, se dejansko uveljavljajo na ravni fizične particije. V praksi to pomeni, da logične particije ne morejo doseči 10.000 RU/s. Namesto tega si omejitve fizične particije delijo z vsemi drugimi logičnimi particijskimi ključi, ki so nameščeni na isti fizični particiji.

Moteči sosedje so tako lahko vplivali na številne nepovezane logične particijske ključe: obremenitve, ki so obdelovale podatke za nišne funkcije produktov, so motile osnovne postopke prijave in registracije.

Omejitev prepustnosti posamezne fizične particije je tudi spremenljiva, saj je odvisna od skupne prepustnosti, dodeljene vsebniku Azure Cosmos DB. Dodeljena prepustnost vsebnika se približno enakomerno porazdeli med njegove fizične particije.

Ko količina podatkov raste, se fizične particije delijo, s čimer se skupno število particij povečuje, skupna dodeljena prepustnost pa ostaja nespremenjena. Z rastjo količine podatkov se zato dejanska omejitev prepustnosti na particijo zmanjšuje.

Pri naših primerih uporabe, ki zahtevajo največ prostora in so podobni shranjevanju velikih binarnih objektov, to povzroča težavo: že sama rast shranjenih podatkov zmanjša prepustnost za aktivne obremenitve, tudi če pogostost zahtev in uporaba ostajata stabilni.

Ločeni vsebniki pomagajo delno odpraviti omejitve particijskih ključev in težave z motečimi sosedi. Vsakemu ločenemu vsebniku je mogoče dodeliti lastne neodvisne fizične particije. Tako lahko le različne obremenitve znotraj istega vsebnika postanejo moteči sosedje ali se prekrivajo v prostoru particijskih ključev. Slabost pa je dodaten vložek pri vzpostavljanju novih vsebnikov: vsak zahteva ločeno načrtovanje zmogljivosti. Zato želimo vsebnike ustvarjati le tam, kjer je to smiselno glede na meje storitve ali primera uporabe.

Za najpomembnejše nove primere uporabe, ki so zahtevali strogo izolacijo, smo začeli uporabljati ločene vsebnike Azure Cosmos DB. Dodali smo še skript za upravljanje šibkih particij, ki je skupno dodeljeno prepustnost vsakega vsebnika usklajeval s številom njegovih fizičnih particij. S tem smo se večini dotedanjih težav izognili.

Ker pa smo začeli s privzetim vsebnikom, so številni starejši kritični primeri uporabe žal ostali vezani nanj, dokler ne bi preselili podatkov. Da bi zaščitili kritične storitve, ki so se še vedno zanašale na podatke v skupnem privzetem vsebniku, smo ekipam pogosto svetovali, naj za nove storitve ali večje funkcije produktov ustvarijo ločene vsebnike. Z našo rastjo se je povečeval pritisk na privzeti vsebnik, z njim pa tudi število incidentov v produkciji. Vsebnike smo začeli vzpostavljati za vsako novo storitev ali večjo funkcijo produkta, zgolj da bi privzeti vsebnik zaščitili pred dodatno obremenitvijo.

To nas je obvarovalo pred številnimi izpadi celotnega spletnega mesta, saj je posledice omejilo na izpade ali slabše delovanje posameznih funkcij oziroma storitev. Toda dodatno delo z vzpostavljanjem novih vsebnikov je sčasoma postalo breme:

V starem skupnem privzetem vsebniku nov primer uporabe, ki je zrasel z 0 na milijon QPS, verjetno ni bistveno spremenil skupne uporabe. V izoliranem vsebniku pa je lahko rast novega primera uporabe z 0 na milijon QPS pomenila 1000-krat večjo obremenitev od izhodišča, ki je temeljilo zgolj na internem preizkušanju produkta.

Pri namenskih vsebnikih so morale ekipe zdaj poskrbeti, da so jim pred uvedbo dodelile pričakovano raven prepustnosti. Produktne ekipe so funkcije pogosto uvedle v produkcijo, a pozabile vnaprej povečati zmogljivosti. Na dan uvedbe smo se zato znašli na kriznih sestankih za resne incidente in v zadnjem trenutku poskušali povečati zmogljivosti vsebnikov.

Prav blaženje takšnih skokov z mešanjem obremenitev je ključna prednost večnajemniških sistemov, ki jo s to strategijo vsebnikov žrtvujemo za boljšo izolacijo.

Sčasoma je tudi spremljanje uporabe namenskih vsebnikov zahtevalo poglobljeno poznavanje produkta, da bi vedeli, kdaj se bo promet preusmeril ali povečal.

Zagotovimo lahko osnovni skript nadzorne ravnine, ki na podlagi trendov rasti povečuje dodeljeno prepustnost vsakega vsebnika. Toda brez stabilne skupne rasti je pravilno prilagajanje zmogljivosti pomenilo, da je morala pri njihovem načrtovanju sodelovati tako rekoč vsaka produktna ekipa v OpenAI.

Ta pristop organizacijsko ni sledil rasti, saj so ekipe, odgovorne za posamezne storitve, zelo različno skrbno upravljale dodeljevanje virov Azure Cosmos DB.

Z rastjo organizacije je bilo te operativne težave vse težje obvladovati. Ker za načrtovanje ni skrbela ena osrednja ekipa, so številne ekipe načrtovale slabo. Zato smo se vrnili k večnajemniški rešitvi in v tesnem sodelovanju z ekipo Azure odpravili prvotne težave večnajemniške zasnove s skupno uporabo virov:

Če najprej omejimo zahteve za najbolj obremenjene ključe, motečim sosedom preprečimo, da bi porabili vso razpoložljivo prepustnost posamezne fizične particije. S tem zmanjšamo učinek motečega soseda, pri katerem lahko en zelo obremenjen ključ vpliva na celotno spletno mesto.

Podobno QoS z razvrščanjem zahtev v razrede preprečuje, da bi paketne obremenitve, kot so množični vnosi ali izvozi podatkov, porabile vso prepustnost posamezne fizične particije. Zahtevam teh obremenitev dodelimo nižjo prednost, zato so omejene najprej. S tem preprečimo omejevanje interaktivnih zahtev z višjo prednostjo, ki služijo končnim uporabnikom.

Azure Cosmos DB je že imel brezstrežniški način, ki bi odpravil našo težavo s šibkimi particijami v načinu z dodeljeno prepustnostjo. Vendar je imel pomembno slabost: prilagajal se je le glede na porabo prostora in je porabo RU omejeval na 5 tis. RU/s na fizično particijo. To bi rešilo težavo s šibkimi particijami, vendar bi nam preprečilo razširjanje primerov uporabe z veliko porabo RU.

Ekipa Azure Cosmos DB je za nas razvila izboljšan brezstrežniški način, ki je vsaki fizični particiji omogočil rast do 10 tis. RU/s. Poleg delitev glede na porabo prostora je uvedel tudi delitve glede na porabo RU, zato nam vsebnikov ni bilo več treba ročno spremljati in povečevati njihovih zmogljivosti.

S temi spremembami smo se lahko vrnili k enemu skupnemu vsebniku. To je produktnim ekipam bistveno poenostavilo začetno in sprotno načrtovanje zmogljivosti, pri tem pa ohranilo izolacijo med obremenitvami. V mesecih od takrat kljub pospešenemu razvoju produktov nismo imeli nobenega incidenta zaradi dodeljevanja virov ali motečih sosedov.

Ko podjetja dosežejo velikost OpenAI, upravljane storitve postanejo manj »upravljane«. Številne obremenitve začnejo odstopati od običajnih vzorcev v infrastrukturi ponudnika oblaka. Ko je OpenAI postal eden največjih uporabnikov Azure Cosmos DB, je uspešno delovanje zahtevalo drugačen pristop: skupne preizkuse, skupne nadzorne plošče, neposredne kanale med inženirji ter skupno odgovornost za načine odpovedi, ki se pojavijo šele pri našem obsegu. Danes naš največji račun Azure Cosmos DB hrani več deset petabajtov podatkov in obdeluje več kot 20 milijonov QPS. Kolikor nam je znano, smo edino podjetje, ki je Azure Cosmos DB uvedlo v takšnem obsegu.

Konec leta 2024 je regionalni izpad jasno pokazal, zakaj je bilo to sodelovanje nujno. Takrat je izpad elektrike prizadel primarno regijo Azure enega naših največjih računov Azure Cosmos DB. Pri preklopu na nadomestno regijo smo ugotovili, da bi naši največji računi za preklop potrebovali več ur. Tega v našem obsegu prej ni preizkusila niti naša ekipa niti ekipa Azure Cosmos DB.

Približno mesec dni pozneje smo med vračanjem teh računov v prvotno regijo sprožili še en resen izpad. Naval povezav v prvotno regijo je preobremenil tamkajšnji prehod Azure Cosmos DB. Zaradi posebnosti pri obravnavi preklopov v odjemalcu Azure Cosmos DB v načinu prehoda so vsi odjemalci takoj vzpostavili povezave in poslali zahteve v prvotno regijo, čeprav se je tja vrnil le del fizičnih particij.

Ob vsakem izpadu sta OpenAI in Azure izvedla svoje postopke obvladovanja incidentov, ugotovila več temeljnih vzrokov in uvedla popravke. Toda ti izpadi so bili znaki širše sistemske težave v načinu delovanja in preizkušanja naše ekipe ter ekipe Azure Cosmos DB. Sprva nam je uporaba upravljanih storitev omogočala hiter napredek in osredotočenost na poslovne cilje. V velikem obsegu postanejo upravljane storitve manj upravljane in zahtevajo tesno povezovanje s ponudnikom storitve na vseh ravneh, od zasnove do obratovanja.

Danes inženirski ekipi Habitat in Azure skupaj spremljata vse plasti Habitata, od naših storitvenih plasti do plasti fizičnega shranjevanja Azure Cosmos DB. Spremembe izvajamo in preizkušamo na neprodukcijskem računu Azure Cosmos DB, ki je po velikosti enak produkcijskemu. Skupaj preizkušamo in izboljšujemo komplete SDK ter določamo najboljše prakse za razširjanje in dimenzioniranje naših računov Azure Cosmos DB. Inženirji imamo neposreden stik prek storitve Teams, vzpostavili pa smo tudi možnosti neposrednega klica dežurnih sodelavcev, ne da bi morali skozi posamezne ravni podpore.

V zadnjem letu smo veliko sodelovali pri izboljšanju razširljivosti nadzorne ravnine in prehoda Azure Cosmos DB. V prehod smo dodali zaščito pred preobremenitvijo in predpomnjenje različnih metapodatkov Azure Cosmos DB, da bi zaščitili particijo z metapodatki. Z zbirko povezav in pogostejšo ponovno uporabo povezav smo zmanjšali pritisk naših procesov habitat-service v Pythonu, delovne obremenitve po možnosti namestili na isto lokacijo ter kritične obremenitve ločili od paketnih z uporabo različnih omrežij VPC.

Tako tesno razvojno sodelovanje je bilo v zadnjem letu ključno za stabilnost naše uporabe Azure Cosmos DB. Vsak dovolj velik ali kritičen sistem zahteva takšno ekipno delo: odpravljanje pregrad med področji odgovornosti in sodelovanje prek organizacijskih meja.

Kot smo omenili v I. delu, je naše osnovno vodilo: najprej naj deluje, nato naj bo hitro, nazadnje pa poceni. Najprej zanesljivost, nato zmogljivost, nato učinkovitost. Habitat je postal ključna infrastruktura za OpenAI, zato je bila prva prednostna naloga zagotoviti njegovo zanesljivost. Ko se je sistem leta 2025 ustalil, OpenAI pa se je širil po svetu, je zakasnitev postala naslednja omejitev za uporabnike in produktne ekipe.

Računske in shranjevalne zmogljivosti so bile pogosto v različnih regijah, zato so bile zahteve med regijami neizogibne.

Zakasnitev se je močno razlikovala glede na to, kje so bili podatki shranjeni in kje je bila zahteva obdelana. Da bi bile zahteve v Habitatu hitre, so razvijalci produktov uporabljali dodatno predpomnjenje na strani odjemalca, združevanje zahtev v pakete in čim manj branj in zapisov v podatkovno zbirko ter delo, kjer je bilo mogoče, umikali s kritične poti. To je sicer prineslo nekaj zanimivih zasnov produktov, odpornejših proti težavam s podatkovno zbirko, vendar je produkte tudi zapletlo in upočasnilo njihov razvoj. S tem Habitat ni dosegel svojega cilja: spodbujati hiter razvoj produktov brez potrebe po poznavanju podatkovne zbirke.

Temu se v letu 2026 intenzivno posvečamo. Razvili smo večplastno strategijo za optimizacijo branja, ki predstavlja več kot 90 % zahtev v Habitatu:

Za uporabnike z zahtevami glede lokalne hrambe podatkov imamo več računov Azure Cosmos DB v različnih regijah Azure po svetu. Tudi uporabnikom brez strogih zahtev glede lokalne hrambe podatkov shranjevanje podatkov v njihovi bližini izboljša izkušnjo zaradi manjše zakasnitve.

V praksi tega zunaj primerov lokalne hrambe podatkov ne moremo širše uresničiti, saj razporejanje omejujejo fizične zmogljivosti oblaka. Naše podatkovne zbirke so tako velike, da številne regije ne morejo zagotoviti ogromnega prostora za shranjevanje, ki bi ga potrebovale za svoj sorazmerni delež uporabniškega prometa.

V regijah z omejenimi zmogljivostmi podatkovnih centrov, napajanjem ali hlajenjem moramo včasih izbirati: rezervirati zmogljivosti za lokalno shranjevanje in manjšo zakasnitev Habitata ali jih nameniti dodatnim računskim virom za obdelavo zahtev ter zahteve za shranjevanje usmerjati dlje.

Odločitve o razporejanju so zato pogosto kompromis med produktnimi potrebami: A) optimizacijo zakasnitve za različne produkte in skupine uporabnikov ter B) razpoložljivimi shranjevalnimi in računskimi zmogljivostmi.

Pri obremenitvah, kjer je zakasnitev najpomembnejša, denimo pri metapodatkih za preverjanje pristnosti, potrebnih pri vsaki zahtevi, skrajšujemo povratni čas (RTT) med računskimi viri in Habitatom z računi Azure Cosmos DB, ki se podvajajo v številne sekundarne regije. Nekateri računi se podvajajo v vseh 40 regij Azure, kjer obdelujemo promet, drugi pa vsaj v eno regijo na celino.

V Habitat smo morali prej, kot smo želeli, vgraditi plast za premikanje podatkov in usmerjanje, ki je za uporabnike neopazna. Tako lahko nabore podatkov premikamo med računi z različnimi topologijami podvajanja.

Vendar tudi ta pristop nazadnje omejujejo zmogljivosti, zato je omejen na nekaj skrbno izbranih naborov podatkov.

Pri obremenitvah Habitata močno prevladuje branje: aplikacije nenehno pridobivajo nastavitve, stanje in druge lastnosti. Nesorazmerno velik delež prometa odpade na razmeroma majhen delovni nabor pogosto dostopanih podatkovnih tipov. Zato je sistem še posebej primeren za porazdeljeno predpomnjenje. Predpomnjenje izboljša zmogljivost infrastrukture že znotraj ene regije, pri delovanju med regijami pa so koristi še večje, saj lahko »skrije« zakasnitev med regijami.

V Habitat smo vgradili porazdeljeno plast stranskega predpomnilnika. Ta hrani kopije nedavno dostopanih objektov in povezav v strežnikih Valkey, ki so v naši infrastrukturi blizu mesta obdelave uporabniških zahtev. Takšni predpomnilniki običajno uporabljajo čas veljavnosti (TTL), ki uravnoteža delež zadetkov in zastarelost podatkov. Kratki časi TTL zmanjšujejo zastarelost, vendar omejujejo koristi predpomnjenja, saj vnosi hitro potečejo in jih je treba pogosteje znova pridobiti. Daljši časi TTL povečajo delež zadetkov, vendar dlje vračajo zastarele podatke, kar slabša uporabniško izkušnjo in povzroča nepredvidljivo delovanje produktov.

Druga možnost je izrecno razveljavljanje vnosov v predpomnilniku, ko aplikacija zapisuje spremembe v iste zaledne podatke. To močno izboljša svežino predpomnjenih podatkov, vendar je pravilna izvedba lahko zahtevna. Še vedno pa ostajajo robni primeri, denimo delne odpovedi, zaradi katerih predpomnilnik ostane zastarel. Postavitve v več regijah te težave še povečajo zaradi manj zanesljivih medregijskih omrežij in tekmovanja med posodabljanjem predpomnilnika ter podvajanjem zalednega shranjevanja. Dodatek časov TTL omeji največjo zastarelost, vendar ostaja isti osnovni kompromis glede TTL, opisan zgoraj.

Izbrali smo naprednejši pristop k razveljavljanju po zgledu sistemov, kot je Metin TAO. Habitatov vgrajeni predpomnilnik se opira na zajem sprememb podatkov (CDC) prek toka sprememb Azure Cosmos DB. Razveljavitve se tako v nekaj sekundah razširijo po svetu, kar zagotavlja velik delež zadetkov ob majhni zastarelosti. Storitev v naši infrastrukturi bere ta tok sprememb in ob posodobitvah zalednih podatkov razveljavlja vnose v lokalnih predpomnilnikih. Ob naslednjem branju teh podatkov zato pride do zgrešitve, predpomnilnik pa se napolni z najnovejšo različico podatkov.

Zakasnitev smo bistveno zmanjšali tudi z odpravo režijskih stroškov v sami storitvi Habitat: kodo smo prepisali v Rust, ki je zmogljivejši od prvotne izvedbe v Pythonu.

Te spremembe so skupaj znižale naš skupni globalni p50 zakasnitve branja s približno 120 ms na približno 10 ms. To je 12-kratno izboljšanje, odkar smo se v začetku letošnjega leta začeli osredotočati na zmogljivost.

Čeprav je predpomnjenje močno znižalo mediano zakasnitve, je treba pri najpočasnejših zahtevah še vedno pridobiti nepredpomnjene podatke iz zaledne shrambe, pogosto iz oddaljenih regij. Ko bodo na voljo dodatne zmogljivosti in bomo izboljšali učinkovitost shranjevanja, nameravamo rešiti bolj temeljni izziv: podatke že od začetka postaviti bliže mestu dostopa.

Zanesljiv in razširljiv CDC – posredovanje sprememb iz podatkovne zbirke nadaljnjim sistemom – ni ključen le za Habitatovo strategijo predpomnjenja. Milijoni zajetih sprememb na sekundo iz tisočev vsebnikov in milijonov njihovih particij tečejo skozi več kot sto tem Kafka. Poganjajo tudi sekundarne indekse z eventualno konsistentnostjo, cevovode za premikanje podatkov, paketno analitiko in druge funkcije produktov v realnem času. Z globalno rastjo naše zaledne infrastrukture je postalo spremljanje sprememb vrstic vse bolj zapleteno. Če želi odjemalec registrirati povratni klic, ki se izvede ob vsaki spremembi vrstic njegovega tipa, mora med drugim najprej ugotoviti, kateri računi in vsebniki Cosmos vsebujejo njegove podatke ter katera postavitev storitve CDC v ustreznih regijah spremlja te vsebnike. Nato mora ustrezno prilagoditi zmogljivosti delovnih procesov CDC, Kafke in svojega porabnika. Naša platforma CDC želi vse te podrobnosti skriti pred razvijalci produktov in jim namesto tega ponuditi preprost vmesnik: odjemalci registrirajo funkcijo, ki naj se pokliče ob spremembah njihovih vrstic, mi pa poskrbimo za vso povezovalno infrastrukturo in razširjanje.

Notranja nadzorna ravnina nenehno zagotavlja zajem vseh potrebnih vsebnikov, izbira regije Cosmos za branje in učinkovito razporeja delo med tisoče delovnih procesov v več geografskih regijah. Uporaba regij z replikami in branja toka z nižjo prednostjo ščitita promet Habitata, občutljiv na zakasnitev, pred obremenitvami zajema v ozadju. V tako veliki množici procesov se nenehno pojavljajo sesutja delovnih procesov, težave z vsebniki, napake v shrambi zakupov, neveljavne konfiguracije in odpovedi ciljnih sistemov. Utrdili smo upravljanje življenjskega cikla delovnih procesov CDC in zakupov, preprečili širjenje napak med tokovi ter uvedli varovala za spremembe konfiguracije in uvajanje novih različic. Uporabljamo čakalne vrste za nedostavljiva sporočila, da trajne napake pri dostavi ne bi blokirale nadaljnje obdelave. Regionalne izpade premostimo s preklopom bralnikov na druge regije Cosmos. Pri našem obsegu smo morali spremeniti celo Azure SDK za CDC, da bi bilo zapisovanje kontrolnih točk učinkovitejše: združujemo jih v pomnilniku in jih le občasno trajno zapišemo.

Čeprav je interna uporaba Azure Cosmos DB v Habitatu zapletena, je bila njegova vrednost od nekdaj v skrivanju infrastrukturnih podrobnosti pred razvijalci produktov, da bi ti lahko razvijali hitreje. Enako velja za našo platformo CDC.

Majhna ekipa je lahko podpirala hitro rastočo platformo za shranjevanje, ker je API za shranjevanje namenoma ohranjala omejen, še naprej razširjala storitev v Pythonu in prednostno reševala najnujnejše inženirske izzive. Najprej smo se osredotočili na zanesljivost za kritični promet produktov, nato na zmogljivost branja za uporabnike po svetu in nazadnje na operativno učinkovitost v velikem obsegu. Ta pristop je omogočil hitro rast in nove primere uporabe ter hkrati izboljšal zanesljivost, zmogljivost in hitrost razvoja produktov.

Da bi Habitat in shranjevanje pogovorov razširili za naslednjo milijardo uporabnikov, moramo rešiti zahtevno podvajanje podatkov po naši infrastrukturi v še večjem obsegu. Zato že razvijamo lasten sistem za spletno shranjevanje v eksabajtnem obsegu, optimiziran za podatkovne tipe Habitata, ki zavzamejo veliko prostora. Ta sistem v razvoju združuje jedro RocksDB Cloud podjetja Rockset s podvajanjem na osnovi protokola Raft. Uporablja enak dokumentni model kot Azure Cosmos DB, vendar z ločenim shranjevanjem in fizičnim podvajanjem zmanjšuje potrebno količino bliskovnega pomnilnika v zameno za nižjo največjo zmogljivost QPS.

Če vas zanima delo na takšnih projektih podatkovne infrastrukture v prelomnem obsegu, si oglejte naša prosta delovna mesta⁠.