OpenAI: 800 milyon kullanıcıyı taşıyan PostgreSQL’i büyük ölçekte ölçeklendirme stratejisi

Özet:

• OpenAI, tek bir Primary ve yaklaşık 50 Read Replica (Azure Flexible Server) ile saniyede milyonlarca sorgu ve 800 milyon kullanıcıyı işliyor.
• Yazma yükünü dağıtmak için sharding yapılabilen iş yükleri Azure Cosmos DB’ye taşındı; uygulama seviyesinde Lazy Write gibi yaklaşımlar uygulanarak yazma işlemleri optimize edildi.
• PgBouncer devreye alınarak bağlantı gecikmesi 50 ms’den 5 ms’ye düşürüldü ve cache miss fırtınasını önlemek için bir cache lock mekanizması uygulandı.
• Karmaşık join sorgularının kaldırılması, 5 saniyenin altında katı şema değişikliği zaman aşımı ve trafik önceliğine göre iş yükü izolasyonu sayesinde kararlılık sağlandı.

Ayrıntılı özet:
1. Arka plan ve mevcut mimari
OpenAI’nin PostgreSQL trafiği son 1 yılda 10 kattan fazla arttı ve şu anda 800 milyon kullanıcıyı ve saniyede milyonlarca sorguyu (QPS) işliyor. Dikkat çekici olan, bu ölçeğin tek bir Primary örneği ile dünya geneline dağılmış yaklaşık 50 Read Replica yapısıyla işletiliyor olması. İlk tasarımdaki çatlakların büyümesini önlemek için OpenAI, hem altyapı hem de uygulama katmanında kapsamlı optimizasyonlar gerçekleştirdi.

2. Başlıca darboğazlar ve optimizasyon stratejileri

• Yazma yükünü dağıtma:

  • PostgreSQL’in tek Writer yapısı ölçeklenebilirlik açısından sınırlı ve MVCC (çok sürümlü eşzamanlılık denetimi) nedeniyle write amplification sorunu bulunuyor.
  • Çözüm olarak, yatay bölme (sharding) yapılabilen yazma yoğun iş yükleri Azure Cosmos DB gibi sistemlere taşındı.
  • Mevcut PostgreSQL üzerinde yeni tablo oluşturulması yasaklandı; ayrıca uygulama hataları düzeltilerek ve Lazy Write (trafik sıçramalarını düzleştirmek için yazmaları gecikmeli işleme) uygulanarak Primary üzerindeki yük en aza indirildi.

• Sorgu optimizasyonu ve ORM yönetimi:

  • Geçmişte 12 tabloyu join eden bir sorgu kesintiye (SEV) yol açtığı için karmaşık çoklu join’lerden kaçınıldı ve bunlar uygulama mantığına ayrıştırıldı.
  • ORM’nin ürettiği verimsiz sorgular sürekli gözden geçiriliyor; ayrıca idle_in_transaction_session_timeout ayarıyla boşta kalan sorguların Autovacuum’u engellemesi önlendi.

• Bağlantı havuzlama (PgBouncer):

  • Azure PostgreSQL’in bağlantı sınırını (5.000) ve bağlantı patlamalarını önlemek için PgBouncer proxy katmanı olarak devreye alındı.
  • Transaction/Statement pooling modları kullanılarak bağlantıların yeniden kullanılabilirliği artırıldı ve ortalama bağlantı süresi 50 ms’den 5 ms’ye indirildi.

• Cache miss önleme (Cache Locking):

  • Cache süresi dolduğunda çok sayıda isteğin aynı anda DB’ye yüklenmesine yol açan “Thundering Herd” sorununu önlemek için cache lock (leasing) mekanizması devreye alındı.
  • Belirli bir anahtarda cache miss oluştuğunda yalnızca tek bir isteğin veriyi yenilemek için DB erişim izni (lock) almasına izin verildi; diğer istekler bekletilerek DB yükü engellendi.

3. Kararlılık ve operasyon politikaları

• Tek hata noktası (SPOF) etkisini azaltma: Primary arızasında bile okuma istekleri Replica üzerinden işlenecek şekilde tasarlanarak olayın şiddeti düşürüldü; ayrıca Primary, yüksek erişilebilirlik (HA) modunda Hot Standby tutarak hızlı failover sağlıyor.
• İş yükü izolasyonu: “Noisy Neighbor” sorununu önlemek için trafik, önem derecesine göre (Low/High Priority) ayrılmış örneklere yönlendiriliyor.
• Katı şema yönetimi: Tüm tablonun yeniden yazılmasına (Full Table Rewrite) yol açan değişiklikler yasaklandı; ayrıca şema değişikliklerinde hizmet gecikmesini önlemek için 5 saniyelik katı bir zaman aşımı uygulanıyor.

4. Gelecek planı (The Road Ahead)
Mevcut yapı ile zaten yeterli ölçeklenebilirlik sağlanmış olsa da, ileride daha fazla Read Replica genişlemesi için Primary’nin tüm Replica’lara WAL göndermesi yerine, ara Replica’nın alt Replica’lara WAL ilettiği Cascading Replication test ediliyor. Uzun vadede PostgreSQL’in kendi içinde sharding de değerlendiriliyor.

[jaemkim]

Hacker News tartışma özeti: https://news.ycombinator.com/item?id=46725300

Tek bir instance’ın gücü: 800 milyon kullanıcı ölçeğindeki trafiğin sharding olmadan tek bir Postgres (Write) ile işlendiği noktasına karşı, “yine görüyoruz ki büyük DB sunucuları dostumuzdur (Big DB servers are your friend)” diyerek dikey ölçeklemenin (Vertical Scaling) geçerliliğini yeniden doğrulayan çok sayıda tepki var.

Sharding vs refactoring ironisi: Metindeki “mevcut uygulamayı refactor etmek çok karmaşık olduğu için sharding’i seçmediler” kısmına karşı, “kodlama yapay zekası satan bir şirketin refactoring zor diye bunu yapamaması ironik” şeklinde iğneli şakalar ve eleştiriler yapıldı. (Öte yandan, sharding’in getireceği operasyonel karmaşıklık ve migration maliyeti düşünüldüğünde bunun makul bir tercih olduğunu savunanlar da var.)

Teknik derinlik konusundaki hayal kırıklığı: Yazı biraz daha genel içeriklere (caching, connection pooling vb.) odaklandığı için, somut mühendislik detaylarının eksik olması nedeniyle bunun “tanıtım amaçlı bir yazı gibi göründüğünü” söyleyen eleştirel görüşler de var.

Rust ile ilgili tartışma: Yorumlarda, ana metinden bağımsız olarak Rust’ın compile-time kontrollerini kullanıp 'Idle Transaction' sorununu en baştan engelleyen bir yöntem paylaşılırken teknik tartışma daha da derinleşti.

[jaemkim]

Ben kişisel olarak Cascading Replication gibi yapıların uygulanmış olması ya da teknik sınırların operasyonla aşılmış olması kısmını ilginç buldum. Bununla ilgili düşüncelerimi Facebook'ta biraz daha uzun şekilde derledim. https://www.facebook.com/share/p/1Kp8V917bL/