Memperluas PostgreSQL untuk melayani 800 juta pengguna ChatGPT

• OpenAI memperluas infrastruktur PostgreSQL dalam skala besar untuk menangani lonjakan trafik ChatGPT dan API, memproses ratusan juta QPS dengan satu Azure PostgreSQL Flexible Server dan sekitar 50 read replica
• Sambil mempertahankan arsitektur yang dioptimalkan untuk beban kerja berorientasi baca, sebagian beban kerja dimigrasikan ke Azure Cosmos DB untuk mengurangi beban tulis
• Berbagai optimasi seperti pooling koneksi PgBouncer, cache locking, rate limiting, dan isolasi beban kerja meningkatkan stabilitas dan latensi
• Untuk mengatasi batasan arsitektur single primary, konfigurasi high availability (HA), hot standby, dan pengujian cascading replication dijalankan secara paralel
• Dengan pendekatan ini, OpenAI mencapai availability 99.999% dan latensi p99 di kisaran puluhan milidetik, sambil membuka jalan untuk ekspansi ke PostgreSQL yang di-shard atau sistem terdistribusi di masa depan

---

Gambaran umum penskalaan PostgreSQL

• PostgreSQL adalah sistem data inti untuk ChatGPT dan OpenAI API, dengan beban meningkat lebih dari 10x selama setahun terakhir
  • Satu instance primary tunggal dan sekitar 50 read replica yang tersebar secara global menangani permintaan dari 800 juta pengguna
• Sambil mempertahankan struktur yang berfokus pada baca, sebagian beban kerja dipindahkan ke Azure Cosmos DB untuk mengurangi beban tulis
• Penambahan tabel baru dilarang, dan beban kerja baru pada dasarnya ditempatkan pada sistem yang sudah di-shard

Tantangan arsitektur single primary dan responsnya

• Arsitektur dengan penulis tunggal memiliki batas skalabilitas tulis dan masalah single point of failure (SPOF)
  • Trafik baca didistribusikan ke replica, sementara trafik tulis dipindahkan ke Cosmos DB untuk beban kerja yang bisa di-shard
  • Konfigurasi high availability dengan hot standby mendukung promosi cepat saat terjadi gangguan (failover)
• Saat beban baca melonjak tajam, terjadi masalah saturasi CPU akibat ledakan cache miss
  • Mekanisme cache locking diterapkan untuk mencegah kueri duplikat pada key yang sama

Optimasi kueri dan sumber daya

• Kueri multi-join yang kompleks menggunakan CPU secara berlebihan dan menyebabkan latensi layanan
  • SQL tidak efisien yang dihasilkan ORM ditinjau ulang, dan logika join yang kompleks dipindahkan ke lapisan aplikasi
  • Pengaturan idle_in_transaction_session_timeout digunakan untuk mencegah kueri menganggur dalam waktu lama
• Untuk mengatasi masalah “noisy neighbor”, trafik dipisahkan ke instance berdasarkan prioritas
  • Isolasi diterapkan agar permintaan prioritas rendah tidak memengaruhi layanan prioritas tinggi

Manajemen koneksi dan kontrol beban

• Untuk mengatasi batas 5.000 koneksi pada Azure PostgreSQL, PgBouncer diperkenalkan sebagai lapisan proxy
  • Dengan penggunaan ulang koneksi, waktu koneksi rata-rata dipersingkat dari 50ms → 5ms
  • Proxy, klien, dan replica ditempatkan di region yang sama untuk mengurangi latensi jaringan antarwilayah
• Rate limiting diterapkan di level aplikasi, proxy, dan kueri untuk mencegah lonjakan trafik mendadak
  • Lapisan ORM juga ditingkatkan agar dapat memblokir digest kueri tertentu

Replikasi dan pengelolaan perubahan skema

• Karena primary harus melakukan streaming WAL log ke semua replica, beban jaringan meningkat seiring bertambahnya jumlah replica
  • Cascading replication sedang diuji bersama tim Azure
  • Replica perantara meneruskan WAL ke replica di bawahnya, membuka kemungkinan ekspansi ke lebih dari 100 replica
• Perubahan skema yang memicu full table rewrite dilarang
  • Hanya perubahan ringan yang diizinkan dalam batas timeout 5 detik, dan pembuatan atau penghapusan indeks dapat dilakukan secara bersamaan
  • Pembatasan laju yang ketat juga diterapkan saat backfill

Hasil dan rencana ke depan

• PostgreSQL menangani ratusan juta QPS, dengan latensi puluhan milidetik (p99) dan availability 99.999%
  • Dalam 12 bulan terakhir, hanya ada satu insiden SEV-0, yang terjadi saat peluncuran ChatGPT ImageGen
• Beban kerja yang masih berpusat pada tulis juga sedang dipindahkan secara bertahap ke Cosmos DB
• Setelah cascading replication selesai, skalabilitas dan stabilitas replica akan diperkuat
• Ke depan, kemungkinan penerapan PostgreSQL yang di-shard atau sistem terdistribusi alternatif sedang ditinjau

[GN⁺]

Komentar Hacker News

• Di PostgreSQL, kueri idle yang berjalan lama sering menimbulkan masalah
  Di codebase perusahaan kami, ada banyak pola “connect → mulai transaction → kerja → commit jika sukses”
  Pendekatan ini membuat slot koneksi tetap terpakai terus meski DB sebenarnya tidak sedang digunakan, sehingga pada akhirnya kami harus menaikkan jumlah koneksi Postgres hingga ribuan
  Karena itu, kami menambahkan pemeriksaan saat compile time di kode Rust, sehingga jika .await dipanggil saat masih memegang koneksi di dalam fungsi async, compiler langsung memberi peringatan
  Lebih dari 100 titik diperbaiki, dan hasilnya sekarang uji beban tidak lagi melambat meski dijalankan dengan pool 32 koneksi alih-alih 10.000 koneksi
  Menurunkan idle timeout memang bisa jadi salah satu cara, tetapi pemeriksaan statis adalah solusi yang jauh lebih pasti

  • Ada usulan bahwa akan lebih baik jika urutannya diubah menjadi “kerjakan dulu → ambil dari connection pool saat berhasil lalu mulai transaction → kembalikan setelah commit”
  • Ada pertanyaan apakah pemeriksaan statis itu berupa aturan lint, atau implementasi yang memanfaatkan type system

• Tulisan ini terasa terlalu dangkal dan hanya mengulang kata kunci seperti “kami melakukan sharding!”
  Hampir tidak ada detail, dan terasa seperti kalimat untuk SEO

  • Bahkan terlihat seperti iklan untuk partner infrastruktur
  • Penjelasan tentang caching, connection pooling, optimasi join, dan lain-lain juga terasa terlalu umum

• Inti tulisannya bisa diringkas sebagai “single writer tidak bisa diskalakan, jadi penulisan dikurangi dan pembacaan dipisahkan”
  Hampir tidak ada hal baru, hanya menyebut pendekatan umum seperti optimasi kueri, sharding, dan read replica

• Salah satu alasan saya menyukai Postgres adalah karena, hanya dengan menambah CPU dan disk, sistem ini bisa bertahan sampai skala yang cukup besar
  Saat sudah sampai titik itu, Anda juga biasanya punya cukup dana untuk mempekerjakan ahli sharding

  • Sebenarnya PostgreSQL sudah mendukung sharding dasar lewat FDW dan partitioning
    Jadi pernyataan bahwa “kalau mau sharding harus meninggalkan Postgres” terdengar agak aneh
  • Namun ada juga yang meragukan pernyataan “akan punya cukup dana untuk mempekerjakan ahli”
    Misalnya, ada berita bahwa OpenAI masih mengalami kerugian sangat besar dan bahkan belum jelas apakah bisa bertahan sampai 2027

• Soal perubahan skema dan timeout, bukan hanya mengatur timeout saja
  Akan jauh lebih efisien jika saat rollout skema juga menjalankan skrip yang otomatis menghentikan transaction yang bentrok
  Akan bagus jika Postgres menyediakan fitur seperti ini secara bawaan — karena daripada menunggu akibat heavy lock, lebih baik membatalkan sebagian transaction

  • Namun ada juga sanggahan bahwa Postgres sudah mendukung perubahan skema berbasis transaction, jadi belum tentu perlu mematikan pekerjaan yang sedang berjalan

• Ini menarik karena merupakan tulisan pertama di blog OpenAI Engineering
  Saya ingin melihat lebih banyak contoh seperti ini ke depannya

  • Ada juga tanggapan bercanda bahwa kenyataannya mereka mungkin bertahan dengan downtime yang sering dan perbaikan darurat jam 2 pagi

• Saya penasaran dengan konfigurasi replikasinya
  Disebutkan bahwa meski ada 50 read replica, hampir tidak ada replication lag,
  padahal dalam praktiknya kemungkinan besar beberapa replica akan tertinggal saat terjadi lonjakan CPU atau memori
  Dalam situasi seperti itu, primary juga bisa melambat karena menunggu pengiriman WAL

  • Namun ada juga pendapat bahwa primary tidak akan melambat karena menunggu TCP ACK, dan yang hanya bertambah adalah jumlah penyimpanan segmen WAL

• Ada bagian yang menyebut bahwa “jika fitur baru memerlukan tabel tambahan, maka itu ditempatkan bukan di PostgreSQL melainkan di Azure CosmosDB”
  Artinya, mereka tampak mempertahankan sistem lama dan hanya memindahkan fitur baru ke DB lain

  • Namun CosmosDB sangat mahal, jadi sulit dipakai kecuali oleh perusahaan dengan dana besar seperti OpenAI

• Disebutkan bahwa mereka “memperbesar ukuran instance”, dan saya penasaran sejauh apa skalanya
  Saya ingin tahu CPU dan RAM apa yang digunakan, apakah instance-nya sama seperti milik pengguna biasa, atau justru hardware kustom

  • Cloud utama menyediakan SKU yang mengalokasikan satu server dua soket penuh ke satu VM
    Contoh: Azure Standard_E192ibds_v6 (96 core, RAM 1,8TB, SSD 10TB, 3M IOPS)
    Yang lebih besar lagi, untuk SAP HANA ada model seperti Standard_M896ixds_24_v3 yang menawarkan 896 core, memori 32TB, dan jaringan 185Gbps
    Ini harganya sekitar 175 ribu dolar per bulan, tetapi OpenAI mungkin mendapat diskon besar
    Secara pribadi, saya lebih suka memakai VM HX176rs untuk server DB
    Berkat cache HBM, throughput memori jauh lebih tinggi, dan performanya jauh lebih baik dibanding VM biasa di kisaran harga yang sama

• Menggunakan Azure PostgreSQL dan CosmosDB sekaligus pasti sangat mahal
  Meski begitu, tulisan ini termasuk salah satu contoh paling realistis tentang “kasus nyata menskalakan PostgreSQL”
  Pendekatannya terasa relevan karena dijalankan di lingkungan cloud standar, tanpa modifikasi kernel atau mengutak-atik source code