Menskalakan penyimpanan online dengan cepat untuk 1 miliar lebih pengguna ChatGPT

Setiap produk OpenAI bergantung pada akses data yang cepat dan andal, baik saat seseorang masuk, memeriksa pengaturan Codex, maupun memulai percakapan baru di ChatGPT. Setiap tindakan tersebut mungkin memerlukan banyak pencarian data terpisah sebelum produk dapat merespons. Jika permintaan tersebut lambat, produk pun terasa lambat. Jika permintaan tersebut gagal, produk berhenti berfungsi sepenuhnya.

Habitat adalah platform penyimpanan online yang kami bangun agar produk OpenAI dapat mengakses informasi yang diperlukan secara cepat dan andal. Habitat kini menangani lebih dari 70 juta permintaan setiap detik, mendukung produk yang digunakan oleh lebih dari 1 miliar orang setiap minggu di hampir 40 wilayah geografis. Habitat pertama kali diluncurkan untuk mendukung GPT di DevDay 2023, bermula sebagai pustaka sisi klien Python sederhana yang terhubung ke satu basis data. Kini, Habitat menjadi sistem terdistribusi kompleks yang melayani lebih dari 500 petabita data.

Membangun dan mengoperasikan infrastruktur pada skala ini bukanlah perkara mudah, tetapi juga bukan sesuatu yang sangat menantang. Yang membuat situasi kami unik adalah laju penskalaan luar biasa yang diperlukan untuk mengimbangi lonjakan pengguna dan permintaan produk, sambil sekaligus membangun platform yang matang. Engineer sistem biasanya membangun untuk skala 10 kali lipat dan berharap sistem bertahan beberapa tahun sambil mempersiapkan peningkatan 10 kali lipat berikutnya. Dalam kasus kami, pertumbuhan tahunan telah melampaui 10 kali lipat selama tiga tahun terakhir. Karena itu, membangun dan mengoperasikan Habitat menjadi rangkaian keputusan taktis dan pengurutan prioritas: memahami setiap komponen hingga tingkat terendah untuk memaksimalkan stack yang ada, sambil mengatasi keterbatasan kapasitas penyimpanan dan komputasi demi mengulur waktu bagi investasi mendasar.

Seiring pertumbuhan OpenAI, Habitat pun harus berkembang: mula-mula menjadi cukup andal untuk lalu lintas produk yang sangat penting, lalu cukup cepat bagi pengguna global, dan akhirnya mampu beroperasi dengan tangkas pada skala masif. Tulisan ini adalah bagian pertama dari seri dua bagian tentang cara kami menskalakan penyimpanan online. Dalam tulisan ini, kami akan membagikan evolusi Habitat, alasan kami mengubahnya dari pustaka menjadi layanan, dan cara kami mengembangkan layanan yang ditulis dalam bahasa yang jarang digunakan untuk stack layanan—Python—menjadi lapisan platform penyimpanan yang andal.

Dalam tulisan mendatang, kami akan mengulas secara mendetail cara mewujudkan keandalan multi-tenancy pada skala besar, strategi berlapis kami untuk mengoptimalkan performa baca, dan cara kami memperluas kemitraan dengan Azure Cosmos DB agar dapat menangani permintaan yang belum pernah terjadi sebelumnya secara andal.

Habitat berawal dari gagasan sederhana: engineer produk tidak semestinya perlu memikirkan pengelolaan basis data. Habitat pertama kali diluncurkan untuk mendukung GPT di DevDay 2023 sebagai pustaka Python kecil yang berinteraksi dengan server utama ChatGPT. Pustaka ini mendukung sejumlah kecil operasi yang secara internal dipetakan ke aplikasi basis data Azure Cosmos DB.

Tugas pustaka ini adalah memberi tim produk cara sederhana untuk menyimpan dan mengambil data tanpa harus menguasai detail teknis yang mendasarinya. Habitat menangani pekerjaan yang diperlukan: menentukan jenis data yang terlibat, dari mana data berasal atau ke mana harus dikirim, apakah permintaan diizinkan, dan sebagainya.

Engineer produk tidak perlu memikirkan pencarian skema, perutean, otorisasi, enkripsi, serialisasi, pembentukan permintaan, dan pengumpulan koneksi. Mereka bahkan tidak perlu mempertimbangkan asal data: Azure Cosmos DB, cache, atau jenis penyimpanan lainnya.

Pustaka Python ini berfungsi baik dan Habitat diadopsi dengan cepat oleh engineer produk di OpenAI, meskipun tidak ada dorongan terpusat untuk meninggalkan penggunaan mandiri Postgres dan Azure Cosmos DB.

Seiring berkembangnya kebutuhan produk, pengembang produk pun dapat dengan mudah menambahkan dukungan untuk fitur seperti caching sisi klien, kompresi, atau enkripsi ke pustaka bersama.

Pada pertengahan 2025, Habitat telah mencapai batasnya sebagai implementasi sisi klien. Seiring makin kompleksnya lapisan Habitat dan bertambahnya jumlah layanan OpenAI, perubahan protokol yang kompatibel dengan versi sebelumnya tidak lagi memungkinkan.

Dalam satu kasus, kami ingin memperkecil dampak gangguan di satu wilayah terhadap set data terpenting dengan memigrasikannya ke sekumpulan akun Azure Cosmos DB yang tersebar secara regional. Perubahan ini mengharuskan kami menambahkan logika perutean ke klien, menonaktifkannya di balik feature flag, memastikan pembaruan diterapkan ke semua klien, lalu mengaktifkan feature flag tersebut.

Mengoordinasikan deployment di puluhan layanan dan bekerja sama dengan setiap tim untuk menerapkannya membutuhkan waktu berhari-hari. Sebelum mengaktifkannya, kami menyadari perlunya pencerminan untuk memastikan logika sharding berfungsi dengan benar. Penerapannya kembali membutuhkan beberapa hari. Memperbaiki bug pada hal lain yang ternyata keliru? Beberapa hari lagi. Akhirnya kami siap mengaktifkan flag tersebut, tetapi salah satu tim mengembalikan layanannya ke versi klien lama yang memiliki bug karena alasan lain, sehingga memicu gangguan yang selama ini berusaha keras kami hindari.

Perubahan pada pustaka klien memerlukan koordinasi rumit di puluhan layanan, sebuah proses yang terbukti makin rapuh, tidak efisien, dan rentan terhadap kegagalan operasional. Untuk mengurangi penyebaran dampak operasional pada deployment mendatang, kami memutuskan menjadikan Habitat sebagai layanan tersendiri.

Dengan memisahkan logika penyimpanan menjadi layanan mandiri, kami membentuk satu titik kendali untuk deployment, observabilitas, dan peningkatan platform. Alih-alih mengelola pembaruan yang terfragmentasi, kami dapat menerapkan peningkatan secara terpusat dan langsung memberi manfaat bagi setiap produk OpenAI.

Layanan terpusat juga memberi kami satu titik kontrol untuk menyediakan fondasi keamanan dan privasi data yang paling kuat. Di layanan Habitat, kami dapat menegakkan kebijakan kontrol akses secara terpusat, melakukan pencatatan audit, dan membatasi akses ke sumber daya penyimpanan dasar seperti Azure Cosmos DB. Habitat berperan penting dalam melindungi data pengguna dan mencegah akses tanpa izin dari pihak eksternal, internal, maupun agen.

Kami tahu bahwa kami membutuhkan layanan, tetapi belum ingin bermigrasi dari Python, meskipun penggunaan Python sebagai layanan menimbulkan overhead tambahan. Menggunakan Python untuk layanan dengan throughput tinggi meningkatkan latensi jaringan serta menambah biaya penskalaan CPU dan memori secara signifikan dibandingkan eksekusi pustaka lokal. Selain itu, kami menyadari bahwa inefisiensi Python tidak dapat diterima pada skala 100 kali lipat sehingga penulisan ulang pada akhirnya hampir pasti diperlukan.

Namun, kami memandangnya sebagai penambahan utang teknis yang strategis. Tujuan utama kami saat itu bukan mengoptimalkan biaya atau sumber daya, melainkan menghilangkan hambatan bagi pengembang produk dan mencapai stabilitas platform. Dengan menerima kompromi performa layanan Python untuk jangka pendek, kami dapat memprioritaskan tantangan yang lebih mendesak, menetapkan API inti, dan membangun infrastruktur yang tangguh.

Kami juga mengambil taruhan yang diperhitungkan bahwa kemajuan pesat model pengodean kami sendiri akan menyederhanakan jalur teknis di masa mendatang. Kami bertaruh bahwa saat migrasi penuh dari Python diperlukan, Codex dan GPT akan membuat migrasi tersebut dapat dilakukan. Taruhan itu akhirnya terbukti tepat.

Menjalankan Habitat sebagai layanan Python bukan pilihan optimal dari sisi performa, tetapi tetap diperlukan. Python memungkinkan kami bergerak cepat, tetapi bukan berarti kami dapat mengabaikan kehati-hatian dan menerima latensi yang jauh lebih buruk. Jika rata-rata permintaan pengguna memicu ratusan panggilan basis data, panggilan basis data paling lambatlah yang dirasakan pengguna. Kami menemukan bahwa tantangan utama menjalankan layanan Python pada skala ini adalah mengelola latensi ekor tersebut.

Asyncio membantu Python menjalankan beban kerja berbasis I/O secara bersamaan, tetapi tidak mengatasi GIL Python ataupun menyediakan paralelisme CPU. Selain meneruskan permintaan yang sarat I/O, Habitat menangani banyak tugas berat CPU dan tugas latar belakang: perutean, kompresi, enkripsi, checksum, pemeriksaan kesehatan layanan hilir, pencerminan permintaan, dan hedging.

Dengan begitu banyak beban kerja berat CPU dan tugas latar belakang dalam layanan kami, penundaan penjadwalan asyncio dapat dengan mudah mendominasi latensi ekor permintaan. Sebelum penyetelan untuk peluncuran awal layanan, jejak permintaan dengan latensi p99 ke atas menunjukkan bahwa meskipun penyimpanan hilir merespons dengan cepat, permintaan sering terhenti saat menunggu coroutine terkait dijadwalkan kembali untuk mengurai respons.

Untuk layanan Python di OpenAI, selain mengukur metrik utilisasi dan saturasi standar pada penggunaan memori, CPU, jaringan, dan disk, kami mendapati bahwa loop asyncio dan tingkat kesibukannya juga harus dipantau, lalu disetel sesuai kebutuhan.

Dengan menjadwalkan tugas latar belakang secara berkala dan mencatat selisih antara waktu eksekusi yang diharapkan dan yang sebenarnya, kami dapat mengukur penundaan penjadwalan event loop secara empiris dan real-time. Pada utilisasi tinggi dengan banyak tugas mahal, jumlah permintaan serentak yang relatif sedikit per proses pun cukup untuk menimbulkan jitter penjadwalan yang signifikan, hingga ratusan milidetik dan, dalam beberapa kasus ekstrem, beberapa detik.

Karena itu, kami membatasi setiap proses agar hanya melayani sedikit permintaan serentak dan sebagai gantinya menambah jumlah proses pekerja Python secara masif.

Saat peluncuran awal layanan, profiling CPU langsung mengungkap salah satu akar penyebab tingginya penundaan asyncio—dan akibatnya, tingginya latensi ekor: penguraian JSON secara berkala atas konfigurasi feature flag melalui Statsig, alat untuk mengelola feature flag, menjalankan pengujian A/B, dan lainnya.

Secara default, Statsig dikonfigurasi untuk mengambil pembaruan konfigurasi setiap menit tanpa jitter, dan konfigurasi tersebut mencakup semua aturan produksi di seluruh layanan. Di bagian lain, diputuskan secara arsitektural untuk menjalankan hingga 8 proses Python per pod demi meningkatkan penggunaan CPU dan menurunkan latensi. Gabungan kondisi ini berarti bahwa setiap menit, pada suatu saat semua pekerja di setiap pod berhenti memproses permintaan yang sedang berjalan dan menghabiskan siklus CPU untuk mengurai berkas konfigurasi berukuran sangat besar.

Setelah profiling CPU membantu menemukan akar masalahnya, perbaikannya sederhana: menerapkan konfigurasi tertarget yang lebih kecil, memperpanjang interval pembaruan, dan menambahkan jitter pada tugas latar belakang semacam ini.

Untuk menjaga penundaan asyncio tetap rendah, permintaan juga harus diseimbangkan dengan baik di seluruh proses server; tanpa penyetelan, pengumpulan koneksi justru dapat menghambat tujuan ini.

Dengan pengumpulan koneksi sisi klien, satu proses klien yang mengirim banyak permintaan serentak mungkin hanya membuat beberapa koneksi server sehingga seluruh bebannya dikirim ke segelintir proses saja. Sebelum menyesuaikan penyeimbangan beban, utilisasi layanan kami sangat bervariasi; beberapa proses di ekor melayani 5–10 kali jumlah rata-rata permintaan serentak.

Kami menemukannya secara kebetulan saat terjadi insiden: meskipun klien yang membebani sebagian layanan telah dihentikan, sebagian proses tetap mengalami penurunan performa lama setelah lonjakan lalu lintas berakhir. Bahkan, kami melihat penurunan performa proses tersebut terus memburuk dan menerima semakin banyak permintaan hingga kami memulai ulang prosesnya. Begitu sebuah pod kelebihan beban, suatu perilaku membuat lebih banyak lalu lintas terus diarahkan ke pod tersebut. Ini adalah jenis kegagalan yang sudah sangat dikenal sebagian rekan kami dari pekerjaan sebelumnya: kegagalan metastabil⁠(terbuka di jendela baru).

Kami menduga pool koneksi sebagai penyebabnya dan menguji dugaan ini dengan membatasi durasi maksimum penggunaan ulang koneksi. Langkah tersebut memang membatasi penurunan performa dan mengonfirmasi arah investigasi kami. Investigasi lebih lanjut menemukan bahwa TCPConnector aiohttp Python secara default menggunakan ulang koneksi dengan pola LIFO: koneksi yang paling baru dikembalikan dipilih untuk permintaan berikutnya. Biasanya ini merupakan default yang wajar: penggunaan ulang koneksi terbaru memungkinkan koneksi tambahan yang dibuat untuk menangani lonjakan lalu lintas mencapai batas waktu saat menganggur, sehingga mengurangi overhead pemeliharaan koneksi tambahan. Dalam kasus ini, perilaku tersebut menimbulkan kegagalan metastabil bagi kami. Saat terjadi lonjakan permintaan, permintaan ke server lambat yang kelebihan beban mengembalikan koneksi ke pool lebih belakangan. Akibatnya, koneksi tersebut lebih sering dipilih oleh permintaan berikutnya sehingga lalu lintas makin terkonsentrasi pada pod yang sudah kewalahan. Mengubah pool koneksi agar menggunakan pola FIFO memutus loop umpan balik ini dan bahkan mengurangi variasi permintaan dalam kondisi stabil.

Kini kami terutama mengandalkan Istio dan Envoy untuk menyediakan pengumpulan koneksi serta strategi penyeimbangan yang lebih peka terhadap beban server di seluruh infrastruktur OpenAI sehingga masalah ini dapat dihindari sepenuhnya.

Salah satu efek samping penyetelan untuk penundaan asyncio yang rendah dan penggunaan begitu banyak proses Python adalah dependensi hilir sangat mudah kewalahan oleh jumlah koneksi yang sangat besar, yang dikenal sebagai “thundering herd”.

Deployment harian biasa—jika tidak disetel agar berlangsung perlahan—dapat menimbulkan lonjakan penggunaan CPU yang signifikan akibat siklus koneksi. Kebocoran koneksi juga dapat melumpuhkan jaringan dengan menjenuhkan gateway NAT. Masalah ini juga lazim terjadi pada layanan lain, tetapi ambang pemicunya menjadi jauh lebih rendah karena jumlah proses lebih besar hingga satu orde magnitudo. Hal ini sering menjenuhkan sumber daya terkait jaringan yang, jika hanya melihat throughput, tidak diperkirakan klien perlu ditangani dalam kondisi stabil.

Kami juga mengandalkan Envoy untuk memaksimalkan fan-in koneksi. Kami menggunakannya untuk meningkatkan koneksi HTTP/1 Python ke HTTP/2 agar dapat memanfaatkan multiplexing, lalu mengumpulkan koneksi tersebut dan memperpanjang masa pakainya. Envoy juga memberi kami satu tempat terpusat untuk menerapkan batas laju dan circuit breaker yang akan kurang efektif jika diterapkan di setiap proses Python mandiri.

Salah satu alasan kami dapat menskalakan Python sejauh ini adalah API Habitat yang terbatas, sehingga biaya permintaan tetap dapat diprediksi. Alih-alih mengizinkan klien menyusun kueri SQL sewenang-wenang yang dapat memicu pemindaian tabel besar atau join banyak tabel, Habitat menyediakan API NoSQL sederhana. Tidak adanya API yang canggih merupakan kompromi yang disengaja dalam desain Habitat.

Kami berupaya mengoptimalkan permintaan yang sederhana, dapat diprediksi, dan memerlukan jumlah kerja konstan. Berdasarkan pengalaman kami, sistem semacam ini jauh lebih mudah diskalakan serta sulit digunakan secara keliru. Permintaan dengan fan-out yang tidak dapat diprediksi berbahaya secara operasional: kondisi ini mempersulit isolasi dan penyeimbangan beban serta menimbulkan lonjakan tajam latensi yang sulit ditangani saat menskalakan layanan maupun kliennya.

Sebelum beralih ke Habitat dan Azure Cosmos DB, sebagian besar data online OpenAI disimpan di Postgres. Saat itu, semua perubahan kueri dan skema mudah ditinjau untuk memastikan perilakunya baik dan beroperasi pada data yang diindeks sebelum diterapkan ke produksi. Seiring pertumbuhan tim dan produk, proses ini cepat menjadi tidak terkendali dan sering menyebabkan gangguan ketika satu kueri baru yang mahal pada jalur sibuk melumpuhkan basis data.

Masalahnya adalah ketimpangan biaya: menulis kueri SQL yang mahal dan sulit dijalankan itu murah dan mudah. Di Habitat, kami menghindari hal ini dan membuat kueri mahal sangat mudah dikenali di sisi klien. Tidak ada kueri tanpa batas yang dapat membebani Habitat secara berlebihan. Join kompleks dan penelusuran graf mengharuskan tim produk menangani sebagian pekerjaan berat, sehingga secara keseluruhan mendorong desain yang lebih efisien.

Habitat menyediakan API NoSQL yang dimodelkan berdasarkan tipe objek dan edge yang ditentukan klien, terinspirasi oleh TAO⁠(terbuka di jendela baru). Klien menentukan objek dan edge serta hubungan di antaranya terlebih dahulu, tetapi tidak menentukan konten setiap tipe. Hubungan yang dihasilkan menyerupai graf, tetapi Habitat sendiri tidak mendukung kueri penelusuran graf biasa selain kueri edge langsung dari objek tertentu.

Kami mempartisi graf ini agar setiap objek dan edge terkait berada bersama dalam satu partisi tingkat penyimpanan, tetapi tidak melakukan upaya khusus pada tingkat basis data untuk menempatkan objek bersama objek jarak jauh yang dirujuk oleh edge-nya. Hasilnya, model mudah dipartisi untuk skalabilitas horizontal, tetapi penelusuran graf tidak efisien karena setiap lompatan antardua objek mungkin perlu mengambil data dari dua akun Azure Cosmos DB yang sepenuhnya berbeda dan tersimpan di wilayah berbeda.

Bagi klien dengan kebutuhan kueri yang lebih kompleks, kami menyediakan tampilan sekunder offline Habitat melalui Rockset. Kami menggunakan change data capture (CDC) untuk mengalirkan perubahan dari penyimpanan online ke instans Rockset terisolasi secara hampir real-time. Setiap tim klien bertanggung jawab menskalakan instans Rockset mereka sendiri untuk memenuhi kebutuhan kueri kompleks.

Penyediaan Rockset ini menambah hambatan bagi klien, tetapi menurut kami merupakan kompromi yang tepat saat ini: menjadikan kueri sederhana sebagai default sekaligus menyediakan jalan keluar bagi mereka yang membutuhkan kueri kompleks. Desain ini mengisolasi penyimpanan online kami dari beban kerja analitik dan pencarian yang sarat baca.

Menunda penulisan ulang Python selama setahun memungkinkan kami berfokus pada tantangan yang lebih mendesak dan berdampak selama periode pertumbuhan luar biasa. Setelah platform makin matang dan pertumbuhan kami terus melaju—serta menjadi layanan terbesar kedua berdasarkan jumlah core di OpenAI dan keempat berdasarkan jejak Envoy—akhirnya tiba saatnya meninggalkan Python. Pada puncaknya, Python membantu kami melayani lebih dari 20 juta permintaan setiap detik.

Pada kuartal kedua 2026, hanya dengan 2 engineer, Codex, dan GPT‑5.5, kami berhasil menulis ulang seluruh layanan dalam Rust. Layanan Rust baru ini kini menangani 95% permintaan produksi kami; Python akan kami hentikan sepenuhnya dalam beberapa minggu mendatang. Data kami menunjukkan bahwa layanan Rust 6 kali lebih efisien dalam penggunaan CPU dan 15 kali lebih efisien dalam penggunaan memori dibandingkan versi Python, dengan latensi rata-rata dan ekor yang jauh lebih rendah. Kami berencana membagikan lebih banyak pelajaran dalam blog mendatang.

Layanan Python—dan kini Rust—hanyalah salah satu aspek Habitat. Dalam bagian II seri tentang cara kami menskalakan penyimpanan online dengan cepat untuk melayani lebih dari 1 miliar pengguna ChatGPT, kami akan membahas lapisan penyimpanan dan cara Habitat melayani lebih dari 500 petabita serta lebih dari 70 juta permintaan setiap detik.

Jika Anda ingin mengembangkan sistem OLTP pada skala terdepan dan tertarik dengan rekayasa semacam ini, lihat posisi yang tersedia di tim kami⁠.