OpenAI: strategi penskalaan besar PostgreSQL untuk menopang 800 juta pengguna

Ringkasan:

• OpenAI menangani jutaan QPS dan 800 juta pengguna dengan satu Primary dan sekitar 50 Read Replica (Azure Flexible Server).
• Untuk mendistribusikan beban tulis, workload yang dapat di-shard dipindahkan ke Azure Cosmos DB, dan penulisan dioptimalkan di level aplikasi dengan menerapkan 'Lazy Write' dan teknik lainnya.
• Dengan mengadopsi PgBouncer, latensi koneksi dipangkas dari 50ms menjadi 5ms, dan mekanisme cache lock diimplementasikan untuk mencegah badai cache miss.
• Stabilitas dijaga lewat penghapusan query join yang kompleks, timeout perubahan skema yang ketat di bawah 5 detik, serta isolasi workload berdasarkan prioritas trafik.

Rangkuman detail:
1. Latar belakang dan kondisi arsitektur saat ini
Trafik PostgreSQL OpenAI meningkat lebih dari 10 kali dalam setahun terakhir dan kini menangani 800 juta pengguna serta jutaan QPS (query per second). Yang mengejutkan, skala ini dijalankan dengan struktur satu Primary dan sekitar 50 Read Replica yang tersebar secara global. Untuk mencegah retaknya desain awal, OpenAI melakukan optimasi besar-besaran baik di lapisan infrastruktur maupun aplikasi.

2. Penyelesaian bottleneck utama dan strategi optimasi

• Distribusi beban tulis:

  • Struktur single writer PostgreSQL memiliki batas dalam penskalaan, dan ada masalah amplifikasi tulis akibat MVCC (multiversion concurrency control).
  • Sebagai solusi, workload intensif tulis yang dapat di-partisi secara horizontal (sharding) dipindahkan ke sistem seperti Azure Cosmos DB.
  • Di PostgreSQL yang ada, pembuatan tabel baru dilarang, dan beban pada Primary diminimalkan melalui perbaikan bug aplikasi serta penerapan Lazy Write (menunda penulisan untuk meratakan lonjakan trafik).

• Optimasi query dan pengelolaan ORM:

  • Pernah ada kasus query yang melakukan join ke 12 tabel dan memicu insiden (SEV), sehingga join majemuk yang kompleks dihindari dan logikanya dipisahkan ke level aplikasi.
  • Query tidak efisien yang dihasilkan ORM terus ditinjau, dan dengan pengaturan idle_in_transaction_session_timeout, query idle dicegah agar tidak memblokir Autovacuum.

• Connection pooling (PgBouncer):

  • Untuk mencegah batas koneksi Azure PostgreSQL (5.000) dan lonjakan koneksi, PgBouncer diterapkan sebagai lapisan proxy.
  • Mode pooling transaction/statement digunakan untuk meningkatkan pemakaian ulang koneksi, dan waktu koneksi rata-rata dipangkas dari 50ms menjadi 5ms.

• Pencegahan cache miss (Cache Locking):

  • Untuk mencegah masalah Thundering Herd, yaitu ketika banyak request sekaligus menghantam DB saat cache kedaluwarsa, OpenAI memperkenalkan mekanisme cache lock (leasing).
  • Saat cache miss terjadi pada key tertentu, hanya satu request yang memperoleh hak akses (lock) ke DB untuk menyegarkan data, sementara request lain menunggu, sehingga beban DB dapat dibendung.

3. Stabilitas dan kebijakan operasional

• Mitigasi single point of failure (SPOF): Saat Primary gagal, request baca tetap dilayani melalui Replica sehingga tingkat keparahan gangguan diturunkan; Primary juga berjalan dalam mode high availability (HA) dengan Hot Standby untuk menjamin failover cepat.
• Isolasi workload: Untuk mencegah masalah Noisy Neighbor, trafik diarahkan ke instance terpisah berdasarkan tingkat kepentingan (Low/High Priority).
• Manajemen skema yang ketat: Perubahan yang memicu full table rewrite dilarang, dan saat melakukan perubahan skema diterapkan timeout ketat 5 detik guna mencegah latensi layanan.

4. Rencana ke depan (The Road Ahead)
Walau struktur saat ini sudah cukup skalabel, OpenAI sedang menguji cascading replication untuk memperluas Read Replica lebih jauh, menggantikan pola di mana Primary mengirim WAL ke semua Replica dengan struktur perantara yang meneruskan WAL ke Replica di bawahnya. Dalam jangka panjang, sharding pada PostgreSQL itu sendiri juga sedang dipertimbangkan.

[jaemkim]

Ringkasan diskusi Hacker News: https://news.ycombinator.com/item?id=46725300

Kekuatan satu instance: Ada banyak tanggapan yang menegaskan kembali efektivitas vertical scaling dengan mengatakan bahwa mereka menangani trafik skala 800 juta pengguna dengan satu Postgres (Write) tanpa sharding, dengan komentar seperti "memang benar server DB besar adalah teman kita (Big DB servers are your friend)".

Ironi sharding vs refactoring: Soal bagian yang menyebut "mereka tidak memilih sharding karena refactoring aplikasi lama terlalu rumit", muncul lelucon tajam dan kritik bahwa "ironis perusahaan yang menjual coding AI justru bilang refactoring terlalu sulit sehingga tidak dilakukan". (Di sisi lain, ada juga pembelaan bahwa ini adalah pilihan yang masuk akal jika mempertimbangkan kompleksitas operasional dan biaya migrasi yang dibawa sharding.)

Kurangnya kedalaman teknis: Karena artikel ini lebih banyak membahas hal-hal umum seperti caching dan connection pooling, sebagian orang mengkritiknya sebagai "terasa seperti tulisan promosi" karena minim detail engineering yang konkret.

Diskusi terkait Rust: Di kolom komentar, terpisah dari artikel utama, ada juga yang membagikan teknik untuk mencegah masalah 'Idle Transaction' sejak awal dengan memanfaatkan compile-time check milik Rust, sehingga memicu diskusi teknis yang lebih mendalam.

[jaemkim]

Secara pribadi, saya merasa bagian yang menarik adalah penerapan struktur seperti Cascading Replication atau upaya menembus batasan teknis melalui operasional. Terkait hal itu, saya sudah merangkum pemikiran saya lebih panjang di Facebook. https://www.facebook.com/share/p/1Kp8V917bL/