Rýchle škálovanie online úložiska pre vyše miliardu používateľov ChatGPT (II. časť)

Všetky produkty OpenAI potrebujú rýchly a spoľahlivý prístup k údajom, ktorý im poskytuje naša úložná platforma Habitat. Musí reagovať v priebehu milisekúnd pre vyše 1 miliardu používateľov v 40 geografických regiónoch. Naša infraštruktúra čelila mimoriadnej výzve: podporovať prudký rast a nové prípady použitia a zároveň ďalej zlepšovať spoľahlivosť, výkon a rýchlosť práce vývojárov produktov. Zvládnutie tejto výzvy si vyžadovalo prehodnotiť návrh aj prevádzku našej platformy online úložiska. Neustále sme zvažovali kompromisy podľa tohto postupu: najprv dosiahnuť dostatočnú spoľahlivosť pre kritickú produktovú prevádzku, potom rýchlosť pre používateľov na celom svete a napokon efektívnu prevádzku v obrovskom rozsahu.

Táto dvojdielna séria vysvetľuje, ako sme Habitat rozvinuli z jednoduchej klientskej knižnice a databázy na globálne distribuovanú úložnú platformu sprístupňujúcu vyše 500 petabajtov údajov. I. časť sa venovala vývoju Habitatu z klienta v Pythone na službu. Opísali sme v nej aj postupy, vďaka ktorým sme službu založenú na Pythone posunuli ďaleko za hranice toho, čo by mnohí považovali za praktické.

V tomto článku, II. časti série, opisujeme, ako sme škálovali podkladový úložný komponent: Azure Cosmos DB. V úzkej spolupráci s tímom Azure sme dospeli k funkčnému viacnájomnému riešeniu so spoločne spravovanými kontajnermi, ktoré poskytuje vynikajúci výkon čítania v obrovskom globálnom rozsahu.

S rastom firiem infraštruktúrne tímy často prechádzajú od prevádzky jednonájomných systémov k viacnájomným. V jednonájomnej architektúre si každý tím zodpovedný za určitú časť produktu spravuje vlastný systém. To obmedzuje dosah výpadkov, jasne vymedzuje zodpovednosť a izoluje záťaž. S rastúcim počtom tímov a častí produktov však takáto prevádzka zdražuje. Jednonájomná architektúra prenáša zodpovednosť za plánovanie kapacity na každý produktový tím a často vedie k prideľovaniu výrazne nadbytočných zdrojov.

Viacnájomná architektúra naopak zveruje riadenie centrálnemu databázovému tímu, ktorý má lepšie znalosti a skúsenosti s prideľovaním zdrojov. Prináša však vlastné problémy, napríklad hlučných susedov: jeden nájomca spotrebúva neobvykle veľký podiel zdrojov na úkor ostatných.

Pri návrhu spoľahlivého a efektívneho úložného systému Habitat vo veľkom rozsahu sme museli zvážiť všetky tieto kompromisy. Dnes je Habitat viacnájomnou databázovou vrstvou pre mnohé produkty OpenAI, no prešli sme cestou, ktorá sa uzavrela do kruhu: od jedného viacnájomného kontajnera Azure Cosmos DB cez zriaďovanie jednonájomných podkladových kontajnerov až späť k viacnájomnému kontajneru ako predvolenému riešeniu. S viacnájomnou architektúrou v Habitate sme stále len na začiatku. Podporujeme širokú škálu prípadov použitia, no investície do tejto oblasti sme dokázali odložiť tým, že všade, kde sa dalo, využívame vstavané základné mechanizmy Azure Cosmos DB.

Skôr než opíšeme našu cestu s Azure Cosmos DB, uvedieme niekoľko základných informácií:

• Účet Azure Cosmos DB definuje množinu kontajnerov a politiku replikácie

• Každému kontajneru je pridelená určitá priepustnosť v jednotkách požiadaviek za sekundu (RU/s)

• Údaje v každom kontajneri sa ukladajú bežným spôsobom rozdeľovania podľa určeného kľúča logickej partície. Na každý takýto kľúč sa vzťahujú zdokumentované limity úložiska a priepustnosti

• Azure Cosmos DB rozdeľuje kľúče logických partícií medzi menší počet podkladových fyzických partícií. Tie ďalej delí, keď objem údajov prekročí prahovú hodnotu alebo keď kontajner potrebuje viac fyzických partícií na zabezpečenie pridelenej priepustnosti

Pôvodne sme prepúšťali všetku klientsku záťaž a pri regulácii toku požiadaviek sme sa spoliehali na deklarovaný limit 10 tis. RU/s na kľúč logickej partície. Na začiatku sme tiež v každom účte používali len jeden predvolený kontajner Azure Cosmos DB. Fungovalo to pomerne dobre, no z niekoľkých dôvodov sa ukázali problémy:

V dôsledku prvotných rozhodnutí pri návrhu API sme výber kľúča logickej partície sprístupnili priamo klientom. Preto pri rôznych prípadoch použitia produktov často dochádza ku kolíziám bežne používaných kľúčov partícií, napríklad user_id alebo workspace_id. Keďže tieto prípady použitia zdieľali limity Azure Cosmos DB pre rovnaké kľúče logických partícií, takýto návrh obmedzoval celkovú priepustnosť pre daného používateľa.

Pred prechodom na Habitat a Azure Cosmos DB sme pri škálovaní Postgresu často čelili tomu, že množstvo požiadaviek z veľmi vyťaženej organizácie alebo na veľmi vyťažený kľúč mohlo vyradiť celú databázu. Stačil teda jediný nájomca vytvárajúci neúmerne vysokú záťaž. Spoločne sme vynaložili značné úsilie na ukladanie týchto kľúčov do vyrovnávacej pamäte a zavedenie mechanizmu dočasných oprávnení pri nenájdení údajov v nej, aby následná záťaž nezahltila podkladovú databázu.

Hoci sa zdokumentované limity objemu údajov a priepustnosti vzťahujú na kľúče logických partícií, v skutočnosti sa uplatňujú na úrovni fyzickej partície. V praxi to znamená, že logické partície nedokážu dosiahnuť 10 000 RU/s. Namiesto toho zdieľajú limity fyzickej partície so všetkými ostatnými kľúčmi logických partícií, ktoré sú na nej umiestnené.

Hluční susedia tak mohli ovplyvňovať mnohé nesúvisiace kľúče logických partícií. Úlohy pracujúce s údajmi pre okrajové funkcie produktov narúšali základné procesy prihlasovania a registrácie.

Aj limit priepustnosti danej fyzickej partície sa mení podľa celkovej priepustnosti pridelenej kontajneru Azure Cosmos DB. Pridelená priepustnosť kontajnera sa rozdeľuje približne rovnomerne medzi jeho fyzické partície.

S rastúcim objemom údajov sa fyzické partície delia. Ich celkový počet tak rastie, no celková pridelená priepustnosť zostáva nezmenená. Výsledkom je, že s rastúcim objemom údajov klesá efektívny limit priepustnosti na partíciu.

Pri našich prípadoch použitia s najväčšími nárokmi na úložisko, podobných ukladaniu blobov, tak vzniká problém: samotný rast objemu uložených údajov znižuje dostupnú priepustnosť pre aktívne úlohy, aj keď počet požiadaviek a využitie zostávajú stabilné.

Samostatné kontajnery pomáhajú čiastočne riešiť tieto limity kľúčov partícií aj problém hlučných susedov. Každému samostatnému kontajneru možno prideliť vlastné nezávislé fyzické partície. Hlučnými susedmi alebo zdrojom prekrývania v priestore kľúčov partícií tak môžu byť len rôzne úlohy v rámci toho istého kontajnera. Zriaďovanie nových kontajnerov však prináša určitú réžiu: každý kontajner si vyžaduje vlastné plánovanie kapacity. Preto chceme kontajnery vytvárať len tam, kde má zmysel oddeliť služby alebo prípady použitia.

Pre najkritickejšie nové prípady použitia vyžadujúce dôslednú izoláciu sme začali používať samostatné kontajnery Azure Cosmos DB. V kombinácii so skriptom, ktorý riešil slabé partície zosúlaďovaním celkovej pridelenej priepustnosti každého kontajnera s počtom jeho fyzických partícií, sme sa takmer úplne vyhli všetkým dovtedajším problémom.

Keďže sme však začínali s predvoleným kontajnerom, mnohé staršie kritické prípady použitia v ňom, žiaľ, zostávali, kým sa ich údaje nepresunuli. Na ochranu kritických služieb, ktoré stále záviseli od údajov v zdieľanom predvolenom kontajneri, sme tímom často odporúčali vytvárať samostatné kontajnery pre nové služby alebo významné funkcie produktov. S rastúcim rozsahom rástla záťaž predvoleného kontajnera aj počet incidentov v produkcii. Začali sme zriaďovať kontajnery pre každú novú službu alebo väčšiu funkciu produktu, len aby sme predvolený kontajner chránili pred ďalšou záťažou.

To nás uchránilo pred mnohými celoplošnými výpadkami a obmedzilo dosah incidentov na zhoršenie fungovania konkrétnej funkcie alebo služby. Napokon sa však naplno prejavila réžia zriaďovania nových kontajnerov:

V pôvodnom zdieľanom predvolenom kontajneri bolo nepravdepodobné, že by rast nového prípadu použitia z 0 na 1 milión QPS výrazne zmenil celkové súhrnné využitie. V izolovanom kontajneri však rast nového prípadu použitia z 0 na 1 milión QPS mohol znamenať 1 000-násobnú záťaž oproti základnej úrovni tvorenej len interným používaním pri testovaní.

Pri vyhradených kontajneroch museli tímy pamätať na to, aby im pred uvedením produktov pridelili očakávanú priepustnosť. Produktové tímy často nasadili funkcie do produkcie a zabudli vopred navýšiť kapacitu. V deň spustenia sme potom na krízových stretnutiach riešili incidenty a na poslednú chvíľu sa pokúšali zväčšiť kapacitu kontajnerov.

Kombinovanie rôznych záťaží je zásadnou výhodou viacnájomných systémov, o ktorú pri tejto stratégii kontajnerov prichádzame výmenou za lepšiu izoláciu.

Monitorovanie využitia vyhradených kontajnerov si časom vyžadovalo aj podrobnú znalosť produktov a toho, kedy sa ich prevádzka zmení alebo narastie.

Môžeme poskytnúť jednoduchý skript riadiacej vrstvy, ktorý zvyšuje pridelenú priepustnosť každého kontajnera podľa trendov rastu. Bez stabilného súhrnného rastu si však správne škálovanie vyžadovalo zapojenie prakticky každého produktového tímu v OpenAI do plánovania kapacity.

Z organizačného hľadiska sa tento prístup nedal škálovať. Tímy zodpovedné za jednotlivé služby totiž venovali prideľovaniu kapacity v Azure Cosmos DB veľmi rozdielnu mieru pozornosti.

S rastom organizácie bolo čoraz ťažšie zvládať tieto prevádzkové problémy. Keďže plánovanie nemal na starosti jeden centrálny tím, mnohé tímy plánovali nedostatočne. Napokon sme sa preto vrátili k viacnájomnému riešeniu a v úzkej spolupráci s tímom Azure sme vyriešili pôvodné problémy viacnájomnej architektúry návrhom so zdieľaným využívaním:

Prednostné obmedzovanie požiadaviek na najvyťaženejšie kľúče bráni hlučným susedom vyčerpať všetku dostupnú priepustnosť danej fyzickej partície. Znižuje sa tým efekt hlučného suseda, pri ktorom môže jediný vyťažený kľúč ovplyvniť celú službu.

Podobne QoS založená na triedení požiadaviek do úrovní bráni offline úlohám, ako sú hromadné vkladanie či extrakcia údajov, vyčerpať všetku priepustnosť danej fyzickej partície. Požiadavkám týchto úloh prideľujeme nižšiu prioritu, takže sa obmedzia ako prvé. Interaktívne požiadavky s vyššou prioritou, ktoré obsluhujú koncových používateľov, tak zostávajú bez obmedzenia.

Azure Cosmos DB už mala bezserverový režim, ktorý by vyriešil náš problém so slabými partíciami v režime s pridelenou kapacitou. Mal však zásadnú nevýhodu: škáloval len podľa využitia úložiska a obmedzoval využitie RU na 5 tis. RU/s na fyzickú partíciu. Vyriešil by tak slabé partície, no znemožnil by nám škálovať prípady použitia s vysokou spotrebou RU.

Tím Azure Cosmos DB pre nás vytvoril nový, vylepšený bezserverový režim. Každej fyzickej partícii umožnil škálovať až na 10 tis. RU/s a popri delení podľa využitia úložiska zaviedol aj delenie podľa spotreby RU. Kontajnery sme tak už nemuseli monitorovať a škálovať ručne.

Vďaka týmto zmenám sme sa mohli vrátiť k jednému zdieľanému kontajneru. Produktovým tímom sa výrazne zjednodušilo plánovanie kapacity pred spustením aj počas prevádzky, pričom izolácia záťaže zostala zachovaná. Za niekoľko mesiacov odvtedy sme nezaznamenali žiadny incident súvisiaci s prideľovaním kapacity ani s hlučnými susedmi, a to napriek zrýchľujúcemu sa vývoju produktov.

Keď firmy dorastú do veľkosti OpenAI, spravované služby už nie sú až také „spravované“. Mnohé záťaže sa v infraštruktúre poskytovateľa cloudu vymykajú bežným vzorcom. Keď sa OpenAI stala jedným z najväčších používateľov Azure Cosmos DB, úspešná prevádzka si vyžiadala iný prístup: spoločné testy, zdieľané prehľady, priame komunikačné kanály medzi technickými tímami a spoločnú zodpovednosť za zlyhania, ktoré sa objavujú len pri našom rozsahu. Náš najväčší účet Azure Cosmos DB dnes uchováva desiatky petabajtov údajov a obsluhuje viac než 20 miliónov QPS. Pokiaľ vieme, sme jedinou firmou, ktorá nasadila Azure Cosmos DB v takomto rozsahu.

Koncom roka 2024 regionálny výpadok jasne ukázal, prečo bola táto spolupráca nevyhnutná. Výpadok elektriny vtedy zasiahol primárny región Azure jedného z našich najväčších účtov Azure Cosmos DB. Pri následnom núdzovom prepínaní sme zistili, že prepnutie našich najväčších účtov do sekundárneho regiónu by trvalo niekoľko hodín. V našom rozsahu to dovtedy netestoval ani náš tím, ani tím Azure Cosmos DB.

Približne o mesiac neskôr sme pri prepínaní týchto účtov späť do pôvodného regiónu spôsobili ďalší vážny výpadok. Nápor pripojení do pôvodného regiónu zahltil tamojšiu bránu Azure Cosmos DB. Osobitosť v spracovaní núdzového prepnutia klientom Azure Cosmos DB v režime brány spôsobila, že všetci klienti okamžite nadviazali pripojenia a začali posielať požiadavky do pôvodného regiónu, hoci sa tam vrátila len časť fyzických partícií.

Pri každom výpadku OpenAI aj Azure uplatnili svoje postupy riadenia incidentov, identifikovali viacero základných príčin a nasadili opravy. Tieto výpadky však boli prejavom širšieho systémového problému v tom, ako náš tím a tím Azure Cosmos DB zabezpečovali prevádzku a testovanie. Spočiatku nám spravované služby umožňovali postupovať rýchlo a sústrediť sa na obchodné ciele. Vo veľkom rozsahu sú však spravované služby menej spravované a vyžadujú si úzke prepojenie s poskytovateľom na všetkých úrovniach, od návrhu až po prevádzku.

Technické tímy Habitatu a Azure dnes spoločne monitorujú každú vrstvu Habitatu, od našich vrstiev služieb až po fyzické úložné vrstvy Azure Cosmos DB. Prevádzkujeme neprodukčný účet Azure Cosmos DB s veľkosťou zodpovedajúcou produkcii a testujeme na ňom zmeny. Spoločne testujeme a vylepšujeme SDK a určujeme osvedčené postupy škálovania a dimenzovania našich účtov Azure Cosmos DB. Naše technické tímy sú v priamom kontakte cez Teams. Zaviedli sme dokonca možnosť priamo privolať pohotovostnú službu druhej strany bez prechádzania úrovňami podpory.

Za posledný rok sme spoločne odviedli množstvo práce na zlepšení škálovateľnosti riadiacej vrstvy a brány Azure Cosmos DB. Do brány sme pridali ochranu pred preťažením a ukladanie rôznych metadát Azure Cosmos DB do vyrovnávacej pamäte, aby sme chránili partíciu s metadátami. Pomocou fondu pripojení a ich častejšieho opätovného využívania sme znížili záťaž z našich procesov habitat-service v Pythone. Kde to bolo možné, umiestnili sme súvisiace úlohy do rovnakej lokality a kritické úlohy sme oddelili od offline úloh pomocou rôznych VPC.

Takáto úzka technická spolupráca bola za posledný rok kľúčová pre stabilitu nášho nasadenia Azure Cosmos DB. Každý dostatočne veľký alebo kritický systém si vyžaduje takúto tímovú spoluprácu: odstraňovanie bariér medzi oblasťami zodpovednosti a spoluprácu naprieč organizáciami.

Ako sme spomenuli v I. časti, naša základná filozofia znie: najprv nech to funguje, potom nech je to rýchle a napokon lacné. Najprv spoľahlivosť, potom výkon a nakoniec efektívnosť. Habitat sa stal kritickou infraštruktúrou OpenAI, preto bolo prvoradé zabezpečiť jeho spoľahlivosť. Keď sa systém v roku 2025 stabilizoval a OpenAI expandovala do sveta, ďalším obmedzením pre používateľov a produktové tímy sa stala latencia.

Výpočtová a úložná kapacita sa často nachádzali v rôznych regiónoch, takže požiadavkám medzi regiónmi sa nedalo vyhnúť.

Latencia sa výrazne líšila podľa toho, kde boli údaje uložené a kde sa požiadavka spracúvala. Na zrýchlenie požiadaviek na Habitat vývojári produktov využívali dodatočnú vyrovnávaciu pamäť na strane klienta, dávkovanie požiadaviek, minimalizáciu čítania a zápisu do databázy a podľa možnosti presúvali prácu mimo kritickej cesty. Viedlo to síce k zaujímavým návrhom produktov odolnejším voči problémom s databázou, no zároveň to produkty komplikovalo a spomaľovalo ich vývoj. Habitat tak nenapĺňal svoj cieľ podporovať rýchly vývoj produktov bez potreby rozumieť databáze.

V roku 2026 sa na to intenzívne zameriavame. Vypracovali sme viacvrstvovú stratégiu optimalizácie výkonu čítania, ktoré tvorí vyše 90 % požiadaviek na Habitat:

Pre používateľov s požiadavkami na rezidenciu údajov máme viacero účtov Azure Cosmos DB v rôznych regiónoch Azure po celom svete. Aj používateľom bez striktných požiadaviek na rezidenciu údajov prináša uloženie údajov v ich blízkosti lepší používateľský zážitok vďaka nižšej latencii.

V praxi to mimo prípadov vyžadujúcich rezidenciu údajov nedokážeme uplatniť plošne, pretože umiestnenie obmedzuje fyzická kapacita cloudu. Vzhľadom na veľkosť našich súborov údajov mnohé regióny nedokážu poskytnúť obrovskú úložnú kapacitu potrebnú pre ich pomerný podiel používateľskej prevádzky.

V regiónoch s obmedzenou kapacitou dátových centier, napájania či chladenia niekedy stojíme pred priamou voľbou: vyhradiť kapacitu pre úložisko v rovnakom regióne a znížiť latenciu Habitatu, alebo ju využiť na ďalšie výpočtové zdroje na obsluhu požiadaviek a požiadavky na úložisko smerovať ďalej.

Rozhodnutia o umiestnení sú tak často produktovým kompromisom medzi A) optimalizáciou latencie pre rôzne produkty a skupiny používateľov a B) samotnou úložnou a výpočtovou kapacitou.

Pri úlohách s najprísnejšími nárokmi na latenciu, napríklad pri autentifikačných metadátach potrebných pri každej požiadavke, znižujeme čas obehu požiadavky (RTT) medzi výpočtovou vrstvou a Habitatom pomocou účtov Azure Cosmos DB replikovaných do mnohých sekundárnych regiónov. Niektoré účty replikujú údaje do všetkých 40 regiónov Azure, v ktorých obsluhujeme prevádzku, iné aspoň do jedného regiónu na každom kontinente.

Transparentnú vrstvu na presun údajov a smerovanie sme museli do Habitatu zabudovať skôr, než sme chceli, aby sme mohli presúvať súbory údajov medzi účtami s rôznymi replikačnými topológiami.

Aj tento prístup však napokon naráža na kapacitné limity, a preto ho používame len na niekoľko starostlivo vybraných súborov údajov.

V záťaži Habitatu výrazne prevláda čítanie: aplikácie neustále načítavajú nastavenia, stav a ďalšie vlastnosti. Neúmerne veľkú časť prevádzky tvorí pomerne malá pracovná množina často používaných typov. Systém je preto mimoriadne vhodný na využitie distribuovanej vyrovnávacej pamäte. Vyrovnávacia pamäť zlepšuje výkon už v infraštruktúre s jedným regiónom. Pri práci naprieč regiónmi sa jej prínosy násobia, pretože dokáže „skryť“ latenciu medzi regiónmi.

Do Habitatu sme integrovali distribuovanú vrstvu vyrovnávacej pamäte typu lookaside. Ukladá kópie nedávno načítaných objektov a hrán na serveroch Valkey v našej infraštruktúre, blízko miesta spracovania používateľských požiadaviek. Takéto vyrovnávacie pamäte zvyčajne používajú čas platnosti (TTL), ktorý predstavuje kompromis medzi úspešnosťou vyhľadávania a zastaranosťou údajov. Krátke TTL obmedzujú zastarávanie údajov, no znižujú prínos vyrovnávacej pamäte: položkám rýchlo vyprší platnosť a treba ich častejšie načítavať. Dlhšie TTL zvyšujú úspešnosť vyhľadávania, no dlhšie poskytujú zastarané údaje, čo zhoršuje používateľský zážitok a spôsobuje nepredvídateľné správanie produktov.

Ďalším prístupom je explicitne zneplatňovať položky, keď aplikácia zapisuje do tých istých podkladových údajov. To výrazne zlepšuje aktuálnosť údajov vo vyrovnávacej pamäti, no správna implementácia môže byť náročná. Stále pritom hrozia okrajové prípady, napríklad čiastočné zlyhania, po ktorých zostanú vo vyrovnávacej pamäti zastarané údaje. Nasadenia vo viacerých regiónoch tieto problémy prehlbujú: siete medzi regiónmi sú menej spoľahlivé a operácie vyrovnávacej pamäte súperia s replikáciou podkladového úložiska. Doplnenie TTL obmedzuje maximálnu zastaranosť, no stále prináša ten istý základný kompromis opísaný vyššie.

Zvolili sme pokročilejší prístup k zneplatňovaniu, inšpirovaný systémami ako TAO od spoločnosti Meta. Integrovaná vyrovnávacia pamäť Habitatu využíva zachytávanie zmien údajov (CDC) cez kanál zmien Azure Cosmos DB. Zneplatnenia sa tak globálne šíria v priebehu sekúnd, čo zabezpečuje vysokú úspešnosť vyhľadávania pri nízkej zastaranosti údajov. Služba v našej infraštruktúre spracúva tento kanál zmien a pri aktualizácii podkladových údajov zneplatňuje položky v lokálnych vyrovnávacích pamätiach. Pri ďalšom čítaní sa preto údaje vo vyrovnávacej pamäti nenájdu a tá sa naplní ich najnovšou verziou.

Latenciu sme výrazne znížili aj odstránením réžie v samotnej službe Habitat: kód sme prepísali do Rustu, ktorý je výkonnejší než pôvodný Python.

Tieto zmeny spoločne znížili náš celkový globálny 50. percentil latencie čítania z približne 120 ms na približne 10 ms. Odkedy sme sa začiatkom tohto roka začali sústrediť na výkon, ide o 12-násobné zlepšenie.

Hoci vyrovnávacia pamäť výrazne znížila medián latencie, najpomalšie požiadavky stále vyžadujú načítanie údajov z podkladového úložiska, často zo vzdialených regiónov. S pribúdajúcou kapacitou a zlepšovaním efektívnosti úložiska plánujeme riešiť zásadnejšiu výzvu: ukladať údaje už od začiatku bližšie k miestu, odkiaľ sa budú používať.

Spoľahlivé a škálovateľné CDC, teda šírenie zmien databázy do nadväzujúcich systémov, je kľúčové nielen pre stratégiu vyrovnávacej pamäte Habitatu. Milióny zachytených zmien za sekundu z tisícok kontajnerov a miliónov ich partícií prúdia cez viac než sto tém Kafka. Podporujú tiež sekundárne indexy s eventualnou konzistenciou, procesy presunu údajov, offline analytiku a ďalšie funkcie produktov v reálnom čase. S globálnym rastom našej podkladovej infraštruktúry je sledovanie zmien riadkov čoraz zložitejšie. Ak chce klient zaregistrovať funkciu spätného volania pri každej zmene riadkov svojho typu, musí najprv okrem iného zistiť, ktoré účty a kontajnery Cosmos obsahujú jeho údaje a ktoré nasadenie služby CDC ich v príslušných regiónoch sleduje. Musí tiež správne škálovať pracovné procesy služby CDC, Kafku aj svojho konzumenta. Cieľom našej platformy CDC je skryť túto zložitosť pred vývojármi produktov. Namiesto nej ponúka jednoduché rozhranie, v ktorom si klienti zaregistrujú funkciu volanú pri zmene ich riadkov a my zabezpečíme všetky prepojenia aj škálovanie.

Interná riadiaca vrstva nepretržite zabezpečuje zachytávanie zmien zo všetkých potrebných kontajnerov, vyberá regióny Cosmos na čítanie a efektívne rozdeľuje prácu medzi tisíce pracovných procesov vo viacerých geografických regiónoch. Využívanie regiónov s replikami a čítanie kanála zmien s nižšou prioritou chráni prevádzku Habitatu citlivú na latenciu pred záťažou zachytávania zmien na pozadí. V takomto veľkom nasadení neustále dochádza k pádom pracovných procesov, problémom s kontajnermi, chybám úložiska dočasných oprávnení, neplatným konfiguráciám a zlyhaniam cieľových systémov. Zvýšili sme odolnosť životného cyklu pracovných procesov CDC aj správy dočasných oprávnení, izolovali zlyhania medzi tokmi a zaviedli ochranné mechanizmy pre zmeny konfigurácie a nasadzovanie. Používame fronty nedoručených správ, aby trvalé zlyhania doručenia neblokovali správy na začiatku frontu a tým aj tie za nimi. Regionálne výpadky zvládame prepnutím čítacích procesov na iné regióny Cosmos. Pri našom rozsahu sme dokonca museli upraviť SDK pre CDC od Azure, aby efektívnejšie pracovalo s kontrolnými bodmi: zhromažďujeme ich do dávok v pamäti a trvalo ich zapisujeme len v pravidelných intervaloch.

Hoci Habitat interne používa Azure Cosmos DB zložitým spôsobom, jeho hlavným prínosom bolo vždy skryť detaily infraštruktúry pred vývojármi produktov a zrýchliť tak vývoj. Naša platforma CDC nie je výnimkou.

Malý tím dokázal podporovať rýchlo rastúcu úložnú platformu tým, že zámerne udržiaval úzky rozsah úložného API, ďalej škáloval službu v Pythone a uprednostňoval najnaliehavejšie technické výzvy. Najprv sme sa sústredili na spoľahlivosť kritickej produktovej prevádzky, potom na výkon čítania pre používateľov na celom svete a napokon na efektívnu prevádzku vo veľkom rozsahu. Tento prístup umožnil rýchly rast a nové prípady použitia a zároveň zlepšil spoľahlivosť, výkon aj rýchlosť vývoja produktov.

Aby sme Habitat a úložisko konverzácií škálovali pre ďalšiu miliardu používateľov, musíme zvládnuť náročnú replikáciu údajov naprieč našou infraštruktúrou v ešte väčšom rozsahu. V predstihu preto vyvíjame vlastný systém online úložiska s exabajtovou kapacitou, optimalizovaný pre objemné dátové typy Habitatu. Tento vyvíjaný systém spája jadro RocksDB Cloud od spoločnosti Rockset s replikáciou založenou na algoritme Raft. Implementuje rovnaký dokumentový model ako Azure Cosmos DB, no používa oddelené úložisko a fyzickú replikáciu na zníženie potrebnej kapacity flash pamäte výmenou za nižší špičkový počet dopytov za sekundu.

Ak vás zaujíma práca na takýchto projektoch dátovej infraštruktúry v prelomovom rozsahu, pozrite si naše voľné pozície⁠.