OpenAI: Melampaui Batas Skalabilitas PostgreSQL

 (pixelstech.net)
35 poin oleh GN⁺ 2025-05-24 | 2 komentar | Bagikan ke WhatsApp
  • OpenAI membagikan di PGConf.dev 2025 bagaimana mereka menggunakan PostgreSQL tanpa sharding sambil tetap menangani trafik ratusan juta pengguna secara efektif
  • Untuk mengatasi masalah bottleneck penulisan, mereka menerapkan berbagai pendekatan seperti distribusi penulisan, optimasi kueri, dan pengelolaan skema
  • Sebagai isu utama, mereka menyebut keterbatasan struktural dan tantangan operasional PostgreSQL seperti pembengkakan tabel/indeks akibat desain MVCC dan lag replikasi karena WAL
  • Strategi optimasi kueri seperti distribusi beban baca, pembatasan transaksi panjang, dan meminimalkan ORM menjadi kunci
  • OpenAI mencapai 1 juta QPS melalui lebih dari 40 replika yang tersebar secara geografis, sekaligus menjamin ketersediaan tinggi bahkan saat terjadi gangguan

Kasus Skalabilitas PostgreSQL Skala Besar di OpenAI

Latar belakang

  • Banyak layanan inti OpenAI bergantung pada PostgreSQL
  • Jika terjadi gangguan database, seluruh layanan terdampak secara langsung
  • Di masa lalu, layanan utama termasuk ChatGPT pernah mengalami insiden penghentian layanan akibat masalah PostgreSQL
  • OpenAI mengoperasikan database terkelola Azure dengan arsitektur Primary-Replica (satu Primary + lebih dari 40 Replica)
  • Dalam lingkungan yang melayani 500 juta pengguna aktif bulanan, skalabilitas menjadi faktor kunci bagi keberhasilan bisnis

Tantangan utama

  • Trafik baca dapat didistribusikan ke banyak Replica, tetapi permintaan tulis terpusat pada satu Primary sehingga menimbulkan bottleneck
  • Poin peningkatan utama
    • Mendistribusikan semua permintaan tulis yang bisa di-offload
    • Meminimalkan koneksi tambahan ke DB Primary dari layanan baru
  • Dalam struktur MVCC (multi-version concurrency control), terdapat kelemahan seperti pembengkakan tabel/indeks, tuning garbage collection yang kompleks, dan pemeriksaan visibilitas indeks
  • Saat jumlah Replica meningkat, trafik WAL (Write-Ahead Logging) juga melonjak tajam, sehingga bandwidth jaringan menjadi bottleneck lain

Langkah penanganan

Distribusi beban pada database Primary

  • Prediksi dan mitigasi beban tulis:
    • Meng-offload semua penulisan yang memungkinkan
    • Mencegah penulisan level aplikasi yang tidak perlu
    • Menerapkan Lazy Write, menyesuaikan siklus backfill data
  • Beban baca sedapat mungkin didistribusikan ke Replica; jika harus diproses di Primary, efisiensi tinggi menjadi keharusan

Optimasi kueri

  • Transaksi jangka panjang menahan sumber daya sistem untuk waktu lama dan menyebabkan keterlambatan garbage collection
  • Menerapkan Timeout per sesi/kueri/klien dan membatasi sesi Idle in transaction
  • Disebutkan bahwa penggunaan ORM dapat meningkatkan inefisiensi, sehingga disarankan digunakan dengan hati-hati
  • Dilakukan optimasi pada kueri multi-join yang kompleks (misalnya join 12 tabel)

Menangani titik kegagalan tunggal (SPOF)

  • Jika Primary gagal, penulisan tidak dapat dilakukan; jika sebagian Replica gagal, kontinuitas baca tetap terjaga
  • Permintaan penting (prioritas tinggi) diproses di Replica khusus untuk meminimalkan interferensi dari permintaan prioritas rendah

Pengelolaan skema

  • Pembuatan tabel baru dan pengenalan workload baru dibatasi pada klaster
  • Penambahan/penghapusan kolom hanya diizinkan untuk operasi ringan dalam batas 5 detik; operasi yang memerlukan penulisan ulang seluruh tabel tidak diperbolehkan
  • Pembuatan/penghapusan indeks hanya diizinkan dengan opsi CONCURRENTLY
  • Terjadi masalah di mana kueri panjang yang memakan waktu lebih dari 1 detik terus memblokir perubahan skema, sehingga optimasi/offload kueri semacam itu diperlukan di level aplikasi

Hasil operasional

  • Seluruh klaster memproses 1 juta QPS (baca+tulis) untuk mendukung layanan utama OpenAI
  • Tidak ada peningkatan lag replikasi meskipun menambah sekitar 40 Replica
  • Read-only Replica ditempatkan di berbagai Region untuk menjaga latensi rendah
  • Dalam 9 bulan terakhir, hanya terjadi 1 insiden SEV0 terkait PostgreSQL
  • Kapasitas telah diamankan untuk memenuhi ruang pertumbuhan di masa mendatang

Kasus gangguan

  • Kegagalan cache yang menyebabkan cascading effect
  • Bug ketika penggunaan CPU tinggi membuat proses WALSender berhenti mengirim WAL dan masuk ke kondisi loop → menyebabkan lag replikasi

Usulan peningkatan fitur untuk PostgreSQL

  1. Manajemen indeks: usulan fitur Disable untuk menonaktifkan indeks yang tidak diperlukan secara aman (untuk meminimalkan risiko sebelum penghapusan)
  2. Observabilitas: permintaan penyediaan metrik berbasis histogram/persentil latensi seperti p95, p99
  3. Riwayat perubahan skema: kebutuhan fitur penyimpanan riwayat perubahan skema seperti DDL
  4. Kejelasan makna monitoring view: pertanyaan tentang penyebab dan penanganan fenomena sesi tertentu yang lama berada dalam status ClientRead
  5. Optimasi parameter default: nilai default PostgreSQL dinilai terlalu konservatif; diminta default yang lebih baik atau heuristik yang lebih tepat

Komentar Lao Feng

  • Strategi skalabilitas OpenAI di lingkungan ekstrem seperti ini bernilai sebagai kasus penggunaan nyata bagi pengembang inti PostgreSQL
  • Layanan berskala besar lain seperti Tantan di Tiongkok juga memiliki pengalaman serupa (33 Replica, 400 ribu QPS, penerapan sharding di sisi aplikasi)
  • Dalam lingkungan HW berperforma tinggi saat ini, skalabilitas agresif dengan satu klaster PostgreSQL seperti OpenAI juga realistis, yang menunjukkan bahwa distributed DB tidak selalu diperlukan
  • OpenAI menggunakan Azure managed PostgreSQL, lebih dari 40 Replica, deployment lintas region, serta Kubernetes + PgBouncer
  • Meski mendapat dukungan intensif dari tim Azure PostgreSQL, kemampuan operasional aplikasi/DBA dan observabilitas tetap esensial
  • Disebutkan pula penggunaan Datadog untuk monitoring, beserta beban performa dan biaya
  • Know-how operasional, pengalaman kegagalan, dan aset DBA merupakan inti kualitas layanan

Tanya Jawab Lao Feng

Fitur penonaktifan indeks

  • Secara internal PostgreSQL memungkinkan penonaktifan indeks melalui field indisvalid (namun memerlukan hak akses superuser, dan dibatasi di lingkungan RDS)
  • Alternatif praktisnya adalah memeriksa penggunaan indeks melalui monitoring lalu menghapusnya secara aman

Ekspansi observabilitas: latensi P95/P99

  • Dukungan metrik persentil di pg_stat_statements sulit karena overhead memori, namun ada pendekatan alternatif seperti pg_stat_monitor/eBPF/monitoring latensi di lapisan aplikasi
  • Dalam lingkungan Azure managed PostgreSQL, beberapa opsi (akses server, eBPF, dll.) tidak didukung

Riwayat perubahan skema

  • Dapat memanfaatkan file log, pgaudit, CREATE EVENT TRIGGER, pg_ddl_historization, dll. (namun memerlukan hak akses superuser, dan dukungan Azure RDS terbatas)
  • Bentuk yang diinginkan adalah penyimpanan riwayat dalam bentuk system view/tabel yang dapat dikueri

Makna monitoring view

  • Kombinasi State=Active + WaitEvent=ClientRead berarti status menunggu input klien saat statement sedang dieksekusi; penyebabnya beragam dan tidak selalu bug
  • Efek samping dapat diminimalkan dengan membatasi durasi koneksi (misalnya pengaturan kedaluwarsa koneksi di lapisan jaringan seperti HAProxy, pengelolaan umur connection pool di sisi klien, dll.); belum pasti apakah Azure mendukung fitur tersebut

Parameter default

  • Nilai default PostgreSQL memang terlalu konservatif, tetapi bisa dilengkapi dengan heuristik spesifik per layanan atau tuning parameter otomatis (RDS, Pigsty, dll.)
  • Jika ke depan alat PostgreSQL dapat mendeteksi dan menerapkan spesifikasi HW secara otomatis, beban operasional di lapangan diperkirakan akan berkurang

Opsi operasi mandiri (self-hosting)

  • Masalah operasional yang nyata lebih banyak berasal dari keterbatasan managed Azure daripada PostgreSQL itu sendiri
  • Jika membangun klaster PostgreSQL berbasis NVMe SSD secara mandiri di lingkungan seperti IaaS (mis. dengan Pigsty), fleksibilitas fungsional dan operasional meningkat
  • Dengan memanfaatkan solusi seperti Pigsty, sebagian besar kebutuhan OpenAI dapat diatasi lebih dulu, sehingga ada ruang untuk mempertimbangkan adopsi sesuai skala dan kebutuhan

Bacaan terkait

2 komentar

 
GN⁺ 2025-05-24
Komentar Hacker News

  • Minggu lalu saya menghadiri PGConf, dan yang paling berkesan adalah bahwa presentasi ini merupakan salah satu sesi dengan jumlah peserta terbanyak, apalagi mengingat konferensinya cenderung introvert karena sebagian besar sesi berfokus pada pengembangan Postgres itu sendiri, sehingga studi kasus ini terasa segar. Rasanya penting untuk selalu mengingat bahwa banyak tim tidak benar-benar memahami secara mendalam bagaimana menskalakan bagian tertentu dari stack ketika produk mereka tumbuh sukses; presentasi ini dinilai sebagai kisah yang bagus tentang bagaimana tim kecil mengatasi masalah sambil belajar. Daripada reaksi yang disederhanakan seperti “kenapa tidak begini saja?”, presentasi ini dianggap sangat cocok untuk acara yang berpusat pada developer internal karena menampilkan kisah pengguna nyata yang dengan jelas menggambarkan proses pertumbuhan dan tingginya popularitas produk. Pesan inti presentasi ini adalah bahwa jika beban tulis tidak banyak, Postgres bisa diskalakan ke throughput baca yang sangat besar hanya dengan node baca-saja (read replicas) dan arsitektur master tunggal. Ada pendapat bahwa pesan inilah yang berlaku untuk sebagian besar aplikasi. Pada sesi tanya jawab, sebagian besar pertanyaan datang dari developer inti Postgres yang ingin mempelajari use case tersebut, hampir tanpa niat mengkritik, dan kesannya komunitas Postgres benar-benar ramah dan terbuka

    • Terkait pesan “jika beban tulis tidak banyak, throughput baca Postgres bisa sangat ditingkatkan dengan master tunggal dan replika baca-saja”, pengalaman saat melakukan wawancara desain sistem menunjukkan terlalu banyak kandidat yang mencoba memperkenalkan arsitektur terdistribusi besar atau sistem yang pada akhirnya mengorbankan konsistensi bahkan untuk sistem sederhana dengan sekitar 5 pembacaan per detik. Ada pendapat bahwa bahkan 10 juta pengguna sebenarnya bukan skala yang terlalu besar. Di saat seluruh industri terlalu terobsesi pada penskalaan horizontal, lebih banyak orang diharapkan menyadari bahwa perangkat keras nyata kini jauh lebih cepat dan lebih besar daripada yang dibayangkan. Sekarang bahkan ada dunia di mana server dengan RAM 32TB bisa disewa dari Amazon. Ditekankan juga bahwa jaminan ACID tetap sangat berharga bahkan pada skala besar

    • Terima kasih, itulah tepatnya pesan inti yang benar-benar ingin disampaikan presentasi ini (Bohan)

    • Ada yang bertanya apakah slide atau rekaman presentasi ini tersedia di suatu tempat

    • Ada opini bahwa utas ini terkesan agak terlalu keras terhadap tim tersebut. Dijelaskan bahwa pengguna HN yang sangat berpengalaman di bidang ini tertarik pada bagaimana layanan berskala besar seperti ChatGPT diskalakan secara arsitektural, dan bagaimana perusahaan dengan sumber daya yang nyaris tak terbatas merekrut orang. Ditafsirkan bahwa pesan presentasi seperti “kalau memakai ORM, kueri yang tidak efisien bisa mudah muncul, jadi hati-hati” justru menunjukkan bahwa tim tersebut belum terlalu berpengalaman dalam mengoperasikan infrastruktur sebesar ini

  • Dari sisi fleksibilitas, self-hosting postgres memang menarik, misalnya karena hak superuser atau penggunaan fitur lanjutan, tetapi mengoperasikannya sendiri memang terasa merepotkan. Ada harapan agar penyedia cloud secara standar mendukung fitur menonaktifkan indeks di query planner sebelum indeks benar-benar di-drop. Jika perusahaan besar, memilih self-hosting demi kustomisasi stack terasa cukup masuk akal

    • Dijelaskan bahwa di Postgres sudah ada berbagai cara untuk memanfaatkan atau menonaktifkan indeks tertentu, dan itu juga bisa digunakan di instance Postgres terkelola di cloud. Contohnya, mengubah pengaturan query planner per kueri (misalnya enable_indexscan=off), atau menambahkan operasi aritmetika sederhana di klausa where agar indeks sengaja tidak dipakai, serta ekstensi pg_hintplan (bisa memberi petunjuk indeks mana yang harus dipakai lewat komentar; referensi: https://pg-hint-plan.readthedocs.io/en/latest/hint_table.html#hints-for-scan-methods)

    • (Dengan menyebut bahwa dirinya bagian dari tim Azure Postgres) OpenAI tidak memakai self-host, melainkan menggunakan PostgreSQL terkelola dari Azure (Flexible Server)

    • Pembicara OpenAI (Bohan) sendiri menjelaskan langsung bahwa mereka tidak menggunakan lingkungan self-host, melainkan Azure Database for PostgreSQL. Ia meminta maaf karena walaupun berkali-kali menyebut “Azure Postgres” dalam presentasi, ia seharusnya menjelaskan lebih tegas bahwa itu adalah layanan yang dikelola Microsoft

    • Ada pendapat bahwa di MySQL atau MariaDB ada DDL untuk membuat indeks menjadi INVISIBLE atau IGNORED sehingga diabaikan oleh query planner, dan cukup mengejutkan bahwa Postgres tidak memiliki fitur serupa

    • Hanya mengutip kalimat asli “Keunggulan self-hosting postgres adalah fleksibilitas…”

  • Menanggapi permintaan akan fitur pencatatan riwayat event perubahan skema (penambahan/penghapusan kolom, dll.), dijelaskan bahwa hal itu sudah bisa diimplementasikan secara real-time dengan memanfaatkan EVENT TRIGGER, dan sebagai contoh bisa melihat implementasi di Aquameta (https://github.com/aquametalabs/aquameta)

    • Dijelaskan bahwa kami juga sedang membangun fitur pengelolaan riwayat perubahan DDL di lingkungan Postgres kami sendiri. Karena Postgres sendiri sangat kuat, ini bisa diimplementasikan dengan berbagai cara, tetapi pengelolaan riwayat dan log operasional untuk database besar atau penting juga merupakan kebutuhan yang sangat umum. Kebanyakan orang tidak menyadari pentingnya sebelum mengalaminya sendiri dengan cara yang menyakitkan. Dijelaskan bahwa bukan hanya perubahan DDL, tetapi juga saat kebijakan operasional penting diterapkan, seperti perubahan model harga atau kustomisasi SKU/harga, “kemampuan audit” wajib dipastikan. Jika benar-benar merancang model relasional, pada aplikasi nyata biasanya hanya sebagian tabel yang sering berubah, sedangkan mayoritas adalah tabel “statis” yang hampir tidak pernah berubah; ketika tabel-tabel ini berubah, mencatat riwayatnya dengan cermat sangat membantu untuk menafsirkan data lama atau melakukan rollback

    • Kami (Xata) menggunakan fungsi di pgroll (https://github.com/xataio/pgroll) dan pgstream (https://github.com/xataio/pgstream) yang mendeteksi perubahan DDL melalui EVENT TRIGGER untuk meninggalkan riwayat migrasi skema, atau memasukkan event perubahan skema ke dalam stream replikasi logis. Namun, ada informasi bahwa sebagian besar DBaaS berbasis Postgres membatasi EVENT TRIGGER karena hak superuser; RDS/Aurora dan Xata mendukungnya, dan Supabase juga sedang menyiapkan dukungan

    • Terima kasih sudah mengingat Aquameta, dan sedikit teaser bahwa fitur baru yang keren akan segera hadir

  • Ada pendapat bahwa hal-hal seperti pembuatan indeks konkuren pada skala besar, menghindari rewrite tabel, distribusi trafik, transaction timeout, dan replika baca, sebenarnya hampir wajib dan sudah seperti pengetahuan umum bahkan pada operasi yang jauh lebih kecil daripada OpenAI. Permintaan terhadap Postgres yang disebut di sini juga pada dasarnya adalah hal-hal yang sudah lama diminta banyak orang, dan meski judulnya “Next Level”, pandangannya justru lebih mirip upaya mati-matian mempertahankan master tunggal sambil tetap menskalakan [dalam kondisi workload baru yang dibatasi]. Dijelaskan bahwa poin intinya adalah mampu menahan beban baca besar dengan stabil, tetapi itu sendiri pada dasarnya adalah pola klasik replika baca dan distribusi horizontal. Cara menonaktifkan indeks dengan memanipulasi field internal (indisvalid) juga hanyalah trik yang secara resmi tidak disediakan, dan ada peringatan bahwa tweak katalog sistem seperti itu berbahaya. Pendapat bahwa cukup mengecek penggunaan indeks lewat monitoring view lalu menghapusnya juga bukan solusi sempurna; untuk lebih jelas menentukan indeks mana yang perlu atau tidak, rencana kueri juga perlu diperiksa agar hasilnya dapat dipercaya

    • TFA (artikel sumber) menyebut OpenAI memproses 1 juta kueri per detik di Azure, dan ini ditafsirkan cukup mengesankan dalam lingkungan cloud nyata, terutama jika memakai storage berbasis jaringan. Namun karena angka tersebut secara keseluruhan didistribusikan ke sekitar 40 replika baca, itu berarti sekitar 25 ribu QPS per instance, sehingga dianggap tidak terlalu mengejutkan. Soal perdebatan penggunaan indeks, dijelaskan bahwa jika statistik terbaru dan karakteristik DB dipahami dengan baik, maka untuk menentukan indeks mana yang tepat dipakai cukup memeriksa apakah kondisi/proyeksi kueri mengikuti left-most prefix indeks dengan baik

    • Tidak ada penjelasan sama sekali tentang mengapa OpenAI tidak melakukan sharding Postgres, dan itu dianggap membuat frustrasi. Bahkan sharding per pengguna saja sepertinya akan membuat masalah jauh lebih mudah diselesaikan, sehingga dipertanyakan mengapa mereka tetap bertahan pada master tunggal

  • Sepertinya mereka menggunakan replikasi fisik, dan saya sendiri sedang mempertimbangkan beralih ke replikasi logis demi penghematan biaya, terutama untuk mengurangi trafik keluar antar-region. Karena sejak Postgres 17 fitur replikasi logis native tampaknya berkembang pesat, saya penasaran apakah ini cukup layak dicoba di lingkungan nyata

  • Ada kritik bahwa untuk menangani beragam kueri, mereka kemungkinan juga memakai storage engine lain secara paralel—key-value, pencarian, vector search, cache, dan sebagainya—namun isi presentasi justru hanya berfokus pada Postgres. Ada dugaan bahwa secara internal mereka mungkin sebenarnya menjalankan berbagai strategi untuk mendistribusikan trafik dan membagi beban

  • Ada rasa penasaran apakah performa yang lebih baik bisa didapat bila hanya instance write yang dioperasikan sendiri langsung pada server khusus dengan SSD lokal cepat, sementara baca ditangani hanya lewat layanan terkelola

  • Ada seruan keras: “Lakukan saja DB sharding.” Menurut pandangan ini, cukup dengan sharding per pengguna/organisasi, masalah utama yang mereka hadapi sekarang akan terselesaikan dengan sederhana. Ada keluhan bahwa mencoba berbagai jalan memutar yang rumit berkali-kali justru terasa seperti memutar lebih jauh

    • Dalam presentasi, pesan intinya adalah bahwa bahkan tanpa sharding pun, arsitektur master tunggal saja bisa diskalakan ke throughput yang sangat besar; tentu saja sharding juga sudah dipertimbangkan, tetapi trade-off-nya tidak cocok dan arsitektur saat ini tetap bisa diskalakan

    • Jawaban langsung dari pembicara OpenAI (Bohan): workload mereka tidak mudah untuk di-shard, dan workload yang beban tulisnya tinggi sudah dipisahkan dari PostgreSQL dan ditangani lewat shard, sehingga yang tersisa hampir sepenuhnya read-only; karena itu memperkenalkan sharding untuk bagian ini membutuhkan usaha yang sangat besar. Saat ini mereka menilai Azure Database for PostgreSQL saja sudah cukup untuk memberikan skalabilitas yang dibutuhkan sekaligus ruang untuk menampung kebutuhan masa depan. Namun, mereka tidak sepenuhnya menutup kemungkinan sharding dalam jangka panjang, hanya saja itu bukan prioritas jangka pendek

    • Ada pendapat bahwa sharding tidak sesederhana yang dibayangkan. Alasan menggunakan DB yang kuat adalah karena bisa melakukan analisis dan kueri data yang kompleks; jika tujuannya hanya penyimpanan/distribusi sederhana, memakai beberapa mount NFS justru akan lebih mudah

    • Ada masukan yang lebih realistis bahwa menyuruh melakukan sharding secara sederhana pada database sebesar ini—misalnya 1 juta kueri per detik—bukan hal yang mudah. Walaupun unit organisasi tampak seperti kunci shard yang alami, pada skala sebesar ini tidak ada yang benar-benar sederhana

    • Respons yang sangat setuju dengan argumen di atas

  • Menanggapi komentar presentasi yang menyarankan berhati-hati memakai ORM, ada pandangan pribadi bahwa semua ORM—terutama ORM yang mendukung banyak DB—bermasalah. Menurut pandangan ini, ORM membuat orang hanya memikirkan pola data di tingkat kode aplikasi, dan pada akhirnya hampir tidak bisa memanfaatkan fitur-fitur kuat yang disediakan masing-masing DB. Ia sendiri sama sekali tidak memakai ORM dan justru aktif memanfaatkan kueri/fitur khusus Postgres; fokus pada kekuatan DB, alih-alih bahasa atau kenyamanan, dianggap jauh lebih menguntungkan. Kesimpulannya, menulis SQL yang baik secara langsung pada akhirnya membawa kebahagiaan bagi seluruh sistem

    • Saat dulu bermigrasi dari DB2 ke psql, ORM sangat membantu untuk meminimalkan downtime. Berkat ORM, pergantian DB bisa dilakukan secara transparan, sebagian besar logika hampir tidak perlu diubah, dan tidak semua developer terbiasa menulis kueri langsung; selain itu, bila kueri bercampur di dalam kode, refactoring maupun pemahaman kode bisa menjadi sangat sulit. Pada akhirnya SQL juga akan diabstraksikan menjadi pustaka

    • Setelah lama memakai Django ORM dan merasa itu perangkat lunak yang benar-benar hebat, akhir-akhir ini menggunakan sqlc memberi kesan bahwa mengubah kueri langsung menjadi kode Go justru merupakan titik kompromi ideal antara ORM dan SQL mentah

    • Ada pandangan bahwa Anda hanya belum pernah merasakan ORM yang benar-benar bagus, misalnya Entity Framework Core

  • Ada masukan ringan bahwa judul “Scaling PostgreSQL to the Next Level at OpenAI” tampaknya lebih sesuai dengan judul presentasi yang sebenarnya
 
ddogi 2025-05-25

Sepertinya produk komersial seperti Oracle RAC atau DB2 pureScale yang mendukung multi-write juga tidak dipertimbangkan, ya.