Mempercepat skala penyimpanan online bagi lebih dari 1 miliar pengguna ChatGPT (Bagian II)

Semua produk OpenAI membutuhkan akses data yang cepat dan andal, yang disediakan oleh platform penyimpanan kami, Habitat. Platform ini harus merespons dalam hitungan milidetik untuk lebih dari 1 miliar pengguna di 40 region geografis. Infrastruktur kami menghadapi tantangan luar biasa: mendukung pertumbuhan pesat dan kasus penggunaan baru sambil terus meningkatkan keandalan, performa, dan kecepatan kerja pengembang produk. Untuk mengatasinya, kami harus memikirkan ulang desain dan pengoperasian platform penyimpanan online kami. Kami terus mengevaluasi kompromi yang diperlukan dengan urutan: pertama, cukup andal untuk trafik produk kritis; lalu cukup cepat bagi pengguna global; dan akhirnya, mampu beroperasi secara tangkas pada skala masif.

Seri dua bagian ini menjelaskan bagaimana kami mengembangkan Habitat dari pustaka klien dan database sederhana menjadi platform penyimpanan terdistribusi global yang melayani lebih dari 500 petabita data. Bagian I berfokus pada evolusi Habitat dari klien Python menjadi layanan. Bagian itu juga membahas teknik yang memungkinkan kami mendorong layanan berbasis Python jauh melampaui batas yang dianggap praktis oleh banyak orang.

Dalam artikel Bagian II ini, kami menguraikan cara meningkatkan skala komponen penyimpanan yang mendasarinya: Azure Cosmos DB. Melalui kerja sama erat dengan tim Azure, kami menemukan pendekatan multi-tenant yang efektif berupa kontainer yang dikelola bersama, dengan performa baca unggul pada skala global yang masif.

Seiring pertumbuhan perusahaan, tim infrastruktur sering beralih dari menjalankan sistem tenant tunggal ke sistem multi-tenant. Dalam sistem tenant tunggal, setiap tim yang menangani bagian produk memelihara sistemnya sendiri. Ini memperkecil cakupan dampak gangguan serta memudahkan pembagian tanggung jawab dan isolasi beban kerja. Seiring bertambahnya tim dan bagian produk, biaya pengoperasiannya menjadi mahal. Sistem tenant tunggal membuat setiap tim produk bertanggung jawab atas perencanaan kapasitas dan sering menghasilkan alokasi sumber daya yang jauh berlebihan.

Sebaliknya, sistem multi-tenant menyerahkan kendali kepada tim database terpusat yang lebih berpengetahuan dan berpengalaman dalam menyediakan sumber daya. Namun, sistem multi-tenant menimbulkan masalah tersendiri, seperti tenant yang boros sumber daya ketika satu tenant memakai sumber daya dalam porsi yang luar biasa besar hingga merugikan tenant lain.

Di Habitat, kami harus mempertimbangkan semua kompromi ini untuk merancang sistem penyimpanan berskala besar yang andal dan efisien. Kini, Habitat adalah lapisan database multi-tenant bagi banyak produk OpenAI. Namun, perjalanan kami berputar: dari satu kontainer Azure Cosmos DB multi-tenant, beralih ke penyediaan kontainer penyimpanan tenant tunggal, lalu kembali memakai kontainer multi-tenant secara default. Perjalanan multi-tenant Habitat masih sangat awal: kami mendukung banyak kasus penggunaan, tetapi dapat menunda investasi di bidang ini dengan memanfaatkan komponen dasar bawaan Azure Cosmos DB sebisa mungkin.

Sebelum membahas perjalanan Azure Cosmos DB kami, berikut beberapa konteks dasar:

• Akun Azure Cosmos DB menentukan sekumpulan kontainer dan kebijakan replikasi

• Setiap kontainer diberi alokasi throughput tertentu dalam unit permintaan per detik (RU/s)

• Data dalam setiap kontainer disimpan dengan sharding berdasarkan kunci partisi logis yang ditentukan, dengan batas penyimpanan dan throughput per kunci partisi logis yang terdokumentasi

• Azure Cosmos DB menangani sharding kunci partisi logis ke sejumlah partisi fisik yang lebih sedikit, lalu membaginya menjadi beberapa partisi fisik saat penyimpanan melewati ambang batas atau saat kontainer membutuhkan lebih banyak partisi fisik untuk menopang throughput yang disediakan

Awalnya, kami membiarkan semua beban klien masuk, dengan mengandalkan batas resmi 10 rb RU/s per kunci partisi logis untuk memberikan tekanan balik. Saat baru memulai, kami juga hanya memakai satu kontainer Azure Cosmos DB default di setiap akun. Ini berjalan cukup baik, tetapi kemudian terbukti bermasalah karena beberapa alasan:

Karena keputusan desain API di awal, kami memberikan pemilihan kunci partisi logis langsung kepada klien. Akibatnya, sering terjadi benturan pada kunci partisi yang umum dipakai, seperti user_id atau workspace_id, di berbagai kasus penggunaan produk. Karena kasus-kasus penggunaan ini berbagi batas Azure Cosmos DB pada kunci partisi logis yang sama, desain tersebut membatasi total throughput untuk seorang pengguna.

Salah satu masalah umum saat meningkatkan skala Postgres, sebelum kami beralih ke Habitat dan Azure Cosmos DB, adalah banyaknya permintaan dari organisasi atau kunci yang sangat aktif—satu tenant dengan beban jauh lebih tinggi dari yang lain—dapat melumpuhkan seluruh database. Kami mencurahkan banyak upaya bersama untuk menyimpan kunci-kunci itu dalam cache dan menerapkan mekanisme lease saat terjadi cache miss, agar beban akibat cache miss tidak membanjiri database di bawahnya.

Meski batas ukuran data dan throughput yang didokumentasikan berlaku untuk kunci partisi logis, batas tersebut sebenarnya diterapkan pada partisi fisik. Dalam praktiknya, ini berarti partisi logis tidak dapat mencapai 10.000 RU/s. Sebaliknya, partisi logis berbagi batas partisi fisik dengan setiap kunci partisi logis lain yang ditempatkan pada partisi fisik yang sama.

Akibatnya, tenant yang boros sumber daya dapat memengaruhi banyak kunci partisi logis yang tidak terkait. Beban kerja yang mengolah data untuk fitur produk khusus pun dapat mengganggu alur inti login dan pendaftaran.

Batas throughput suatu partisi fisik juga bervariasi, bergantung pada total throughput yang dialokasikan ke kontainer Azure Cosmos DB. Throughput yang disediakan untuk kontainer dibagi kurang lebih merata ke seluruh partisi fisiknya.

Seiring bertambahnya volume data, partisi fisik terbagi sehingga jumlah total partisi meningkat, sementara total throughput yang disediakan tetap sama. Akibatnya, batas throughput efektif per partisi menyusut seiring bertambahnya ukuran data.

Untuk kasus penggunaan mirip blob yang paling banyak memakan penyimpanan, ini menciptakan kondisi kegagalan: pertumbuhan penyimpanan saja sudah mengurangi kapasitas throughput beban kerja aktif, meski laju permintaan dan penggunaan tetap stabil.

Kontainer terpisah membantu mengatasi sebagian masalah batas kunci partisi dan tenant yang boros sumber daya ini. Dengan kontainer terpisah, masing-masing dapat diberi partisi fisik independen. Hanya beban kerja di dalam kontainer itu sendiri yang dapat saling menjadi tenant yang boros sumber daya atau memiliki ruang kunci partisi yang tumpang tindih. Namun, penyediaan kontainer baru tetap membutuhkan upaya tambahan—setiap kontainer memerlukan perencanaan kapasitas tersendiri—jadi kami ingin membuat kontainer hanya pada batas layanan atau kasus penggunaan yang masuk akal.

Kami mulai memakai kontainer Azure Cosmos DB terpisah untuk kasus penggunaan baru yang paling kritis dan membutuhkan isolasi kuat. Ditambah skrip untuk menangani partisi lemah dengan menyelaraskan total throughput yang disediakan bagi setiap kontainer dengan jumlah partisi fisiknya, kami berhasil menghindari sebagian besar masalah yang dihadapi.

Namun, karena kami memulai dengan kontainer default, banyak kasus penggunaan kritis lama sayangnya tetap terjebak di sana tanpa migrasi data. Untuk melindungi layanan kritis yang masih bergantung pada data di kontainer default bersama, kami sering menyarankan tim membuat kontainer terpisah untuk layanan baru atau fitur produk utama. Seiring meningkatnya skala, tekanan pada kontainer default bertambah, begitu pula insiden di lingkungan produksi. Kami mulai menyediakan kontainer untuk setiap layanan baru atau fitur produk besar, semata-mata untuk melindungi kontainer default dari beban tambahan.

Ini menghindarkan kami dari banyak gangguan yang dapat melumpuhkan seluruh situs, dengan membatasi dampaknya pada penurunan kualitas fitur atau layanan. Namun, beban tambahan untuk menyediakan kontainer baru akhirnya menjadi kendala:

Di kontainer default bersama yang lama, kenaikan suatu kasus penggunaan baru dari 0 QPS menjadi 1 juta QPS kecil kemungkinannya mengubah total penggunaan agregat secara signifikan. Namun, di kontainer terisolasi, kenaikan kasus penggunaan baru dari 0 menjadi 1 juta QPS bisa berarti beban 1.000× lebih besar dari beban dasar yang hanya berasal dari pengujian oleh pengguna internal.

Dengan kontainer khusus, tim kini harus ingat untuk menyediakan throughput kontainer sesuai perkiraan kebutuhan peluncuran sejak awal. Tim produk sering merilis fitur ke produksi tetapi lupa meningkatkan kapasitas sebelumnya. Akibatnya, pada hari peluncuran kami harus menangani insiden di ruang SEV sambil berusaha menambah kapasitas kontainer pada saat terakhir.

Inilah manfaat utama penggabungan beban kerja dalam sistem multi-tenant yang harus kami korbankan demi isolasi lebih baik melalui strategi kontainer ini.

Seiring waktu, pemantauan penggunaan kontainer khusus juga membutuhkan pemahaman produk yang mendalam tentang kapan trafik akan bergeser atau meningkat.

Kami dapat menyediakan skrip control plane sederhana untuk meningkatkan throughput setiap kontainer berdasarkan tren pertumbuhan. Namun, tanpa pertumbuhan agregat yang stabil, penskalaan yang tepat praktis mengharuskan setiap tim produk di OpenAI ikut merencanakan kapasitas.

Pendekatan ini tidak mampu mengikuti pertumbuhan organisasi, karena tingkat ketelitian tiap tim pemilik layanan dalam menyediakan kapasitas Azure Cosmos DB sangat bervariasi.

Seiring pertumbuhan organisasi, masalah operasional itu makin sulit ditangani pada skala yang lebih besar. Tanpa satu tim pusat yang menangani perencanaan, banyak tim akhirnya menyusun rencana yang kurang matang. Akibatnya, kami kembali beralih ke solusi multi-tenant dan bekerja erat dengan tim Azure untuk memperbaiki masalah awal melalui desain berbagi tenant:

Membatasi laju kunci yang paling aktif terlebih dahulu mencegah tenant yang boros sumber daya menghabiskan seluruh throughput suatu partisi fisik. Ini mengurangi gangguan antartenant, ketika satu kunci yang sangat aktif dapat berdampak ke seluruh situs.

QoS dengan pengelompokan tingkat permintaan juga mencegah beban kerja offline, seperti penyisipan massal atau ekstraksi data, menghabiskan seluruh throughput suatu partisi fisik. Dengan memberi prioritas lebih rendah pada permintaan beban kerja ini, lajunya dibatasi lebih dahulu. Ini mencegah pembatasan pada permintaan interaktif berprioritas lebih tinggi yang melayani pengguna akhir.

Azure Cosmos DB sudah memiliki mode serverless yang dapat mengatasi masalah partisi lemah pada mode dengan kapasitas teralokasi. Namun, ada kelemahan besar: penskalaannya hanya berdasarkan penggunaan penyimpanan dan penggunaan RU dibatasi hingga 5 rb RU/s per partisi fisik. Ini akan mengatasi masalah partisi lemah, tetapi menghalangi kami meningkatkan skala kasus penggunaan yang membutuhkan banyak RU.

Mode serverless baru yang disempurnakan tim Azure Cosmos DB untuk kami memungkinkan setiap partisi fisik mencapai 10 rb RU/s dan menambahkan pembelahan berdasarkan penggunaan RU, selain penggunaan penyimpanan. Dengan ini, kami tidak perlu lagi memantau dan meningkatkan kapasitas kontainer secara manual.

Perubahan ini memungkinkan kami kembali memakai satu kontainer bersama, sehingga perencanaan kapasitas awal maupun berkelanjutan bagi tim produk menjadi jauh lebih sederhana, tanpa mengorbankan isolasi antar-beban kerja. Dalam beberapa bulan sejak itu, tidak ada insiden terkait penyediaan kapasitas maupun gangguan antartenant, meski pengembangan produk makin cepat.

Saat perusahaan tumbuh hingga skala OpenAI, layanan terkelola menjadi tidak sepenuhnya “terkelola”. Banyak beban kerja menjadi kasus di luar kebiasaan dalam infrastruktur penyedia cloud. Ketika OpenAI menjadi salah satu pengguna terbesar Azure Cosmos DB, pengoperasiannya membutuhkan pendekatan berbeda: pengujian bersama, dasbor bersama, saluran komunikasi langsung antartim rekayasa, serta tanggung jawab bersama atas kondisi kegagalan yang hanya muncul pada skala kami. Kini, akun Azure Cosmos DB terbesar kami menyimpan puluhan petabita data dan melayani lebih dari 20 juta QPS. Sepengetahuan kami, hanya perusahaan kami yang menerapkan Azure Cosmos DB pada skala ini.

Pada akhir 2024, gangguan di satu region memperjelas pentingnya kolaborasi ini. Saat itu, pemadaman listrik melanda region Azure utama untuk salah satu akun Azure Cosmos DB terbesar kami. Dalam proses failover yang menyusul, kami menyadari bahwa akun-akun terbesar kami memerlukan beberapa jam untuk beralih ke region sekunder. Baik tim kami maupun tim Azure Cosmos DB belum pernah menguji hal ini pada skala kami.

Sekitar sebulan kemudian, saat mengalihkan akun-akun tersebut kembali ke region semula, kami memicu gangguan serius lainnya. Lonjakan koneksi serentak ke region semula membanjiri gateway Azure Cosmos DB di region tersebut. Perilaku khusus klien Azure Cosmos DB dalam mode gateway saat menangani failover membuat semua klien langsung membuka koneksi dan mengirim permintaan ke region semula, meski hanya sebagian partisi fisik yang sudah dipindahkan kembali.

Pada setiap gangguan, OpenAI dan Azure menjalankan proses manajemen insiden masing-masing, mengidentifikasi sejumlah akar penyebab, dan menerapkan perbaikan. Namun, gangguan ini merupakan gejala masalah sistemik yang lebih besar dalam cara tim kami dan tim Azure Cosmos DB beroperasi serta melakukan pengujian. Pada awalnya, layanan terkelola memungkinkan kami bergerak cepat dan berfokus pada tujuan bisnis. Pada skala besar, layanan terkelola tidak lagi sepenuhnya terkelola dan memerlukan integrasi mendalam dengan penyedia layanan di semua tingkat, dari desain hingga operasi.

Kini, tim rekayasa Habitat dan Azure bersama-sama memantau setiap lapisan Habitat, dari lapisan layanan kami hingga lapisan penyimpanan fisik Azure Cosmos DB. Kami mengoperasikan dan menguji perubahan pada akun Azure Cosmos DB nonproduksi yang berukuran setara dengan lingkungan produksi. Kami bersama-sama menguji dan menyempurnakan SDK, serta menentukan praktik terbaik untuk penskalaan dan penentuan kapasitas akun Azure Cosmos DB kami. Tim rekayasa kami dapat saling menghubungi langsung melalui Teams. Kami bahkan menyediakan cara untuk langsung memanggil petugas siaga satu sama lain tanpa melewati jenjang dukungan.

Selama setahun terakhir, kami banyak bekerja sama untuk meningkatkan skalabilitas control plane dan gateway Azure Cosmos DB. Upaya ini mencakup penambahan perlindungan beban dan caching berbagai metadata Azure Cosmos DB di gateway untuk melindungi partisi metadata Azure Cosmos DB, pengurangan tekanan dari kumpulan proses habitat-service Python kami melalui pooling dan peningkatan penggunaan ulang koneksi, penempatan beban kerja di lokasi yang sama jika memungkinkan, serta isolasi beban kerja kritis dari beban kerja offline melalui VPC yang berbeda.

Kolaborasi rekayasa sedalam ini sangat penting bagi stabilitas Azure Cosmos DB kami selama setahun terakhir. Setiap sistem yang cukup besar atau kritis membutuhkan kerja sama semacam ini: mendobrak sekat tanggung jawab dan bekerja lintas batas organisasi.

Seperti disebutkan di Bagian I, filosofi utama kami adalah: buat agar berfungsi, lalu cepat, lalu hemat. Keandalan dahulu, lalu performa, kemudian efisiensi. Habitat telah menjadi infrastruktur kritis bagi OpenAI, sehingga prioritas pertama adalah memastikan keandalannya. Saat sistem mulai stabil pada 2025 dan OpenAI berekspansi secara global, latensi menjadi kendala berikutnya bagi pengguna dan tim produk.

Kapasitas komputasi dan penyimpanan sering berada di region yang berbeda, sehingga permintaan lintas region tak terhindarkan.

Latensi sangat bervariasi, tergantung lokasi penyimpanan data dan lokasi permintaan dilayani. Agar permintaan Habitat berkinerja baik, pengembang produk mengandalkan caching tambahan di sisi klien, pengelompokan permintaan, pengurangan operasi baca dan tulis database, serta pemindahan pekerjaan dari jalur kritis sebisa mungkin. Meski menghasilkan beberapa desain produk menarik yang lebih tahan terhadap masalah database, pendekatan ini juga menambah kompleksitas dan memperlambat iterasi produk. Ini tidak sejalan dengan tujuan Habitat untuk mendorong pengembangan produk yang cepat tanpa perlu memahami database.

Hal ini menjadi fokus utama kami pada 2026. Kami telah mengembangkan strategi berlapis untuk mengoptimalkan performa baca, yang mencakup lebih dari 90% permintaan Habitat:

Kami memiliki sejumlah akun Azure Cosmos DB di berbagai region Azure di seluruh dunia untuk pengguna dengan persyaratan residensi data. Bahkan bagi pengguna tanpa persyaratan residensi data yang ketat, menempatkan data di dekat mereka juga meningkatkan pengalaman melalui latensi yang lebih rendah.

Dalam praktiknya, kami belum bisa menerapkan ini secara luas di luar kasus penggunaan residensi data karena penempatan dibatasi oleh kapasitas fisik cloud. Karena besarnya kumpulan data kami, banyak region tidak mampu menampung kebutuhan penyimpanan yang sangat besar untuk melayani porsi trafik pengguna di region tersebut.

Di region dengan kapasitas pusat data, daya, atau pendinginan terbatas, kami terkadang harus memilih: mencadangkan kapasitas untuk penyimpanan di lokasi yang sama demi menurunkan latensi Habitat, atau memakai kapasitas itu untuk komputasi tambahan guna melayani permintaan dan mengarahkan permintaan penyimpanan ke lokasi yang lebih jauh.

Akibatnya, keputusan penempatan sering menjadi kompromi produk antara: A) optimasi latensi untuk berbagai produk dan kelompok pengguna, dan B) kapasitas dasar penyimpanan dan komputasi.

Untuk beban kerja yang paling bergantung pada latensi rendah, seperti metadata autentikasi yang diperlukan di setiap permintaan, kami mengurangi RTT antara komputasi dan Habitat dengan memakai akun Azure Cosmos DB yang direplikasi ke banyak region sekunder. Beberapa akun direplikasi ke seluruh 40 region Azure tempat kami melayani trafik; akun lainnya direplikasi ke setidaknya satu region per benua.

Kami harus membangun lapisan pemindahan data dan perutean yang transparan di Habitat lebih awal dari rencana agar dapat memindahkan kumpulan data antar-akun dengan topologi replikasi berbeda.

Namun, pendekatan ini pun pada akhirnya dibatasi kapasitas, sehingga hanya diterapkan pada beberapa kumpulan data yang dipilih secara khusus.

Beban kerja Habitat sangat didominasi pembacaan, dengan aplikasi terus mengambil pengaturan, status, dan properti lain. Porsi trafik yang sangat besar berasal dari sekumpulan tipe data aktif yang relatif kecil dan sering diakses. Karena itu, sistem ini sangat cocok untuk caching terdistribusi. Caching meningkatkan performa infrastruktur satu region, tetapi manfaatnya berlipat saat bekerja lintas region karena dapat “menyembunyikan” latensi antar-region.

Kami telah mengintegrasikan lapisan caching lookaside terdistribusi ke Habitat. Lapisan ini menyimpan salinan objek dan relasi yang baru diakses pada server Valkey dalam infrastruktur kami, dekat dengan lokasi pemrosesan permintaan pengguna. Biasanya, cache semacam ini memakai TTL yang menyeimbangkan tingkat hit dengan keusangan data. TTL pendek mengurangi keusangan, tetapi membatasi manfaat caching karena item cepat kedaluwarsa dari cache dan harus lebih sering diambil ulang. TTL lebih panjang meningkatkan tingkat hit, tetapi menyajikan data usang lebih lama, sehingga pengalaman pengguna memburuk dan perilaku produk sulit diprediksi.

Pendekatan lain adalah menjalankan operasi invalidasi secara eksplisit saat aplikasi melakukan operasi tulis pada data dasar yang sama. Ini sangat meningkatkan kemutakhiran data dalam cache, tetapi penerapannya bisa sulit dilakukan dengan benar. Pendekatan ini juga tetap rentan terhadap sejumlah kasus khusus, seperti kegagalan parsial yang membuat cache tetap usang. Penerapan multi-region memperparah masalah ini karena jaringan antar-region kurang andal dan terjadi kondisi balapan antara cache dan replikasi penyimpanan dasarnya. Melengkapinya dengan TTL membatasi keusangan maksimum, tetapi tetap menghadapi kompromi dasar TTL yang sama seperti di atas.

Kami menerapkan pendekatan invalidasi yang lebih canggih, mengikuti jejak sistem seperti TAO dari Meta. Cache terintegrasi Habitat mengandalkan penangkapan perubahan data (CDC) melalui change feed Azure Cosmos DB untuk menyebarkan invalidasi secara global dalam hitungan detik, sehingga tingkat hit tinggi dan keusangan tetap rendah. Sebuah layanan dalam infrastruktur kami membaca change feed ini dan menginvalidasi cache lokal saat data dasarnya diperbarui. Ini memicu cache miss saat data berikutnya dibaca, lalu cache diisi dengan versi data terbaru.

Kami juga sangat mengurangi latensi dengan menghilangkan overhead di layanan Habitat sendiri melalui penulisan ulang kode dalam Rust, yang berkinerja lebih baik daripada Python semula.

Secara keseluruhan, perubahan ini menurunkan latensi baca p50 global kami dari sekitar 120 ms menjadi sekitar 10 ms, peningkatan 12× sejak kami mulai berfokus pada performa awal tahun ini.

Meski caching sangat mengurangi latensi median, permintaan paling lambat masih perlu mengambil data yang belum di-cache dari penyimpanan dasar, sering kali dari region yang jauh. Seiring tersedianya kapasitas tambahan dan meningkatnya efisiensi penyimpanan, kami berencana mengatasi tantangan yang lebih mendasar: sejak awal menempatkan data lebih dekat ke lokasi aksesnya.

CDC yang andal dan skalabel—yang meneruskan perubahan database ke sistem hilir—merupakan komponen penting, bukan hanya untuk strategi caching Habitat. Jutaan perubahan yang ditangkap per detik dari ribuan kontainer dan jutaan partisi kontainer mengalir melalui lebih dari seratus topik Kafka. Aliran ini juga mendukung indeks sekunder dengan konsistensi eventual, pipeline pemindahan data, analitik offline, dan fitur produk real-time lainnya. Seiring pertumbuhan global infrastruktur pendukung kami, pemantauan perubahan baris menjadi makin kompleks. Jika klien ingin mendaftarkan callback yang dijalankan setiap kali baris dengan tipe datanya berubah, mereka harus terlebih dahulu menentukan akun dan kontainer Cosmos yang menyimpan data tersebut, deployment layanan CDC di tiap region yang memantau kontainer itu, serta menyesuaikan skala kumpulan worker CDC, Kafka, dan konsumennya. Platform CDC kami bertujuan menyembunyikan semua kerumitan ini dari pengembang produk. Sebagai gantinya, kami menyediakan antarmuka sederhana untuk mendaftarkan fungsi yang dipanggil saat baris berubah, sementara kami menangani seluruh infrastruktur penghubung dan penskalaannya.

Control plane internal terus memastikan perubahan di semua kontainer yang diperlukan ditangkap, memilih region Cosmos sebagai sumber baca, dan membagi pekerjaan secara efisien ke ribuan worker di berbagai region geografis. Pemakaian region replika dan pembacaan feed berprioritas rendah melindungi trafik Habitat yang sensitif terhadap latensi dari beban penangkapan perubahan di latar belakang. Worker yang crash, masalah kontainer, kesalahan penyimpanan lease, konfigurasi tidak valid, dan kegagalan tujuan terus terjadi dalam kumpulan sistem sebesar ini. Kami memperkuat siklus hidup worker CDC dan penanganan lease, mengisolasi kegagalan antaraliran, serta membangun pengaman untuk perubahan konfigurasi dan peluncuran. Kami memakai dead letter queue agar kegagalan pengiriman permanen tidak menghambat seluruh antrean. Kami mengatasi gangguan regional dengan mengalihkan pembaca ke region Cosmos alternatif. Pada skala kami, SDK CDC Azure pun harus diubah agar implementasi checkpoint lebih efisien, dengan mengelompokkan checkpoint di memori dan hanya menuliskannya ke penyimpanan secara berkala.

Meski penggunaan internal Azure Cosmos DB oleh Habitat kompleks, nilai utamanya selalu terletak pada penyembunyian detail infrastruktur dari pengembang produk agar pengembangan lebih cepat. Platform CDC kami pun demikian.

Tim kecil mampu mendukung platform penyimpanan yang tumbuh pesat dengan sengaja membatasi cakupan API penyimpanan, terus meningkatkan skala layanan Python, dan memprioritaskan tantangan rekayasa paling mendesak. Kami berfokus pertama pada keandalan untuk trafik produk kritis, lalu performa baca bagi pengguna global, dan terakhir efisiensi operasional pada skala besar. Pendekatan ini memungkinkan pertumbuhan pesat dan kasus penggunaan baru, sekaligus meningkatkan keandalan, performa, dan kecepatan pengembangan produk.

Untuk meningkatkan skala Habitat dan penyimpanan percakapan bagi satu miliar pengguna berikutnya, kami perlu mengatasi kesulitan mereplikasi data di seluruh infrastruktur pada skala yang lebih besar lagi. Untuk mengantisipasinya, kami sedang membangun sendiri sistem penyimpanan online khusus berskala eksabita, yang dioptimalkan untuk tipe data Habitat berukuran besar. Sistem yang sedang dikembangkan ini memadukan inti RocksDB Cloud dari Rockset dengan replikasi berbasis Raft. Sistem ini menerapkan model dokumen yang sama dengan Azure Cosmos DB, tetapi memakai penyimpanan terpisah dari komputasi dan replikasi fisik untuk mengurangi kebutuhan kapasitas flash, dengan konsekuensi QPS puncak yang lebih rendah.

Jika Anda tertarik mengerjakan infrastruktur data semacam ini pada skala terdepan, lihat lowongan kami⁠.