Nggedhekake panyimpenan online kanthi cepet kanggo 1 milyar luwih pangguna ChatGPT (Bagean II)

Kabeh produk OpenAI mbutuhake akses data sing cepet lan bisa diandelake, sing disedhiyakake dening platform panyimpenan kita, Habitat. Platform iki kudu nanggapi sajrone milidetik kanggo luwih saka 1 milyar pangguna ing 40 wilayah geografis. Infrastruktur kita ngadhepi tantangan sing luar biasa: nyengkuyung tuwuh sing cepet banget lan kasus panggunaan anyar, sinambi terus ningkatake kaandalan, kinerja, lan kecepetan pangembang produk. Kanggo ngrampungake tantangan kasebut, kita kudu mikir maneh carane platform panyimpenan online kita dirancang lan dioperasikake. Kita terus nimbang paedah lan kakurangan saben pilihan kanthi pola iki: dhisik kudu cukup bisa diandelake kanggo lalu lintas produk sing kritis, banjur cukup cepet kanggo pangguna global, lan pungkasane bisa dioperasikake kanthi trampil ing skala gedhe banget.

Seri rong bagean iki nerangake carane kita ngembangake Habitat saka pustaka klien lan database prasaja dadi platform panyimpenan sing disebar sacara global lan nglayani luwih saka 500 petabyte data. Bagean I fokus marang owah-owahane Habitat saka klien Python dadi layanan. Bagean kasebut uga ngrembug teknik sing ngidini kita ngembangake layanan adhedhasar Python nganti adoh ngluwihi wates sing dianggep praktis dening akeh wong.

Ing tulisan iki, Bagean II, kita nerangake carane nggedhekake skala komponen panyimpenan dhasare: Azure Cosmos DB. Liwat kerja bareng sing raket karo tim Azure, kita nemokake pendekatan multitenant sing bisa ditrapake nganggo kontainer sing dikelola bareng, kanthi kinerja maca sing apik banget ing skala global sing gedhe.

Nalika perusahaan saya gedhe, tim infrastruktur asring ngalih saka ngoperasikake sistem tenant tunggal menyang sistem multitenant. Ing sistem tenant tunggal, saben tim bagean produk njaga sisteme dhewe. Iki nyuda jembar dampak gangguan lan menehi wates tanggung jawab uga isolasi beban kerja sing prasaja. Nalika tim lan bagean produk saya akeh, biaya operasi cara iki saya larang. Sistem tenant tunggal ndadekake saben tim produk tanggung jawab ngrancang kapasitas, lan asring nyebabake alokasi sumber daya sing kakehan banget.

Kosok baline, sistem multitenant masrahake kendhali marang tim database pusat sing duwe kawruh lan pengalaman luwih apik kanggo ngalokasikan sumber daya. Nanging, sistem multitenant nuwuhake masalah dhewe, kayata tangga sing ngganggu: siji tenant nggunakake bagean sumber daya sing gedhe banget nganti ngrugekake tenant liyane.

Ing Habitat, kita kudu nimbang kabeh paedah lan kakurangan iki kanggo ngrancang sistem panyimpenan sing bisa diandelake lan efisien ing skala gedhe. Saiki, Habitat dadi lapisan database multitenant kanggo akeh produk OpenAI. Nanging, lakune kita wis muter: saka nggunakake siji kontainer Azure Cosmos DB multitenant, banjur nyiyapake kontainer panyimpenan tenant tunggal, nganti bali maneh nggunakake kontainer multitenant minangka gawan. Perjalanan multitenant kita ing Habitat isih ing tahap awal banget. Kita nyengkuyung akeh kasus panggunaan, nanging bisa nundha investasi ing babagan iki kanthi nggunakake fungsi dhasar bawaan Azure Cosmos DB sabisa-bisa.

Sadurunge ngrembug perjalanan kita nganggo Azure Cosmos DB, iki sawetara konteks dhasar:

• Akun Azure Cosmos DB nemtokake sakumpulan kontainer lan kabijakan replikasi

• Saben kontainer diwenehi kapasitas pangolahan tartamtu ing unit panjaluk saben detik (RU/s)

• Data ing saben kontainer disimpen kanthi cara sharding umum adhedhasar kunci partisi logis sing ditemtokake, kanthi wates panyimpenan lan kapasitas pangolahan saben kunci partisi logis sing wis didokumentasikake

• Azure Cosmos DB ngatur sharding kunci partisi logis menyang partisi fisik dhasar sing cacahe luwih sithik. Partisi kasebut dipecah dadi sawetara partisi fisik nalika panyimpenan ngluwihi ambang wates, utawa nalika kontainer mbutuhake partisi fisik luwih akeh kanggo nyukupi kapasitas pangolahan sing dialokasikan

Wiwitane, kita nglolosake kabeh beban klien lan ngandelake wates 10K RU/s saben kunci partisi logis sing kasebut ing dokumentasi kanggo menehi tekanan balik. Nalika lagi miwiti, kita uga mung nggunakake siji kontainer Azure Cosmos DB gawan ing saben akun. Cara iki mlaku cukup apik, nanging banjur kabukten nuwuhake masalah amarga sawetara sebab:

Amarga pilihan desain API ing wiwitan, kita menehi klien akses langsung kanggo milih kunci partisi logis. Akibate, kita kerep nemoni tabrakan kunci partisi sing umum digunakake, kayata user_id utawa workspace_id, ing maneka kasus panggunaan produk. Amarga kasus panggunaan iki nuduhake wates Azure Cosmos DB ing kunci partisi logis sing padha, desain kasebut mbatesi total kapasitas pangolahan kanggo saben pangguna.

Salah siji masalah umum nalika nggedhekake skala Postgres sadurunge pindhah menyang Habitat lan Azure Cosmos DB yaiku akehe panjaluk saka organisasi utawa kunci sing aktif banget—siji tenant sing ngasilake beban gedhe ora imbang—bisa ndadekake kabeh database mandheg. Kita ngupayakake akeh gaweyan bebarengan kanggo nyimpen kunci kasebut ing cache lan nambah mekanisme lease nalika cache miss, supaya beban saka cache miss ora nganti ngluwihi kemampuane database dhasar.

Sanajan wates ukuran data lan kapasitas pangolahan ing dokumentasi ditrapake kanggo kunci partisi logis, sejatine wates kasebut dileksanakake ing partisi fisik. Ing praktik, iki tegese partisi logis ora bisa tekan 10.000 RU/s. Nanging, wates partisi fisik digunakake bareng karo kabeh kunci partisi logis liyane ing partisi fisik kasebut.

Iki ndadekake tangga sing ngganggu bisa mengaruhi akeh kunci partisi logis sing ora ana gandhengane. Beban kerja sing ngolah data kanggo fitur produk winates bisa ngganggu alur mlebu lan ndhaptar sing dadi fungsi inti.

Wates kapasitas pangolahan saben partisi fisik uga bisa owah, gumantung marang total kapasitas pangolahan sing diwenehake kanggo kontainer Azure Cosmos DB. Kapasitas pangolahan sing dialokasikan kanggo kontainer disebar meh rata ing kabeh partisi fisik kontainer kasebut.

Nalika volume data saya gedhe, partisi fisik pecah lan cacah totale mundhak, dene total kapasitas pangolahan sing dialokasikan tetep. Akibate, wates kapasitas pangolahan efektif saben partisi saya suda nalika ukuran data mundhak.

Kanggo kasus panggunaan kaya blob sing paling akeh mbutuhake panyimpenan, iki nuwuhake pola kegagalan: tuwuhe panyimpenan wae wis bisa nyuda kapasitas pangolahan kanggo beban kerja aktif, sanajan tingkat panjaluk lan panggunaan tetep stabil.

Kontainer kapisah mbantu ngrampungake sebagian masalah wates kunci partisi lan tangga sing ngganggu iki. Kanthi kontainer kapisah, saben kontainer bisa oleh partisi fisik dhewe sing mandiri. Mung maneka beban kerja ing kontainer kasebut sing bisa dadi tangga sing ngganggu utawa tumpang tindih ing ruang kunci partisi. Kakurangane, nyiyapake kontainer anyar tetep mbutuhake gaweyan tambahan—saben kontainer mbutuhake rencana kapasitas dhewe. Mula, kita mung pengin nggawe kontainer ing wates layanan utawa kasus panggunaan sing trep.

Kita wiwit nggunakake kontainer Azure Cosmos DB kapisah kanggo kasus panggunaan anyar sing paling kritis lan mbutuhake isolasi kuwat. Kanthi tambahan skrip kanggo ngatur partisi ringkih, sing nyelarasake total kapasitas pangolahan saben kontainer karo cacah partisi fisike, kita bisa ngendhani meh kabeh masalah sing lagi diadhepi.

Nanging, amarga kita miwiti nganggo kontainer gawan, akeh kasus panggunaan lawas sing kritis isih kepepet ing kono yen datane ora dimigrasi. Kanggo ngreksa layanan kritis sing isih ngandelake data ing kontainer gawan bareng, kita asring menehi saran supaya tim nggawe kontainer kapisah kanggo layanan anyar utawa fitur produk utama. Nalika skala kita mundhak, tekanan ing kontainer gawan saya gedhe lan insiden ing lingkungan produksi uga saya akeh. Kita wiwit nyiyapake kontainer kanggo saben layanan anyar utawa fitur produk gedhe, mung kanggo ngreksa kontainer gawan saka beban tambahan.

Iki nylametake kita saka akeh gangguan ing saindenging situs, lan mbatesi dampake mung ing gangguan utawa mudhune mutu fitur utawa layanan. Nanging, gaweyan tambahan kanggo nyiyapake kontainer anyar pungkasane dadi masalah:

Ing kontainer gawan bareng sing lawas, siji kasus panggunaan anyar sing mundhak saka 0 QPS dadi 1 yuta QPS cilik kemungkinane ngowahi total panggunaan agregat kanthi signifikan. Nanging ing kontainer sing diisolasi, kasus panggunaan anyar sing mundhak saka 0 dadi 1 yuta QPS bisa ateges beban 1.000 kaping luwih gedhe tinimbang beban dhasar sing mung saka uji coba internal.

Kanthi kontainer khusus, saiki tim kudu eling nyiyapake kapasitas pangolahan kontainer luwih dhisik miturut kabutuhan sing dikira-kira nalika peluncuran. Tim produk asring ngluncurake fitur menyang produksi nanging lali nggedhekake kapasitas sadurunge. Akibate, ing dina peluncuran kita kudu ngumpul ing ruang penanganan SEV kanggo nggedhekake kapasitas kontainer ing wektu pungkasan.

Iki minangka paedah utama saka nyampur beban kerja ing sistem multitenant sing kudu kita lepas supaya oleh isolasi luwih apik liwat strategi kontainer iki.

Suwe-suwe, ngawasi panggunaan kontainer khusus uga mbutuhake pangerten produk sing jero babagan kapan lalu lintas bakal owah utawa mundhak.

Kita bisa nyedhiyakake skrip control plane prasaja kanggo nambah kapasitas pangolahan saben kontainer adhedhasar tren tuwuh. Nanging, tanpa tuwuh agregat sing stabil, ngatur kapasitas kanthi bener praktise mbutuhake keterlibatan saben tim produk ing OpenAI kanggo ngrancang kapasitas.

Cara iki ora bisa ngimbangi tuwuhe organisasi, amarga tingkat katliten saben tim sing tanggung jawab layanan nalika nyiyapake sumber daya Azure Cosmos DB beda-beda banget.

Nalika organisasi saya gedhe, masalah operasional kasebut saya angel ditangani ing skala sing saya mundhak. Amarga ora ana siji tim pusat sing ngrancang, akeh tim ora ngrancang kanthi becik. Mula, pungkasane kita bali menyang solusi multitenant lan kerja raket karo tim Azure kanggo ngrampungake masalah multitenant awal liwat desain tenant bareng:

Mbatesi kunci sing paling aktif luwih dhisik nyegah tangga sing ngganggu ngentekake kabeh kapasitas pangolahan sing kasedhiya ing sawijining partisi fisik. Iki nyuda dampak tangga sing ngganggu, yaiku nalika siji kunci sing aktif banget bisa nyebabake gangguan ing saindenging situs.

QoS kanthi tingkatan panjaluk uga nyegah beban kerja offline, kayata panyisipan massal utawa ekstraksi data, nggunakake kabeh kapasitas pangolahan sawijining partisi fisik. Kanthi menehi prioritas luwih endhek marang panjaluk beban kerja iki, panjaluk kasebut diwatesi luwih dhisik. Iki nyegah pambatesan panjaluk interaktif kanthi prioritas luwih dhuwur sing nglayani pangguna pungkasan.

Azure Cosmos DB wis duwe mode serverless sing bisa ngrampungake masalah partisi ringkih kita ing mode kanthi alokasi kapasitas. Nanging, ana kakurangan gedhe: skalane mung mundhak adhedhasar panggunaan panyimpenan, lan panggunaan RU diwatesi nganti 5K RU/s saben partisi fisik. Iki bisa ngrampungake masalah partisi ringkih, nanging ngalangi kita nggedhekake kapasitas kasus panggunaan sing akeh mbutuhake RU.

Tim Azure Cosmos DB nggawe mode serverless anyar sing luwih apik kanggo kita. Mode iki ngidini saben partisi fisik mundhak nganti 10K RU/s lan nambah pamecahan adhedhasar panggunaan RU, saliyane pamecahan adhedhasar panggunaan panyimpenan. Kanthi iki, kita ora perlu maneh ngawasi lan nggedhekake kapasitas kontainer kanthi manual.

Kanthi owah-owahan iki, kita bisa bali nggunakake siji kontainer bareng. Iki nyederhanakake banget perencanaan kapasitas awal utawa terus-terusan kanggo tim produk, nanging tetep njaga isolasi antarane beban kerja. Sajrone pirang-pirang sasi sawise iku, kita ora nemoni insiden alokasi sumber daya utawa tangga sing ngganggu, sanajan pangembangan produk saya cepet.

Nalika perusahaan tekan skala OpenAI, layanan sing dikelola ora maneh sakabehe “dikelola”. Akeh beban kerja dadi kasus sing ora umum ing infrastruktur panyedhiya cloud. Nalika OpenAI dadi salah siji pangguna Azure Cosmos DB paling gedhe, supaya operasine sukses dibutuhake cara sing beda: uji bareng, dasbor bareng, jalur komunikasi langsung antarane tim rekayasa, lan tanggung jawab bareng kanggo pola kegagalan sing mung katon ing skala kita. Saiki, akun Azure Cosmos DB kita sing paling gedhe nyimpen puluhan petabyte data lan nglayani luwih saka 20 yuta QPS. Sapangertene kita, mung perusahaan kita sing wis ngetrapake Azure Cosmos DB ing skala iki.

Ing pungkasan taun 2024, gangguan ing sawijining wilayah nuduhake kanthi cetha sebabe kerja bareng iki dibutuhake. Nalika iku, listrik mati ing wilayah Azure utama kanggo salah siji akun Azure Cosmos DB kita sing paling gedhe. Nalika nindakake failover amarga kedadeyan kasebut, kita ngerti yen akun-akun paling gedhe butuh pirang-pirang jam kanggo ngalih menyang wilayah sekunder. Bab iki durung tau diuji ing skala kita, dening tim kita utawa tim Azure Cosmos DB.

Udakara sesasi sabanjure, nalika mbalekake akun-akun kasebut menyang wilayah asal, kita nyebabake gangguan serius liyane. Lonjakan sambungan bebarengan menyang wilayah asal ngluwihi kemampuane gateway Azure Cosmos DB ing wilayah kasebut. Ana prilaku ora lumrah ing cara klien Azure Cosmos DB mode gateway nangani failover. Iki nyebabake kabeh klien langsung nggawe sambungan lan ngirim panjaluk menyang wilayah asal, sanajan mung sebagian partisi fisik sing wis bali menyang wilayah kasebut.

Ing saben gangguan, OpenAI lan Azure padha nindakake proses penanganan insiden, nemokake sawetara panyebab dhasar, lan ngetrapake perbaikan. Nanging, gangguan iki minangka pratandha masalah sistemis sing luwih gedhe ing cara tim kita lan tim Azure Cosmos DB ngoperasikake lan nguji sistem. Wiwitane, nggunakake layanan sing dikelola ngidini kita maju kanthi cepet lan fokus marang tujuan bisnis. Ing skala gedhe, layanan sing dikelola saya mbutuhake keterlibatan kita lan integrasi jero karo panyedhiya layanan ing kabeh tingkat, saka desain nganti operasi.

Saiki, tim rekayasa Habitat lan Azure bebarengan ngawasi saben lapisan Habitat, saka lapisan layanan kita nganti lapisan panyimpenan fisik Azure Cosmos DB. Kita ngoperasikake lan nguji owah-owahan ing akun Azure Cosmos DB nonproduksi sing ukurane padha karo akun produksi. Kita bebarengan nguji lan nyempurnakake SDK, uga nemtokake praktik paling apik kanggo nggedhekake skala lan nemtokake ukuran akun Azure Cosmos DB kita. Tim rekayasa kita bisa sesambungan langsung liwat Teams. Kita malah wis nyedhiyakake cara kanggo ngirim tandha darurat langsung marang siji lan sijine tanpa liwat tingkatan dhukungan.

Sajrone setaun pungkasan, kita nindakake akeh kerja bareng kanggo ningkatake skalabilitas control plane lan gateway Azure Cosmos DB. Iki kalebu nambah pangreksan saka beban lan caching maneka metadata Azure Cosmos DB ing gateway kanggo ngreksa partisi metadata Azure Cosmos DB; nyuda tekanan saka kumpulan proses habitat-service Python liwat connection pooling lan panganggone sambungan maneh sing luwih akeh; nyelehake beban kerja ing lokasi sing padha yen bisa; lan misahake beban kerja kritis saka beban kerja offline nganggo VPC sing beda.

Kerja bareng rekayasa kanthi tingkat kaya mangkene dadi kunci kestabilan Azure Cosmos DB kita sajrone setaun pungkasan. Sistem apa wae sing cukup gedhe utawa kritis mbutuhake kerja tim kaya iki: ngilangi sekat tanggung jawab lan makarya ngliwati wates organisasi.

Kaya sing kasebut ing Bagean I, prinsip dhasar kita yaiku: gawe supaya bisa mlaku, gawe supaya cepet, gawe supaya irit. Kaping pisan kudu bisa diandelake, banjur kinerja, banjur efisiensi. Habitat wis dadi infrastruktur kritis kanggo OpenAI, mula prioritas kapisan yaiku mesthekake supaya bisa diandelake. Nalika sistem saya stabil ing taun 2025 lan OpenAI ngrembaka sacara global, latensi dadi kendala sabanjure kanggo pangguna lan tim produk.

Kapasitas komputasi lan panyimpenan asring ana ing wilayah sing beda, mula panjaluk lintas wilayah ora bisa diendhani.

Latensi beda-beda banget gumantung marang papan data disimpen lan papan panjaluk dilayani. Supaya panjaluk Habitat bisa diproses kanthi cepet, pangembang produk ngandelake caching tambahan ing sisih klien, nglumpukake panjaluk dadi batch, nyuda operasi maca lan nulis database, lan mindhah tugas metu saka jalur kritis yen bisa. Sanajan ngasilake sawetara desain produk sing narik kawigaten lan luwih tahan marang masalah database, cara iki uga nggawe produk luwih rumit lan nyuda kecepetan iterasi produk. Iki ora cocog karo tujuane Habitat: nyengkuyung pangembangan produk sing cepet tanpa kudu ngerti seluk-beluk database.

Iki dadi fokus utama kita ing taun 2026. Kita wis nyusun strategi kanthi pirang-pirang lapis kanggo ngoptimalake kinerja maca, sing nyakup luwih saka 90% panjaluk Habitat:

Kita duwe sawetara akun Azure Cosmos DB ing maneka wilayah Azure ing saindenging donya kanggo pangguna sing duwe syarat domisili data. Malah kanggo pangguna tanpa syarat domisili data sing ketat, nyelehake data cedhak pangguna uga ndadekake pengalaman panganggone luwih apik amarga latensine luwih endhek.

Ing praktik, kita durung bisa ngetrapake iki kanthi jembar ing njaba kasus panggunaan domisili data, amarga panggonan data diwatesi kapasitas fisik cloud. Amarga kumpulan data kita gedhe banget, akeh wilayah ora bisa nyukupi kabutuhan papan panyimpenan sing gedhe kanggo bagean lalu lintas pangguna sing kudune dilayani.

Ing wilayah sing kapasitas pusat data, listrik, utawa pendinginane winates, kadhang kita kudu milih: nyisihake kapasitas kanggo panyimpenan ing lokasi sing padha supaya latensi Habitat luwih endhek, utawa nggunakake kapasitas kasebut kanggo komputasi layanan tambahan lan ngarahake panjaluk panyimpenan menyang lokasi sing luwih adoh.

Mula, keputusan panggonan data asring kudu nimbang pilihan produk antarane: A) ngoptimalake latensi kanggo maneka produk lan klompok pangguna, lan B) kapasitas dhasar panyimpenan lan komputasi.

Kanggo beban kerja sing paling mbutuhake latensi endhek, kayata metadata autentikasi sing dibutuhake ing saben panjaluk, kita nyuda RTT antarane komputasi lan Habitat nganggo akun Azure Cosmos DB sing direplikasi ing akeh wilayah sekunder. Sawetara akun direplikasi menyang kabeh 40 wilayah Azure sing nglayani lalu lintas kita; liyane direplikasi menyang paling ora siji wilayah ing saben bawana.

Kita kudu mbangun lapisan pamindhahan data lan pangarah rute ing Habitat sing ora katon dening klien, luwih awal tinimbang sing dikarepake, supaya bisa mindhah kumpulan data antarane akun kanthi topologi replikasi sing beda.

Nanging, cara iki pungkasane uga diwatesi kapasitas, mula mung ditrapake kanggo sawetara kumpulan data sing dipilih kanthi tliti.

Beban kerja Habitat umume banget awujud maca data, kanthi aplikasi sing terus njupuk setelan, status, lan properti liyane. Bagean lalu lintas sing gedhe banget asale saka kumpulan data aktif sing relatif cilik, awujud jinis data sing kerep diakses. Mula, sistem iki cocog banget kanggo caching terdistribusi. Caching ningkatake kinerja infrastruktur siji wilayah, nanging paedahe saya gedhe nalika digunakake lintas wilayah, amarga bisa “ndhelikake” latensi lintas wilayah.

Kita wis nggabungake lapisan caching lookaside terdistribusi menyang Habitat. Lapisan iki nyimpen salinan objek lan edge sing bubar diakses ing server Valkey, sing diselehake ing infrastruktur kita cedhak papan panjaluk pangguna diproses. Biasane, cache kaya iki nganggo TTL kanggo ngimbangi tingkat cache hit lan keusangan data. TTL cekak nyuda keusangan data nanging uga nyuda paedah caching, amarga item cepet kedaluwarsa saka cache lan kudu luwih kerep dijupuk maneh. TTL luwih dawa ningkatake tingkat cache hit, nanging nyedhiyakake data lawas luwih suwe, saengga pengalaman pangguna dadi ala lan prilaku produk angel dikira-kira.

Cara liyane yaiku nindakake invalidasi kanthi eksplisit nalika aplikasi nindakake operasi nulis ing data dhasar sing padha. Iki ndadekake data ing cache luwih anyar banget, nanging bisa angel ditrapake kanthi bener. Cara iki uga isih rentan marang sawetara kasus khusus, kayata kegagalan parsial, sing ndadekake data cache tetep lawas. Penerapan ing pirang-pirang wilayah nambah masalah kasebut: jaringan lintas wilayah kurang bisa diandelake, lan proses cache bisa balapan karo replikasi panyimpenan dhasar. Nambah TTL bisa mbatesi suwene data lawas disedhiyakake, nanging isih ngadhepi pilihan paedah lan kakurangan TTL sing padha kaya kasebut ing ndhuwur.

Kita nggunakake cara invalidasi sing luwih maju, ngetutake lakune sistem kaya TAO saka Meta. Cache terintegrasi Habitat ngandelake change data capture (CDC) liwat change feed Azure Cosmos DB kanggo nyebar invalidasi sacara global sajrone sawetara detik. Iki ngasilake tingkat cache hit dhuwur kanthi keusangan data tetep endhek. Sawijining layanan ing infrastruktur kita maca change feed iki lan nindakake invalidasi cache lokal nalika data dhasar dianyari. Iki nyebabake cache miss nalika data diwaca maneh, banjur cache diisi nganggo versi data paling anyar.

Kita uga nyuda latensi kanthi signifikan kanthi ngilangi overhead ing layanan Habitat dhewe, liwat panulisan ulang kode nganggo Rust sing kinerjane luwih apik tinimbang Python sing digunakake sadurunge.

Kanthi bebarengan, owah-owahan iki nyuda p50 wektu maca global sakabèhé saka udakara 120 ms dadi udakara 10 ms, luwih cepet 12 kaping wiwit kita fokus marang kinerja ing wiwitan taun iki.

Sanajan caching wis nyuda latensi median kanthi drastis, panjaluk sing paling alon isih kudu njupuk data sing ora ana ing cache saka panyimpenan dhasar, asring saka wilayah sing adoh. Nalika kapasitas tambahan kasedhiya lan efisiensi panyimpenan saya apik, kita ngrancang ngrampungake tantangan sing luwih dhasar: wiwit awal nyelehake data luwih cedhak karo papan data bakal diakses.

CDC sing bisa diandelake lan digedhekake skalane—nyebar owah-owahan database menyang sistem hilir—dadi komponen kritis ora mung kanggo strategi caching Habitat. Mayuta-yuta owah-owahan direkam saben detik saka ewonan kontainer lan mayuta-yuta partisi kontainer, banjur dialirake liwat luwih saka satus topik Kafka. Aliran iki uga nyengkuyung indeks sekunder sing konsisten kanthi bertahap, pipeline pamindhahan data, analitik offline, lan fitur produk wektu nyata liyane. Nalika infrastruktur panyengkuyung kita ngrembaka sacara global, ngawasi owah-owahan baris data saya rumit. Yen klien pengin ndhaptar callback kanggo mlaku saben baris saka jinis datane owah, ana sawetara bab sing kudu ditindakake dhisik: nemtokake akun lan kontainer Cosmos sing ngemot datane, nemtokake deployment layanan CDC ing saben wilayah sing ngawasi kontainer kasebut, lan ngatur skala kumpulan worker layanan CDC, Kafka, uga konsumene kanthi bener. Platform CDC kita nduweni tujuan ndhelikake kabeh kerumitan iki saka pangembang produk. Minangka gantine, kita nyedhiyakake antarmuka prasaja kanggo klien ndhaptar fungsi sing arep ditimbali nalika baris datane owah, dene kabeh sambungan teknis lan pangaturan skala ditangani dening kita.

Control plane internal terus mesthekake kabeh kontainer sing dibutuhake direkam owah-owahane, milih wilayah Cosmos kanggo sumber wacan, lan mbagekake tugas kanthi efisien marang ewonan worker ing pirang-pirang wilayah geografis. Nggunakake wilayah replika lan maca feed kanthi prioritas luwih endhek ngreksa lalu lintas Habitat sing sensitif marang latensi saka beban kerja perekaman ing latar mburi. Worker mandheg dumadakan, masalah kontainer, kesalahan panyimpenan lease, konfigurasi ora valid, lan kegagalan tujuan kiriman terus kedadeyan ing kumpulan sistem sing gedhe iki. Kita nguwatake siklus urip worker CDC lan penanganan lease, ngisolasi kegagalan antarane aliran, lan mbangun pangaman kanggo owah-owahan konfigurasi lan peluncuran. Kita nggunakake dead letter queue supaya kegagalan pangiriman permanen ora ngalangi antrean ing ngarepe. Kita bisa tetep mlaku nalika ana gangguan wilayah kanthi ngalihake proses maca menyang wilayah Cosmos alternatif. Ing skala kita, kita malah kudu ngowahi SDK CDC Azure supaya implementasi checkpointing luwih efisien, kanthi nglumpukake checkpoint ing memori lan mung nulis menyang panyimpenan kanthi periodik.

Sanajan panggunaan Azure Cosmos DB ing njero Habitat rumit, paedah utamane tetep padha: ndhelikake rincian infrastruktur saka pangembang produk supaya pangembangan produk luwih cepet. Platform CDC kita uga mangkono.

Tim cilik bisa nyengkuyung platform panyimpenan sing tuwuh kanthi cepet kanthi sengaja mbatesi cakupan API panyimpenan, terus nggedhekake skala layanan Python, lan ngutamakake tantangan rekayasa sing paling mendesak. Kaping pisan kita fokus marang kaandalan kanggo lalu lintas produk kritis, banjur kinerja maca kanggo pangguna global, lan pungkasane efisiensi operasional ing skala gedhe. Cara iki ngidini tuwuh kanthi cepet lan kasus panggunaan anyar, sinambi ningkatake kaandalan, kinerja, lan kecepetan pangembangan produk.

Kanggo nggedhekake skala Habitat lan panyimpenan pacelathon kanggo tambahan siji milyar pangguna sabanjure, kita kudu ngrampungake kangelan replikasi data ing saindenging infrastruktur kanthi skala sing luwih gedhe maneh. Kanggo ngantisipasi iki, kita wis mbangun sistem panyimpenan online khusus kanthi skala exabyte sacara internal, sing dioptimalake kanggo jinis data Habitat sing gedhe. Sistem sing isih dikembangake iki nggabungake inti RocksDB Cloud saka Rockset karo replikasi adhedhasar Raft. Sistem iki ngetrapake model dokumen sing padha karo Azure Cosmos DB, nanging nggunakake panyimpenan sing dipisah saka komputasi lan replikasi fisik kanggo nyuda kabutuhan kapasitas flash, kanthi konsekuensi qps puncak sing luwih endhek.

Yen sampeyan kasengsem nggarap infrastruktur data kaya iki ing skala teknologi tercanggih, delengen lowongan kerja kita⁠.