Serverless Mimaride Postgres Bağlantı Havuzunu PgDog ile Nasıl Çözdük

Bağlantı Sorunlarının Temeli

Vercel üzerine yapılan her dağıtımda, sunucusuz (serverless) fonksiyonlar aniden çoğalıyor ve her biri veritabanından bir bağlantı talep ediyordu. Veritabanı CPU veya bellek açısından zorlanmasa da, bağlantı limiti dolduğu için uygulama hatalar veriyordu. Başlangıçta Supabase'in varsayılan havuzlayıcısı olan Supavisor kullanıldı, ancak bağlantıların geri dönüştürülmemesi sorunu yaşandı. Ardından PgBouncer'a geçildi. PgBouncer takılı kalan bağlantı sorununu çözse de, sunucusuz mimarinin doğasındaki anlık sıçramalar (bursts) sırasında yetersiz kaldı.

PgBouncer'ın temel sorunu tek iş parçacıklı (single-threaded) olmasıdır. Yüzlerce sunucusuz fonksiyon aynı anda ayağa kalktığında, tek bir iş parçacığı bu bağlantıları yeterince hızlı atayamaz. Trafik düzenli olduğunda sorunsuz çalışan PgBouncer, trafik aniden yükseldiğinde darboğaza neden oluyordu. Oturum zaman aşımları (session timeouts) ve sorgu optimizasyonları gibi veritabanı tarafındaki iyileştirmeler genel sağlığı artırsa da, anlık bağlantı artışı (connection spike) sorununu çözemedi.

PgDog ile Tanışma ve Kurulum

Anlık trafik artışlarına uygun olan, Instacart tarafından geliştirilen ancak sonlandırılan çok iş parçacıklı havuzlayıcı PgCat'in bir çatalı (fork) olan PgDog ile tanıştık. PgDog'un kurulum felsefesi iki temel noktaya dayanır:

Bağlantı sınırlarını artırmak için veritabanını büyütmek (scale up) zorunda kalmamalısınız; bu sorunu havuzlayıcı (pooler) çözmelidir.
Havuzlayıcıyı veritabanınıza ve uygulamanızın çalışma zamanına (runtime) yakın tutmalısınız.

PgDog'u AWS EKS (Elastic Kubernetes Service) üzerinde kurarak veritabanımıza bağladık. Pgbench kullanarak çeşitli sorgularla testler gerçekleştirdik ve ardından gerçek trafik simülasyonları ile staging ortamında denemeler yaptık. Bağlantı sıçramaları metriklerde görünse de PgDog bu yükü hiç zorlanmadan yönetti.

Ayrıca Prisma'nın hazırlanan ifadeler (prepared statements) kullanımı ile PgDog'un bunları önbelleğe alması arasında oluşan bir uyumsuzluk, PgDog ekibi tarafından çok kısa sürede giderildi.

Örnek Kurulum Adımı

PgDog'u AWS EKS üzerinde yapılandırırken, veritabanı bağlantılarınızı yönlendirmek için pgdog.toml yapılandırma dosyasını kullanabilirsiniz:

[databases.primary]
host = "db.example.com"
port = 5432
user = "postgres"
password = "supersecretpassword"
dbname = "production_db"

[pool]
pool_size = 100
max_client_connections = 10000

(Not: Bu bölüm kaynakta belirtilen yapıyı açıklamak için oluşturulmuş örnek bir adımdır.)

PgDog'un Beklenmeyen Avantajları

Bağlantı sıçramalarını çözmesinin yanı sıra PgDog farklı faydalar da sağladı:

Sağlık Farkındalıklı Yük Dengeleme (Health-aware load balancing): PgDog, her Postgres örneğini kontrol eder ve sağlıksız sunuculara sorgu göndermeyi durdurur. Bu sayede veritabanı yeniden boyutlandırma işlemlerinde okuma kesintisi (read downtime) sıfıra iner.
Gelişmiş Metrikler: Açık metrik (OpenMetrics) formatında sağlanan veriler sayesinde Prometheus ve Grafana kullanarak istemci bağlantıları, bekleyen istemciler ve sorgu gecikmeleri gerçek zamanlı olarak izlenebilir hale geldi.

Sonuç ve Maliyet Optimizasyonu

PgDog sayesinde bir adet okuma replikası (read replica) kaldırıldı ve Supabase sunucuları 12xl boyutundan 4xl boyutuna düşürüldü. Dağıtım sırasındaki anlık artışlarda bile havuzlayıcı-veritabanı bağlantıları güvenli sınırlar içinde kaldı. Veritabanı boyutlandırması, bağlantı sorunlarına göre değil gerçek kaynak kullanımına göre yapılmaya başlandı.

AWS üzerinde EKS ile PgDog çalıştırmanın maliyeti, gereğinden fazla büyük (overprovisioned) bir veritabanı kullanmaktan çok daha düşüktür. Artık en yoğun saatlerde bile prod ortamına endişe etmeden dağıtım yapılabiliyor.

Sıkça Sorulan Sorular (FAQ)

1. Serverless mimaride veritabanı bağlantı havuzu neden önemlidir?

Serverless fonksiyonlar, eşzamanlı olarak hızla çoğaldığı için (scale out), veritabanına olan bağlantı sayısı aniden artar. Geleneksel veritabanları bu anlık ve çoklu bağlantı isteklerini yönetmekte zorlanabilir; bu yüzden aracı bir bağlantı havuzlayıcıya ihtiyaç duyulur.

2. PgBouncer neden anlık trafik artışlarında yetersiz kalabilir?

PgBouncer tek iş parçacıklı (single-threaded) çalıştığı için aynı anda gelen çok sayıdaki yeni bağlantı isteğini tek bir işlem hattı üzerinden atamaya çalışır. Bu durum yüksek eşzamanlılıklarda darboğaza neden olur.

3. PgDog'un PgBouncer'dan farkı nedir?

PgDog (ve atası PgCat), çok iş parçacıklı (multi-threaded) bir yapıya sahiptir. Bu özellik sayesinde eşzamanlı bağlantı sıçramalarını (connection spikes) çok daha hızlı ve verimli bir şekilde işleyebilir. Ayrıca sağlık kontrolü gibi gelişmiş yönlendirme yetenekleri bulunur.

4. PgDog ile yük dengeleme (load balancing) yapılabilir mi?

Evet, PgDog veritabanı replikaları arasında sağlık farkındalıklı (health-aware) okuma yükü dengelemesi yapabilir. Sağlıksız olan veya yeniden başlatılan düğümleri otomatik olarak trafikten çıkarır.

Kaynak / Source: https://circleback.ai/blog/how-we-fixed-postgres-connection-pooling-on-serverless-with-pgdog