Mabilis na pagpapalawak ng online storage para sa mahigit 1 bilyong user ng ChatGPT (Bahagi II)

Kailangan ng lahat ng produkto ng OpenAI ang mabilis at maaasahang access sa data, na ibinibigay ng aming storage platform na Habitat. Kailangan nitong tumugon sa loob ng ilang millisecond para sa mahigit 1 bilyong user sa 40 heograpikong rehiyon. Humarap ang aming imprastraktura sa isang pambihirang hamon: suportahan ang napakabilis na paglago at mga bagong paggamit habang patuloy na pinapahusay ang pagiging maaasahan, performance, at bilis ng pagbuo ng produkto. Upang malutas ito, kinailangan naming muling pag-isipan ang disenyo at pagpapatakbo ng aming online storage platform. Patuloy naming tinimbang ang mga pakinabang at kapalit, ayon sa pagkakasunod na ito: maging sapat na maaasahan para sa kritikal na trapiko ng produkto, maging sapat na mabilis para sa mga user sa buong mundo, at panghuli, maging mahusay sa pagpapatakbo sa napakalaking saklaw.

Ipinapaliwanag ng seryeng ito na may dalawang bahagi kung paano namin binuo ang Habitat mula sa simpleng client library at database tungo sa isang storage platform na nakakalat sa buong mundo at naghahatid ng mahigit 500 petabyte ng data. Nakatuon ang Bahagi I sa pag-unlad ng Habitat mula sa isang Python client tungo sa isang serbisyo. Tinalakay rin nito ang mga paraang nagbigay-daan upang mapalawak namin ang isang serbisyong nakabatay sa Python nang higit pa sa itinuturing ng marami na praktikal.

Sa post na ito, ang Bahagi II, tatalakayin namin kung paano namin pinalawak ang pinagbabatayang bahagi ng storage: ang Azure Cosmos DB. Sa malapit na pakikipagtulungan sa Azure team, nakabuo kami ng praktikal na paraan ng multi-tenancy gamit ang mga container na sama-samang pinamamahalaan, na may napakahusay na performance sa pagbasa sa napakalaki at pandaigdigang saklaw.

Habang lumalaki ang mga kompanya, madalas lumilipat ang mga infrastructure team mula sa pagpapatakbo ng mga single-tenant system tungo sa mga multi-tenant system. Sa single-tenancy, may sariling sistemang pinapanatili ang bawat team na namamahala sa isang bahagi ng produkto. Nalilimitahan nito ang saklaw ng epekto ng mga problema at pinadadali ang pagtukoy ng responsibilidad at paghihiwalay ng mga workload. Habang dumarami ang mga team at bahagi ng produkto, nagiging magastos itong patakbuhin. Sa single-tenancy, bawat product team ang may pananagutan sa pagpaplano ng kapasidad, na madalas humahantong sa labis-labis na paglalaan ng mga resource.

Sa kabilang banda, sa multi-tenancy, nasa isang sentralisadong database team ang kontrol, na may mas malalim na kaalaman at karanasan sa paglalaan ng mga resource. Pero may sarili ring mga problema ang multi-tenancy, gaya ng pag-agaw ng resource: gumagamit ang isang tenant ng di-karaniwang malaking bahagi ng mga resource, kaya naaapektuhan ang iba.

Sa Habitat, kinailangan naming timbangin ang lahat ng ito upang makadisenyo ng isang maaasahan at episyenteng storage system sa malaking saklaw. Ngayon, ang Habitat ay isang multi-tenant database layer para sa maraming produkto ng OpenAI. Pero umikot ang aming paglalakbay: mula sa isang multi-tenant Azure Cosmos DB container, lumipat kami sa paglalaan ng mga single-tenant backing container, bago bumalik sa multi-tenant container bilang default. Nasa maagang yugto pa lang kami ng multi-tenancy sa Habitat: marami kaming sinusuportahang paggamit, pero naipagpaliban namin ang pamumuhunan dito sa pamamagitan ng paggamit ng mga built-in na pangunahing kakayahan ng Azure Cosmos DB hangga't maaari.

Bago talakayin ang aming paglalakbay sa Azure Cosmos DB, narito ang ilang pangunahing kaalaman:

• Tinutukoy ng isang Azure Cosmos DB account ang isang hanay ng mga container at isang patakaran sa replication

• Nilalaanan ang bawat container ng takdang throughput na sinusukat sa request units per second (RU/s)

• Iniimbak ang data sa bawat container sa karaniwang paraan ng sharding ayon sa tinukoy na logical partition key, na may mga dokumentadong limitasyon sa storage at throughput bawat logical partition key

• Pinamamahalaan ng Azure Cosmos DB ang sharding ng mga logical partition key sa mas kaunting pinagbabatayang physical partition. Hinahati ang mga ito sa maraming physical partition kapag lumampas ang storage sa isang threshold o kapag kailangan ng container ng mas maraming physical partition upang masuportahan ang nakalaang throughput

Noong una, pinapayagan naming dumaan ang anumang load mula sa client, at umaasa sa nakasaad na limitasyong 10K RU/s bawat logical partition key upang magbigay ng back pressure. Noong nagsisimula rin kami, iisa lang ang default na Azure Cosmos DB container na ginagamit namin sa bawat account. Sapat naman ito sa simula, pero nagdulot ng mga problema dahil sa ilang dahilan:

Dahil sa mga unang desisyon namin sa API, direktang mga client ang pinapili namin ng logical partition key. Dahil dito, madalas magkapareho ang mga karaniwang partition key, gaya ng user_id o workspace_id, sa iba't ibang paggamit ng produkto. Dahil pinagsasaluhan ng mga paggamit na ito ang mga limitasyon ng Azure Cosmos DB sa parehong logical partition key, nalimitahan ng disenyo ang kabuuang throughput para sa isang user.

Bago kami lumipat sa Habitat at Azure Cosmos DB, isang karaniwang problema sa pag-scale ng Postgres ang kakayahan ng maraming request mula sa isang organisasyon o key na napakataas ng paggamit—isang tenant na lumilikha ng di-proporsiyonadong load—na pabagsakin ang buong database. Malaking sama-samang pagsisikap ang inilaan sa pag-cache ng mga key na iyon at pagdaragdag ng mga lease sa mga cache miss, upang hindi ma-overload ng mga ito ang pinagbabatayang database.

Bagama't ang mga dokumentadong limitasyon sa laki ng data at throughput ay para sa mga logical partition key, sa physical partition talaga ipinapatupad ang mga limitasyon. Sa praktika, ibig sabihin nito ay hindi umaabot sa 10,000 RU/s ang mga logical partition. Sa halip, pinagsasaluhan nila ang mga limitasyon ng physical partition kasama ng lahat ng iba pang logical partition key na naroon.

Dahil dito, naapektuhan ng mga workload na umaagaw ng resource ang maraming hindi kaugnay na logical partition key. Ang mga workload para sa data ng mga feature na iilan lang ang gumagamit ay nakagagambala sa mga pangunahing proseso ng pag-log in at pag-sign up.

Nagbabago rin ang limitasyon sa throughput ng isang physical partition, depende sa kabuuang throughput na itinalaga sa Azure Cosmos DB container. Halos pantay na ipinapamahagi ang nakalaang throughput ng container sa mga physical partition nito.

Habang lumalaki ang dami ng data, nahahati ang mga physical partition. Dumarami ang mga partition, pero hindi nagbabago ang kabuuang nakalaang throughput. Bilang resulta, lumiliit ang aktuwal na limitasyon sa throughput bawat partition habang lumalaki ang data.

Para sa aming mga paggamit na mala-blob at nangangailangan ng pinakamaraming storage, nagdudulot ito ng problemang ang paglaki pa lamang ng storage ay nagpapababa na sa kapasidad ng throughput para sa mga aktibong workload, kahit hindi nagbabago ang dalas ng mga request at ang paggamit.

Bahagyang nalulutas ng magkakahiwalay na container ang mga limitasyong ito sa partition key at ang pag-agaw ng resource ng mga kasabay na workload. Sa paggamit ng magkakahiwalay na container, maaaring magkaroon ang bawat isa ng sarili nitong mga physical partition. Tanging ang mga workload sa loob ng mismong container ang maaaring mag-agawan ng resource o mag-overlap sa partition key space. Ang kapalit, may dagdag na trabaho sa paglalaan ng mga bagong container—kailangan ng hiwalay na pagpaplano ng kapasidad para sa bawat isa. Kaya gusto naming gumawa lang ng container kapag makatuwiran itong ihiwalay ayon sa serbisyo o paggamit.

Nagsimula kaming gumamit ng magkakahiwalay na Azure Cosmos DB container para sa pinakamahahalagang bagong paggamit na nangangailangan ng mahigpit na paghihiwalay. Sinamahan namin ito ng script na tumutugon sa mga partition na kulang sa kapasidad sa pamamagitan ng pagtutugma ng kabuuang nakalaang throughput ng bawat container sa bilang ng mga physical partition nito. Dahil dito, naiwasan namin ang halos lahat ng problemang kinakaharap namin.

Gayunman, dahil nagsimula kami sa isang default na container, sa kasamaang-palad ay naiwan doon ang maraming dating kritikal na paggamit hangga't hindi naililipat ang data. Upang protektahan ang mga kritikal na serbisyong umaasa pa rin sa data sa pinagsasaluhang default na container, madalas naming pinayuhan ang mga team na gumawa ng hiwalay na container para sa mga bagong serbisyo o pangunahing feature ng produkto. Habang lumalawak kami, tumataas ang load sa default na container at dumarami rin ang mga insidente sa production. Nagsimula kaming maglaan ng container para sa bawat bagong serbisyo o malaking feature para lang protektahan ang default na container mula sa dagdag na load.

Naiwasan namin ang maraming pagkaantala sa buong site, at nalimitahan ang epekto sa paghina o pagkawala ng isang feature o serbisyo. Pero kalaunan, naging pabigat din ang dagdag na trabaho sa paglalaan ng mga bagong container:

Sa dating pinagsasaluhang default na container, malabong malaki ang mabago sa kabuuang paggamit kapag ang isang bagong paggamit ay tumaas mula 0 QPS tungo sa 1 milyong QPS. Pero sa isang hiwalay na container, ang pagtaas mula 0 tungo sa 1 milyong QPS ay maaaring mangahulugan ng 1,000x na load kumpara sa baseline na mula lang sa panloob na pagsubok ng produkto.

Sa mga nakalaang container, kailangan nang tandaan ng mga team na maglaan nang maaga ng kapasidad para sa inaasahang throughput sa paglulunsad. Madalas ilabas ng mga product team ang kanilang feature sa production nang nakakalimutang dagdagan muna ang kapasidad. Kaya sa araw ng paglulunsad, nasa mga SEV room kami at nagmamadaling mag-scale up ng mga container.

Ito ang isang pangunahing pakinabang ng pagsasama ng mga workload sa mga multi-tenant system na nawawala sa amin kapalit ng mas mahusay na paghihiwalay gamit ang estratehiyang ito sa container.

Sa paglipas ng panahon, nangailangan din ang pagsubaybay sa paggamit ng mga nakalaang container ng malalim na kaalaman sa produkto upang matukoy kung kailan magbabago o tataas ang trapiko.

Makapagbibigay kami ng simpleng control plane script para dagdagan ang nakalaang throughput ng bawat container batay sa mga trend ng paglago. Pero dahil walang matatag na paglago sa kabuuang paggamit, ang tamang pag-scale ay nangangailangan ng pakikilahok ng halos bawat product team sa OpenAI sa pagpaplano ng kapasidad.

Hindi ito nakasabay sa paglaki ng organisasyon, dahil malaki ang pagkakaiba sa antas ng atensyong ibinibigay ng bawat team sa paglalaan ng kapasidad ng Azure Cosmos DB para sa kanilang serbisyo.

Habang lumalaki ang organisasyon, mas naging mahirap tugunan ang mga problemang iyon sa operasyon. Dahil walang iisang sentral na team na nagpaplano, naging hindi maayos ang pagpaplano ng maraming team. Kaya bumalik kami sa isang multi-tenant na solusyon at nakipagtulungan nang malapitan sa Azure team upang lutasin ang aming mga orihinal na problema sa multi-tenancy gamit ang disenyong shared-tenancy:

Sa paglimita muna sa mga key na pinakamataas ang paggamit, napipigilan ang mga workload na umaagaw ng resource na ubusin ang lahat ng throughput ng isang physical partition. Nababawasan nito ang epekto ng mga ito, kung saan maaaring maapektuhan ang buong site ng isang key na mataas ang paggamit.

Gayundin, pinipigilan ng QoS na nag-uuri ng mga request ayon sa antas ang mga offline workload, gaya ng maramihang pagpasok o pagkuha ng data, na ubusin ang lahat ng throughput ng isang physical partition. Sa pagbibigay ng mas mababang prayoridad sa mga request ng mga workload na ito, sila ang unang nililimitahan. Naiiwasang malimitahan ang mas mataas ang prayoridad na mga interactive request para sa mga end user.

May serverless mode na ang Azure Cosmos DB na makalulutas sana sa problema namin sa mga partition na kulang sa kapasidad sa provisioned mode. Pero may malaking kapalit ito: nag-scale lang ito batay sa paggamit ng storage at nilimitahan ang RU sa 5K RU/s bawat physical partition. Malulutas nito ang problema sa mga partition na kulang sa kapasidad, pero mahahadlangan ang pag-scale up ng mga paggamit na nangangailangan ng maraming RU.

Bumuo ang Azure Cosmos DB team para sa amin ng mas mahusay na serverless mode. Pinahintulutan nito ang bawat physical partition na umabot sa 10K RU/s at nagdagdag ng paghahati batay sa paggamit ng RU, bukod sa paghahati batay sa storage. Dahil dito, hindi na namin kailangang manu-manong subaybayan at dagdagan ang kapasidad ng mga container.

Dahil sa mga pagbabagong ito, nakabalik kami sa paggamit ng iisang pinagsasaluhang container. Lubos nitong pinasimple ang pauna at tuloy-tuloy na pagpaplano ng kapasidad para sa mga product team habang pinananatiling magkahiwalay ang mga workload. Sa mga buwang sumunod, wala kaming naging insidente sa paglalaan ng kapasidad o pag-agaw ng resource, sa kabila ng bumibilis na pagbuo ng produkto.

Kapag umabot ang mga kumpanya sa laki ng OpenAI, hindi na gaanong “pinamamahalaan” para sa kanila ang mga managed service. Maraming workload ang lumalayo sa karaniwan sa imprastraktura ng cloud provider. Nang maging isa ang OpenAI sa pinakamalalaking gumagamit ng Azure Cosmos DB, kinailangan ng ibang paraan upang matagumpay itong mapatakbo: magkakasamang pagsubok, pinagsasaluhang dashboard, direktang ugnayan ng mga engineer, at magkatuwang na pananagutan sa mga uri ng pagkabigong lumilitaw lamang sa ganitong laki. Ngayon, ang pinakamalaki naming Azure Cosmos DB account ay nag-iimbak ng sampu-sampung petabyte ng data at nagsisilbi ng mahigit 20M QPS. Sa pagkakaalam namin, kami lang ang kumpanyang nag-deploy ng Azure Cosmos DB sa ganitong laki.

Noong huling bahagi ng 2024, nilinaw ng isang regional outage kung bakit kailangan ang pagtutulungang ito. Noon, nawalan ng kuryente ang pangunahing rehiyon ng Azure para sa isa sa pinakamalalaki naming Azure Cosmos DB account. Sa isinagawang failover, nalaman naming aabutin ng ilang oras ang paglipat ng pinakamalalaki naming account sa isang sekundaryang rehiyon. Hindi pa ito nasubukan ng aming team o ng Azure Cosmos DB team sa ganitong laki.

Pagkalipas ng halos isang buwan, habang ibinabalik ang mga account sa orihinal na rehiyon, nakapagsimula kami ng isa pang malubhang outage. Na-overload ang Azure Cosmos DB gateway ng orihinal na rehiyon dahil sa sabay-sabay na pagdagsa ng mga koneksyon dito. Dahil sa isang kakaibang asal ng Azure Cosmos DB client sa gateway mode kapag may failover, agad na kumonekta at nagpadala ng mga request ang lahat ng client sa orihinal na rehiyon, kahit bahagi pa lamang ng mga physical partition ang nakababalik doon.

Sa bawat outage, sinunod ng OpenAI at Azure ang kani-kanilang proseso sa pamamahala ng insidente, natukoy ang ilang ugat ng problema, at nag-deploy ng mga pag-aayos. Pero sintomas ang mga outage na ito ng mas malawak na sistemikong problema sa paraan ng pagpapatakbo at pagsubok ng aming team at ng Azure Cosmos DB team. Noong una, nakatulong ang mga managed service upang makakilos kami nang mabilis at makapagpokus sa mga layunin ng negosyo. Sa malaking saklaw, hindi na sapat ang pamamahala ng provider sa mga managed service. Kailangan ang malalim na integrasyon sa service provider sa lahat ng antas, mula disenyo hanggang operasyon.

Ngayon, magkasamang sinusubaybayan ng mga engineering team ng Habitat at Azure ang bawat layer ng Habitat, mula sa aming mga service layer hanggang sa mga physical storage layer ng Azure Cosmos DB. Pinapatakbo at sinusubukan namin ang mga pagbabago sa isang Azure Cosmos DB account na kasinglaki ng nasa production pero hindi ginagamit sa production. Sama-sama naming sinusubukan at pinapahusay ang mga SDK at tinutukoy ang pinakamahuhusay na paraan ng pag-scale at pagtatakda ng laki ng aming mga Azure Cosmos DB account. Direktang nakikipag-ugnayan ang aming mga engineer sa isa't isa sa Teams, at naglaan pa kami ng mga paraan upang direktang magpadala ng agarang alerto sa isa't isa nang hindi na dumadaan sa mga antas ng suporta.

Sa nakaraang taon, malaki ang pinagsamang pagsisikap upang pahusayin ang kakayahang mag-scale ng control plane at gateway ng Azure Cosmos DB. Nagdagdag kami ng proteksiyon laban sa labis na load at caching ng iba't ibang Azure Cosmos DB metadata sa kanilang gateway upang protektahan ang metadata partition nito. Binawasan din namin ang load mula sa aming mga Python habitat-service process sa pamamagitan ng connection pooling at mas madalas na muling paggamit ng koneksiyon, inilagay sa iisang lokasyon ang mga workload kung maaari, at inihiwalay ang mga kritikal na workload sa mga offline workload gamit ang magkakaibang VPC.

Mahalaga ang ganitong antas ng pagtutulungan sa engineering sa katatagan ng aming Azure Cosmos DB sa nakaraang taon. Kailangan ng anumang malaki o kritikal na sistema ang ganitong pagtutulungan: pag-aalis ng mga hadlang sa pagitan ng mga may responsibilidad at pagtatrabaho lampas sa hangganan ng mga organisasyon.

Gaya ng nabanggit sa Bahagi I, ang pangunahing prinsipyo namin ay: paganahin ito, pabilisin ito, at pababain ang gastos. Pagiging maaasahan muna, kasunod ang performance, at saka ang episyenteng paggamit ng mga resource. Naging kritikal na imprastraktura ng OpenAI ang Habitat, kaya ang unang priyoridad ay gawin itong maaasahan. Habang naging mas matatag ang sistema noong 2025 at lumawak ang OpenAI sa buong mundo, latency naman ang naging susunod na hadlang para sa mga user at product team.

Madalas nasa magkaibang rehiyon ang kapasidad para sa compute at storage, kaya hindi maiwasan ang mga request sa pagitan ng mga rehiyon.

Malaki ang pagkakaiba ng latency depende sa kung saan nakaimbak ang data at kung saan pinoproseso ang request. Upang mapabilis ang mga request sa Habitat, umasa ang mga product developer sa dagdag na client-side caching, pagsasama-sama ng mga request sa batch, pagbawas ng pagbasa at pagsulat sa database, at pag-alis ng mga gawain sa critical path hangga't maaari. Bagama't nagbunga ito ng ilang interesanteng disenyo ng produkto na mas matatag laban sa mga problema sa database, naging mas komplikado rin ang mga produkto at bumagal ang mga pag-aayos at pagpapahusay. Hindi nito natupad ang layunin ng Habitat na pabilisin ang pagbuo ng produkto nang hindi kailangang unawain ang database.

Malaking pokus namin ito sa 2026, at bumuo kami ng patong-patong na estratehiya upang pabilisin ang pagbasa, na bumubuo sa mahigit 90% ng mga request sa Habitat:

May ilang Azure Cosmos DB account kami sa iba't ibang rehiyon ng Azure sa buong mundo para sa mga user na may mga kinakailangan sa lokasyon ng data. Kahit para sa mga user na walang mahigpit na kinakailangan sa lokasyon ng data, mas maganda ang karanasan kapag malapit sa kanila ang data dahil mas mababa ang latency.

Sa praktika, hindi namin ito malawakang maipatupad maliban sa mga paggamit na may kinakailangan sa lokasyon ng data, dahil nililimitahan ng pisikal na kapasidad ng cloud ang paglalagyan nito. Dahil sa laki ng aming mga dataset, maraming rehiyon ang walang sapat na storage para sa katumbas nilang bahagi ng trapiko ng mga user.

Sa mga rehiyong limitado ang kapasidad ng datacenter, kuryente, o pagpapalamig, kung minsan ay kailangan naming pumili: magreserba ng kapasidad para sa kalapit na storage at mas mababang latency ng Habitat, o gamitin iyon para sa dagdag na compute na nagsisilbi sa mga request at ipadala ang mga storage request sa mas malayo.

Kaya ang mga desisyon sa paglalagay ay madalas nakabatay sa pagtitimbang ng pangangailangan ng produkto: A) pag-optimisa ng latency para sa iba't ibang produkto at pangkat ng user, at B) kabuuang kapasidad ng storage at compute.

Para sa mga workload na pinakamahalaga ang mababang latency, gaya ng authentication metadata na kailangan sa bawat request, binabawasan namin ang RTT sa pagitan ng compute at Habitat gamit ang mga Azure Cosmos DB account na maraming replica sa mga sekondaryang rehiyon. May mga account na nagre-replicate sa lahat ng 40 rehiyon ng Azure kung saan kami nagsisilbi ng trapiko; ang iba naman ay sa kahit isang rehiyon bawat kontinente.

Kinailangan naming magdagdag sa Habitat, nang mas maaga sa nais namin, ng layer para sa paglipat at pag-route ng data na hindi kailangang asikasuhin ng gumagamit. Sa ganitong paraan, naililipat namin ang mga dataset sa pagitan ng mga account na may magkakaibang replication topology.

Gayunman, limitado pa rin ang paraang ito ng kapasidad, kaya ginagamit lamang ito para sa ilang maingat na piniling dataset.

Karamihan sa mga workload ng Habitat ay read-heavy: tuloy-tuloy na kumukuha ang mga application ng mga setting, state, at iba pang property. Napakalaking bahagi ng trapiko ang mula sa maliit na hanay ng mga uri ng data na madalas gamitin. Dahil dito, angkop na angkop ang sistema sa distributed caching. Napapahusay ng caching ang performance sa imprastrakturang nasa iisang rehiyon, pero mas malaki ang pakinabang kapag maraming rehiyon ang sangkot: maaari nitong “itago” ang latency sa pagitan ng mga rehiyon.

Nagdagdag kami sa Habitat ng isang distributed lookaside caching layer. Nag-iimbak ito ng kopya ng mga kamakailang na-access na object at edge sa mga Valkey server sa aming imprastraktura, malapit sa kung saan pinoproseso ang mga request ng user. Karaniwan, gumagamit ang ganitong mga cache ng TTL na nagbabalanse sa hit rate at pagiging luma ng data. Nababawasan ng maikling TTL ang lumang data, pero nababawasan din ang pakinabang ng caching: mabilis mag-expire ang mga item sa cache kaya mas madalas silang kailangang kunin muli. Napapataas ng mas mahabang TTL ang hit rate, pero mas matagal itong naghahatid ng lumang data, na nagdudulot ng hindi magandang karanasan at di-mahulaan na asal ng produkto.

Isa pang paraan ang tahasang pag-invalidate sa cache kapag nagsusulat ang application sa parehong pinagbabatayang data. Napapanatili nitong mas napapanahon ang naka-cache na data, pero mahirap itong maipatupad nang tama. May mga di-karaniwang sitwasyon din, gaya ng bahagyang pagkabigo, na maaaring mag-iwan ng lumang data sa cache. Lumalala ang mga problemang ito sa mga multi-region deployment dahil hindi gaanong maaasahan ang network sa pagitan ng mga rehiyon, at nagkakaroon ng race condition sa pagitan ng cache at replication ng pinagbabatayang storage. Nalilimitahan ng pagdaragdag ng TTL ang pinakamahabang panahong maaaring luma ang data, pero nananatili ang nabanggit na kompromiso sa TTL.

Gumamit kami ng mas advanced na paraan ng invalidation, na sumusunod sa mga sistemang gaya ng TAO ng Meta. Umaasa ang integrated cache ng Habitat sa change data capture (CDC) sa pamamagitan ng change feed ng Azure Cosmos DB upang maipalaganap ang mga invalidation sa buong mundo sa loob ng ilang segundo. Nagbibigay ito ng mataas na hit rate habang kaunti ang lumang data. Isang serbisyo sa aming imprastraktura ang tumatanggap ng change feed na ito at nag-i-invalidate sa mga lokal na cache kapag na-update ang pinagbabatayang data. Nagdudulot ito ng cache miss sa susunod na pagbasa sa data, at napupunan ang cache ng pinakabagong bersiyon nito.

Malaki rin ang ibinaba ng latency nang bawasan namin ang overhead sa mismong serbisyo ng Habitat sa pamamagitan ng muling pagsulat ng code sa Rust, na mas mabilis kaysa sa orihinal na Python.

Sama-sama, ibinaba ng mga pagbabagong ito ang aming pangkalahatang global read p50 mula sa humigit-kumulang 120 ms tungo sa 10 ms—12x na mas mabilis mula nang tutukan namin ang performance nitong unang bahagi ng taon.

Bagama't lubhang ibinaba ng caching ang median latency, kailangan pa rin ng pinakamabagal na mga request na kumuha ng hindi naka-cache na data sa pinagbabatayang storage, na madalas nasa malalayong rehiyon. Habang nagiging available ang mas maraming kapasidad at nagiging mas episyente ang storage, plano naming tugunan ang mas pundamental na hamon: ilagay ang data malapit sa gagamit nito sa simula pa lang.

Mahalaga ang maaasahan at kayang lumawak na CDC—ang pagpapasa ng mga pagbabago sa database sa mga downstream system—hindi lang sa estratehiya ng Habitat sa caching. Milyon-milyong pagbabagong nakukuha bawat segundo mula sa libo-libong container at milyon-milyong partition ang dumadaloy sa mahigit isang daang Kafka topic. Sinusuportahan din ng mga ito ang mga eventually consistent na secondary index, data-movement pipeline, offline analytics, at iba pang real-time na feature ng produkto. Habang lumalawak sa buong mundo ang aming pinagbabatayang imprastraktura, lalong nagiging komplikado ang pagsubaybay sa mga pagbabago sa row. Kung gustong magrehistro ng client ng callback na tatakbo tuwing nagbabago ang mga row ng kanilang uri ng data, kailangan muna nilang tukuyin, bukod sa iba pa, kung aling mga Cosmos account at container ang may hawak ng kanilang data at kung aling CDC service deployment ang sumusubaybay sa mga iyon sa bawat rehiyon. Kailangan din nilang wastong i-scale ang mga CDC service worker, Kafka, at kanilang consumer. Layunin ng aming CDC platform na alisin ang lahat ng komplikasyong ito para sa mga product developer. Sa halip, nagbibigay ito ng simpleng interface kung saan nagrerehistro ang mga client ng function na tatawagin kapag nagbago ang kanilang mga row, habang kami ang bahala sa lahat ng koneksiyon at pag-scale.

Patuloy na tinitiyak ng isang panloob na control plane na nakukuha ang mga pagbabago sa lahat ng kinakailangang container, pinipili kung aling mga rehiyon ng Cosmos ang babasahin, at mahusay na ipinapamahagi ang trabaho sa libo-libong worker sa iba't ibang heograpikong rehiyon. Pinoprotektahan ng paggamit ng mga replica region at mas mababang priyoridad na pagbasa sa feed ang trapiko ng Habitat na sensitibo sa latency mula sa mga background capture workload. Sa ganito karaming worker, patuloy na nangyayari ang mga worker crash, problema sa container, error sa lease store, di-wastong configuration, at pagkabigo sa destinasyon. Pinatatag namin ang lifecycle ng CDC worker at paghawak sa lease, pinigilang kumalat ang mga pagkabigo sa pagitan ng mga stream, at nagdagdag ng mga proteksiyon para sa mga pagbabago sa configuration at rollout. Gumagamit kami ng mga dead letter queue upang hindi maharang ang pila dahil sa mga permanenteng pagkabigo sa paghahatid. Nakakayanan namin ang mga regional outage sa pamamagitan ng paglipat ng mga reader sa ibang rehiyon ng Cosmos. Sa laki ng aming sistema, kinailangan pa naming baguhin ang CDC SDK ng Azure upang gawing mas episyente ang checkpointing nito: pinagsasama-sama muna sa memory ang mga checkpoint at pana-panahon lang isinusulat ang mga ito.

Bagama't komplikado ang panloob na paggamit ng Habitat sa Azure Cosmos DB, lagi nitong layunin na alisin sa mga product developer ang pangangailangang asikasuhin ang mga detalye ng imprastraktura upang mapabilis ang pagbuo ng produkto. Ganoon din ang aming CDC platform.

Nasuportahan ng isang maliit na team ang mabilis na lumalaking storage platform sa pamamagitan ng sadyang paglilimita sa saklaw ng storage API, patuloy na pag-scale ng serbisyo sa Python, at pag-una sa pinakamahihigpit na pangangailangan sa engineering. Inuna namin ang pagiging maaasahan para sa kritikal na trapiko ng produkto, kasunod ang bilis ng pagbasa para sa mga user sa buong mundo, at panghuli ang episyenteng operasyon sa malaking saklaw. Nagbigay-daan ito sa mabilis na paglago at mga bagong paggamit habang pinapahusay ang pagiging maaasahan, performance, at bilis ng pagbuo ng produkto.

Upang mapalawak ang Habitat at storage ng pag-uusap para sa susunod na bilyong user, kailangan naming tugunan ang hirap ng pag-replicate ng data sa aming imprastraktura sa mas malaking saklaw pa. Bilang paghahanda, bumubuo kami ng sarili naming online storage system na may kapasidad sa antas ng exabyte, na naka-optimize para sa malalaking uri ng data ng Habitat. Pinagsasama ng sistemang ito na ginagawa pa ang RocksDB Cloud core mula sa Rockset at replication na nakabatay sa Raft. Ipinapatupad nito ang parehong document model ng Azure Cosmos DB, pero gumagamit ng disaggregated storage at physical replication upang bawasan ang kinakailangang flash capacity, kapalit ng mas mababang pinakamataas na qps.

Kung interesado kang magtrabaho sa ganitong mga proyekto ng data infrastructure sa frontier na saklaw, tingnan ang aming mga bakanteng posisyon⁠.