Nyekalakake panyimpenan online kanthi cepet kanggo 1 milyar luwih pangguna ChatGPT

Saben produk OpenAI gumantung marang akses data sing cepet lan andal, nalika wong mlebu, mriksa setelan Codex, utawa miwiti pacelathon anyar ing ChatGPT. Saben tumindak kasebut bisa mbutuhake akeh panggolekan data kapisah sadurunge produk bisa nanggapi. Yen panjaluk kasebut alon, produke krasa alon. Yen panjaluk kasebut gagal, produke mandheg sakabehe.

Habitat minangka platform panyimpenan online sing kita bangun supaya produk OpenAI bisa ngakses informasi sing dibutuhake kanthi cepet lan andal. Saiki Habitat nangani luwih saka 70 yuta panjaluk saben detik lan ndhukung produk sing digunakake luwih saka 1 milyar wong saben minggu ing meh 40 wilayah geografis. Habitat pisanan diluncurake kanggo ndhukung GPT ing DevDay 2023, wiwit saka pustaka Python sisi klien prasaja sing nyambung menyang siji basis data. Saiki, Habitat dadi sistem kasebar rumit sing nglayani data luwih saka 500 petabyte.

Mbangun lan ngoperasikake infrastruktur ing skala iki ora gampang, nanging uga ora mligi angel. Sing ndadekake kahanan kita unik yaiku laju penskalaan sing durung tau ana sadurunge kanggo ndhukung pertumbuhan pangguna lan panjaluk produk sing luar biasa, sembari mbangun platform sing mateng. Insinyur sistem kerep mbangun kanggo skala 10x lan ngarepake sistem kasebut tahan pirang-pirang taun nalika nyiapake 10x sabanjure. Ing kasus kita, pertumbuhan saben taun luwih saka 10x sajrone telung taun kepungkur. Mula, pembangunan lan operasi Habitat dadi rerangkening keputusan taktis lan urutan tumindak: mangerteni saben komponen nganti tingkat paling ngisor kanggo ngoptimalake stack sing ana, sembari ngatasi kekurangan kapasitas panyimpenan lan komputasi supaya ana wektu kanggo investasi dhasar.

Nalika OpenAI saya gedhe, Habitat uga kudu melu tuwuh: pisanan cukup andal kanggo lalu lintas produk sing kritis, banjur cukup cepet kanggo pangguna global, lan pungkasane bisa dioperasikake kanthi prigel ing skala gedhe banget. Tulisan iki minangka bagean kapisan saka seri rong bagean babagan cara kita nyekalakake panyimpenan online. Ing tulisan iki, kita bakal nuduhake evolusi Habitat, alasan ngowahi saka pustaka dadi layanan, lan cara kita ngoptimalake layanan sing ditulis nganggo basa sing ora umum kanggo stack layanan—Python—dadi lapisan platform panyimpenan sing andal.

Ing tulisan sabanjure, kita bakal njlentrehake carane nggawe multi-tenancy andal ing skala gedhe, strategi berlapis kanggo ngoptimalake kinerja maca, lan carane nyekalakake kemitraan karo Azure Cosmos DB supaya bisa nangani panjaluk sing durung tau ana kanthi andal.

Habitat diwiwiti saka gagasan prasaja: insinyur produk ora perlu mikirake pengelolaan basis data. Habitat pisanan diluncurake kanggo ndhukung GPT ing DevDay 2023 minangka pustaka Python cilik sing sesambungan karo server utama ChatGPT. Pustaka iki ndhukung sawetara operasi sing ing balik layar dipetakake menyang aplikasi basis data, Azure Cosmos DB.

Tugas pustaka kasebut yaiku menehi cara prasaja marang tim produk kanggo nyimpen lan njupuk data tanpa kudu nguwasani rincian dhasare. Habitat nangani tugas sing dibutuhake: nemtokake jinis data, saka ngendi data kudu dijupuk utawa dikirim, apa panjaluke diidini, lan liya-liyane.

Insinyur produk ora perlu ngurusi panggolekan skema, perutean, otorisasi, enkripsi, serialisasi, pambentukan panjaluk, lan pooling sambungan. Dheweke malah ora perlu mikir saka ngendi datane: Azure Cosmos DB, cache, utawa jinis panyimpenan liyane.

Pustaka Python iki bisa digunakake kanthi apik lan Habitat cepet diadopsi insinyur produk ing OpenAI, sanajan ora ana dorongan terpusat kanggo ninggalake Postgres lan Azure Cosmos DB swalayan.

Nalika kabutuhan produk berkembang, pangembang produk uga gampang nambah dhukungan ing pustaka bebarengan kanggo fitur kayata caching sisi klien, kompresi, utawa enkripsi.

Ing tengah taun 2025, Habitat wis tekan wates minangka implementasi sisi klien. Nalika lapisan Habitat saya rumit lan cacah layanan OpenAI tambah, owah-owahan protokol sing kompatibel karo versi lawas wis ora bisa ditindakake.

Ing salah siji kasus, kita kepengin nyuda cakupan dampak yen ana gangguan ing siji wilayah kanggo set data paling kritis, kanthi migrasi menyang sakumpulan akun Azure Cosmos DB sing kasebar miturut wilayah. Owah-owahan iki mbutuhake logika perutean tambahan ing klien sing dipateni ing balik feature flag, mesthekake disebarake menyang kabeh klien, banjur ngaktifake feature flag kasebut.

Koordinasi deployment ing puluhan layanan lan kerja bareng saben tim kanggo nyebarake mbutuhake pirang-pirang dina. Sadurunge ngaktifake, kita sadhar pengin nambah shadowing kanggo mesthekake logika sharding wis bener. Panyebarane mbutuhake rong dina maneh. Ndandani bug saka bab sing banjur kita sadhari kliru? Rong dina maneh. Pungkasane, nalika wis siyap ngaktifake flag, salah siji tim mbalekake layanane amarga alasan liya menyang klien lawas sing isih duwe bug, saengga nyebabake gangguan sing wis kita upayakake banget supaya ora kedadeyan.

Owah-owahan pustaka klien mbutuhake koordinasi rumit ing puluhan layanan, sawijining proses sing saya ringkih, ora efisien, lan gampang ngalami kegagalan operasional. Kanggo nyuda panyebaran operasional ing deployment sabanjure, kita mutusake misahake Habitat dadi layanan dhewe.

Kanthi misahake logika panyimpenan dadi layanan mandiri, kita nggawe siji titik kontrol kanggo deployment, observabilitas, lan pangembangan platform. Tinimbang ngatur nganyari sing kapisah-pisah, kita bisa ngetrapake perbaikan kanthi terpusat, saengga saben produk OpenAI langsung entuk manfaat.

Layanan terpusat uga menehi siji titik kendali kanggo nyedhiyakake primitif keamanan lan privasi data sing paling kuwat. Ing layanan Habitat, kita bisa ngetrapake kabijakan kontrol akses kanthi terpusat, nyathet audit, lan matesi akses menyang sumber daya panyimpenan dhasar kayata Azure Cosmos DB. Habitat nduweni peran kritis kanggo nglindhungi data pangguna lan nyegah akses tanpa wewenang saka pihak eksternal, internal, lan agen.

Kita ngerti yen mbutuhake layanan, nanging durung kepengin migrasi saka Python, sanajan Python nambah overhead nalika dadi layanan. Panggunaan Python kanggo layanan kanthi kapasitas pangolahan dhuwur nambah latensi jaringan lan biaya penskalaan CPU lan memori kanthi gedhe tinimbang eksekusi pustaka lokal. Kajaba iku, kita ngerti yen inefisiensi Python ora bisa ditampa ing skala 100x, mula pungkasane mesthi kudu ditulis maneh.

Nanging, iki kita anggep minangka panambahan utang teknis kanthi strategis. Tujuan utama kita wektu iku dudu ngoptimalake biaya utawa sumber daya, nanging mbukak alangan kanggo pangembang produk lan nggayuh stabilitas platform. Kanthi nampa kompromi kinerja layanan Python kanggo wektu cendhak, kita bisa ngutamakake tantangan sing luwih mendesak, netepake API inti, lan mbangun infrastruktur sing kukuh.

Kita uga nggawe taruhan sing wis dietung: kemajuan cepet model pangodean kita dhewe bakal nggampangake jalur teknis ing tembe. Kita yakin yen nalika migrasi lengkap saka Python dibutuhake, Codex lan GPT bakal ndadekake migrasi kasebut bisa ditindakake. Pungkasane, taruhan kasebut kabukten bener.

Nglakokake Habitat minangka layanan Python ora optimal saka sisi kinerja, nanging pilihan iki perlu. Python ndadekake kita bisa maju kanthi cepet, nanging dudu ateges kita bisa sembrana lan nampa latensi sing luwih ala kanthi nyata. Nalika rata-rata panjaluk pangguna nyebabake atusan panggilan basis data, panggilan basis data sing paling alon iku sing dirasakake pangguna. Kita nemokake yen tantangan utama nglakokake layanan Python ing skala iki yaiku ngatur latensi buntut kasebut.

Asyncio mbantu Python nglakokake beban kerja sing gumantung marang I/O kanthi bebarengan, nanging ora bisa ngatasi GIL Python utawa nyedhiyakake paralelisme CPU. Saliyane dadi proksi panjaluk sing abot I/O, Habitat nangani akeh tanggung jawab lan tugas latar mburi sing abot CPU: perutean, kompresi, enkripsi, checksum, pamriksa kesehatan layanan hilir, shadowing panjaluk, lan hedging.

Amarga akeh beban kerja lan tugas latar mburi sing abot CPU ing layanan, tundha panjadwalan asyncio bisa gampang ndominasi latensi buntut panjaluk. Sadurunge nyetel peluncuran awal layanan, ing trace panjaluk kanthi latensi p99 utawa luwih dhuwur, kita weruh yen sanajan panyimpenan hilir nanggapi kanthi cepet, panjaluk kerep mandheg nalika ngenteni coroutine sing tanggung jawab dijadwalake maneh kanggo ngurai respons.

Kanggo layanan Python ing OpenAI, saliyane ngukur metrik utilisasi lan saturasi standar kanggo memori, CPU, jaringan, lan disk, kita nemokake yen ngawasi loop asyncio lan tingkat kesibukane, banjur nyetel adhedhasar iku, pancen wigati.

Kanthi njadwalake tugas latar mburi kanthi periodik lan nyathet selisih antarane wektu eksekusi sing dikarepake lan sing nyata, kita bisa ngukur tundha panjadwalan event loop kanthi empiris lan wektu nyata. Nalika utilisasi dhuwur lan ana akeh tugas abot, panjaluk bebarengan saben proses sing cacahe ora akeh wae wis cukup kanggo nyebabake jitter panjadwalan gedhe, nganti atusan milidetik lan ing sawetara kasus ekstrem nganti pirang-pirang detik.

Mula, saben proses mung kita gunakake kanggo nglayani sawetara panjaluk bebarengan, dene cacah proses worker Python ditambah kanthi gedhe.

Nalika peluncuran awal layanan, liwat profiling CPU layanan langsung kita nemokake salah siji panyebab utama tundha asyncio sing dhuwur—lan latensi buntut sing dhuwur: panguraian JSON periodik kanggo konfigurasi feature flag liwat Statsig, piranti kanggo ngatur feature flag, nglakokake tes A/B, lan liya-liyane.

Kanthi gawan, Statsig dikonfigurasi kanggo njupuk konfigurasi anyar saben menit tanpa jitter, lan konfigurasi kasebut ngemot saben aturan produksi saka kabeh layanan. Ing bagean liya, ana keputusan arsitektur kanggo nglakokake nganti 8 proses Python saben pod supaya panggunaan CPU luwih dhuwur lan latensi luwih cendhek. Gabungan kasebut ateges saben menit, saben pod ngalami wektu nalika kabeh worker mandheg ngolah panjaluk sing lagi lumaku lan malah nggunakake siklus CPU kanggo ngurai file konfigurasi gedhe banget.

Sawise profiling CPU mbantu nemokake panyebab utama, solusine prasaja: pasang konfigurasi sing luwih cilik lan tertarget, dawaake interval panyegaran, lan tambahake jitter ing tugas latar mburi kaya iki.

Kanggo njaga tundha asyncio tetep cendhek, pangimbangan beban panjaluk sing apik ing antarane proses server uga wigati; tanpa panyetelan, pooling sambungan bisa malah ngalangi tujuan iki.

Kanthi pooling sambungan sisi klien, siji proses klien sing nggawe akeh panjaluk bebarengan bisa wae mung nggawe sawetara sambungan server, mula kabeh bebane mung dikirim menyang sawetara proses. Sadurunge nyetel pangimbangan beban, utilisasi layanan kita beda-beda banget, lan sawetara proses buntut nglayani panjaluk bebarengan 5–10x luwih akeh tinimbang rata-rata.

Kita nemokake iki tanpa sengaja nalika sawetara proses tetep mudhun kinerjane suwé sawise lalu lintas sing melonjak, sanajan klien sing ngakehi beban ing bagean layanan wis dipateni. Malah, proses kasebut saya rusak tanpa kendhali lan nampa panjaluk luwih akeh nganti kita miwiti maneh. Sawise pod kakehan beban, ana prilaku sing nahan lalu lintas luwih akeh ing pod kasebut. Iki kalebu jinis kegagalan sing wis dikenal sawetara kanca saka pakaryan sadurunge: kegagalan metastabil⁠(mbukak ing jendhela anyar).

Kita curiga pool sambungan minangka panyebabe lan nguji kanthi matesi durasi maksimal panggunaan maneh sambungan. Iki pancen matesi penurunan kinerja lan ngonfirmasi arah investigasi. Investigasi sabanjure nemokake yen TCPConnector aiohttp Python kanthi gawan nggunakake maneh sambungan kanthi LIFO: sambungan sing paling mentas bali dipilih kanggo panjaluk sabanjure. Biasane iki pilihan gawan sing lumrah: nggunakake sambungan anyar maneh ngidini sambungan tambahan sing digawe kanggo nangani lonjakan lalu lintas tekan idle timeout, saengga overhead njaga sambungan tambahan suda. Ing kasus iki, pilihan kasebut nyebabake kegagalan metastabil. Nalika panjaluk melonjak, panjaluk menyang server alon sing kakehan beban mbalekake sambungan menyang pool luwih pungkasan, mula luwih kerep dipilih panjaluk sabanjure. Akibate, lalu lintas saya musat ing pod sing wis kewalahan. Nambal pool sambungan supaya nggunakake maneh kanthi FIFO medhot loop umpan balik iki lan uga nyuda variasi panjaluk nalika kondisi ajeg.

Saiki, kita utamane ngandelake Istio lan Envoy kanggo pooling sambungan lan strategi pangimbangan sing luwih ngerti beban server ing saindhenging infrastruktur OpenAI, saengga masalah iki bisa dicegah sakabehe.

Salah siji efek samping panyetelan kanggo tundha asyncio sing cendhek lan akeh banget proses Python yaiku dependensi hilir gampang banget kewalahan amarga cacah sambungan sing gedhe banget—dikenal minangka “thundering herd”.

Deployment saben dina sing lumrah—yen ora disetel supaya alon—bisa nyebabake owah-owahan beban CPU sing gedhe amarga siklus sambungan. Utawa, kebocoran sambungan bisa mateni jaringan amarga gateway NAT kebak. Masalah iki uga lumrah ing layanan liya, nanging ambang pemicune mudhun banget amarga cacahe proses luwih akeh sak tingkat magnitudo. Iki kerep nggawe sumber daya jaringan kebak, sanajan adhedhasar kapasitas pangolahan wae klien ora ngira sumber daya kasebut kudu nangani beban kaya mangkono nalika kondisi ajeg.

Kita uga ngandelake Envoy kanggo nggedhekake fan-in sambungan. Envoy digunakake kanggo nganyarke sambungan HTTP/1 Python dadi HTTP/2 supaya bisa nggunakake multiplexing, banjur nglumpukake sambungan kasebut lan ndawakake umure. Envoy uga menehi papan terpusat kanggo ngetrapake watesan laju lan circuit breaker, sing bakal kurang efektif yen diterapake ing saben proses Python mandiri.

Salah siji sebab Python bisa kita skalakake nganti iki yaiku API Habitat sing diwatesi, saengga biaya panjaluk tetep bisa dipredhiksi. Tinimbang ngidini klien nggawe kueri SQL sawenang-wenang sing bisa nyebabake pemindaian tabel gedhe utawa join ing akeh tabel, Habitat nyedhiyakake API NoSQL sing prasaja. Ora anane API sing canggih minangka kompromi sing disengaja ing rancangan Habitat.

Kita ngupaya ngoptimalake panjaluk sing prasaja, bisa dipredhiksi, lan mbutuhake beban kerja ajeg. Miturut pengalaman kita, sistem kaya iki luwih gampang diskalakake lan angel digunakake kanthi kliru utawa disalahgunakake. Panjaluk kanthi fanout sing ora bisa dipredhiksi mbebayani tumrap operasi: iki ngruwetake isolasi lan pangimbangan beban, sarta nyebabake lonjakan latensi sing angel diskalakake kanggo layanan lan kliene.

Sadurunge pindhah menyang Habitat lan Azure Cosmos DB, umume data online OpenAI disimpen ing Postgres. Nalika iku, kabeh owah-owahan kueri lan skema gampang ditinjau kanggo mesthekake tumindake apik lan ngoperasikake data sing wis diindeks sadurunge dikirim menyang produksi. Nalika tim lan produk saya gedhe, iki cepet dadi ora bisa dikelola lan kerep nyebabake gangguan nalika siji kueri anyar sing larang ing jalur sibuk ngrusak basis data.

Masalahe yaiku ora imbang ing biaya: kueri SQL sing larang lan angel dilakokake murah lan gampang ditulis. Ing Habitat, iki kita cegah lan kueri larang digawe cetha banget ing sisi klien. Ora ana kueri tanpa wates sing bisa ngakehi beban Habitat. Join rumit lan penelusuran graf mbutuhake tim produk nindakake sawatara tugas abot, saengga sakabehe luwih optimal kanggo rancangan sing efisien.

Habitat nyedhiyakake API NoSQL sing dimodelake adhedhasar jinis objek lan edge sing ditetepake klien, kanthi inspirasi saka TAO⁠(mbukak ing jendhela anyar). Klien netepake objek lan edge luwih dhisik, uga sesambungane, nanging ora netepake isi saben jinis. Sesambungan sing diasilake mirip graf, nanging Habitat dhewe ora ndhukung kueri penelusuran graf umum, kajaba kueri edge langsung saka objek tartamtu.

Graf iki kita partisi supaya saben objek lan edge sing gegandhengan dilebokake bebarengan ing partisi tingkat panyimpenan, nanging ora ana upaya khusus ing tingkat basis data kanggo nglumpukake objek karo objek remot sing dituju edge. Asile, model gampang dipartisi kanggo skalabilitas horizontal, nanging penelusuran graf ora efisien amarga saben lompatan antarobjek bisa mbutuhake njupuk data saka rong akun Azure Cosmos DB sing beda lan disimpen ing wilayah beda.

Kanggo klien kanthi kabutuhan kueri sing luwih rumit, kita nyedhiyakake tampilan sekunder offline saka Habitat liwat Rockset. Kita nggunakake change data capture (CDC) kanggo streaming owah-owahan saka panyimpenan online menyang instance Rockset sing diisolasi kanthi meh wektu nyata. Saben tim klien tanggung jawab nyekalakake instance Rockset dhewe kanggo kabutuhan kueri rumit.

Panyedhiya Rockset iki nambah alangan kanggo klien, nanging saiki kita nganggep iki kompromi sing bener: kueri prasaja dadi gawan, kanthi jalur alternatif kanggo sing mbutuhake kueri rumit. Rancangan iki ngisolasi panyimpenan online kita saka beban kerja analitik lan telusuran sing abot maca.

Nundha panulisan ulang Python setaun ngidini kita fokus marang tantangan sing luwih mendesak lan nduweni dampak nalika tuwuh kanthi cepet banget. Nalika platform saya mateng lan pertumbuhan terus luwih cepet, sarta dadi layanan nomer loro paling gedhe adhedhasar cacah inti ing OpenAI—lan nomer papat kanggo jejak Envoy—pungkasane wis wayahe ninggalake Python. Ing puncake, Python mbantu kita nglayani luwih saka 20 yuta panjaluk saben detik.

Ing triwulan II 2026, kanthi mung 2 insinyur, Codex, lan GPT‑5.5, kita bisa nulis maneh kabeh layanan nganggo Rust. Layanan Rust anyar iki saiki nangani 95% panjaluk produksi; Python bakal dipungkasi sakabehe sajrone sawetara minggu maneh. Data kita nuduhake yen layanan Rust 6x luwih efisien nggunakake CPU lan 15x luwih efisien nggunakake memori tinimbang versi Python, kanthi latensi rata-rata lan buntut sing luwih cendhek banget. Kita arep nuduhake luwih akeh pamulangan ing blog sabanjure.

Layanan Python—lan saiki Rust—mung salah siji aspek Habitat. Ing bagean II seri iki sing nerangake cara kita nyekalakake panyimpenan online kanthi cepet kanggo nglayani luwih saka 1 milyar pangguna ChatGPT, kita bakal ngrembug lapisan panyimpenan lan carane Habitat nglayani luwih saka 500 petabyte lan 70 yuta panjaluk saben detik.

Yen sampeyan kepengin nggarap sistem OLTP kanthi skala tercanggih lan kasengsem marang rekayasa kaya iki, delengen lowongan ing tim kita iki⁠.