Penskalaan pesat storan dalam talian untuk lebih 1 bilion pengguna ChatGPT (Bahagian II)

Semua produk OpenAI memerlukan akses data yang pantas dan boleh dipercayai, yang disediakan oleh platform storan kami, Habitat. Platform ini perlu memberikan respons dalam milisaat kepada lebih 1 bilion pengguna di 40 rantau geografi. Infrastruktur kami menghadapi cabaran luar biasa: menyokong pertumbuhan pesat dan kes penggunaan baharu sambil terus meningkatkan kebolehpercayaan, prestasi dan kepantasan kerja pembangun produk. Untuk mengatasi cabaran itu, kami perlu memikirkan semula cara platform storan dalam talian kami direka dan dikendalikan. Kami sentiasa menilai kompromi mengikut urutan ini: mula-mula mencapai kebolehpercayaan yang mencukupi untuk trafik produk kritikal, kemudian kepantasan yang mencukupi untuk pengguna global, dan akhirnya beroperasi dengan cekap pada skala besar.

Siri dua bahagian ini menerangkan cara kami membangunkan Habitat daripada pustaka klien dan pangkalan data ringkas kepada platform storan teragih global yang menyediakan akses kepada lebih 500 petabait data. Bahagian I menumpukan pada evolusi Habitat daripada klien Python kepada perkhidmatan. Bahagian itu juga merangkumi teknik yang membolehkan kami mengembangkan perkhidmatan berasaskan Python jauh melangkaui tahap yang dianggap praktikal oleh ramai pihak.

Dalam siaran Bahagian II ini, kami menerangkan cara kami meningkatkan skala komponen storan asas: Azure Cosmos DB. Melalui kerjasama rapat dengan pasukan Azure, kami menghasilkan pendekatan berbilang penyewa yang berdaya maju menggunakan kontena yang diurus bersama, dengan prestasi bacaan cemerlang pada skala global yang besar.

Apabila syarikat berkembang, pasukan infrastruktur sering beralih daripada mengendalikan sistem penyewa tunggal kepada sistem berbilang penyewa. Dalam sistem penyewa tunggal, setiap pasukan yang menjaga bahagian produk menyelenggara sistem sendiri. Ini mengehadkan skop kesan gangguan serta memudahkan penetapan sempadan pemilikan dan pengasingan beban kerja. Apabila pasukan dan bahagian produk bertambah, kos pengendaliannya meningkat. Sistem penyewa tunggal menjadikan setiap pasukan produk bertanggungjawab terhadap perancangan kapasiti dan sering mengakibatkan peruntukan sumber berlebihan yang ketara.

Sebaliknya, sistem berbilang penyewa menyerahkan kawalan kepada pasukan pangkalan data berpusat yang lebih berpengetahuan dan berpengalaman dalam memperuntukkan sumber. Namun, sistem berbilang penyewa membawa masalah tersendiri, seperti isu jiran yang mengganggu, apabila satu penyewa menggunakan bahagian sumber yang luar biasa besar sehingga menjejaskan penyewa lain.

Dalam Habitat, kami perlu menimbang semua kompromi ini untuk mereka bentuk sistem storan yang boleh dipercayai dan cekap pada skala besar. Kini, Habitat ialah lapisan pangkalan data berbilang penyewa untuk banyak produk OpenAI. Namun, perjalanan kami telah kembali ke titik asal: daripada satu kontena Azure Cosmos DB berbilang penyewa, kepada penyediaan kontena sokongan penyewa tunggal, kemudian kembali kepada kontena berbilang penyewa secara lalai. Perjalanan sistem berbilang penyewa Habitat masih di peringkat awal. Kami menyokong pelbagai kes penggunaan, tetapi dapat menangguhkan pelaburan dalam bidang ini dengan memanfaatkan primitif terbina dalam Azure Cosmos DB sedapat mungkin.

Sebelum menerangkan perjalanan Azure Cosmos DB kami, berikut ialah konteks asas:

• Akaun Azure Cosmos DB mentakrifkan satu set kontena dan dasar mereplika

• Setiap kontena diperuntukkan daya pemprosesan tertentu dalam unit permintaan sesaat (RU/s)

• Data dalam setiap kontena disimpan dengan kaedah lazim pembahagian syard mengikut kunci pemetakan logik yang ditetapkan, dengan had storan dan daya pemprosesan yang didokumenkan bagi setiap kunci pemetakan logik

• Azure Cosmos DB mengendalikan pembahagian kunci partisi logik merentas bilangan partisi fizikal sokongan yang lebih kecil. Partisi fizikal dipecahkan apabila storan melebihi ambang atau apabila kontena memerlukan lebih banyak partisi fizikal untuk menampung daya pemprosesan yang diperuntukkan

Pada mulanya, kami membenarkan semua beban klien masuk dan bergantung pada had 10K RU/s yang dinyatakan bagi setiap kunci pemetakan logik untuk memberikan tekanan balik. Semasa bermula, kami juga hanya menggunakan satu kontena Azure Cosmos DB lalai dalam setiap akaun. Pendekatan ini berfungsi agak baik, tetapi menimbulkan masalah atas beberapa sebab:

Disebabkan pilihan API awal, kami membolehkan klien memilih kunci pemetakan logik secara langsung. Akibatnya, pertembungan kerap berlaku pada kunci pemetakan yang biasa digunakan, seperti user_id atau workspace_id, merentas kes penggunaan produk yang berbeza. Oleh sebab kes penggunaan ini berkongsi had Azure Cosmos DB pada kunci pemetakan logik yang sama, reka bentuk tersebut mengehadkan daya pemprosesan keseluruhan bagi seseorang pengguna.

Sebelum beralih kepada Habitat dan Azure Cosmos DB, antara masalah biasa ketika meningkatkan skala Postgres ialah permintaan yang banyak daripada organisasi atau kunci yang sangat aktif—satu penyewa yang menjana beban tidak seimbang tingginya—boleh melumpuhkan seluruh pangkalan data. Banyak usaha bersama dicurahkan untuk menyimpan kunci tersebut dalam cache dan membina mekanisme pajakan bagi kegagalan capaian cache, supaya beban yang terhasil tidak membebankan pangkalan data asas.

Walaupun had saiz data dan daya pemprosesan yang didokumenkan terpakai pada kunci partisi logik, had sebenarnya dikuatkuasakan pada partisi fizikal. Dalam amalan, ini bermakna partisi logik tidak dapat mencapai 10,000 RU/s. Sebaliknya, partisi logik berkongsi had partisi fizikal dengan semua kunci partisi logik lain yang ditempatkan pada partisi fizikal tersebut.

Ini membolehkan jiran yang mengganggu menjejaskan banyak kunci partisi logik yang tidak berkaitan, dengan beban kerja yang mengendalikan data ciri produk khusus mengganggu aliran teras log masuk dan pendaftaran.

Had daya pemprosesan bagi sesuatu pemetakan fizikal juga berubah-ubah, bergantung pada jumlah daya pemprosesan yang diperuntukkan kepada kontena Azure Cosmos DB. Daya pemprosesan yang diperuntukkan kepada kontena diagihkan hampir sama rata antara pemetakan fizikalnya.

Apabila kelantangan data bertambah, pemetakan fizikal dipecahkan, lalu meningkatkan jumlah pemetakan sedangkan jumlah daya pemprosesan yang diperuntukkan kekal sama. Akibatnya, had daya pemprosesan efektif bagi setiap pemetakan mengecil apabila saiz data bertambah.

Bagi kes penggunaan seakan blob yang paling intensif storan, ini mewujudkan mod kegagalan apabila pertumbuhan storan sahaja mengurangkan kapasiti daya pemprosesan beban kerja aktif, walaupun kadar permintaan dan penggunaan kekal stabil.

Kontena berasingan membantu menyelesaikan sebahagian masalah had kunci partisi dan jiran yang mengganggu ini. Dengan menggunakan kontena berasingan, setiap kontena boleh diperuntukkan partisi fizikalnya sendiri yang bebas. Hanya beban kerja dalam kontena yang sama boleh mengganggu satu sama lain atau bertindih dalam ruang kunci partisi. Kelemahannya, penyediaan kontena baharu tetap melibatkan overhed—setiap kontena memerlukan perancangan kapasiti tersendiri. Jadi, kami hanya mahu mencipta kontena pada sempadan perkhidmatan atau kes penggunaan yang munasabah.

Kami mula menggunakan kontena Azure Cosmos DB berasingan untuk kes penggunaan baharu paling kritikal yang memerlukan pengasingan kukuh. Digabungkan dengan skrip untuk mengurus partisi lemah dengan menyelaraskan jumlah daya pemprosesan yang diperuntukkan bagi setiap kontena dengan bilangan partisi fizikalnya, kami dapat mengelakkan kebanyakan masalah yang dihadapi.

Namun, oleh sebab kami bermula dengan kontena lalai, banyak kes penggunaan kritikal legasi malangnya kekal terperangkap di situ tanpa migrasi data. Untuk melindungi perkhidmatan kritikal yang masih bergantung pada data dalam kontena lalai dikongsi, kami sering menasihati pasukan supaya mencipta kontena berasingan untuk perkhidmatan baharu atau ciri produk utama. Apabila skala kami bertambah, tekanan pada kontena lalai meningkat, begitu juga insiden dalam persekitaran produksi. Kami mula menyediakan kontena untuk setiap perkhidmatan baharu atau ciri produk besar semata-mata untuk melindungi kontena lalai daripada beban tambahan.

Ini mengelakkan banyak gangguan seluruh laman, dengan mengehadkan kesannya kepada gangguan yang merosotkan prestasi ciri atau perkhidmatan tertentu. Namun, overhed penyediaan kontena baharu akhirnya mula membebankan kami:

Dalam kontena lalai dikongsi yang lama, peningkatan mana-mana kes penggunaan baharu daripada 0 QPS kepada 1 juta QPS tidak mungkin mengubah jumlah penggunaan agregat dengan ketara. Namun, dalam kontena terasing, peningkatan kes penggunaan baharu daripada 0 kepada 1 juta QPS mungkin mewakili beban 1,000 kali ganda berbanding garis dasar daripada ujian penggunaan dalaman sahaja.

Dengan kontena khusus, pasukan kini perlu ingat untuk memperuntukkan daya pemprosesan kontena lebih awal pada tahap yang dijangka bagi pelancaran mereka. Pasukan produk sering melancarkan ciri ke produksi tetapi terlupa meningkatkan skala terlebih dahulu. Akibatnya, pada hari pelancaran kami terpaksa berada di bilik pengurusan insiden SEV, cuba meningkatkan skala kontena pada saat akhir.

Inilah manfaat utama pencampuran beban kerja dalam sistem berbilang penyewa yang kami korbankan demi pengasingan lebih baik melalui strategi kontena ini.

Lama-kelamaan, pemantauan penggunaan kontena khusus turut memerlukan pengetahuan produk yang mendalam tentang bila trafik akan beralih atau meningkat.

Kami boleh menyediakan skrip satah kawalan asas untuk meningkatkan daya pemprosesan yang diperuntukkan bagi setiap kontena berdasarkan trend pertumbuhan. Namun, tanpa pertumbuhan agregat yang stabil, penskalaan yang betul pada dasarnya memerlukan setiap pasukan produk di OpenAI terlibat dalam perancangan kapasiti.

Pendekatan ini tidak dapat berkembang seiring organisasi kerana tahap ketelitian pasukan pemilik setiap perkhidmatan dalam memperuntukkan sumber Azure Cosmos DB sangat berbeza-beza.

Apabila organisasi berkembang, masalah operasi tersebut semakin sukar dikendalikan pada skala yang lebih besar. Ketiadaan satu pasukan pusat yang merancang menyebabkan banyak pasukan membuat perancangan yang lemah. Oleh itu, kami akhirnya kembali kepada penyelesaian berbilang penyewa dan bekerjasama rapat dengan pasukan Azure untuk membina pembaikan bagi masalah asal kami melalui reka bentuk penyewaan dikongsi:

Mendikitkan kunci paling aktif terlebih dahulu menghalang jiran yang mengganggu daripada menggunakan semua daya pemprosesan yang tersedia bagi sesuatu partisi fizikal. Ini mengurangkan kesan jiran yang mengganggu, apabila satu kunci beraktiviti tinggi boleh menjejaskan seluruh laman.

QoS berasaskan peringkat permintaan turut menghalang beban kerja luar talian, seperti penyisipan pukal atau pengekstrakan data, daripada menggunakan semua daya pemprosesan bagi sesuatu pemetakan fizikal. Dengan memberikan keutamaan lebih rendah kepada permintaan beban kerja ini, permintaan tersebut didikitkan dahulu. Ini mengelakkan pendikitan permintaan interaktif berkeutamaan lebih tinggi yang melayani pengguna akhir.

Azure Cosmos DB sudah mempunyai mod tanpa pelayan yang boleh menyelesaikan masalah partisi lemah kami dalam mod sumber diperuntukkan. Namun, terdapat kelemahan besar: penskalaannya hanya berdasarkan penggunaan storan dan penggunaan RU dihadkan kepada 5K RU/s bagi setiap pemetakan fizikal. Ini akan menyelesaikan masalah pemetakan lemah kami, tetapi menghalang kami daripada meningkatkan skala kes penggunaan yang intensif RU.

Mod tanpa pelayan baharu yang ditambah baik oleh pasukan Azure Cosmos DB untuk kami membolehkan setiap pemetakan fizikal diskalakan hingga 10K RU/s. Mod ini juga memperkenalkan pemecahan berdasarkan penggunaan RU selain penggunaan storan, membolehkan kami berhenti memantau dan meningkatkan skala kontena secara manual.

Dengan perubahan ini, kami dapat kembali menggunakan satu kontena dikongsi. Ini sangat memudahkan perancangan kapasiti awal dan berterusan bagi pasukan produk, sambil mengekalkan pengasingan antara beban kerja. Dalam beberapa bulan sejak itu, kami tidak mengalami sebarang insiden peruntukan sumber atau jiran yang mengganggu, walaupun pembangunan produk semakin pantas.

Apabila syarikat berkembang ke skala OpenAI, perkhidmatan terurus menjadi kurang “terurus”. Banyak beban kerja menjadi kes luar biasa dalam infrastruktur penyedia awan. Apabila OpenAI menjadi antara pengguna terbesar Azure Cosmos DB, kejayaan operasinya memerlukan pendekatan berbeza: ujian bersama, papan pemuka dikongsi, saluran kejuruteraan langsung dan tanggungjawab bersama terhadap mod kegagalan yang hanya muncul pada skala kami. Kini, akaun Azure Cosmos DB terbesar kami menyimpan berpuluh-puluh petabait data dan mengendalikan lebih 20 juta QPS. Setakat pengetahuan kami, kami satu-satunya syarikat yang telah menggunakan Azure Cosmos DB pada skala ini.

Pada akhir 2024, gangguan serantau memperjelas sebab kerjasama ini diperlukan. Ketika itu, gangguan bekalan kuasa melanda rantau Azure utama bagi salah satu akaun Azure Cosmos DB terbesar kami. Semasa proses peralihan akibat kegagalan itu, kami menyedari bahawa akaun terbesar kami memerlukan beberapa jam untuk beralih ke rantau sekunder. Proses ini belum pernah diuji pada skala kami, sama ada oleh pasukan kami atau pasukan Azure Cosmos DB.

Kira-kira sebulan kemudian, ketika mengembalikan akaun tersebut ke rantau asal, kami mencetuskan satu lagi gangguan serius. Lonjakan sambungan serentak ke rantau asal membebankan gerbang laluan Azure Cosmos DB di rantau itu. Keanehan dalam cara klien Azure Cosmos DB mod gerbang laluan mengendalikan peralihan kegagalan menyebabkan semua klien segera mewujudkan sambungan dan menghantar permintaan ke rantau asal, walaupun hanya sebahagian pemetakan fizikal telah dipindahkan kembali ke sana.

Dalam setiap gangguan, OpenAI dan Azure menjalankan proses pengurusan insiden masing-masing, mengenal pasti beberapa punca utama dan melaksanakan pembaikan. Namun, gangguan ini ialah gejala masalah sistemik yang lebih besar dalam cara pasukan kami dan pasukan Azure Cosmos DB beroperasi dan menjalankan ujian. Pada awalnya, perkhidmatan terurus membolehkan kami bergerak pantas dan menumpukan pada matlamat perniagaan. Pada skala besar, perkhidmatan terurus menjadi kurang terurus dan memerlukan integrasi mendalam dengan penyedia perkhidmatan pada semua peringkat, daripada reka bentuk hingga operasi.

Kini, pasukan kejuruteraan Habitat dan Azure bersama-sama memantau setiap lapisan Habitat, daripada lapisan perkhidmatan kami hingga lapisan storan fizikal Azure Cosmos DB. Kami menjalankan operasi dan menguji perubahan pada akaun Azure Cosmos DB bukan produksi yang bersaiz setara dengan produksi. Kami menguji dan menambah baik SDK bersama-sama serta menentukan amalan terbaik untuk penskalaan dan penetapan saiz akaun Azure Cosmos DB kami. Kami boleh berhubung terus dengan jurutera satu sama lain melalui Teams, malah menyediakan cara untuk menghantar panggilan kecemasan terus tanpa melalui peringkat sokongan.

Sepanjang tahun lalu, banyak usaha bersama telah dilakukan untuk meningkatkan kebolehskalaan satah kawalan dan get laluan Azure Cosmos DB. Ini termasuk menambah perlindungan beban dan penyimpanan cache pelbagai metadata Azure Cosmos DB dalam get laluannya untuk melindungi pemetakan metadata, mengurangkan tekanan daripada kumpulan proses habitat-service Python kami melalui pengumpulan sambungan dan penggunaan semula sambungan yang lebih tinggi, menempatkan beban kerja di lokasi yang sama jika boleh, serta mengasingkan beban kerja kritikal daripada beban kerja luar talian melalui VPC yang berbeza.

Kerjasama kejuruteraan sedalam ini amat penting untuk kestabilan Azure Cosmos DB kami sepanjang tahun lalu. Mana-mana sistem yang cukup besar atau kritikal memerlukan kerjasama seperti ini: meruntuhkan tembok pemilikan dan beroperasi merentas sempadan organisasi.

Seperti yang disebut dalam Bahagian I, falsafah teras kami ialah: pastikan ia berfungsi, kemudian pantas, kemudian murah. Kebolehpercayaan dahulu, kemudian prestasi, diikuti kecekapan. Habitat telah menjadi infrastruktur kritikal bagi OpenAI, jadi keutamaan pertama ialah memastikan kebolehpercayaannya. Apabila sistem semakin stabil pada 2025 dan OpenAI berkembang ke seluruh dunia, kependaman menjadi kekangan seterusnya bagi pengguna dan pasukan produk.

Kapasiti pengkomputeran dan storan sering terletak di rantau berbeza, menjadikan permintaan rentas rantau tidak dapat dielakkan.

Kependaman sangat berbeza-beza mengikut lokasi data disimpan dan permintaan diproses. Untuk memastikan permintaan Habitat berprestasi baik, pembangun produk bergantung pada cache tambahan di pihak klien, pemprosesan permintaan secara kelompok, pengurangan bacaan dan penulisan pangkalan data, serta pemindahan kerja keluar daripada laluan kritikal jika boleh. Walaupun ini menghasilkan beberapa reka bentuk produk menarik yang lebih tahan terhadap masalah pangkalan data, produk turut menjadi lebih rumit dan lelaran produk menjadi perlahan. Ini bercanggah dengan matlamat Habitat untuk menggalakkan pembangunan produk yang pantas tanpa perlu memahami pangkalan data.

Perkara ini menjadi tumpuan utama kami pada 2026. Kami telah membangunkan strategi berlapis untuk mengoptimumkan prestasi bacaan, yang merangkumi lebih 90% permintaan Habitat:

Kami mempunyai beberapa akaun Azure Cosmos DB di rantau Azure yang berbeza di seluruh dunia untuk pengguna dengan keperluan lokasi data. Walaupun pengguna tiada keperluan lokasi data yang ketat, penempatan data berdekatan mereka turut meningkatkan pengalaman melalui kependaman yang lebih rendah.

Dalam amalan, kami tidak dapat melaksanakannya secara meluas di luar kes penggunaan lokasi data kerana penempatan dibatasi kapasiti fizikal awan. Disebabkan saiz set data kami, banyak rantau tidak dapat menampung ruang storan besar yang diperlukan untuk bahagian trafik pengguna masing-masing.

Di rantau yang mempunyai kapasiti pusat data, kuasa atau penyejukan terhad, kami kadangkala perlu memilih: memperuntukkan kapasiti untuk storan setempat dan mengurangkan kependaman Habitat, atau menggunakan kapasiti itu bagi pengkomputeran tambahan untuk memproses permintaan sambil menghala permintaan storan ke lokasi lebih jauh.

Oleh itu, keputusan penempatan sering melibatkan kompromi produk antara: A) pengoptimuman kependaman untuk produk dan subset pengguna yang berbeza, dan B) kapasiti asas storan dan pengkomputeran.

Bagi beban kerja yang paling memerlukan kependaman rendah, seperti metadata pengesahan yang diperlukan pada setiap permintaan, kami mengurangkan RTT antara pengkomputeran dan Habitat dengan menggunakan akaun Azure Cosmos DB yang direplikasi secara meluas ke banyak rantau sekunder. Sesetengah akaun direplikasi ke kesemua 40 rantau Azure tempat kami mengendalikan trafik; yang lain direplikasi ke sekurang-kurangnya satu rantau bagi setiap benua.

Kami terpaksa membina lapisan pemindahan dan penghalaan data yang telus kepada pengguna dalam Habitat lebih awal daripada yang diingini, supaya set data dapat dipindahkan antara akaun dengan topologi replikasi berbeza.

Namun, pendekatan ini akhirnya turut dibatasi kapasiti dan oleh itu terhad kepada beberapa set data yang dipilih dengan teliti.

Beban kerja Habitat amat didominasi bacaan, dengan aplikasi sentiasa mengambil tetapan, keadaan dan sifat lain. Sebahagian besar trafik berpunca daripada set kerja yang agak kecil, terdiri daripada jenis data yang kerap diakses. Ini menjadikan sistem sangat sesuai untuk cache teragih. Walaupun cache meningkatkan prestasi infrastruktur satu rantau, manfaatnya bertambah apabila beroperasi merentas rantau kerana cache boleh “menyembunyikan” kependaman rentas rantau.

Kami telah menyepadukan lapisan cache sisi teragih ke dalam Habitat. Lapisan ini menyimpan salinan objek dan hubungan graf yang baru diakses dalam pelayan Valkey, yang ditempatkan dalam infrastruktur kami berdekatan lokasi permintaan pengguna diproses. Biasanya, cache sebegini menggunakan TTL yang mengimbangi kadar hit dengan keusangan data. TTL pendek mengurangkan keusangan tetapi mengehadkan manfaat cache, kerana item cepat luput daripada cache dan perlu diambil semula lebih kerap. TTL lebih panjang meningkatkan kadar hit, tetapi menyajikan data lapuk lebih lama, lalu menyebabkan pengalaman pengguna yang buruk dan tingkah laku produk yang sukar dijangka.

Pendekatan lain ialah melaksanakan operasi pembatalan cache secara eksplisit apabila aplikasi menulis pada data asas yang sama. Ini menjadikan data dalam cache jauh lebih terkini, tetapi sukar dilaksanakan dengan betul. Pendekatan ini juga masih terdedah kepada beberapa kes pinggir, seperti kegagalan separa yang menyebabkan cache kekal lapuk. Pelaksanaan berbilang rantau merumitkan masalah ini, dengan rangkaian rentas rantau yang kurang boleh dipercayai serta keadaan perlumbaan antara cache dengan mereplikakan storan asas. Menggabungkannya dengan TTL mengehadkan tempoh maksimum keusangan, tetapi masih menghadapi kompromi TTL asas yang sama seperti di atas.

Kami menggunakan pendekatan pembatalan cache yang lebih maju, mencontohi sistem seperti TAO daripada Meta. Cache bersepadu Habitat bergantung pada penangkapan perubahan data (CDC) melalui suapan perubahan Azure Cosmos DB untuk menyebarkan pembatalan cache secara global dalam beberapa saat, mencapai kadar hit tinggi sambil memastikan keusangan rendah. Satu perkhidmatan dalam infrastruktur kami membaca suapan perubahan ini dan membatalkan entri cache setempat apabila data asas dikemas kini. Ini menyebabkan data tidak ditemui dalam cache pada bacaan seterusnya, lalu cache diisi dengan versi data terkini.

Kami juga mengurangkan kependaman dengan ketara dengan menghapuskan overhed dalam perkhidmatan Habitat itu sendiri melalui penulisan semula kod dalam Rust, yang lebih berprestasi berbanding Python asal.

Secara keseluruhan, perubahan ini mengurangkan p50 bacaan global kami daripada kira-kira 120 ms kepada 10 ms, peningkatan 12 kali ganda sejak kami mula menumpukan pada prestasi awal tahun ini.

Walaupun cache telah mengurangkan kependaman median dengan ketara, permintaan paling perlahan masih perlu mengambil data yang tiada dalam cache daripada storan asas, sering kali merentas rantau yang jauh. Apabila lebih banyak kapasiti tersedia dan kecekapan storan bertambah baik, kami merancang untuk menangani cabaran yang lebih asas: menempatkan data lebih dekat dengan lokasi akses sejak awal lagi.

CDC yang boleh dipercayai dan diskalakan—yang menyebarkan perubahan pangkalan data ke sistem hiliran—ialah komponen kritikal bukan sahaja bagi strategi cache Habitat. Berjuta-juta perubahan ditangkap setiap saat merentas ribuan kontena dan jutaan pemetakan kontena, lalu disalurkan melalui lebih seratus topik Kafka. Ini turut menyokong indeks sekunder dengan ketekalan akhirnya, saluran pemindahan data, analitik luar talian dan ciri produk masa nyata lain. Apabila infrastruktur sokongan kami berkembang secara global, pemantauan perubahan baris menjadi semakin rumit. Jika klien mahu mendaftarkan panggil balik untuk dijalankan setiap kali baris jenis datanya berubah, klien perlu mengenal pasti akaun dan kontena Cosmos yang menyimpan datanya serta pelaksanaan perkhidmatan CDC di rantau berkenaan yang memantau kontena itu. Klien juga perlu menskalakan kumpulan pekerja CDC, Kafka dan penggunanya dengan betul, selain tugas lain. Platform CDC kami bertujuan menyembunyikan semua kerumitan ini daripada pembangun produk dan menyediakan antara muka ringkas: klien mendaftarkan fungsi untuk dipanggil apabila baris mereka berubah, manakala kami mengendalikan semua sambungan dalaman dan penskalaan.

Satah kawalan dalaman sentiasa memastikan perubahan semua kontena yang diperlukan ditangkap, memilih rantau Cosmos untuk dibaca dan mengagihkan kerja dengan cekap antara ribuan pekerja merentas pelbagai rantau geografi. Penggunaan rantau replika dan bacaan suapan berkeutamaan rendah melindungi trafik Habitat yang sensitif terhadap kependaman daripada beban kerja penangkapan latar belakang. Dalam kumpulan pekerja sebesar ini, ranap pekerja, masalah kontena, ralat stor pajakan, konfigurasi tidak sah dan kegagalan destinasi berlaku berterusan. Kami memperkukuh kitar hayat pekerja CDC dan pengendalian pajakan, mengasingkan kegagalan antara aliran serta membina perlindungan untuk perubahan konfigurasi dan pelancaran. Kami menggunakan baris gilir mesej gagal untuk mengelakkan sekatan di kepala baris akibat kegagalan penghantaran kekal. Kami menangani gangguan serantau dengan menukar pembaca ke rantau Cosmos alternatif. Pada skala kami, SDK CDC Azure pun perlu diubah agar pelaksanaan titik semaknya lebih cekap, dengan mengelompokkan titik semak dalam memori dan hanya menulisnya ke storan secara berkala.

Walaupun penggunaan dalaman Azure Cosmos DB oleh Habitat rumit, nilai utamanya sentiasa terletak pada penyembunyian butiran infrastruktur daripada pembangun produk untuk mempercepat pembangunan. Platform CDC kami juga begitu.

Pasukan kecil dapat menyokong platform storan yang berkembang pesat dengan sengaja mengehadkan skop API storan, terus menskalakan perkhidmatan Python dan mengutamakan cabaran kejuruteraan paling mendesak. Kami mendahulukan kebolehpercayaan untuk trafik produk kritikal, kemudian prestasi bacaan untuk pengguna global, dan akhirnya kecekapan operasi pada skala besar. Pendekatan ini membolehkan pertumbuhan pesat dan kes penggunaan baharu, sambil meningkatkan kebolehpercayaan, prestasi dan kepantasan pembangunan produk.

Untuk menskalakan Habitat dan storan perbualan bagi satu bilion pengguna seterusnya, kami perlu menangani kesukaran mereplikakan data merentas infrastruktur kami pada skala yang lebih besar lagi. Sebagai persediaan, kami sedang membina sistem storan dalam talian tersuai berskala eksabait secara dalaman, yang dioptimumkan untuk jenis data Habitat bersaiz besar. Sistem yang sedang dibangunkan ini menggabungkan teras RocksDB Cloud daripada Rockset dengan replika berasaskan Raft. Sistem ini melaksanakan model dokumen yang sama seperti Azure Cosmos DB, tetapi menggunakan storan terpisah dan replika fizikal untuk mengurangkan kapasiti storan kilat yang diperlukan, dengan kompromi qps puncak yang lebih rendah.

Jika anda berminat untuk mengusahakan infrastruktur data seperti ini pada skala perbatasan, lihat jawatan kosong kami⁠.