Strauja tiešsaistes krātuves mērogošana vairāk nekā miljardam ChatGPT lietotāju (II daļa)

Visiem OpenAI produktiem vajadzīga ātra un uzticama piekļuve datiem, ko nodrošina mūsu glabāšanas platforma Habitat. Tai milisekundēs jāatbild vairāk nekā miljardam lietotāju 40 ģeogrāfiskajos reģionos. Mūsu infrastruktūrai bija jārisina ārkārtējs izaicinājums: atbalstīt strauju izaugsmi un jaunus lietošanas gadījumus, vienlaikus turpinot uzlabot uzticamību, veiktspēju un produktu izstrādes tempu. Lai to paveiktu, bija jāpārdomā mūsu tiešsaistes datu glabāšanas platformas uzbūve un ekspluatācija. Mēs pastāvīgi izvērtējām kompromisus, ievērojot šādu secību: vispirms panākt pietiekamu uzticamību kritiski svarīgai produktu datplūsmai, tad — pietiekamu ātrumu lietotājiem visā pasaulē, un visbeidzot — prasmīgu darbību milzīgā mērogā.

Šajā divdaļīgajā rakstu sērijā skaidrojam, kā Habitat no vienkāršas klienta bibliotēkas un datubāzes pārvērtām par globāli sadalītu glabāšanas platformu, kas nodrošina piekļuvi vairāk nekā 500 petabaitiem datu. I daļā pievērsāmies Habitat attīstībai no Python klienta līdz pakalpojumam. Tajā aplūkojām arī paņēmienus, kas ļāva Python pakalpojuma iespējas paplašināt tālu aiz robežām, ko daudzi uzskatītu par praktiski sasniedzamām.

Šajā rakstā, II daļā, izskaidrojam, kā mērogojām pamatā esošo glabāšanas komponentu — Azure Cosmos DB. Cieši sadarbojoties ar Azure komandu, izveidojām dzīvotspējīgu vairāku nomnieku risinājumu ar kopīgi pārvaldītiem konteineriem un izcilu lasīšanas veiktspēju milzīgā globālā mērogā.

Uzņēmumiem augot, infrastruktūras komandas bieži pāriet no viena nomnieka sistēmām uz vairāku nomnieku sistēmām. Viena nomnieka pieeja, kur katra produkta daļas komanda uztur savu sistēmu, samazina kļūmju ietekmes apjomu, nodrošina skaidras atbildības robežas un darba slodžu izolāciju. Komandām un produktu klāstam augot, šāda pieeja kļūst dārga. Viena nomnieka pieeja padara katru produktu komandu atbildīgu par resursu plānošanu un bieži noved pie ievērojamas resursu pārrezervēšanas.

Savukārt vairāku nomnieku pieeja uztic pārvaldību centralizētai datubāzu komandai ar labākām zināšanām un pieredzi resursu nodrošināšanā. Taču vairāku nomnieku pieeja rada savas problēmas, piemēram, traucējošus kaimiņus — viens nomnieks patērē neparasti lielu resursu daļu, kaitējot pārējiem.

Veidojot Habitat, mums bija jāizsver visi šie kompromisi, lai izstrādātu uzticamu un efektīvu glabāšanas sistēmu lielam mērogam. Šodien Habitat ir vairāku nomnieku datubāzes slānis daudziem OpenAI produktiem, taču līdz tam nonācām pa apli: no viena vairāku nomnieku Azure Cosmos DB konteinera pārgājām uz atsevišķiem viena nomnieka glabāšanas konteineriem un tad atgriezāmies pie vairāku nomnieku konteinera kā noklusējuma izvēles. Habitat vairāku nomnieku risinājums vēl ir agrīnā attīstības posmā. Atbalstām plašu lietošanas gadījumu loku, taču ieguldījumus šajā jomā esam spējuši atlikt, kur vien iespējams izmantojot Azure Cosmos DB iebūvētos pamatmehānismus.

Pirms aplūkojam savu pieredzi ar Azure Cosmos DB, daži pamatprincipi:

• Azure Cosmos DB konts nosaka konteineru kopu un replikācijas politiku

• Katram konteineram nodrošina noteiktu caurlaidspēju pieprasījumu vienībās sekundē (RU/s)

• Dati katrā konteinerā tiek glabāti, tos ierastā veidā sadalot pēc norādītas loģiskā nodalījuma atslēgas; katrai šādai atslēgai ir dokumentēti glabāšanas apjoma un caurlaidspējas limiti

• Azure Cosmos DB sadala loģisko nodalījumu atslēgas mazākā skaitā fizisko nodalījumu. Tie tiek sadalīti vairākos fiziskos nodalījumos, kad datu apjoms pārsniedz slieksni vai konteineram vajadzīgi papildu fiziskie nodalījumi, lai uzturētu nodrošināto caurlaidspēju

Sākotnēji pieņēmām jebkādu klientu slodzi, paļaujoties, ka norādītais 10 tūkst. RU/s limits katrai loģiskā nodalījuma atslēgai nodrošinās slodzes bremzēšanu. Sākumā katrā kontā izmantojām arī tikai vienu noklusējuma Azure Cosmos DB konteineru. Tas darbojās pietiekami labi, taču radīja problēmas vairāku iemeslu dēļ:

Agrīnu API izstrādes lēmumu dēļ loģiskā nodalījuma atslēgas izvēli ļāvām tieši veikt klientiem. Tāpēc dažādos produktu lietošanas gadījumos bieži sakrīt plaši izmantotas nodalījumu atslēgas, piemēram, user_id vai workspace_id. Tā kā šiem lietošanas gadījumiem bija kopīgi Azure Cosmos DB limiti vienām un tām pašām loģisko nodalījumu atslēgām, šī uzbūve ierobežoja kopējo caurlaidspēju konkrētam lietotājam.

Pirms pārejas uz Habitat un Azure Cosmos DB, mērogojot Postgres, bieži saskārāmies ar problēmu: daudzi pieprasījumi no ļoti aktīvas organizācijas vai uz ļoti noslogotu atslēgu — tātad viens nomnieks ar nesamērīgi lielu slodzi — varēja apturēt visu datubāzi. Kopīgi ieguldījām daudz darba šo atslēgu kešošanā un pagaidu ekskluzīvu tiesību mehānismos gadījumiem, kad kešatmiņā datu nav, lai šādu pieprasījumu radītā slodze nepārslogotu pamatā esošo datubāzi.

Lai gan dokumentētie datu apjoma un caurlaidspējas limiti attiecas uz loģisko nodalījumu atslēgām, faktiski tie tiek piemēroti fiziskā nodalījuma līmenī. Praksē tas nozīmē, ka loģiskie nodalījumi nespēj sasniegt 10 000 RU/s. Tiem fiziskā nodalījuma limiti ir kopīgi ar visām pārējām šajā fiziskajā nodalījumā izvietotajām loģisko nodalījumu atslēgām.

Tādējādi traucējoši kaimiņi varēja ietekmēt daudzas nesaistītas loģisko nodalījumu atslēgas: darba slodzes, kas apstrādāja nišas funkciju datus, traucēja pamata pieteikšanās un reģistrācijas procesus.

Arī konkrēta fiziskā nodalījuma caurlaidspējas limits ir mainīgs un atkarīgs no Azure Cosmos DB konteineram piešķirtās kopējās caurlaidspējas. Konteineram nodrošinātā caurlaidspēja tiek aptuveni vienmērīgi sadalīta starp tā fiziskajiem nodalījumiem.

Pieaugot datu apjomam, fiziskie nodalījumi sadalās un to kopskaits palielinās, bet kopējā nodrošinātā caurlaidspēja nemainās. Rezultātā, pieaugot datu apjomam, katra nodalījuma faktiskās caurlaidspējas limits samazinās.

Lietošanas gadījumos ar vislielāko glabāšanas apjomu un lieliem bināriem objektiem tas rada kļūmes scenāriju: tikai datu apjoma pieaugums vien samazina aktīvajām darba slodzēm pieejamo caurlaidspēju, pat ja pieprasījumu biežums un lietojums nemainās.

Atsevišķi konteineri palīdz daļēji atrisināt nodalījumu atslēgu limitu un traucējošo kaimiņu problēmas. Izmantojot atsevišķus konteinerus, katram var piešķirt neatkarīgus fiziskos nodalījumus. Tad par traucējošiem kaimiņiem var kļūt vai nodalījumu atslēgu telpā pārklāties tikai darba slodzes šajā pašā konteinerā. Taču jaunu konteineru sagatavošana prasa papildu darbu — katram atsevišķi jāplāno resursi. Tāpēc vēlamies veidot konteinerus tikai tur, kur to pamatoti nosaka pakalpojuma vai lietošanas gadījuma robežas.

Svarīgākajiem jaunajiem lietošanas gadījumiem, kuriem vajadzīga stingra izolācija, sākām izmantot atsevišķus Azure Cosmos DB konteinerus. Papildus izmantojām skriptu vājo nodalījumu pārvaldībai, saskaņojot katram konteineram nodrošināto kopējo caurlaidspēju ar tā fizisko nodalījumu skaitu. Tas ļāva lielākoties izvairīties no visām iepriekšējām problēmām.

Tomēr, tā kā sākām ar noklusējuma konteineru, daudzi agrākie kritiskie lietošanas gadījumi diemžēl palika tajā — bez datu migrācijas tos pārcelt nevarēja. Lai aizsargātu kritiskos pakalpojumus, kas joprojām izmantoja datus koplietotajā noklusējuma konteinerā, bieži ieteicām komandām jauniem pakalpojumiem vai būtiskām produktu funkcijām veidot atsevišķus konteinerus. Mērogam pieaugot, palielinājās slodze uz noklusējuma konteineru un arī incidentu skaits produkcijas vidē. Sākām sagatavot konteinerus katram jaunam pakalpojumam vai lielai produkta funkcijai, lai pasargātu noklusējuma konteineru no papildu slodzes.

Tas pasargāja mūs no daudziem visas vietnes darbības pārtraukumiem, ierobežojot kļūmju ietekmi līdz atsevišķu funkciju vai pakalpojumu darbības pasliktinājumam. Tomēr ar laiku jaunu konteineru sagatavošanas papildu slogs kļuva jūtams:

Vecajā koplietotajā noklusējuma konteinerā viena jauna lietošanas gadījuma pieaugums no 0 līdz 1 miljonam vaicājumu sekundē (QPS), visticamāk, būtiski nemainītu kopējo lietojumu. Savukārt izolētā konteinerā jauna lietošanas gadījuma pieaugums no 0 līdz 1 miljonam QPS varētu radīt 1000 reižu lielāku slodzi nekā sākotnējā, ko veidoja tikai iekšēja izmēģināšana.

Izmantojot atsevišķus konteinerus, komandām bija jāatceras jau iepriekš tiem nodrošināt palaišanai paredzēto caurlaidspēju. Produktu komandas bieži ieviesa funkcijas produkcijas vidē, aizmirstot iepriekš palielināt resursus, un palaišanas dienā mēs sēdējām kritisko incidentu koordinācijas sanāksmēs, pēdējā brīdī mēģinot palielināt konteineru jaudu.

Šī ir būtiska vairāku nomnieku sistēmu priekšrocība — dažādu darba slodžu apvienošana —, ko ar šo konteineru stratēģiju zaudējam par labu labākai izolācijai.

Ar laiku atsevišķo konteineru lietojuma uzraudzībai bija vajadzīgas arī padziļinātas zināšanas par produktu, lai paredzētu datplūsmas izmaiņas vai pieaugumu.

Varam nodrošināt vienkāršu vadības slāņa skriptu, kas palielina katra konteinera caurlaidspēju atbilstoši pieauguma tendencēm. Taču bez stabila kopējā pieauguma pareiza mērogošana faktiski prasīja resursu plānošanā iesaistīties gandrīz katrai OpenAI produktu komandai.

Organizācijai augot, šī pieeja nedarbojās: dažādu pakalpojumu atbildīgās komandas ļoti atšķirīgi rūpējās par savu Azure Cosmos DB resursu nodrošināšanu.

Organizācijai augot, šīs darbības problēmas kļuva arvien grūtāk pārvaldāmas. Tā kā nebija vienas centralizētas plānošanas komandas, daudzas komandas plānoja nepietiekami labi. Tāpēc atgriezāmies pie vairāku nomnieku risinājuma un cieši sadarbojāmies ar Azure komandu, lai koplietojamā arhitektūrā novērstu sākotnējās vairāku nomnieku pieejas problēmas:

Vispirms ierobežojot noslogotākās atslēgas, traucējošiem kaimiņiem neļaujam patērēt visu konkrētā fiziskā nodalījuma caurlaidspēju. Tas mazina traucējošo kaimiņu efektu, kad viena noslogota atslēga var ietekmēt visu vietni.

Arī QoS pieprasījumu dalīšana līmeņos neļauj bezsaistes darba slodzēm, piemēram, lielapjoma datu ievietošanai vai izvilkšanai, patērēt visu konkrētā fiziskā nodalījuma caurlaidspēju. Piešķirot šo darba slodžu pieprasījumiem zemāku prioritāti, tie tiek ierobežoti pirmie, pasargājot no ierobežošanas augstākas prioritātes interaktīvos pieprasījumus, kas apkalpo galalietotājus.

Azure Cosmos DB jau bija bezservera režīms, kas būtu atrisinājis vājo nodalījumu problēmu režīmā ar iepriekš nodrošinātu caurlaidspēju. Tomēr tam bija būtisks trūkums: tas mērogojās tikai pēc glabāšanas apjoma un ierobežoja RU patēriņu līdz 5 tūkst. RU/s katram fiziskajam nodalījumam. Tas atrisinātu vājo nodalījumu problēmu, bet neļautu mērogot lietošanas gadījumus ar lielu RU patēriņu.

Azure Cosmos DB komanda mums izveidoja uzlabotu bezservera režīmu, kurā katrs fiziskais nodalījums var sasniegt 10 tūkst. RU/s. Papildus sadalīšanai pēc glabāšanas apjoma tas ieviesa sadalīšanu pēc RU patēriņa, ļaujot mums pārtraukt manuālu konteineru uzraudzību un jaudas palielināšanu.

Šīs izmaiņas ļāva atgriezties pie viena koplietota konteinera, būtiski vienkāršojot produktu komandu sākotnējo un turpmāko resursu plānošanu, vienlaikus saglabājot darba slodžu izolāciju. Kopš tā laika pagājušajos mēnešos nav bijis neviena ar resursu nodrošināšanu vai traucējošiem kaimiņiem saistīta incidenta, lai gan produktu izstrāde ir paātrinājusies.

Uzņēmumiem sasniedzot OpenAI mērogu, pārvaldītie pakalpojumi kļūst mazāk „pārvaldīti”. Daudzas darba slodzes vairs neatbilst mākoņpakalpojumu sniedzēja infrastruktūrai ierastajiem scenārijiem. OpenAI kļūstot par vienu no lielākajiem Azure Cosmos DB lietotājiem, sekmīgai darbībai bija vajadzīga cita pieeja: kopīgi testi un informācijas paneļi, tieši saziņas kanāli starp inženieriem un kopīga atbildība par kļūmju scenārijiem, kas parādās tikai mūsu mērogā. Šodien mūsu lielākais Azure Cosmos DB konts glabā desmitiem petabaitu datu un apstrādā vairāk nekā 20 miljonus vaicājumu sekundē. Cik mums zināms, esam vienīgais uzņēmums, kas Azure Cosmos DB ir ieviesis šādā mērogā.

2024. gada beigās reģionāls darbības pārtraukums skaidri parādīja, kāpēc šī sadarbība bija vajadzīga. Toreiz vienam no mūsu lielākajiem Azure Cosmos DB kontiem primārajā Azure reģionā pārtrūka elektroapgāde. Veicot nepieciešamo kļūmjpārlēci, konstatējām, ka mūsu lielāko kontu pārslēgšana uz sekundāro reģionu prasītu vairākas stundas. Ne mūsu, ne Azure Cosmos DB komanda to nebija pārbaudījusi mūsu mērogā.

Aptuveni mēnesi vēlāk, pārslēdzot šos kontus atpakaļ uz sākotnējo reģionu, izraisījām vēl vienu nopietnu darbības pārtraukumu. Masveida savienojumu pieplūdums sākotnējā reģionā pārslogoja tā Azure Cosmos DB vārteju. Azure Cosmos DB klienta kļūmjpārlēces apstrādes īpatnība vārtejas režīmā lika visiem klientiem nekavējoties veidot savienojumus un sūtīt pieprasījumus uz sākotnējo reģionu, lai gan tajā bija atgriezusies tikai daļa fizisko nodalījumu.

Katrā darbības pārtraukumā gan OpenAI, gan Azure īstenoja savus incidentu pārvaldības procesus, identificēja vairākus pamatcēloņus un ieviesa labojumus. Taču šie pārtraukumi liecināja par plašāku sistēmisku problēmu mūsu un Azure Cosmos DB komandas darba un testēšanas pieeju saskaņošanā. Sākumā pārvaldītie pakalpojumi ļāva mums virzīties ātri un koncentrēties uz uzņēmuma mērķiem. Lielā mērogā pārvaldītie pakalpojumi kļūst mazāk pārvaldīti un prasa ciešu integrāciju ar pakalpojuma sniedzēju visos līmeņos — no projektēšanas līdz ekspluatācijai.

Šodien Habitat un Azure inženieru komandas kopīgi uzrauga katru Habitat slāni — no mūsu pakalpojumu slāņiem līdz Azure Cosmos DB fiziskās glabāšanas slāņiem. Mēs darbinām un testējam izmaiņas Azure Cosmos DB kontā, kas atbilst produkcijas vides apjomam, bet netiek izmantots produkcijā. Kopīgi testējam un pilnveidojam SDK un nosakām labāko praksi Azure Cosmos DB kontu mērogošanai un resursu apjoma izvēlei. Mūsu inženieri var tieši sazināties lietotnē Teams, un esam pat izveidojuši iespēju tieši izsaukt otras komandas dežurantus, neizejot cauri atbalsta līmeņiem.

Pēdējā gada laikā kopīgi paveikts daudz, lai uzlabotu Azure Cosmos DB vadības slāņa un vārtejas mērogojamību. Vārtejā pievienota aizsardzība pret pārslodzi un dažādu Azure Cosmos DB metadatu kešošana, lai aizsargātu metadatu nodalījumu. Izmantojot savienojumu pūlus un biežāk atkārtoti lietojot savienojumus, samazināta mūsu Python habitat-service procesu kopuma radītā slodze. Kur iespējams, darba slodzes izvietotas līdzās, bet kritiskās darba slodzes izolētas no bezsaistes darba slodzēm atsevišķos VPC.

Šāda līmeņa kopīga inženiertehniskā izstrāde pēdējā gadā ir bijusi izšķiroša mūsu Azure Cosmos DB stabilitātei. Jebkurai pietiekami lielai vai kritiskai sistēmai vajadzīgs šāds komandas darbs: jānojauc barjeras starp atbildības jomām un jāsadarbojas pāri organizāciju robežām.

Kā minēts I daļā, mūsu pamatprincips ir: vispirms panākt, lai tas darbojas, tad — lai darbojas ātri, un visbeidzot — lēti. Vispirms uzticamība, tad veiktspēja, tad efektivitāte. Habitat bija kļuvusi par OpenAI kritisko infrastruktūru, tāpēc galvenā prioritāte bija tās uzticamība. Kad 2025. gadā sistēma stabilizējās un OpenAI paplašinājās visā pasaulē, par nākamo ierobežojumu lietotājiem un produktu komandām kļuva aizkave.

Skaitļošanas un glabāšanas resursi bieži atradās dažādos reģionos, tāpēc starpreģionu pieprasījumi bija neizbēgami.

Aizkave būtiski atšķīrās atkarībā no datu glabāšanas un pieprasījuma apstrādes vietas. Lai Habitat pieprasījumi tiktu izpildīti ātri, produktu izstrādātāji izmantoja papildu kešošanu klienta pusē, pieprasījumu apvienošanu paketēs, samazināja datubāzes lasīšanas un rakstīšanas operāciju skaitu un, kur vien iespējams, pārcēla darbu ārpus kritiskā izpildes ceļa. Tas radīja dažus interesantus produktu risinājumus, kas bija noturīgāki pret datubāzes problēmām, taču arī sarežģīja produktus un palēnināja to pilnveidi. Tādējādi netika sasniegts Habitat mērķis — veicināt ātru produktu izstrādi bez vajadzības iedziļināties datubāzē.

2026. gadā tam esam pievērsuši lielu uzmanību un izstrādājuši daudzslāņainu stratēģiju lasīšanas veiktspējas optimizēšanai, jo lasīšana veido vairāk nekā 90 % Habitat pieprasījumu:

Lietotājiem ar datu rezidences vietas prasībām mums ir vairāki Azure Cosmos DB konti dažādos Azure reģionos visā pasaulē. Arī lietotājiem bez stingrām datu rezidences vietas prasībām datu izvietošana tuvumā uzlabo lietošanas pieredzi, samazinot aizkavi.

Praksē ārpus datu rezidences vietas prasību izpildes mēs to nevaram īstenot plaši, jo izvietojumu ierobežo mākoņa fizisko resursu pieejamība. Mūsu datu kopas ir tik lielas, ka daudzos reģionos nepietiek vietas milzīgajam datu apjomam, kas atbilstu šo reģionu lietotāju datplūsmas daļai.

Reģionos ar ierobežotiem datu centru, elektroapgādes vai dzesēšanas resursiem dažkārt jāizvēlas: rezervēt resursus līdzās izvietotai krātuvei un samazināt Habitat aizkavi vai izmantot tos papildu skaitļošanai pieprasījumu apstrādē un krātuves pieprasījumus novirzīt tālāk.

Tāpēc izvietojuma lēmumos bieži jārod kompromiss starp A) aizkaves optimizēšanu dažādiem produktiem un lietotāju grupām un B) pieejamo glabāšanas un skaitļošanas jaudu.

Darba slodzēm, kur aizkave ir viskritiskākā, piemēram, katram pieprasījumam vajadzīgajiem autentifikācijas metadatiem, mēs samazinām turp-atpakaļ laiku (RTT) starp skaitļošanas resursiem un Habitat, izmantojot plaši replicētus Azure Cosmos DB kontus ar daudziem sekundārajiem reģioniem. Daži konti tiek replicēti visos 40 Azure reģionos, kuros apstrādājam datplūsmu; citi — vismaz vienā reģionā katrā kontinentā.

Agrāk, nekā vēlējāmies, Habitat nācās izveidot lietotājiem nemanāmu datu pārvietošanas un maršrutēšanas slāni, lai datu kopas varētu pārvietot starp kontiem ar dažādām replikācijas topoloģijām.

Tomēr arī šo pieeju galu galā ierobežo resursu pieejamība, tāpēc to izmantojam tikai dažām īpaši atlasītām datu kopām.

Habitat darba slodzēs pārliecinoši dominē lasīšana: lietotnes pastāvīgi izgūst iestatījumus, stāvokli un citas īpašības. Nesamērīgi lielu datplūsmas daļu rada salīdzinoši neliela bieži izmantotu datu tipu kopa. Tāpēc sistēma ir īpaši piemērota sadalītai kešošanai. Kešošana uzlabo veiktspēju viena reģiona infrastruktūrā, bet, darbojoties vairākos reģionos, ieguvums ir vēl lielāks, jo tā var „noslēpt” starpreģionu aizkavi.

Habitat esam integrējuši sadalītas kešatmiņas slāni, ko pārbauda pirms vēršanās datubāzē. Tas glabā nesen izmantotu objektu un saišu kopijas Valkey serveros, kas mūsu infrastruktūrā atrodas tuvu lietotāju pieprasījumu apstrādes vietai. Parasti šādās kešatmiņās izmanto derīguma laiku (TTL), līdzsvarojot kešatmiņas trāpījumu īpatsvaru un datu novecojumu. Īss TTL samazina datu novecojumu, bet mazina kešošanas ieguvumu, jo ierakstu derīgums kešatmiņā ātri beidzas un tie jāizgūst biežāk. Garāks TTL palielina trāpījumu īpatsvaru, taču ilgāk tiek atgriezti novecojuši dati, pasliktinot lietošanas pieredzi un padarot produkta darbību neparedzamu.

Cita pieeja ir tieši anulēt kešatmiņas ierakstus, kad lietotne veic rakstīšanas operācijas ar tiem pašiem pamatdatiem. Tas būtiski uzlabo kešatmiņas datu aktualitāti, taču var būt grūti īstenojams pareizi. Joprojām pastāv arī vairāki robežgadījumi, piemēram, daļējas kļūmes, kuru dēļ kešatmiņā paliek novecojuši dati. Izvietojums vairākos reģionos šīs problēmas saasina: starpreģionu tīkli ir mazāk uzticami, un kešatmiņas darbība var sacensties ar pamatkrātuves replikāciju. Papildinot šo pieeju ar TTL, var ierobežot maksimālo datu novecojumu, taču saglabājas iepriekš aprakstītais TTL kompromiss.

Esam izvēlējušies pilnīgāku anulēšanas pieeju, sekojot tādu sistēmu piemēram kā Meta izstrādātā TAO. Habitat integrētā kešatmiņa izmanto datu izmaiņu tveršanu (CDC) ar Azure Cosmos DB izmaiņu plūsmu, lai dažu sekunžu laikā izplatītu anulēšanas paziņojumus visā pasaulē, panākot augstu trāpījumu īpatsvaru un mazu datu novecojumu. Mūsu infrastruktūras pakalpojums apstrādā šo izmaiņu plūsmu un, atjauninoties pamatdatiem, anulē ierakstus vietējās kešatmiņās. Nākamajā lasīšanas reizē datu kešatmiņā vairs nav, un tā tiek aizpildīta ar jaunāko datu versiju.

Esam arī būtiski samazinājuši aizkavi pašā Habitat pakalpojumā, pārrakstot kodu Rust valodā, kas nodrošina labāku veiktspēju nekā sākotnēji izmantotā Python.

Kopā šīs izmaiņas samazināja kopējo globālo lasīšanas aizkaves p50 no aptuveni 120 ms līdz aptuveni 10 ms — 12 reižu uzlabojums, kopš šī gada sākumā pievērsāmies veiktspējai.

Lai gan kešošana ir krasi samazinājusi aizkaves mediānu, lēnākajiem pieprasījumiem joprojām jāizgūst nekešoti dati no pamatkrātuves, bieži — attālos reģionos. Pieaugot pieejamajiem resursiem un uzlabojot glabāšanas efektivitāti, plānojam risināt fundamentālāku uzdevumu: jau sākotnēji izvietot datus tuvāk to izmantošanas vietai.

Uzticama un mērogojama CDC — datubāzes izmaiņu nodošana pakārtotajām sistēmām — ir kritiski svarīga ne tikai Habitat kešošanas stratēģijai. Miljoniem izmaiņu sekundē no tūkstošiem konteineru un miljoniem konteineru nodalījumu plūst caur vairāk nekā simt Kafka tēmām. Tās nodrošina arī ar laiku saskaņotus sekundāros indeksus, datu pārvietošanas konveijerus, bezsaistes analītiku un citas reāllaika produktu funkcijas. Mūsu pamatinfrastruktūrai paplašinoties visā pasaulē, rindu izmaiņu uzraudzība ir kļuvusi arvien sarežģītāka. Ja klients vēlas reģistrēt atzvanfunkciju, ko izpildīt ikreiz, kad mainās tā datu tipa rindas, vispirms cita starpā jānosaka, kuros Cosmos kontos un konteineros ir tā dati un kurš CDC pakalpojuma izvietojums attiecīgajos reģionos uzrauga šos konteinerus. Jānodrošina arī atbilstošs CDC darba procesu kopuma, Kafka un sava patērētāja mērogs. Mūsu CDC platformas mērķis ir paslēpt šo sarežģītību no produktu izstrādātājiem. Tā nodrošina vienkāršu saskarni, kur klients reģistrē funkciju, kas jāizsauc mainītajām rindām, bet mēs parūpējamies par visu savienošanu un mērogošanu.

Iekšējs vadības slānis nepārtraukti nodrošina visu vajadzīgo konteineru izmaiņu tveršanu, izvēlas Cosmos reģionus lasīšanai un efektīvi sadala darbu starp tūkstošiem darba procesu vairākos ģeogrāfiskajos reģionos. Repliku reģionu un zemākas prioritātes plūsmas lasīšanas izmantošana pasargā pret aizkavi jutīgo Habitat datplūsmu no fona tveršanas slodzes. Tik lielā procesu kopumā pastāvīgi notiek darba procesu avārijas, konteineru problēmas, pagaidu tiesību krātuves kļūdas, konfigurācijas kļūdas un galamērķu atteices. Nostiprinājām CDC darba procesu dzīvescikla un pagaidu tiesību pārvaldību, izolējām plūsmu kļūmes un izveidojām aizsargmehānismus konfigurācijas izmaiņām un jaunu versiju ieviešanai. Izmantojam nepiegādāto ziņojumu rindas, lai pastāvīgas piegādes kļūmes nebloķētu rindā sekojošo ziņojumu apstrādi. Reģionālus darbības pārtraukumus pārvaram, pārslēdzot lasītājus uz citiem Cosmos reģioniem. Mūsu mērogā nācās pat mainīt Azure CDC SDK, lai padarītu kontrolpunktu saglabāšanu efektīvāku: apvienojam tos atmiņā paketēs un ierakstām tikai periodiski.

Lai gan Habitat iekšējā Azure Cosmos DB izmantošana ir sarežģīta, tās galvenā vērtība vienmēr ir bijusi infrastruktūras detaļu paslēpšana no produktu izstrādātājiem, lai paātrinātu izstrādi. Arī mūsu CDC platformai ir tas pats mērķis.

Neliela komanda spēja uzturēt strauji augošu glabāšanas platformu, apzināti saglabājot šauru glabāšanas API funkcionalitāti, turpinot mērogot Python pakalpojumu un prioritāri risinot steidzamākos inženiertehniskos uzdevumus. Vispirms pievērsāmies kritiski svarīgās produktu datplūsmas uzticamībai, tad lasīšanas veiktspējai lietotājiem visā pasaulē un visbeidzot — darbības efektivitātei lielā mērogā. Šī pieeja ļāva strauji augt un atbalstīt jaunus lietošanas gadījumus, vienlaikus uzlabojot uzticamību, veiktspēju un produktu izstrādes tempu.

Lai mērogotu Habitat un sarunu glabāšanu nākamajam miljardam lietotāju, mums jāatrisina datu replicēšanas grūtības visā infrastruktūrā vēl lielākā mērogā. Lai tam laikus sagatavotos, paši izstrādājam eksabaitu mēroga tiešsaistes glabāšanas sistēmu, kas optimizēta apjomīgajiem Habitat datu tipiem. Šī vēl izstrādē esošā sistēma apvieno Rockset izmantoto RocksDB Cloud kodolu ar Raft balstītu replikāciju. Tā īsteno tādu pašu dokumentu modeli kā Azure Cosmos DB, bet izmanto no skaitļošanas atdalītu krātuvi un fizisku replikāciju, lai samazinātu vajadzīgo zibatmiņas apjomu, pretī pieņemot mazāku maksimālo vaicājumu skaitu sekundē.

Ja jūs interesē darbs pie šādiem datu infrastruktūras uzdevumiem robežšķirtnes mērogā, apskatiet mūsu vakances⁠.