Hröð stækkun netgeymslu fyrir yfir milljarð ChatGPT‑notenda (II. hluti)

Allar vörur OpenAI þurfa hraðan og áreiðanlegan aðgang að gögnum, sem geymslukerfið okkar Habitat veitir. Það þarf að svara á millisekúndum fyrir yfir milljarð notenda á 40 landfræðilegum svæðum. Innviðir okkar stóðu frammi fyrir óvenjumikilli áskorun: að styðja við öran vöxt og ný notkunartilvik og um leið halda áfram að bæta áreiðanleika, afköst og hraða vöruþróunar. Til að leysa þessa áskorun þurftum við að endurhugsa hönnun og rekstur geymslukerfisins okkar fyrir netþjónustur. Við mátum stöðugt kosti og galla og fylgdum þessari röð: fyrst að verða nógu áreiðanleg fyrir mikilvæga vöruumferð, síðan nógu hraðvirk fyrir notendur um allan heim og loks að reka kerfið lipurlega í gríðarlegum mæli.

Í þessari tveggja hluta greinaröð útskýrum við hvernig Habitat þróaðist úr einföldu biðlarasafni og gagnagrunni í alþjóðlega dreift geymslukerfi sem veitir aðgang að yfir 500 petabætum af gögnum. I. hluti fjallaði um þróun Habitat úr Python-biðlara í þjónustu. Þar var líka fjallað um aðferðirnar sem gerðu okkur kleift að ná mun meiru út úr Python-þjónustu en margir myndu telja raunhæft.

Í þessari grein, II. hluta, förum við yfir hvernig við stækkuðum undirliggjandi geymsluhluta: Azure Cosmos DB. Í nánu samstarfi við Azure-teymið fundum við raunhæfa leið til samnýtingar með sameiginlega stýrðum gámum, með framúrskarandi lestrarafköstum í gríðarlegum mæli á heimsvísu.

Þegar fyrirtæki stækka færast innviðateymi oft frá rekstri einkakerfa yfir í samnýtt kerfi. Einkanotkun, þar sem hvert teymi sem sinnir tilteknum vöruhluta heldur úti eigin kerfi, takmarkar áhrif bilana, skýrir ábyrgðarmörk og aðskilur vinnsluálag. Þegar teymum og vöruhlutum fjölgar verður þessi rekstur kostnaðarsamur. Einkanotkun gerir hvert vöruþróunarteymi ábyrgt fyrir skipulagningu afkastagetu og leiðir oft til þess að mun meiri afkastagetu er úthlutað en þörf er á.

Samnýting felur hins vegar miðlægu gagnagrunnsteymi stjórnina, með betri þekkingu og reynslu af úthlutun tilfanga. En samnýting skapar eigin vandamál, svo sem álagsfreka nágranna: einn aðili notar óvenjustóran hluta tilfanga á kostnað hinna.

Við þurftum að vega og meta alla þessa kosti og galla til að hanna áreiðanlegt og hagkvæmt geymslukerfi í stórum stíl fyrir Habitat. Í dag er Habitat samnýtt gagnagrunnslag fyrir margar vörur OpenAI. En leiðin lá í hring: frá einum samnýttum Azure Cosmos DB-gámi yfir í aðskilda undirliggjandi einkagáma og aftur að samnýttum gámi sem sjálfgefnu vali. Við erum enn á byrjunarreit í þróun samnýtingar í Habitat. Við styðjum margs konar notkun, en höfum getað frestað fjárfestingu á þessu sviði með því að nýta innbyggðar grunneiningar Azure Cosmos DB þar sem hægt er.

Áður en við förum yfir þróunarleið okkar með Azure Cosmos DB er gagnlegt að þekkja nokkur grunnatriði:

• Azure Cosmos DB-reikningur skilgreinir safn gáma og afritunarstefnu

• Hverjum gámi er úthlutað tilteknum afköstum í beiðnieiningum á sekúndu (RU/s)

• Gögn í hverjum gámi eru geymd með hefðbundinni dreifingu eftir tilgreindum röklegum skiptilykli, með skráðum geymslu- og afkastamörkum fyrir hvern slíkan lykil

• Azure Cosmos DB dreifir röklegum skiptilyklum yfir færri undirliggjandi efnislega gagnahluta. Þeim er skipt upp þegar gagnamagn fer yfir tiltekin mörk eða gámurinn þarf fleiri efnislega gagnahluta til að standa undir úthlutuðum afköstum

Upphaflega hleyptum við öllu álagi frá biðlurum í gegn og treystum á að uppgefin mörk, 10 þús. RU/s á hvern röklegan skiptilykil, héldu aftur af því. Í byrjun notuðum við líka aðeins einn sjálfgefinn Azure Cosmos DB-gám á hverjum reikningi. Þetta virkaði ágætlega, en reyndist vandasamt af nokkrum ástæðum:

Vegna ákvarðana sem teknar voru snemma í API-hönnuninni gátu biðlarar valið röklega skiptilykla beint. Því rekast ólík notkunartilvik vara oft á vegna algengra skiptilykla, svo sem user_id eða workspace_id. Þar sem þessi notkunartilvik deildu mörkum Azure Cosmos DB fyrir sömu röklegu skiptilyklana takmarkaði hönnunin heildarafköst fyrir hvern notanda.

Áður en við færðum okkur yfir í Habitat og Azure Cosmos DB var algengt vandamál við stækkun Postgres að margar beiðnir frá mjög virku fyrirtæki eða fyrir mikið notaðan lykil — einum aðila sem skapaði óhóflega mikið álag — gátu slegið út allan gagnagrunninn. Mikil sameiginleg vinna fór í að geyma þessa lykla í skyndiminni og innleiða tímabundinn einkarétt þegar gögn vantaði þar, svo álagið við að sækja þau yfirkeyrði ekki undirliggjandi gagnagrunn.

Þótt skráð mörk gagnamagns og afkasta eigi við um röklega skiptilykla er það í raun í efnislega gagnahlutanum sem mörkunum er framfylgt. Í reynd þýðir þetta að röklegir gagnahlutar ná ekki 10.000 RU/s. Þess í stað deila þeir mörkum efnislega gagnahlutans með öllum öðrum röklegum skiptilyklum sem þar eru geymdir.

Þetta gerði álagsfrekum nágrönnum kleift að hafa áhrif á marga ótengda röklega skiptilykla. Vinnsla gagna fyrir sérhæfða vörueiginleika gat þannig truflað grunnferli innskráningar og nýskráningar.

Afkastamörk hvers efnislegs gagnahluta eru líka breytileg og ráðast af heildarafköstum sem úthlutað er til Azure Cosmos DB-gámsins. Úthlutuðum afköstum gámsins er dreift nokkurn veginn jafnt yfir efnislega gagnahluta hans.

Þegar gagnamagn eykst skiptast efnislegir gagnahlutar upp. Gagnahlutunum fjölgar því en heildarafköst sem úthlutað er haldast óbreytt. Niðurstaðan er sú að raunveruleg afkastamörk hvers gagnahluta lækka eftir því sem gagnamagnið vex.

Í geymslufrekustu notkunartilvikunum okkar, sem líkjast geymslu stórra gagnablokka, getur þetta valdið því að aukið gagnamagn eitt og sér skerði afkastagetu virkrar vinnslu, þótt beiðnatíðni og notkun haldist stöðug.

Aðskildir gámar hjálpa að hluta til við að leysa vandamál vegna skiptilyklamarka og álagsfrekra nágranna. Með aðskildum gámum má úthluta hverjum þeirra sjálfstæðum efnislegum gagnahlutum. Þá getur aðeins mismunandi vinnsla innan sama gáms valdið nágrannaáhrifum eða skörun skiptilykla. Á móti kemur að uppsetning nýrra gáma hefur vinnu í för með sér: skipuleggja þarf afkastagetu hvers gáms sérstaklega. Því viljum við aðeins stofna gáma þar sem eðlileg skil eru milli þjónusta eða notkunartilvika.

Við fórum að nota aðskilda Azure Cosmos DB-gáma fyrir mikilvægustu nýju notkunartilvikin sem kröfðust skýrs aðskilnaðar. Með þessu, ásamt skriftu sem leysti vanda afkastalítilla gagnahluta með því að samræma heildarafköst hvers gáms við fjölda efnislegra gagnahluta hans, komumst við að mestu hjá öllum þeim vandamálum sem við glímdum við.

Þar sem við höfðum byrjað með sjálfgefinn gám voru mörg eldri og mikilvæg notkunartilvik því miður föst þar nema ráðist væri í gagnaflutning. Til að verja mikilvægar þjónustur sem reiddu sig enn á gögn í samnýtta sjálfgefna gámnum ráðlögðum við teymum oft að stofna sérstaka gáma fyrir nýjar þjónustur eða stóra vörueiginleika. Eftir því sem við stækkuðum jókst álagið á sjálfgefna gáminn og rekstrartruflunum fjölgaði. Við fórum að setja upp gáma fyrir hverja nýja þjónustu eða stóran vörueiginleika, eingöngu til að verja sjálfgefna gáminn fyrir meira álagi.

Þetta forðaði okkur frá mörgum heildarbilunum og takmarkaði áhrifin við truflanir á einstökum eiginleikum eða þjónustum. En að lokum fór vinnan við uppsetningu nýrra gáma að segja til sín:

Í gamla samnýtta sjálfgefna gámnum var ólíklegt að eitt nýtt notkunartilvik sem færi úr 0 í 1 milljón QPS breytti heildarnotkuninni verulega. Í aðskildum gámi gat sama aukning úr 0 í 1 milljón QPS hins vegar þýtt þúsundfalt meira álag en grunnálagið sem stafaði aðeins af innri notkun við prófanir.

Með einkagámum þurftu teymin nú að muna að úthluta þeim fyrirfram nægum afköstum fyrir væntanlega notkun við opnun. Vöruþróunarteymi settu oft eiginleika í rekstur en gleymdu að auka afkastagetuna fyrirfram. Þá sátum við á neyðarfundum á opnunardegi og reyndum að stækka gáma á síðustu stundu.

Þetta er einn helsti kostur þess að blanda vinnsluálagi í samnýttum kerfum, sem við fórnum fyrir betri aðskilnað með þessari gámastefnu.

Með tímanum fór eftirlit með notkun einkagáma líka að krefjast náinnar þekkingar á vörunum og því hvenær umferð myndi breytast eða aukast.

Við getum útvegað einfalda stjórnkerfisskriftu sem eykur úthlutuð afköst hvers gáms eftir vaxtarþróun. Án stöðugs heildarvaxtar þurfti þó í raun hvert vöruþróunarteymi hjá OpenAI að taka þátt í skipulagningu afkastagetu til að rétt væri staðið að stækkuninni.

Þetta fyrirkomulag stóðst ekki stækkun fyrirtækisins, enda var mjög misjafnt hversu vel ábyrgðarteymi hverrar þjónustu sinnti úthlutun tilfanga í Azure Cosmos DB.

Eftir því sem fyrirtækið stækkaði varð erfiðara að ráða við þessa rekstrarvanda. Án eins miðlægs teymis sem sinnti áætlanagerð skipulögðu mörg teymi illa. Því færðumst við aftur í átt að samnýttri lausn og unnum náið með Azure-teyminu að úrbótum á upphaflegu samnýtingarvandamálunum með eftirfarandi hönnun:

Með því að hraðatakmarka mest notuðu lyklana fyrst komum við í veg fyrir að álagsfrekir nágrannar noti öll tiltæk afköst tiltekins efnislegs gagnahluta. Þetta dregur úr nágrannaáhrifum, þar sem einn mikið notaður lykill getur haft áhrif á alla þjónustuna.

Forgangsflokkun beiðna með QoS kemur á svipaðan hátt í veg fyrir að bakgrunnsvinnsla, svo sem fjöldainnsetningar eða gagnaútdráttur, noti öll afköst tiltekins efnislegs gagnahluta. Með því að gefa þessum beiðnum lægri forgang eru þær hraðatakmarkaðar fyrst. Þannig er komið í veg fyrir hraðatakmörkun gagnvirkra beiðna með hærri forgang sem þjóna endanotendum.

Azure Cosmos DB hafði þegar þjónalausan ham sem hefði leyst vandann með afkastalitla gagnahluta í hamnum með fyrirframúthlutuðum afköstum. Hann hafði þó stóran ókost: hann stækkaði aðeins eftir geymslunotkun og takmarkaði RU-notkun við 5 þús. RU/s á hvern efnislegan gagnahluta. Þetta hefði leyst vandann með afkastalitla gagnahluta en komið í veg fyrir að við gætum stækkað notkunartilvik sem krefjast margra beiðnieininga.

Azure Cosmos DB-teymið þróaði fyrir okkur nýjan, endurbættan þjónalausan ham sem leyfði hverjum efnislegum gagnahluta að ná 10 þús. RU/s. Hann bætti við skiptingu eftir RU-notkun, til viðbótar við skiptingu eftir geymslunotkun. Þannig gátum við hætt að fylgjast með og stækka gáma handvirkt.

Með þessum breytingum höfum við getað snúið aftur að einum samnýttum gámi. Það hefur létt verulega á vöruþróunarteymum við skipulagningu afkastagetu, bæði fyrirfram og til lengri tíma, án þess að fórna aðskilnaði vinnsluálags. Á mánuðunum síðan hafa engar truflanir orðið vegna tilfangaúthlutunar eða álagsfrekra nágranna, þrátt fyrir hraðari vöruþróun.

Þegar fyrirtæki verða jafn stór og OpenAI verður fullstýrð þjónusta síður „fullstýrð“. Margs konar vinnsluálag fellur utan þess sem venjulegt er í innviðum skýjaþjónustunnar. Þegar OpenAI varð einn stærsti notandi Azure Cosmos DB þurfti annað fyrirkomulag til að tryggja góðan rekstur: sameiginleg próf og mælaborð, bein samskipti milli þróunarteyma og sameiginlega ábyrgð á bilunum sem koma aðeins fram í okkar mælikvarða. Í dag geymir stærsti Azure Cosmos DB-reikningurinn okkar tugi petabæta af gögnum og afgreiðir yfir 20 milljónir fyrirspurna á sekúndu. Eftir því sem við best vitum erum við eina fyrirtækið sem hefur tekið Azure Cosmos DB í notkun í þessum mæli.

Seint árið 2024 sýndi svæðisbundið rekstrarrof skýrt hvers vegna þetta samstarf var nauðsynlegt. Þá varð rafmagnsleysi á aðal-Azure-svæðinu eins stærsta Azure Cosmos DB-reikningsins okkar. Þegar við fluttum reksturinn á varasvæði kom í ljós að það tæki nokkrar klukkustundir fyrir stærstu reikningana okkar. Hvorki við né Azure Cosmos DB-teymið höfðum prófað slíkan yfirfærslutíma á þeirri stærðargráðu sem við störfum á.

Um mánuði síðar ollum við annarri alvarlegri truflun þegar við fluttum reikningana aftur á upprunalega svæðið. Skyndileg holskefla tenginga yfirkeyrði Azure Cosmos DB-gáttina á upprunalega svæðinu. Sérkenni í því hvernig Azure Cosmos DB-biðlarinn í gáttarham brást við yfirfærslu olli því að allir biðlarar stofnuðu strax tengingar og sendu beiðnir á upprunalega svæðið, þótt aðeins hluti efnislegu gagnahlutanna hefði verið fluttur þangað aftur.

Í hvorri truflun fylgdu bæði OpenAI og Azure sínum viðbragðsferlum. Nokkrar undirliggjandi orsakir fundust og úrbætur voru teknar í notkun. En truflanirnar voru einkenni stærri kerfislægs vanda í samspili vinnubragða og prófana hjá okkar teymi og Azure Cosmos DB-teyminu. Í upphafi gerði fullstýrð þjónusta okkur kleift að vinna hratt og einbeita okkur að viðskiptamarkmiðum. Þegar umfang rekstrarins eykst verður fullstýrð þjónusta síður fullstýrð og krefst náins samstarfs við þjónustuveituna á öllum stigum, frá hönnun til rekstrar.

Í dag fylgjast þróunarteymi Habitat og Azure sameiginlega með öllum lögum Habitat, frá þjónustulögunum okkar niður í efnisleg geymslulög Azure Cosmos DB. Við rekum Azure Cosmos DB-prófunarreikning í sömu stærð og framleiðslureikning og prófum breytingar á honum utan framleiðsluumhverfis. Við prófum og endurbætum SDK-söfn saman og mótum bestu starfsvenjur við stækkun og stærðarákvörðun Azure Cosmos DB-reikninganna okkar. Þróunarteymin hafa beinan aðgang hvert að öðru í gegnum Teams. Við höfum jafnvel gert þeim kleift að kalla beint eftir aðstoð hvert hjá öðru án þess að fara í gegnum þjónustuver.

Á síðasta ári höfum við unnið umfangsmikið samstarfsverkefni til að bæta skalanleika stjórnkerfis og gáttar Azure Cosmos DB. Við höfum bætt við álagsvörnum og skyndigeymslu ýmissa lýsigagna Azure Cosmos DB í gáttinni til að verja lýsigagnahlutann. Við höfum einnig dregið úr álagi frá fjölda Python-ferla habitat-service með tengingasöfnum og aukinni endurnýtingu tenginga, komið vinnslu fyrir á sama stað þar sem hægt er og aðskilið mikilvæga vinnslu frá bakgrunnsvinnslu með aðskildum VPC-netum.

Þetta nána þróunarsamstarf hefur skipt sköpum fyrir stöðugleika Azure Cosmos DB hjá okkur á síðasta ári. Öll kerfi sem eru nægilega stór eða mikilvæg krefjast slíkrar samvinnu: að brjóta niður múra milli ábyrgðarsviða og vinna þvert á skipulagsheildir.

Eins og kom fram í I. hluta er grunnhugsunin okkar þessi: láta það virka, gera það hraðvirkt, gera það ódýrt. Áreiðanleiki fyrst, síðan afköst og loks hagkvæmni. Habitat var orðið mikilvægur hluti innviða OpenAI og því var fyrsta forgangsmálið að tryggja áreiðanleika þess. Þegar kerfið varð stöðugra árið 2025 og OpenAI stækkaði á heimsvísu varð biðtími næsta hindrun fyrir notendur og vöruþróunarteymi.

Reikni- og geymslugeta voru oft á ólíkum svæðum, svo ekki varð komist hjá beiðnum milli svæða.

Biðtími var mjög breytilegur eftir því hvar gögnin voru geymd og hvar beiðnin var afgreidd. Til að hraða Habitat-beiðnum notuðu vöruhönnuðir aukið skyndiminni biðlaramegin, sendu beiðnir í lotum, lágmörkuðu lestur og skrif í gagnagrunn og færðu vinnslu af mikilvægri framkvæmdarleið þar sem hægt var. Þótt þetta leiddi til áhugaverðrar vöruhönnunar sem þoldi betur gagnagrunnsvandamál jók það einnig flækjustig vara og hægði á þróun þeirra. Þannig náðist ekki markmið Habitat um að auðvelda hraða vöruþróun án þess að þurfa að skilja gagnagrunninn.

Þetta hefur verið eitt helsta áherslumál okkar árið 2026. Við höfum mótað margþætta stefnu til að bæta lestrarafköst, enda eru lestrarbeiðnir yfir 90% allra Habitat-beiðna:

Við erum með nokkra Azure Cosmos DB-reikninga á mismunandi Azure-svæðum um allan heim fyrir notendur með kröfur um gagnageymslu. Jafnvel fyrir notendur sem gera ekki strangar kröfur um gagnageymslu bætir það upplifunina að geyma gögn nálægt þeim, þar sem biðtími styttist.

Í reynd getum við ekki gert þetta almennt nema þar sem kröfur um gagnageymslu kalla á það, því staðsetning takmarkast af efnislegri getu skýjainnviða. Gagnasöfnin okkar eru svo stór að mörg svæði ráða ekki við það gríðarlega geymslurými sem þarf fyrir hlutfallslegan hlut þeirra í notendaumferð.

Á svæðum þar sem rými gagnavera, rafmagn eða kæling er takmörkuð þurfum við stundum að velja: að taka frá getu fyrir geymslu á sama stað og stytta biðtíma Habitat, eða nýta hana fyrir meiri reiknigetu til afgreiðslu beiðna og beina geymslubeiðnum lengra í burtu.

Ákvarðanir um staðsetningu fela því oft í sér málamiðlun milli A) sem stysts biðtíma fyrir ólíkar vörur og notendahópa og B) hreinnar geymslu- og reiknigetu.

Fyrir vinnslu þar sem biðtími skiptir mestu, svo sem lýsigögn auðkenningar sem þarf fyrir hverja beiðni, styttum við ferðatíma fram og til baka (RTT) milli reiknivinnslu og Habitat með Azure Cosmos DB-reikningum sem hafa afrit á mörgum aukasvæðum. Sumir reikningar afrita gögn á öll 40 Azure-svæðin þar sem við afgreiðum umferð; aðrir á að minnsta kosti eitt svæði í hverri heimsálfu.

Við þurftum fyrr en ætlunin var að byggja lag inn í Habitat fyrir gagnaflutning og beiningu sem er ósýnilegt notendum þess, svo við gætum flutt gagnasöfn milli reikninga með ólíka afritunarskipan.

Þessi leið takmarkast þó líka á endanum af tiltækri getu og er því aðeins notuð fyrir fáein sérstaklega valin gagnasöfn.

Vinnsla í Habitat er að langmestu leyti lestur. Forrit sækja stöðugt stillingar, stöðu og aðra eiginleika, og óvenjustór hluti umferðarinnar stafar af tiltölulega litlu vinnusafni gagnagerða sem eru oft sóttar. Því hentar kerfið sérlega vel fyrir dreift skyndiminni. Skyndiminni bætir afköst innviða á einu svæði, en ávinningurinn margfaldast þegar unnið er yfir mörg svæði, þar sem það getur „falið“ biðtíma milli svæða.

Við höfum byggt dreift skyndiminnislag inn í Habitat sem er flett upp í áður en gögn eru sótt í gagnagrunn. Það geymir afrit af nýlega sóttum hlutum og tengslum á Valkey-þjónum í innviðum okkar, nálægt þeim stað þar sem beiðnir notenda eru afgreiddar. Slíkt skyndiminni notar yfirleitt líftíma (TTL) sem felur í sér málamiðlun milli hittni og úreldingar gagna. Stuttur líftími dregur úr úreldingu en minnkar ávinning skyndiminnisins, því færslur renna fljótt út og þarf að sækja þær oftar. Lengri líftími eykur hittni, en skilar úreltum gögnum lengur. Það leiðir til verri notendaupplifunar og ófyrirsjáanlegrar hegðunar vara.

Önnur leið er að ógilda skyndiminnisfærslur sérstaklega þegar forritið skrifar í sömu undirliggjandi gögn. Þetta heldur gögnum í skyndiminni mun betur uppfærðum, en getur verið erfitt að útfæra rétt. Ýmis jaðartilvik, svo sem bilanir í hluta kerfisins, geta þó enn skilið eftir úrelt gögn í skyndiminni. Rekstur á mörgum svæðum magnar vandann: netsamskipti milli svæða eru óáreiðanlegri og kapphlaup getur orðið milli skyndiminnis og afritunar undirliggjandi geymslu. Með því að bæta við líftímamörkum má setja hámark á úreldingu, en sama málamiðlun varðandi líftíma og áður var lýst er enn til staðar.

Við höfum tekið upp þróaðri leið til ógildingar og fylgt fordæmi kerfa á borð við TAO frá Meta. Innbyggt skyndiminni Habitat notar breytingaföngun (CDC) úr breytingastraumi Azure Cosmos DB til að dreifa ógildingum um allan heim á nokkrum sekúndum. Þannig næst mikil hittni með lítilli úreldingu. Þjónusta í innviðum okkar les þennan breytingastraum og ógildir færslur í staðbundnu skyndiminni þegar undirliggjandi gögn eru uppfærð. Við næsta lestur finnast gögnin því ekki í skyndiminninu og nýjasta útgáfa þeirra er sótt og geymd þar.

Við höfum líka stytt biðtíma verulega með því að draga úr umframvinnslu í Habitat-þjónustunni sjálfri. Það gerðum við með því að endurskrifa kóðann í Rust, sem er hraðvirkara en upprunalegi Python-kóðinn.

Saman hafa þessar breytingar lækkað heildarmiðgildi (p50) lestrartíma á heimsvísu úr um 120 ms í um 10 ms. Það er tólfföld framför frá því að við hófum að einbeita okkur að afköstum fyrr á árinu.

Þótt skyndiminni hafi lækkað miðgildi biðtíma verulega þurfa hægustu beiðnirnar enn að sækja gögn sem vantar í skyndiminni úr undirliggjandi geymslu, oft milli fjarlægra svæða. Eftir því sem meiri afkastageta verður tiltæk og við nýtum geymslurými betur ætlum við að takast á við grundvallaráskorun: að staðsetja gögn frá upphafi nær þeim stað þar sem þau verða notuð.

Áreiðanleg og skalanleg breytingaföngun — dreifing gagnagrunnsbreytinga til kerfa sem taka við þeim — er mikilvæg fyrir fleira en skyndiminnisstefnu Habitat. Milljónir breytinga á sekúndu, úr þúsundum gáma og milljónum gagnahluta þeirra, fara um yfir hundrað Kafka-efnisrásir. Þær knýja einnig aukavísitölur sem samræmast að lokum, gagnaflutningsferli, greiningar í bakgrunni og aðra rauntímaeiginleika vara. Eftir því sem undirliggjandi innviðir okkar hafa vaxið um allan heim hefur orðið sífellt flóknara að fylgjast með breytingum á færslum. Ef biðlari vill skrá bakfall sem keyrir þegar færslur af hans gerð breytast þarf hann meðal annars að finna hvaða Cosmos-reikningar og gámar geyma gögnin og hvaða CDC-þjónustuuppsetning fylgist með þeim á viðkomandi svæðum. Einnig þarf að stilla afkastagetu vinnuferla CDC-þjónustunnar, Kafka og móttakarans rétt. CDC-kerfið okkar á að fela allt þetta fyrir vöruhönnuðum og bjóða einfalt viðmót þar sem biðlarar skrá fall sem á að kalla á þegar færslur þeirra breytast. Við sjáum um allar tengingar og stækkun.

Innra stjórnkerfi tryggir stöðugt að breytingar úr öllum nauðsynlegum gámum séu fangaðar, velur hvaða Cosmos-svæði eru lesin og dreifir vinnu á hagkvæman hátt milli þúsunda vinnuferla á mörgum landfræðilegum svæðum. Með því að nota afritunarsvæði og gefa lestri breytingastrauma lægri forgang verjum við Habitat-umferð sem er viðkvæm fyrir biðtíma gegn álagi frá breytingaföngun í bakgrunni. Hrun vinnuferla, gámavandamál, villur í geymslu tímabundinna einkaréttinda, ógildar stillingar og bilanir á áfangastað eru sífelldir viðburðir í svo stóru kerfi. Við styrktum lífsferilsstýringu CDC-vinnuferla og meðhöndlun tímabundinna einkaréttinda, einangruðum bilanir milli strauma og byggðum inn varnir við stillingabreytingar og innleiðingu uppfærslna. Við notum sérstakar biðraðir fyrir óafhendanleg skilaboð svo varanlegar afhendingarvillur stöðvi ekki allt sem á eftir kemur. Við þolum svæðisbundin rekstrarrof með því að beina lesurum á önnur Cosmos-svæði. Vegna stærðar kerfisins höfum við jafnvel þurft að breyta CDC SDK-safni Azure til að gera vistun stöðupunkta skilvirkari: safna þeim í lotur í minni og skrifa þær aðeins með reglulegu millibili.

Þótt innri notkun Habitat á Azure Cosmos DB sé flókin hefur gildi þess alltaf falist í að fela smáatriði innviðanna fyrir vöruhönnuðum og hraða þannig vöruþróun. Hið sama gildir um CDC-kerfið okkar.

Lítið teymi gat stutt við ört vaxandi geymslukerfi með því að halda geymslu-API-inu vísvitandi afmörkuðu, halda áfram að auka afkastagetu Python-þjónustunnar og forgangsraða brýnustu tækniáskorununum. Við lögðum fyrst áherslu á áreiðanleika fyrir mikilvæga vöruumferð, síðan á lestrarafköst fyrir notendur um allan heim og loks á hagkvæman rekstur í stórum mælikvarða. Þessi nálgun gerði hraðan vöxt og ný notkunartilvik möguleg og bætti um leið áreiðanleika, afköst og hraða vöruþróunar.

Til að stækka Habitat og samtalageymsluna fyrir næsta milljarð notenda þurfum við að leysa vandann við að afrita gögn okkar yfir innviðina í enn stærri mælikvarða. Til að mæta þessu fyrirfram höfum við verið að þróa eigið sérsniðið geymslukerfi fyrir netþjónustur á exabætaskala, fínstillt fyrir fyrirferðarmiklar gagnagerðir Habitat. Kerfið er enn í þróun og sameinar RocksDB Cloud-kjarnann frá Rockset og afritun byggða á Raft. Það notar sama skjalalíkan og Azure Cosmos DB, en aðskilda geymslu og afritun á efnislegu stigi til að draga úr þörf fyrir leifturminni, gegn lægra hámarki fyrirspurna á sekúndu.

Ef þú hefur áhuga á að vinna að slíkum gagnainnviðum í áður óþekktum mæli skaltu skoða laus störf hjá okkur⁠.