Võrgusalvestuse kiire skaleerimine enam kui miljardile ChatGPT kasutajale (II osa)

Kõik OpenAI tooted vajavad kiiret ja töökindlat juurdepääsu andmetele, mida pakub meie salvestusplatvorm Habitat. See peab vastama millisekunditega enam kui miljardile kasutajale 40 geograafilises piirkonnas. Meie taristu ees seisis erakordne ülesanne: toetada plahvatuslikku kasvu ja uusi kasutusjuhte, parandades samal ajal töökindlust, jõudlust ja tootearendajate töökiirust. Selle lahendamiseks tuli ümber mõtestada meie võrgusalvestusplatvormi ülesehitus ja käitamine. Kaalusime pidevalt kompromisse, järgides põhimõtet: esmalt piisav töökindlus kriitilise tooteliikluse jaoks, siis piisav kiirus üleilmsetele kasutajatele ning lõpuks sujuv toimimine tohutus mastaabis.

See kaheosaline sari selgitab, kuidas arendasime Habitati lihtsast klienditeegist ja andmebaasist üleilmselt hajutatud salvestusplatvormiks, mis teenindab üle 500 petabaidi andmeid. I osa keskendus Habitati arengule Pythoni kliendist teenuseks. Seal käsitlesime ka võtteid, mis võimaldasid meil viia Pythoni-põhise teenuse palju kaugemale sellest, mida paljud peaksid praktiliseks.

Selles postituses ehk II osas vaatame, kuidas skaleerisime aluseks olevat salvestuskomponenti Azure Cosmos DB-d. Tihedas koostöös Azure’i tiimiga jõudsime toimiva mitme rentnikuga lahenduseni, mis põhineb ühiselt hallatavatel konteineritel ja pakub suurepärast lugemisjõudlust tohutus üleilmses mastaabis.

Ettevõtete kasvades liiguvad taristutiimid sageli ühe rentnikuga süsteemidelt mitme rentnikuga süsteemidele. Ühe rentniku mudelis haldab iga tooteosa tiim oma süsteemi. See piirab tõrgete mõjuulatust ning muudab vastutuspiirid ja töökoormuste isoleerimise lihtsaks. Tiimide ja tooteosade lisandudes muutub selle käitamine kalliks. Ühe rentniku mudelis vastutab iga tootetiim ressursside planeerimise eest ning sageli eraldatakse neid märkimisväärselt üle vajaduse.

Mitme rentniku mudelis on juhtimine seevastu keskse andmebaasitiimi käes, kellel on ressursside eraldamiseks paremad teadmised ja kogemused. Kuid mitme rentniku mudel tekitab omad probleemid, näiteks häirivad naabrid: üks rentnik tarbib ebatavaliselt suure osa ressurssidest teiste rentnike arvelt.

Habitati puhul pidime kõiki neid kompromisse kaaluma, et luua suuremahuline töökindel ja tõhus salvestussüsteem. Tänaseks on Habitat paljude OpenAI toodete ühine mitme rentnikuga andmebaasikiht. Sinna jõudmiseks läbisime aga ringi: ühelt mitme rentnikuga Azure Cosmos DB konteinerilt ühe rentnikuga aluskonteinerite loomisele ja seejärel tagasi mitme rentnikuga konteineri kasutamisele vaikimisi. Habitati mitme rentniku lahendus on alles varajases järgus. Toetame paljusid kasutusjuhte, kuid oleme saanud selle valdkonna investeeringuid edasi lükata, kasutades kõikjal, kus võimalik, Azure Cosmos DB sisseehitatud alusmehhanisme.

Enne meie Azure Cosmos DB teekonna juurde asumist veidi tausta:

• Azure Cosmos DB konto määratleb konteinerite kogumi ja replikatsioonipoliitika

• Igale konteinerile eraldatakse kindel läbilase, mida mõõdetakse päringuühikutes sekundis (RU/s)

• Iga konteineri andmed jaotatakse tavapärasel viisil etteantud loogilise sektsioonivõtme järgi kildudeks; iga loogilise sektsioonivõtme salvestusmahu ja läbilaske kohta kehtivad dokumenteeritud piirangud

• Azure Cosmos DB jaotab loogilised sektsioonivõtmed väiksema arvu füüsiliste alussektsioonide vahel. Füüsilised sektsioonid jagunevad, kui salvestusmaht ületab lävendi või konteiner vajab eraldatud läbilaske tagamiseks rohkem füüsilisi sektsioone

Algul lubasime läbi kogu kliendikoormuse, lootes, et loogilise sektsioonivõtme kohta lubatud 10 tuh RU/s piirmäär tagab vajaliku vastusurve. Samuti kasutasime alguses igal kontol ainult üht Azure Cosmos DB vaikekonteinerit. See toimis küllalt hästi, kuid osutus mõnel põhjusel probleemseks:

Varajaste API-disaini valikute tõttu andsime loogilise sektsioonivõtme valiku otse klientide kätte. Seetõttu esineb meil eri toodete kasutusjuhtudes sageli kokkupõrkeid levinud sektsioonivõtmetel, nagu user_id või workspace_id. Kuna need kasutusjuhud jagasid samade loogiliste sektsioonivõtmete Azure Cosmos DB piiranguid, piiras selline lahendus konkreetse kasutaja koguläbilaset.

Enne Habitati ja Azure Cosmos DB kasutuselevõttu seisis Postgresi skaleerimisel sageli ees probleem: väga aktiivse organisatsiooni või võtmega seotud arvukad päringud – üks rentnik, kes tekitas ebaproportsionaalselt suure koormuse – võisid kogu andmebaasi rivist välja viia. Tegime ühiselt palju tööd nende võtmete vahemällu salvestamiseks ja vahemälust puudumise korral ajutiste ainuõiguste lisamiseks, et vahemälust mööduvate päringute koormus ei koormaks alusandmebaasi üle.

Kuigi dokumenteeritud andmemahu ja läbilaske piirangud kehtivad loogiliste sektsioonivõtmete kohta, jõustatakse neid tegelikult füüsilise sektsiooni tasemel. Praktikas tähendab see, et loogilised sektsioonid ei suuda saavutada 10 000 RU/s. Selle asemel jagavad nad füüsilise sektsiooni piiratud ressursse kõigi teiste samas füüsilises sektsioonis paiknevate loogiliste sektsioonivõtmetega.

Nii said häirivad naabrid mõjutada paljusid omavahel mitteseotud loogilisi sektsioonivõtmeid: nišifunktsioonide andmeid töötlevad töökoormused häirisid põhilisi sisselogimis- ja registreerumisvooge.

Ka konkreetse füüsilise sektsiooni läbilaske piirmäär on muutuv ja sõltub Azure Cosmos DB konteinerile määratud koguläbilaskest. Konteinerile eraldatud läbilase jaotatakse selle füüsiliste sektsioonide vahel ligikaudu võrdselt.

Andmemahu kasvades füüsilised sektsioonid jagunevad: sektsioonide koguarv suureneb, kuid eraldatud koguläbilase jääb samaks. Selle tulemusena väheneb andmemahu kasvades iga sektsiooni tegelik läbilaske piirmäär.

Meie suurima salvestusvajadusega, suurte binaarobjektide laadsete andmete kasutusjuhtudes tekitab see tõrkeolukorra, kus ainuüksi andmemahu kasv vähendab aktiivsete töökoormuste läbilaskevõimsust, kuigi päringusagedus ja kasutus püsivad stabiilsena.

Eraldi konteinerid aitavad sektsioonivõtmete piirangute ja häirivate naabrite probleeme osaliselt lahendada. Eraldi konteinerite kasutamisel saab igaühele määrata oma sõltumatud füüsilised sektsioonid. Nii saavad häirivateks naabriteks olla või sektsioonivõtmete ruumis kattuda ainult sama konteineri töökoormused. Miinuspoolel kaasneb uute konteinerite loomisega lisatöö: iga konteineri ressursse tuleb eraldi planeerida. Seetõttu tahame konteinereid luua ainult teenuste või kasutusjuhtude mõistlikel piiridel.

Hakkasime kasutama eraldi Azure Cosmos DB konteinereid kõige kriitilisemate uute kasutusjuhtude jaoks, mis vajasid tugevat isolatsiooni. Lisaks kasutasime nõrkade sektsioonide haldamiseks skripti, mis hoidis iga konteineri eraldatud koguläbilaske vastavuses selle füüsiliste sektsioonide arvuga. Nii suutsime seniseid probleeme suuresti vältida.

Kuna olime aga alustanud vaikekonteinerist, jäid paljud varasemad kriitilised kasutusjuhud kahjuks sinna lõksu: nende eraldamiseks oleks tulnud andmed migreerida. Et kaitsta kriitilisi teenuseid, mis sõltusid endiselt ühiskasutusega vaikekonteineri andmetest, soovitasime tiimidel sageli luua uute teenuste või suuremate tootefunktsioonide jaoks eraldi konteinerid. Meie mahu kasvades suurenes vaikekonteineri koormus ja sagenesid ka tootmiskeskkonna intsidendid. Hakkasime looma konteinereid igale uuele teenusele või suurele tootefunktsioonile lihtsalt selleks, et kaitsta vaikekonteinerit lisakoormuse eest.

See päästis meid paljudest kogu saiti hõlmavatest katkestustest, piirates mõju üksikute funktsioonide või teenuste häiretega. Lõpuks hakkas uute konteinerite loomise lisakoormus siiski tunda andma:

Vanas ühiskasutusega vaikekonteineris ei muutnud ühe uue kasutusjuhu kasv nullist miljoni päringuni sekundis (QPS) tõenäoliselt kogukasutust märkimisväärselt. Eraldatud konteineris võis aga uue kasutusjuhu kasv nullist miljoni QPS-ini tähendada 1000 korda suuremat koormust võrreldes lähtetasemega, mis põhines üksnes ettevõttesisesel toote proovikasutusel.

Eraldatud konteinerite puhul pidid tiimid nüüd meeles pidama, et enne väljalaset tuleb konteineritele oodatav läbilase eraldada. Tootetiimid viisid sageli oma funktsioonid tootmiskeskkonda, unustades ressursse ette suurendada, ning meie istusime väljalaskepäeval tõsiste intsidentide kriisikoosolekutel, püüdes konteinerite mahtu viimasel hetkel kasvatada.

Töökoormuste ühendamine on mitme rentnikuga süsteemide põhieelis, millest selle konteineristrateegia puhul parema isolatsiooni nimel loobume.

Aja jooksul nõudis ka eraldatud konteinerite kasutuse jälgimine põhjalikke tooteteadmisi, et mõista, millal liiklus muutub või kasvab.

Saame pakkuda lihtsat juhtkihi skripti, mis suurendab kasvutrendide põhjal igale konteinerile eraldatud läbilaset. Stabiilse kogukasvu puudumisel eeldas õige skaleerimine aga sisuliselt iga OpenAI tootetiimi kaasamist ressursside planeerimisse.

Organisatsiooni kasvades see lahendus ei toiminud, sest teenuste eest vastutavad tiimid pöörasid oma Azure Cosmos DB ressursside eraldamisele väga erineval määral tähelepanu.

Organisatsiooni kasvades muutus nende käitusprobleemidega toimetulek üha raskemaks. Ühe keskse planeerimistiimi puudumine tähendas, et paljud tiimid planeerisid halvasti. Seetõttu liikusime lõpuks tagasi mitme rentnikuga lahenduse poole ning töötasime tihedalt koos Azure’i tiimiga, et lahendada ühiskasutusega arhitektuuris meie algsed probleemid:

Suurima koormusega võtmete esmajärjekorras piiramine takistab häirivatel naabritel kogu füüsilise sektsiooni saadaolevat läbilaset hõivamast. See vähendab häiriva naabri mõju, mille puhul üks suure koormusega võti võib häirida kogu saiti.

Päringute prioriteediklassidel põhinev QoS takistab samamoodi taustatöökoormustel, näiteks hulgiandmete lisamisel või väljavõtete tegemisel, kogu füüsilise sektsiooni läbilaset hõivamast. Kui määrata nende töökoormuste päringutele madalam prioriteet, piiratakse neid esimesena. See väldib lõppkasutajaid teenindavate kõrgema prioriteediga interaktiivsete päringute piiramist.

Azure Cosmos DB-l oli juba serverita režiim, mis oleks lahendanud meie nõrkade sektsioonide probleemi eraldatud ressurssidega režiimis. Sellel oli aga suur puudus: see skaleerus ainult kasutatud salvestusmahu järgi ja piiras RU-kasutuse 5 tuh RU/s-ni füüsilise sektsiooni kohta. See lahendanuks nõrkade sektsioonide probleemi, kuid takistanuks meil suure RU-vajadusega kasutusjuhte skaleerida.

Azure Cosmos DB tiim ehitas meile täiustatud serverita režiimi, milles iga füüsiline sektsioon sai kasvada kuni 10 tuh RU/s-ni. Lisaks salvestusmahupõhisele jagunemisele lisati RU-kasutusel põhinev jagunemine, mistõttu ei pidanud me enam konteinereid käsitsi jälgima ega suurendama.

Nende muudatustega saime naasta ühe ühiskasutusega konteineri juurde. See on tootetiimide esialgset ja jooksvat ressursside planeerimist märkimisväärselt lihtsustanud, säilitades töökoormuste vahelise isolatsiooni. Järgnenud kuudel pole meil olnud ühtki ressursside eraldamise ega häirivate naabritega seotud intsidenti, kuigi tootearendus on kiirenenud.

Kui ettevõte kasvab OpenAI mõõtu, muutuvad hallatud teenused vähem „hallatuks“. Paljud töökoormused ei mahu enam pilveteenuse pakkuja taristu tavapärastesse raamidesse. Kui OpenAI-st sai üks Azure Cosmos DB suurimaid kasutajaid, nõudis edukas käitamine teistsugust töökorraldust: ühiseid teste ja juhtpaneele, arendajate otsesuhtluskanaleid ning jagatud vastutust tõrkeolukordade eest, mis tekivad ainult meie mastaabis. Praegu talletab meie suurim Azure Cosmos DB konto kümneid petabaite andmeid ja teenindab üle 20 miljoni päringu sekundis. Meile teadaolevalt oleme ainus ettevõte, kes on Azure Cosmos DB sellises mastaabis kasutusele võtnud.

2024. aasta lõpus näitas piirkondlik katkestus selgelt, miks see koostöö on vajalik. Siis tabas elektrikatkestus ühe meie suurima Azure Cosmos DB konto esmast Azure’i piirkonda. Sellele järgnenud ümberlülitamisel avastasime, et meie suurimate kontode ümberlülitamine teisesesse piirkonda võtaks mitu tundi. Seda polnud meie mastaabis testinud ei meie ega Azure Cosmos DB tiim.

Umbes kuu aega hiljem põhjustasime kontode algsesse piirkonda tagasilülitamisel veel ühe tõsise katkestuse. Ühenduste tulv algsesse piirkonda koormas üle selle piirkonna Azure Cosmos DB lüüsi. Lüüsirežiimis Azure Cosmos DB kliendi ümberlülituste käsitlemise eripära tõttu lõid kõik kliendid kohe ühendused algse piirkonnaga ja hakkasid sinna päringuid saatma, kuigi tagasi oli viidud vaid osa füüsilistest sektsioonidest.

Iga katkestuse ajal järgisid nii OpenAI kui ka Azure oma intsidendihalduse protsesse, tuvastasid mitu algpõhjust ja rakendasid parandusi. Need katkestused olid aga laiema süsteemse probleemi sümptomid, mis tulenesid meie ja Azure Cosmos DB tiimi käitus- ja testimistavade erinevustest. Alguses võimaldas hallatud teenuste kasutamine meil kiiresti edasi liikuda ja ärieesmärkidele keskenduda. Suures mastaabis muutuvad hallatud teenused vähem hallatuks ning nõuavad tihedat lõimumist teenusepakkujaga kõigil tasanditel, alates kavandamisest kuni käitamiseni.

Täna jälgivad Habitati ja Azure’i arendustiimid ühiselt Habitati kõiki kihte, meie teenusekihtidest kuni Azure Cosmos DB füüsiliste salvestuskihtideni. Käitame ja testime muudatusi tootmiskeskkonnaga sama suurel Azure Cosmos DB kontol, mis ise tootmiskeskkonda ei kuulu. Testime ja täiustame SDK-sid ühiselt ning määrame kindlaks parimad tavad oma Azure Cosmos DB kontode skaleerimiseks ja mahu määramiseks. Meie arendajad saavad Teamsi kaudu otse suhelda ning oleme loonud isegi võimalused üksteist otse valveväljakutsega teavitada, ilma et peaks läbima kasutajatoe tasemeid.

Viimase aasta jooksul oleme teinud ulatuslikku koostööd Azure Cosmos DB juhtkihi ja lüüsi skaleeritavuse parandamiseks. Lisasime lüüsi koormuskaitse ja mitmesuguste Azure Cosmos DB metaandmete vahemällu salvestamise, et kaitsta metaandmete sektsiooni. Vähendasime Pythoni habitat-service’i protsesside tekitatud koormust ühenduspuulide ja ühenduste suurema taaskasutusega, paigutasime töökoormused võimaluse korral samasse asukohta ning eraldasime kriitilised töökoormused taustatöökoormustest eri VPC-de abil.

Nii tihe arenduskoostöö on olnud viimase aasta jooksul meie Azure Cosmos DB stabiilsuse jaoks määrava tähtsusega. Iga piisavalt suur või kriitiline süsteem vajab sellist meeskonnatööd: vastutusvaldkondade vaheliste tõkete ületamist ja tegutsemist üle organisatsioonipiiride.

Nagu I osas mainitud, on meie põhimõte: pane see tööle, tee see kiireks, tee see odavaks. Esmalt töökindlus, siis jõudlus ja lõpuks tõhusus. Habitatist oli saanud OpenAI kriitiline taristu, seega oli esmatähtis muuta see töökindlaks. Kui süsteem 2025. aastal stabiliseerus ja OpenAI laienes üle maailma, sai latentsusest kasutajate ja tootetiimide jaoks järgmine kitsaskoht.

Arvutus- ja salvestusressursid asusid sageli eri piirkondades, mistõttu olid piirkondadevahelised päringud vältimatud.

Latentsus erines suuresti sõltuvalt sellest, kus andmed asusid ja kus päringut teenindati. Habitati päringute kiirendamiseks kasutasid tootearendajad täiendavat kliendipoolset vahemälu ja päringute pakktöötlust, minimeerisid andmebaasi lugemisi ja kirjutamisi ning viisid töö võimaluse korral kriitiliselt täitmisteelt kõrvale. Kuigi nii sündis huvitavaid tootelahendusi, mis talusid andmebaasiprobleeme paremini, muutis see ka tooted keerukamaks ja aeglustas arendust. Seega jäi saavutamata Habitati eesmärk: võimaldada kiiret tootearendust ilma vajaduseta andmebaasi üksikasju mõista.

See on olnud 2026. aastal meie põhifookuses. Oleme välja töötanud mitmekihilise strateegia lugemiste jõudluse parandamiseks, sest lugemised moodustavad üle 90% Habitati päringutest:

Meil on eri Azure’i piirkondades üle maailma mitu Azure Cosmos DB kontot kasutajatele, kellel on andmete asukohanõuded. Ka rangete andmete asukohanõueteta kasutajate puhul parandab andmete paigutamine nende lähedale kasutuskogemust, vähendades latentsust.

Praktikas ei saa me seda väljaspool andmete asukohanõuetega kasutusjuhte laialdaselt rakendada, sest paigutust piirab pilvetaristu füüsiline maht. Meie andmestikud on nii suured, et paljudes piirkondades ei jätku salvestusruumi nende kasutajaliikluse osakaalule vastava tohutu andmemahu jaoks.

Piirkondades, kus andmekeskuste maht, elektrivarustus või jahutus on piiratud, seisame vahel otsese valiku ees: kas reserveerida ressursse kohalikuks salvestuseks ja vähendada Habitati latentsust või kasutada neid täiendavaks päringute teenindamise arvutusvõimsuseks ning suunata salvestuspäringud kaugemale.

Seetõttu tuleb paigutusotsustes sageli leida tootepõhine kompromiss kahe asja vahel: A) eri toodete ja kasutajarühmade latentsuse optimeerimine ning B) olemasolev salvestus- ja arvutusvõimsus.

Kõige latentsustundlikumate töökoormuste puhul, näiteks igas päringus vajalike autentimise metaandmete jaoks, vähendame arvutuskihi ja Habitati vahelist edasi-tagasi viivitust (RTT), kasutades ulatuslikult replitseeritud Azure Cosmos DB kontosid paljude teiseste piirkondadega. Mõne konto andmed replitseeritakse kõigisse 40 Azure’i piirkonda, kus liiklust teenindame; teiste omad vähemalt ühte piirkonda igal mandril.

Pidime ehitama Habitati kasutajale läbipaistva andmete teisaldamise ja marsruutimise kihi varem, kui soovisime, et saaksime andmestikke eri replikatsioonitopoloogiatega kontode vahel liigutada.

Kuid ka seda lähenemist piiravad lõpuks ressursid, mistõttu kasutame seda vaid mõne hoolikalt valitud andmestiku puhul.

Habitati töökoormustes domineerivad lugemised: rakendused pärivad pidevalt sätteid, olekut ja muid atribuute. Ebaproportsionaalselt suur osa liiklusest langeb suhteliselt väikesele sageli kasutatavate andmetüüpide töökomplektile. See teeb süsteemi hajutatud vahemälu jaoks eriti sobivaks. Vahemälu parandab jõudlust ka ühe piirkonna taristus, kuid mitme piirkonna puhul on kasu veelgi suurem, sest sellega saab piirkondadevahelist latentsust „peita“.

Oleme integreerinud Habitati hajutatud kõrvalvahemälu kihi. See hoiab hiljuti kasutatud objektide ja seoste koopiaid Valkey serverites, mis asuvad meie taristus kasutajapäringute töötlemise koha lähedal. Tavaliselt kasutavad sellised vahemälud kehtivusaega (TTL), millega tasakaalustatakse tabamusmäära ja andmete vananemist. Lühike TTL vähendab andmete vananemist, kuid piirab vahemälu kasu, sest kirjed aeguvad kiiresti ja neid tuleb sagedamini uuesti tuua. Pikem TTL parandab tabamusmäära, kuid pakub pikemalt aegunud andmeid, halvendades kasutuskogemust ja muutes toote käitumise ettearvamatuks.

Teine võimalus on vahemälukirjed selgesõnaliselt kehtetuks muuta, kui rakendus samadesse alusandmetesse kirjutab. See parandab oluliselt vahemälus olevate andmete ajakohasust, kuid seda võib olla raske õigesti teostada. Samuti jäävad alles erandolukorrad, näiteks osalised tõrked, mille tõttu vahemälu ei uuene. Mitme piirkonnaga lahendused süvendavad neid probleeme: piirkondadevahelised võrgud on vähem töökindlad ning vahemälu uuendamine võib sattuda alussalvestuse replikatsiooniga võistlusolukorda. TTL-i lisamine seab andmete vananemisele ülempiiri, kuid sellega kaasneb endiselt sama eespool kirjeldatud kompromiss.

Oleme valinud kehtetuks muutmiseks täiustatuma lähenemise, järgides selliste süsteemide nagu Meta TAO eeskuju. Habitati integreeritud vahemälu kasutab Azure Cosmos DB muudatuste voo kaudu andmemuudatuste hõivet (CDC), et levitada kehtetuks muutmisi üle maailma sekunditega. Nii saavutame suure tabamusmäära ja hoiame andmed ajakohasena. Meie taristu teenus loeb seda muudatuste voogu ja muudab alusandmete uuendamisel kohalike vahemälude vastavad kirjed kehtetuks. Järgmisel lugemisel jääb vahemälutabamus seetõttu saamata ning vahemälu täidetakse andmete uusima versiooniga.

Oleme latentsust märkimisväärselt vähendanud ka Habitati teenuse enda lisakulu kõrvaldamisega: kirjutasime koodi ümber Rustis, mis on algsest Pythonist jõudlam.

Need muudatused on koos vähendanud meie üleilmsete lugemiste üldist p50-latentsust ligikaudu 120 ms-lt 10 ms-le – see on 12-kordne paranemine ajast, mil hakkasime tänavuse aasta alguses jõudlusele keskenduma.

Kuigi vahemälu on mediaanlatentsust oluliselt vähendanud, peavad kõige aeglasemad päringud endiselt tooma vahemälust puuduvaid andmeid alussalvestusest, sageli kaugetest piirkondadest. Kui lisandub ressursse ja parandame salvestustõhusust, plaanime lahendada põhimõttelisema probleemi: paigutada andmed algusest peale lähemale kohale, kus neid kasutatakse.

Töökindel ja skaleeritav CDC ehk andmebaasimuudatuste edastamine järgnevatele süsteemidele on kriitilise tähtsusega ka mujal kui Habitati vahemälustrateegias. Tuhandetest konteineritest ja miljonitest konteinerisektsioonidest hõivatud miljonid muudatused sekundis läbivad enam kui sadat Kafka teemat. Need toetavad ka lõpliku kooskõlaga teiseseid indekseid, andmete teisaldamise torujuhtmeid, taustaanalüütikat ja muid reaalajas tootefunktsioone. Meie alustaristu üleilmse kasvu tõttu on reamuudatuste jälgimine muutunud üha keerukamaks. Kui klient soovib registreerida tagasikutse, mis käivitub tema tüüpi ridade muutmisel, peab ta muu hulgas selgitama välja, millistel Cosmose kontodel ja konteinerites tema andmed asuvad ning milline CDC teenuse juurutus vastavates piirkondades neid konteinereid jälgib. Samuti peab ta õigesti skaleerima CDC teenuse tööprotsessid, Kafka ja oma tarbijaprotsessi. Meie CDC platvormi eesmärk on peita kogu see keerukus tootearendajate eest ja pakkuda lihtsat liidest: kliendid registreerivad funktsiooni, mida soovivad muudetud ridade korral käivitada, ning meie hoolitseme ühenduste ja skaleerimise eest.

Sisemine juhtkiht tagab pidevalt kõigi vajalike konteinerite muudatuste hõive, valib lugemiseks Cosmose piirkonnad ja jaotab töö tõhusalt tuhandete tööprotsesside vahel mitmes geograafilises piirkonnas. Replikapiirkondade kasutamine ja voo lugemiste madalam prioriteet kaitsevad latentsustundlikku Habitati liiklust taustal toimuva hõive koormuse eest. Nii suures süsteemis esineb pidevalt tööprotsesside krahhe, konteineriprobleeme, ajutiste kasutusõiguste hoidla vigu, vigaseid seadistusi ja sihtsüsteemide tõrkeid. Muutsime CDC tööprotsesside elutsükli ja ajutiste kasutusõiguste haldamise töökindlamaks, isoleerisime voogude tõrked ning lisasime seadistusmuudatustele ja kasutuselevõttudele kaitsemeetmed. Kasutame edastamata sõnumite järjekordi, et püsivad edastustõrked ei blokeeriks järjekorra ülejäänud sõnumeid. Piirkondlike katkestustega tuleme toime, lülitades lugejad teistesse Cosmose piirkondadesse. Oma mastaabi tõttu oleme pidanud muutma isegi Azure’i CDC SDK-d, et muuta kontrollpunktide salvestamine tõhusamaks: koondame need mälus pakkidesse ja kirjutame püsisalvestusse vaid perioodiliselt.

Kuigi Azure Cosmos DB sisemine kasutus Habitatis on keerukas, on Habitati väärtus alati seisnenud taristu üksikasjade peitmises tootearendajate eest, et kiirendada tootearendust. Meie CDC platvorm järgib sama põhimõtet.

Väike tiim suutis toetada kiiresti kasvavat salvestusplatvormi, hoides salvestus-API teadlikult kitsa ulatusega, jätkates Pythoni teenuse skaleerimist ja seades esikohale kõige pakilisemad tehnilised probleemid. Keskendusime esmalt kriitilise tooteliikluse töökindlusele, seejärel üleilmsete kasutajate lugemisjõudlusele ning lõpuks tõhusale käitamisele suures mastaabis. See lähenemine võimaldas kiiret kasvu ja uusi kasutusjuhte, parandades samal ajal töökindlust, jõudlust ja tootearenduse kiirust.

Et skaleerida Habitati ja vestluste salvestust järgmise miljardi kasutaja jaoks, peame lahendama andmete replitseerimise keerukuse kogu meie taristus veelgi suuremas mastaabis. Selleks oleme juba ehitamas oma eksabaidiskaalas võrgusalvestussüsteemi, mis on optimeeritud Habitati mahukatele andmetüüpidele. See arendatav süsteem ühendab Rockseti RocksDB Cloudi tuuma Raft-põhise replikatsiooniga. See rakendab sama dokumendimudelit nagu Azure Cosmos DB, kuid kasutab eraldatud salvestuskihti ja füüsilist replikatsiooni, et vähendada vajalikku välkmälumahtu väiksema maksimaalse päringusageduse arvelt.

Kui soovid töötada selliste andmetaristuprojektidega tipptasemel mastaabis, vaata meie vabu töökohti⁠.