Neden başka bir Postgres bağlantı havuzlayıcısı daha geliştirdik?
PgDog, Postgres'i ölçeklendirmek için bir proxy'dir. Özelliklerinden biri, birçok istemci uygulamasının bağlantı sınırını aşmadan aynı veritabanını kullanmasına olanak tanıyan bağlantı havuzu oluşturmadır.
PgBouncer, RDS Proxy, Pgpool-II, Supavisor ve diğerleri başta olmak üzere birçok bağlantı havuzlayıcısı var. Peki neden başka bir tane inşa edelim?
Nasıl Önlem Alınmalı?
Sızdıran soyutlamalar
Sistem Güvenliği
Postgres ekosistemindeki çoğu araç UNIX felsefesini çok ciddiye alır: tek bir şey yapın ve onu iyi yapın. Genel olarak bu, güvenilir yazılım oluşturmanın iyi bir yoludur ve PgBouncer'ın bugün bu kadar popüler olmasının nedeni de budur. İşe yarıyor.
Ancak sektörde sızdıran soyutlama dediğimiz şeyi ortaya koyarak işe yarıyor.
PgBouncer veya RDS Proxy'yi dağıttığınızda, veritabanınızı kullanma şeklinizi değiştiren bir altyapı parçası eklediğinizi hemen fark edersiniz. Çoğunlukla uygulama kodunuzu değiştirerek ödün vermenizi gerektirir.
Detaylar ve Etkileri
Uygulamanızı bir süredir geliştiriyorsanız (ki bu genellikle bağlantı havuzu oluşturmanız gerektiğinde gerçekleşir), bu, genellikle çok az test kapsamıyla binlerce satırlık üretim kodunu değiştirmek anlamına gelebilir.
PgDog ile buna artık gerek yok.
Bir bağlantı havuzlayıcı eklediğinizde ilk yapmanız gereken oturum kontrolü, yani SET komutlarıdır. Örneğin daha yavaş sorguları yürütmek amacıyla veritabanı ayarlarını geçici olarak geçersiz kılmak için kullanılırlar:
statement_timeout'u '5m' OLARAK AYARLAYIN; YASAKLANMIŞ OLDUĞUNU KULLANICILARDAN SEÇİN * DOĞRU;
Teknik Analiz
Bağlantı havuzlayıcıları istemciler arasındaki bağlantıları yeniden kullandığından, bir istemcinin bağlantı durumu diğerinin bağlantı durumuna "sızar".
Üretimde bu oldukça kötü olabilir. En iyi senaryoda, yavaş bir sorgu bir süreliğine çalıştırılarak veritabanı olayına neden olur. En kötü durumda, bir oturum değişkenine dayanan Satır Düzeyinde Güvenlik (RLS) politikanız çalışmayı durdurur ve satırlar sessizce kaybolur.
Gelecekte Ne Bekleniyor?
Bu nedenle, bağlantı havuzuna geçiş yaparken verilen tipik tavsiye artık SET kullanmamaktır.
Ancak SET gerçek bir Postgres özelliğidir. Bir veritabanı özelliğini kullanmanıza izin verilmiyorsa, bir ödün vermiş olursunuz ve uygulamalarınızı yazma şeklinizi değiştirmeniz gerekir. Ve bunu RLS gibi önemli bir şey için kullanıyorsanız, bağlantı havuzu oluşturmayı hiçbir şekilde kullanamazsınız.
SET ifadelerini işleme
PgDog yerleşik bir SQL ayrıştırıcıyla birlikte gelir. SET ifadelerini algılayabilir, değişken adlarını ve değerlerini çıkarabilir ve bunları proxy'deki her istemci bağlantısında saklayabilir.
Uzmanların Görüşleri
Bir istemci bir sorgu çalıştırdığında, PgDog ilk olarak kendi durumunun sunucunun durumuyla eşleşip eşleşmediğini kontrol eder ve eğer eşleşmiyorsa, kendi SET ifadelerini çalıştırarak günceller.
SET ifadelerini tespit etmek için kullandığımız algoritma çok hızlıdır. Birkaç değişken farklıysa, bunları tek bir gidiş dönüşte güncellemek için sorgu hattını kullanırız.
Sonuç ve Değerlendirme
Bu, performans etkisini küçük kılar ve ölçeklendirirken güvendiğiniz bir Postgres özelliğini kullanmaya devam edebilirsiniz.
LISTEN ve NOTIFY, Postgres içinde yayınlama/abone olma kuyruğunu uygulayan Postgres komutlarıdır. Bu harika bir özellik ve yığınınıza başka bir veritabanı eklemek zorunda kalmadan oldukça iyi çalışıyor.
Önemli Gelişmeler
Bu aynı zamanda bir havuz oluşturucu eklediğinizde, en azından işlem modunu kullanmak istiyorsanız, vazgeçmeniz gereken bir özelliktir.
Son 10 yılda bir uygulama geliştirdiyseniz (PostgreSQL 10 2017'de çıktı), muhtemelen SQS veya Redis'e geçmeden önce onu kullanmışsınızdır.
PgDog da bunun işe yaramasını sağlıyor. Mesajları birden fazla PgDog işlemi arasında taşırken her iki komutu da dahili olarak yönetir. Müşteriye göre bu PgDog komisyoncu gibi görünüyor, ancak aslında hala Postgres.
Ayrıca NOTIFY'ın tüm işlemsel semantiklerini, hatta bazı arkadaşlarımızın veritabanlarını kaldırmasına neden olanları bile koruduğumuzdan emin oluyoruz (bu arada bunu düzelttik).
Dahili uygulama oldukça ilginç. Aynı PgDog sürecinde istemciler arasında mesajları taşımak için Tokio'nun yayın kanalını kullanıyoruz. Birden fazla PgDog sürecini desteklemek için (örneğin, üretimde birkaç konteyner çalıştırırsınız), ayrıca tüm LISTEN ve NOTIFY komutlarını özel bir bağlantı aracılığıyla Postgres'e göndeririz.
Yani gerçekte, PgDog bir pub/sub istemcisi gibi davranır, diğer pub/sub istemcilerine proxy uygular ve Postgres'i aracı olarak kullanır. Postgres'i ölçeklendirirken "sadece çalışın" kullandığımız bir özelliği oluşturmak için biraz yaratıcı mühendislik.
PgDog, çok iş parçacıklı çalışanlara sahip bir Rust eşzamansız çalışma zamanı olan Tokio üzerine kurulmuştur. Her istemci, bağlantı sayısına göre doğrusal olarak ölçeklenen kendi eşzamansız görevi tarafından yönetilir.
Tokio'yu kullanmak, birden fazla CPU'nun avantajlarından faydalanmamıza olanak tanıyor. tek bir PgDog işleminden istemciler ve saniyede daha fazla sorgu.
Ancak PgBouncer'ın SO_REUSEPORT ve RDS Proxy "sunucusuz" otomatik ölçeklendirmeyi desteklemesi nedeniyle bu neden önemli?
Her iki araç da bağlantı havuzlarınızı "parçalamanızı" gerektirir. Her proxy işleminin kendine özel Postgres bağlantıları vardır. Bir istemci bağlandığında artık örnekleri değiştiremez; dolayısıyla aşırı yüklenirse diğer tüm istemciler de takılıp kalır.
Birden fazla CPU üzerinde çoklu iş parçacığı kullanılarak PgDog işlemleri çok daha fazla trafiği işleyebilir. Bu, daha az sunucu bağlantısıyla daha fazla istemciyi bir araya toplamasına, bağlantı kullanımını ve verimliliğini artırmasına olanak tanır.
Çok iş parçacıklı işlemler, otomatik ölçeklendirmeyi beklemeleri gerekmediği için ani sorgu patlamalarını da daha iyi yönetebilir. Uygulamanızın gecikmeli bir SLA'sı varsa proxy'nizin size engel olmasını istemezsiniz.
Son olarak, çok iş parçacıklı süreçleri yönetmeye yönelik runbook daha kısadır: Linux çekirdeği veya AWS RDS kontrol düzlemi gibi karmaşıklığı hata ayıklamanın zor olduğu yerlere itmeden yalnızca tek bir ölçüm ve durum denetimleri kaynağı.
PgBouncer gibi 20 yıllık bir projenin yerine yenisini koymak zor olabilir ama bir şeyin yolunda gitmediğini düşündüğümüzde onu düzeltiriz. PgDog bir yılı aşkın süredir üretimde ve bağlantıları saniyede 2 milyon sorguyla bir araya getiriyor.
Ücretsizdir (kullanma ve değiştirme özgürlüğünde olduğu gibi), açık kaynaktır ve istediğiniz yere dağıtabilirsiniz.
