ChatGPT’yi 800 milyon kullanıcı için desteklemek üzere PostgreSQL’i ölçeklendirme

• OpenAI, ChatGPT ve API trafiğindeki ani artışa yanıt vermek için PostgreSQL altyapısını büyük ölçekte genişletti; tek bir Azure PostgreSQL Flexible Server ve yaklaşık 50 okuma replikasıyla saniyede milyonlarca sorguyu işliyor
• Okuma ağırlıklı iş yüklerine optimize edilmiş yapıyı korurken, yazma yükünü hafifletmek için bazı iş yüklerini Azure Cosmos DB’ye taşıdı
• PgBouncer bağlantı havuzu, cache locking, rate limiting, iş yükü izolasyonu gibi çeşitli optimizasyonlarla kararlılık ve gecikme iyileştirildi
• Tek primary mimarisinin sınırlarını aşmak için yüksek erişilebilirlik (HA) yapılandırmasıyla birlikte hot standby ve kademeli çoğaltma (cascading replication) testleri yürütüldü
• Bu yaklaşımla %99,999 erişilebilirlik ve çift haneli milisaniye düzeyinde p99 gecikme elde edildi; gelecekte sharded PostgreSQL veya dağıtık sistemlere ölçeklenme olasılığı güvence altına alındı

---

PostgreSQL ölçeklendirmesine genel bakış

• PostgreSQL, ChatGPT ve OpenAI API’nin çekirdek veri sistemi ve son 1 yılda yük 10 kattan fazla arttı
  • Tek bir primary instance ve dünya geneline dağılmış yaklaşık 50 okuma replikasıyla 800 milyon kullanıcının istekleri işleniyor
• Okuma ağırlıklı yapı korunurken, yazma yükünü hafifletmek için bazı iş yükleri Azure Cosmos DB’ye taşındı
• Yeni tablo eklenmesi yasaklandı ve yeni iş yükleri varsayılan olarak sharding sistemine yerleştirildi

Tek primary mimarisinin zorlukları ve alınan önlemler

• Tek yazıcı mimarisi, yazma ölçeklenebilirliği sınırı ve tek hata noktası (SPOF) sorunlarına sahip
  • Okuma trafiği replikalara dağıtılıyor, yazma trafiği ise shard edilebilen iş yükleri için Cosmos DB’ye taşınıyor
  • Arıza durumunda hızlı terfi (failover) desteği için hot standby ile yüksek erişilebilirlik yapılandırması kullanılıyor
• Okuma yükü aniden arttığında, cache miss patlaması nedeniyle CPU doygunluğu sorunu yaşandı
  • Aynı anahtar için yinelenen sorguları önlemek amacıyla bir cache locking mekanizması devreye alındı

Sorgu ve kaynak optimizasyonu

• Karmaşık çoklu JOIN sorguları CPU’yu aşırı tüketerek hizmet gecikmesine yol açtı
  • ORM’nin ürettiği verimsiz SQL gözden geçirildi ve karmaşık JOIN mantığı uygulama katmanına taşındı
  • idle_in_transaction_session_timeout ayarıyla uzun süre boşta kalan sorgular engellendi
• “Noisy neighbor” sorununu çözmek için trafik, öncelik bazlı instance’lara ayrıldı
  • Düşük öncelikli isteklerin yüksek öncelikli hizmetleri etkilememesi için izolasyon sağlandı

Bağlantı yönetimi ve yük kontrolü

• Azure PostgreSQL’in 5.000 bağlantı sınırı sorununu çözmek için proxy katmanında PgBouncer devreye alındı
  • Bağlantıların yeniden kullanılmasıyla ortalama bağlantı süresi 50ms → 5ms seviyesine indirildi
  • Bölgeler arası ağ gecikmesini azaltmak için proxy, istemci ve replika aynı bölgede konumlandırıldı
• Rate limiting, ani trafik patlamalarını önlemek için uygulama, proxy ve sorgu seviyelerinde uygulandı
  • Belirli sorgu digest’lerini ORM katmanında da engelleyebilecek şekilde iyileştirmeler yapıldı

Replikasyon ve şema değişikliği yönetimi

• Primary’nin tüm replikalara WAL loglarını stream etmesi gerektiğinden, replika sayısı arttıkça ağ yükü de yükseliyor
  • Kademeli çoğaltma (cascading replication), Azure ekibiyle iş birliği içinde test ediliyor
  • Ara replikalar WAL’i alt replikalara ileterek 100’den fazla replika ölçekleme olasılığı sağlıyor
• Tam tablo yeniden yazımı (full table rewrite) tetikleyen şema değişiklikleri yasaklandı
  • 5 saniyelik timeout içinde yalnızca hafif değişikliklere izin veriliyor; indeks oluşturma ve silme işlemleri eşzamanlı yapılabiliyor
  • Backfill sırasında da sıkı hız sınırlamaları uygulanıyor

Sonuçlar ve gelecek planları

• PostgreSQL, saniyede milyonlarca sorguyu işlerken onlarca milisaniyelik gecikme (p99) ve %99,999 erişilebilirlik sağladı
  • Son 12 ayda yalnızca bir adet SEV-0 olay yaşandı (ChatGPT ImageGen lansmanı sırasında)
• Kalan yazma ağırlıklı iş yükleri de kademeli olarak Cosmos DB’ye taşınıyor
• Kademeli çoğaltma tamamlandıktan sonra replika ölçeklenebilirliği ve kararlılığın daha da güçlendirilmesi planlanıyor
• Gelecekte sharded PostgreSQL veya alternatif dağıtık sistemlerin kullanıma alınma olasılığı değerlendiriliyor

[GN⁺]

Hacker News yorumları

• PostgreSQL'de uzun süre çalışan idle sorgular sık sık sorun çıkarıyor
  Şirketimizin kod tabanında “bağlan → transaction başlat → işi yap → başarılıysa commit et” deseni çok yaygındı
  Bu yaklaşım, aslında veritabanını kullanmasa bile bağlantı slotlarını sürekli meşgul ediyordu; sonuçta Postgres'teki bağlantı sayısını binler seviyesine çıkarmak zorunda kalmıştık
  Bu yüzden Rust koduna derleme zamanında denetim ekledik; bir async fonksiyon içinde bağlantıyı elinde tutarken .await çağrılırsa derleyici hemen uyarı veriyordu
  100'den fazla yeri düzelttik ama bunun sayesinde artık 10.000 bağlantı yerine 32'lik bir havuzla load test çalıştırdığımızda yavaşlama olmuyor
  Sadece idle timeout'u düşürmek de bir yöntem ama statik denetim çok daha kesin bir çözüm oldu

  • Sıralamayı “önce işi yap → başarılıysa bağlantı havuzundan alıp transaction başlat → commit ettikten sonra geri ver” şeklinde değiştirmenin daha iyi olup olmayacağı öneriliyor
  • Bu statik denetimin bir lint kuralı mı olduğu, yoksa type system kullanılarak mı uygulandığı soruluyor

• Yazı fazla yüzeysel ve sadece “biz sharding yaptık!” gibi anahtar kelimeleri tekrarlıyor
  Neredeyse hiç ayrıntı yoktu, SEO için yazılmış cümleler gibi hissettirdi

  • Hatta altyapı partneri reklamı gibi göründüğünü söyleyenler vardı
  • Caching, connection pooling, join optimizasyonu gibi konular da fazla genel geçer açıklamalarla anlatılmıştı

• Yazının özü kabaca “tek writer ölçeklenmiyor, bu yüzden yazmayı azalttık ve okumayı ayırdık” diye özetleniyor
  Neredeyse hiç yeni bir şey yoktu; sadece sorgu optimizasyonu, sharding ve read replica gibi yaygın yaklaşımlardan söz ediliyordu

• Postgres'i sevmemin nedeni, sadece CPU ve diski büyüterek bile oldukça büyük ölçeğe kadar dayanabilmesi
  O noktaya gelindiğinde sharding uzmanı tutacak bütçe de oluşuyor

  • Aslında PostgreSQL zaten FDW ve partitioning ile temel düzeyde sharding destekliyor
    Bu yüzden “sharding için Postgres'ten ayrılmak gerekir” sözü biraz tuhaf geliyor
  • Ama “uzman tutacak bütçe oluşur” kısmına itiraz edenler de vardı
    Örneğin OpenAI şu anda da çok büyük zarar ediyor ve 2027'ye kadar dayanıp dayanamayacağının belirsiz olduğuna dair haberler var

• Şema değişiklikleri ve timeout'lar konusunda, sadece timeout ayarı yapmak yerine
  şema rollout'u sırasında çakışan transaction'ları otomatik sonlandıran script'leri birlikte çalıştırmak çok daha verimli olabilir
  Postgres'in bunu yerleşik olarak sunması iyi olurdu — çünkü ağır lock'larla beklemek yerine bazı transaction'ları iptal etmek daha mantıklı olabilir

  • Buna karşılık, Postgres zaten transaction tabanlı şema değişikliklerini destekliyor; o halde neden işleri zorla sonlandırmak gereksin diye itiraz edenler de vardı

• OpenAI Engineering blogunun ilk yazısı olması ilginç bulundu
  İleride daha fazla vaka görmek istediklerini söyleyenler vardı

  • Hatta işin aslında sık kesintiler ve sabahın 2'sinde acil düzeltmelerle yürütüldüğüne dair şakalı yorumlar da vardı

• Replikasyon ayarları merak edildi
  50 read replica olmasına rağmen neredeyse hiç replication lag olmadığını söylemişlerdi,
  ama gerçekte CPU veya bellek sıçramaları yüzünden bazı replikaların geride kalma ihtimalinin yüksek olduğu belirtildi
  Böyle bir durumda WAL gönderiminde bekleme yüzünden primary'nin de yavaşlayabileceği söylendi

  • Buna karşılık, TCP ACK beklediği için primary'nin yavaşlamayacağı, sadece tutulması gereken WAL segmenti miktarının artacağı yönünde görüş de vardı

• “Yeni özellik ek tablo gerektiriyorsa onu PostgreSQL yerine Azure CosmosDB'ye koyuyoruz” denilen bir bölüm vardı
  Yani mevcut sistemi koruyup sadece yeni özellikleri başka bir veritabanına taşıyor gibiydiler

  • Ancak CosmosDB'nin çok pahalı olduğu, OpenAI gibi parası bol bir şirket değilseniz kullanmanın zor olduğu da belirtildi

• “Instance boyutunu büyüttük” demişlerdi; ama bunun tam olarak hangi seviyeye çıktığı merak edildi
  Hangi CPU ve RAM kullanıldığı, normal kullanıcılarla aynı instance'lar mı olduğu yoksa özel donanım mı kullanıldığı soruldu

  • Büyük bulut sağlayıcıları, iki soketli sunucunun tamamını tek bir VM'e ayıran SKU'lar sunuyor
    Örneğin Azure Standard_E192ibds_v6 (96 çekirdek, 1.8TB RAM, 10TB SSD, 3M IOPS)
    Daha büyüğü olarak SAP HANA için 896 çekirdek, 32TB bellek, 185Gbps ağ sağlayan Standard_M896ixds_24_v3 gibi modeller var
    Bunlar aylık yaklaşık 175 bin dolar seviyesinde ama OpenAI muhtemelen çok büyük indirim almıştır
    Kişisel olarak veritabanı sunucusu için HPC amaçlı HX176rs VM'leri tercih ettiğini söyleyenler de vardı
    HBM cache sayesinde bellek throughput'u çok daha yüksek ve benzer fiyatlı genel amaçlı VM'lere göre performansının çok daha iyi olduğu belirtildi

• Azure PostgreSQL ile CosmosDB'yi birlikte kullanmanın inanılmaz pahalıya mal olacağı söylendi
  Buna rağmen bu yazı, “PostgreSQL'i ölçeklendirmeye dair gerçek bir örnek” olarak en gerçekçi olanlardan biri sayıldı
  Kernel modifikasyonları veya source code hack'leri olmadan, standart bir bulut ortamında işletilen bir yaklaşım olması nedeniyle takdir edildi