Menskalakan storan dalam talian dengan pantas untuk lebih 1 bilion pengguna ChatGPT

Setiap produk OpenAI bergantung pada akses data yang pantas dan andal, sama ada seseorang sedang log masuk, menyemak tetapan Codex atau memulakan perbualan baharu dalam ChatGPT. Setiap tindakan tersebut mungkin memerlukan banyak carian data berasingan sebelum produk dapat bertindak balas. Jika permintaan itu lambat, produk akan terasa lambat. Jika permintaan itu gagal, produk akan berhenti berfungsi sepenuhnya.

Habitat ialah platform storan dalam talian yang kami bina supaya produk OpenAI dapat mengakses maklumat yang diperlukan dengan pantas dan andal. Habitat kini mengendalikan lebih 70 juta permintaan setiap saat, menyokong produk yang digunakan oleh lebih satu bilion orang setiap minggu di hampir 40 rantau geografi. Habitat mula dilancarkan untuk menyokong GPT di DevDay 2023 sebagai pustaka Python ringkas pada pihak klien yang disambungkan kepada satu pangkalan data. Kini, Habitat ialah sistem teragih kompleks yang menyediakan lebih 500 petabait data.

Membina dan mengendalikan infrastruktur pada skala ini bukanlah mudah, tetapi juga bukan sesuatu yang sangat mencabar. Keunikan situasi kami ialah kadar penskalaan yang belum pernah berlaku sebelum ini untuk menampung pertumbuhan pengguna dan permintaan produk yang luar biasa, sambil membina platform yang matang. Jurutera sistem sering membina untuk skala 10 kali ganda dan berharap sistem itu bertahan beberapa tahun sambil bersiap sedia untuk peningkatan 10 kali ganda yang seterusnya. Dalam kes kami, pertumbuhan tahunan telah melebihi 10 kali ganda sepanjang tiga tahun lalu. Oleh itu, pembinaan dan pengendalian Habitat melibatkan serangkaian keputusan taktikal dan penyusunan langkah: memahami setiap komponen hingga ke peringkat paling asas untuk memaksimumkan tindanan sedia ada, sambil menangani kekangan kapasiti storan dan pengkomputeran bagi mendapatkan masa untuk pelaburan asas.

Seiring pertumbuhan OpenAI, Habitat juga perlu berkembang: mula-mula menjadi cukup andal untuk trafik produk kritikal, kemudian cukup pantas untuk pengguna global dan akhirnya mampu beroperasi dengan cekap pada skala yang sangat besar. Catatan ini ialah bahagian pertama siri dua bahagian tentang cara kami menskalakan storan dalam talian. Dalam catatan ini, kami akan berkongsi cara Habitat berkembang, sebab kami mengubahnya daripada pustaka kepada perkhidmatan, serta cara kami mengembangkan perkhidmatan yang ditulis dalam bahasa yang jarang digunakan untuk tindanan penyajian—Python—menjadi lapisan platform storan yang andal.

Dalam catatan akan datang, kami akan menerangkan secara terperinci cara kami mencapai keandalan berbilang penyewa pada skala besar, strategi berlapis untuk mengoptimumkan prestasi bacaan, serta cara kami mengembangkan kerjasama dengan Azure Cosmos DB bagi menangani permintaan luar biasa dengan andal.

Habitat bermula daripada idea mudah: jurutera produk tidak sepatutnya perlu memikirkan pengurusan pangkalan data. Habitat mula dilancarkan untuk menyokong GPT di DevDay 2023 sebagai pustaka Python kecil yang berinteraksi dengan pelayan utama ChatGPT. Habitat menyokong set operasi kecil yang dipetakan secara dalaman kepada aplikasi pangkalan data Azure Cosmos DB.

Tugas pustaka itu adalah untuk memberi pasukan produk cara mudah menyimpan dan mendapatkan data tanpa perlu menguasai butiran asasnya. Habitat mengurus kerja yang diperlukan: menentukan jenis data yang terlibat, sumber atau destinasinya, sama ada permintaan dibenarkan dan sebagainya.

Jurutera produk tidak perlu memikirkan carian skema, penghalaan, pengesahan, penyulitan, pensirian, pembentukan permintaan dan pengumpulan sambungan. Mereka juga tidak perlu mempertimbangkan sumber data tersebut: Azure Cosmos DB, cache atau jenis storan lain.

Pustaka Python ini berfungsi dengan baik dan Habitat diterima pakai dengan pantas oleh jurutera produk di OpenAI, walaupun tiada usaha pusat yang tersusun untuk beralih daripada penggunaan Postgres dan Azure Cosmos DB layan diri.

Apabila keperluan produk berkembang, pembangun produk juga mudah menambahkan sokongan bagi ciri seperti cache pihak klien, pemampatan atau penyulitan pada pustaka kongsi.

Menjelang pertengahan 2025, Habitat telah mencapai hadnya sebagai pelaksanaan pihak klien. Apabila lapisan Habitat menjadi semakin kompleks dan bilangan perkhidmatan OpenAI meningkat, perubahan protokol yang serasi dengan versi terdahulu menjadi tidak lagi praktikal.

Dalam satu keadaan, kami mahu mengurangkan kesan gangguan mana-mana satu rantau terhadap set data paling kritikal kami dengan memindahkannya ke sekumpulan akaun Azure Cosmos DB yang diedarkan merentas rantau. Perubahan ini memerlukan kami memperkenalkan logik penghalaan tambahan ke dalam klien, melumpuhkannya di sebalik bendera ciri, memastikan perubahan tersebut dilancarkan kepada semua klien, dan kemudian mendayakan bendera ciri tersebut.

Penyelarasan penggunaan merentas berpuluh-puluh perkhidmatan dan kerjasama dengan setiap pasukan untuk melancarkannya mengambil masa beberapa hari. Sebelum mengaktifkannya, kami sedar bahawa pencerminan perlu ditambah untuk memastikan logik pembahagian itu betul. Pelancarannya mengambil masa beberapa hari lagi. Bagaimana pula dengan pembetulan pepijat bagi sesuatu yang kami sedari tidak betul? Beberapa hari lagi. Akhirnya, kami bersedia untuk mendayakan bendera tersebut, tetapi salah satu pasukan terpaksa mengembalikan perkhidmatan mereka atas sebab yang tidak berkaitan kepada klien yang sebelum ini bermasalah, lalu menyebabkan gangguan yang telah cuba kami elakkan dengan sedaya upaya.

Perubahan pada pustaka klien memerlukan penyelarasan rumit merentas berpuluh-puluh perkhidmatan, dan proses ini semakin rapuh, tidak cekap serta mudah mengalami kegagalan operasi. Untuk mengurangkan pengembangan operasi ini bagi penggunaan akan datang, kami memutuskan untuk menjadikan Habitat sebagai perkhidmatan tersendiri.

Dengan memisahkan logik storan menjadi perkhidmatan kendiri, kami mewujudkan satu pusat kawalan untuk penggunaan, kebolehcerapan dan peningkatan platform. Daripada mengurus kemas kini yang berpecah-pecah, kami dapat melaksanakan penambahbaikan secara berpusat dan memberikan manfaat serta-merta kepada setiap produk OpenAI.

Perkhidmatan berpusat juga memberi kami satu titik kawalan untuk menyediakan asas keselamatan dan privasi data yang paling kukuh. Perkhidmatan Habitat membolehkan kami menguatkuasakan dasar kawalan akses secara berpusat, menjalankan pengelogan audit dan mengehadkan akses kepada sumber storan asas seperti Azure Cosmos DB. Habitat memainkan peranan penting dalam melindungi data pengguna dan mencegah akses tanpa kebenaran oleh pelaku luaran, dalaman dan ejen.

Kami tahu bahawa kami memerlukan sebuah perkhidmatan, tetapi belum mahu beralih daripada Python, walaupun Python menambah overhed apabila digunakan sebagai perkhidmatan. Penggunaan Python untuk perkhidmatan berdaya pemprosesan tinggi meningkatkan kependaman rangkaian serta menambah kos penskalaan CPU dan memori yang besar berbanding pelaksanaan pustaka setempat. Selain itu, kami sedar bahawa ketidakcekapan Python tidak dapat diterima pada skala 100 kali ganda, sekali gus menjadikan penulisan semula pada masa depan hampir pasti.

Namun, kami melihatnya sebagai langkah strategik untuk menanggung hutang teknikal. Matlamat utama kami ketika itu bukan untuk mengoptimumkan kos atau sumber, tetapi untuk menghapuskan halangan bagi pembangun produk dan mencapai kestabilan platform. Dengan menerima kompromi prestasi perkhidmatan Python untuk jangka pendek, kami dapat mengutamakan cabaran yang lebih mendesak, memantapkan API teras dan membina infrastruktur yang teguh.

Kami juga membuat pertaruhan terancang bahawa kemajuan pesat model pengekodan kami sendiri akan memudahkan laluan teknikal pada masa depan. Kami bertaruh bahawa apabila penghijrahan penuh daripada Python diperlukan, Codex dan GPT akan membolehkan penghijrahan itu dilaksanakan. Pertaruhan itu akhirnya terbukti tepat.

Menjalankan Habitat sebagai perkhidmatan Python bukanlah pilihan terbaik dari segi prestasi, tetapi pilihan itu diperlukan. Python membolehkan kami bergerak pantas, tetapi itu tidak bermakna kami boleh mengabaikan langkah berjaga-jaga dan menerima kependaman yang jauh lebih buruk. Apabila purata permintaan pengguna menghasilkan ratusan panggilan pangkalan data, panggilan paling perlahanlah yang dirasai pengguna. Kami mendapati bahawa cabaran utama menjalankan perkhidmatan Python pada skala ini ialah mengurus kependaman hujung agihan.

Asyncio membantu Python melaksanakan beban kerja terikat I/O secara serentak, tetapi tidak dapat mengatasi GIL Python atau menyediakan keselarian CPU. Selain memproksikan permintaan intensif I/O, Habitat mengendalikan banyak tanggungjawab dan tugas latar belakang intensif CPU: penghalaan, pemampatan, penyulitan, penjanaan hasil tambah semak, pemeriksaan kesihatan hiliran, pencerminan permintaan dan lindung nilai permintaan.

Dengan begitu banyak beban kerja dan tugas latar belakang intensif CPU dalam perkhidmatan kami, kelewatan penjadualan asyncio boleh menjadi penyumbang utama kepada kependaman hujung agihan permintaan. Sebelum penalaan untuk pelancaran awal perkhidmatan, jejak bagi permintaan dengan kependaman p99 dan ke atas menunjukkan bahawa walaupun storan hiliran bertindak balas dengan pantas, permintaan sering terhenti sementara menunggu coroutine berkenaan dijadualkan semula untuk menghuraikan respons.

Bagi perkhidmatan Python di OpenAI, selain mengukur metrik penggunaan dan ketepuan standard untuk memori, CPU, rangkaian dan cakera, kami mendapati bahawa pemantauan gelung asyncio serta tahap kesibukannya amat penting, diikuti penalaan yang sewajarnya.

Dengan menjadualkan tugas latar belakang secara berkala dan merekodkan perbezaan antara masa pelaksanaan yang dijangka dengan masa sebenar, kami dapat mengukur kelewatan penjadualan gelung peristiwa secara empirikal dan masa nyata. Pada penggunaan tinggi dengan banyak tugas berkos tinggi, bilangan sederhana permintaan serentak bagi setiap proses pun cukup untuk menghasilkan jitter penjadualan yang ketara, sehingga ratusan milisaat dan, dalam beberapa kes terpencil, beberapa saat.

Oleh itu, kami mengehadkan setiap proses supaya hanya mengendalikan sebilangan kecil permintaan serentak, sebaliknya meningkatkan jumlah proses pekerja Python secara besar-besaran.

Semasa pelancaran awal perkhidmatan, pemprofilan CPU perkhidmatan langsung menemukan satu punca utama kelewatan asyncio yang tinggi—dan kependaman hujung agihan yang terhasil—iaitu penghuraian JSON secara berkala bagi konfigurasi bendera ciri melalui Statsig, alat untuk mengurus bendera ciri, menjalankan ujian A/B dan banyak lagi.

Secara lalai, Statsig dikonfigurasi untuk meninjau konfigurasi baharu setiap minit tanpa jitter, dan konfigurasi itu merangkumi setiap peraturan pengeluaran bagi semua perkhidmatan. Dalam keputusan seni bina yang lain, sehingga lapan proses Python dijalankan bagi setiap pod untuk meningkatkan penggunaan CPU dan mengurangkan kependaman. Gabungan ini bermakna bahawa pada setiap minit, akan tiba satu ketika apabila semua pekerja dalam setiap pod menghentikan pemprosesan permintaan yang sedang berjalan dan menggunakan kitaran CPU untuk menghuraikan fail konfigurasi yang sangat besar.

Selepas pemprofilan CPU membantu kami mengenal pasti punca masalah, penyelesaiannya mudah: gunakan konfigurasi lebih kecil dan tersasar, panjangkan selang penyegaran serta tambahkan jitter pada tugas latar belakang seperti ini.

Untuk mengekalkan kelewatan asyncio yang rendah, pengimbangan beban permintaan yang baik merentas proses pelayan juga amat penting; tanpa penalaan, pengumpulan sambungan boleh menghasilkan kesan yang bertentangan.

Dengan pengumpulan sambungan pada pihak klien, satu proses klien yang membuat banyak permintaan serentak mungkin hanya mewujudkan beberapa sambungan pelayan, dan akibatnya menghantar keseluruhan bebannya kepada hanya beberapa proses. Sebelum kami melaraskan cara kami melakukan pengimbangan beban, perkhidmatan kami mempunyai variasi penggunaan yang ketara, dengan sesetengah proses pada hujung taburan melayani 5-10 kali ganda bilangan permintaan serentak berbanding purata.

Kami menemui perkara ini melalui satu kejadian yang berlaku secara kebetulan, apabila walaupun klien yang membebankan sebahagian daripada perkhidmatan kami telah dihentikan, sebahagian proses masih mengalami kemerosotan lama selepas trafik yang melonjak itu berakhir. Malah, kami mendapati bahawa proses tersebut mengalami kemerosotan yang semakin tidak terkawal, menerima semakin banyak permintaan sehingga kami memulakannya semula. Setelah sesuatu pod terlebih beban, terdapat tingkah laku tertentu yang menyebabkan lebih banyak trafik terus dihantar ke pod yang terlebih beban itu. Ini merupakan kelas kegagalan yang sudah biasa dialami oleh sesetengah rakan sepasukan kami daripada kerja terdahulu: kegagalan metastabil⁠(dibuka dalam tetingkap baru).

Kami mengesyaki kumpulan sambungan sebagai puncanya dan menguji andaian ini dengan mengehadkan tempoh maksimum penggunaan semula sambungan. Langkah itu sememangnya mengehadkan kemerosotan dan mengesahkan hala tuju siasatan kami. Siasatan lanjut mendapati bahawa aiohttp TCPConnector Python menggunakan semula sambungan secara LIFO secara lalai: sambungan yang paling baru dikembalikan dipilih untuk permintaan seterusnya. Biasanya, ini ialah pilihan lalai yang munasabah: penggunaan semula sambungan terkini membolehkan sambungan tambahan yang dicipta untuk menangani lonjakan trafik tamat masa ketika melahu, sekali gus mengurangkan overhed penyelenggaraan sambungan tambahan. Dalam kes ini, keadaan itu mewujudkan kegagalan metastabil. Semasa lonjakan permintaan, permintaan kepada pelayan perlahan yang terlebih beban mengembalikan sambungan kepada kumpulan dengan lebih lewat. Oleh itu, sambungan tersebut lebih kerap dipilih oleh permintaan berikutnya, lalu semakin menumpukan trafik pada pod yang sudah terjejas. Penampalan kumpulan sambungan supaya menggunakan semula sambungan secara FIFO memutuskan gelung maklum balas ini dan turut mengurangkan variasi permintaan dalam keadaan stabil.

Kini, kami kebanyakannya bergantung pada Istio dan Envoy untuk menyediakan pengumpulan sambungan serta strategi pengimbangan yang lebih peka terhadap beban pelayan di seluruh infrastruktur OpenAI, sekali gus mengelakkan masalah ini sepenuhnya.

Salah satu kesan sampingan penalaan untuk kelewatan asyncio rendah dan penggunaan begitu banyak proses Python ialah kebergantungan hiliran amat mudah dibebankan oleh jumlah sambungan yang sangat besar, yang dikenali sebagai “thundering herd”.

Penggunaan harian biasa—jika tidak ditala supaya berjalan perlahan—boleh menyebabkan pergolakan CPU yang ketara akibat kitaran sambungan. Kebocoran sambungan juga boleh melumpuhkan rangkaian dengan memenuhi get laluan NAT. Masalah seperti ini juga bukan sesuatu yang luar biasa bagi perkhidmatan lain, tetapi ambang untuk mencetuskannya menjadi jauh lebih rendah apabila terdapat proses yang lebih banyak sehingga satu susunan magnitud, yang sering menyebabkan sumber berkaitan rangkaian menjadi tepu yang tidak dijangka perlu dikendalikan oleh klien dalam keadaan stabil berdasarkan daya pemprosesan semata-mata.

Kami juga bergantung pada Envoy untuk memaksimumkan fan-in sambungan kami. Kami menggunakannya untuk menaik taraf sambungan HTTP/1 Python kepada HTTP/2 bagi memanfaatkan pemultipleksan, kemudian mengumpulkan sambungan tersebut dan memanjangkan jangka hayat sambungan. Envoy juga memberikan kami tempat berpusat untuk melaksanakan had kadar dan pemutus litar, yang kurang berkesan jika dilaksanakan pada setiap proses Python secara berasingan.

Salah satu sebab kami dapat menskalakan Python sehingga tahap ini ialah API Habitat yang mempunyai kekangan, yang memastikan kos permintaan kekal boleh dijangka. Daripada membenarkan klien membina pertanyaan SQL sewenang-wenangnya yang boleh mengakibatkan imbasan jadual yang besar atau cantuman merentas banyak jadual, Habitat menyediakan API NoSQL yang ringkas. Kekurangan API yang berkuasa merupakan pertukaran yang disengajakan dalam reka bentuk Habitat.

Kami mahu mengoptimumkan permintaan yang ringkas, boleh diramal dan memerlukan jumlah kerja yang tetap. Berdasarkan pengalaman kami, sistem ini jauh lebih mudah diskalakan serta sukar untuk disalahgunakan atau tersilap dikendalikan. Permintaan dengan pengembangan tidak menentu berbahaya dari segi operasi: permintaan ini merumitkan pengasingan dan pengimbangan beban, serta mewujudkan jurang kependaman yang sukar diskalakan oleh perkhidmatan mahupun kliennya.

Sebelum kami beralih kepada Habitat dan Azure Cosmos DB, kebanyakan data dalam talian OpenAI disimpan dalam Postgres. Pada masa itu, semua perubahan pertanyaan dan skema mudah disemak untuk memastikan kelakuannya baik serta beroperasi pada data berindeks sebelum digunakan dalam pengeluaran. Apabila pasukan dan produk berkembang, perkara ini dengan cepat menjadi sukar diurus dan kerap menyebabkan gangguan apabila satu pertanyaan baharu yang mahal pada laluan sibuk melumpuhkan pangkalan data.

Masalahnya ialah ketidakseimbangan kos: pertanyaan SQL yang mahal dan sukar dijalankan boleh ditulis dengan murah dan mudah. Dalam Habitat, kami mengelakkan masalah ini dan memastikan pertanyaan mahal amat jelas pada pihak klien. Tiada pertanyaan tanpa had yang boleh membebankan Habitat, manakala cantuman kompleks dan perentasan graf memerlukan pasukan produk melakukan sebahagian kerja berat, sekali gus membantu mengoptimumkan reka bentuk yang lebih cekap secara keseluruhan.

Habitat menyediakan API NoSQL yang dimodelkan berasaskan jenis objek dan sisi yang ditakrifkan klien, diilhamkan oleh TAO⁠(dibuka dalam tetingkap baru). Klien mentakrifkan objek dan sisi serta hubungan antara kedua-duanya terlebih dahulu, tetapi bukan kandungan setiap jenis. Hubungan yang terhasil menyerupai graf, tetapi Habitat sendiri tidak menyokong pertanyaan perentasan graf biasa selain pertanyaan sisi langsung bagi objek tertentu.

Kami membahagikan graf ini supaya setiap objek dan sisi berkaitannya ditempatkan bersama dalam satu petak peringkat storan, tetapi kami tidak berusaha secara khusus pada peringkat pangkalan data untuk menempatkan objek bersama objek jauh yang dirujuk oleh sisinya. Hasilnya, model ini mudah dibahagikan untuk kebolehskalaan mendatar, tetapi perentasan graf tidak cekap kerana setiap lompatan antara objek mungkin memerlukan pengambilan daripada dua akaun Azure Cosmos DB yang berbeza sama sekali dan disimpan di rantau berlainan.

Bagi klien dengan keperluan pertanyaan lebih kompleks, kami menyediakan paparan sekunder luar talian Habitat melalui Rockset. Kami menggunakan tangkapan perubahan data (CDC) untuk menstrim perubahan daripada storan dalam talian kepada tika Rockset yang diasingkan hampir dalam masa nyata. Setiap pasukan klien bertanggungjawab menskalakan tika Rockset mereka sendiri bagi memenuhi keperluan pertanyaan kompleks.

Penyediaan Rockset ini menambah sedikit kesukaran bagi klien kami, tetapi kami menganggapnya sebagai kompromi yang tepat buat masa ini: menjadikan pertanyaan ringkas sebagai pilihan lalai sambil menyediakan jalan keluar bagi mereka yang memerlukan pertanyaan kompleks. Reka bentuk ini mengasingkan storan dalam talian kami daripada beban kerja analitik dan carian yang intensif bacaan.

Penangguhan penulisan semula Python selama setahun membolehkan kami menumpukan perhatian pada cabaran yang lebih mendesak dan berimpak semasa pertumbuhan luar biasa kami. Apabila platform semakin matang dan pertumbuhan terus memecut—serta menjadi perkhidmatan kedua terbesar di OpenAI mengikut bilangan teras dan keempat mengikut jejak Envoy—akhirnya tiba masanya untuk kami meninggalkan Python. Pada kemuncaknya, Python membantu kami mengendalikan lebih 20 juta permintaan setiap saat.

Pada suku kedua 2026, dengan hanya dua jurutera, Codex dan GPT‑5.5, kami berjaya menulis semula seluruh perkhidmatan dalam Rust. Perkhidmatan Rust baharu ini kini mengendalikan 95% permintaan pengeluaran kami; kami akan menamatkan penggunaan Python sepenuhnya dalam beberapa minggu akan datang. Data kami menunjukkan bahawa perkhidmatan Rust enam kali lebih cekap menggunakan CPU dan 15 kali lebih cekap menggunakan memori berbanding versi Python, dengan purata kependaman dan kependaman hujung agihan yang jauh lebih rendah. Kami merancang untuk berkongsi lebih banyak pembelajaran dalam catatan blog akan datang.

Perkhidmatan Python—dan kini Rust—hanyalah satu aspek Habitat. Dalam bahagian II siri yang menerangkan cara kami menskalakan storan dalam talian dengan pantas untuk melayani lebih satu bilion pengguna ChatGPT, kami akan membincangkan lapisan storan dan cara Habitat menyediakan lebih 500 petabait serta mengendalikan lebih 70 juta permintaan setiap saat.

Jika anda berminat untuk mengusahakan sistem OLTP pada skala termaju dan berminat dengan bidang kejuruteraan seperti ini, lihat jawatan kosong ini dalam pasukan kami⁠.