PostgreSQL'i 800 milyon ChatGPT kullanıcısı için ölçeklendirme

PostgreSQL, yıllardır ChatGPT ve OpenAI'ın API'si gibi temel ürünleri destekleyen en önemli arka plan veri sistemlerinden biri olmuştur. Kullanıcı tabanımız hızla büyüdükçe, veritabanlarımıza olan talepler de katlanarak arttı. Son bir yıl içinde PostgreSQL yükümüz 10 kattan fazla arttı ve hızla artmaya devam ediyor.

Bu büyümeyi sürdürmek için üretim altyapımızı geliştirme çabalarımız yeni bir kavrayışı ortaya çıkardı: PostgreSQL, daha önce mümkün olduğu düşünülenden çok daha büyük okuma ağırlıklı iş yüklerini güvenilir bir şekilde destekleyecek şekilde ölçeklendirilebilir. Sistem (ilk olarak California Üniversitesi, Berkeley'deki bir bilim insanları ekibi tarafından oluşturuldu), tek bir birincil Azure PostgreSQL esnek sunucu örneği⁠(yeni bir pencerede açılır) ve dünya genelinde birden fazla bölgeye yayılmış yaklaşık 50 okuma replikası ile devasa küresel trafiği desteklememizi sağladı. Bu, OpenAI'da PostgreSQL'i, titiz optimizasyonlar ve sağlam mühendislik çalışmalarıyla 800 milyon kullanıcı için saniyede milyonlarca sorguyu destekleyecek şekilde nasıl ölçeklendirdiğimizin hikayesidir. Ayrıca, bu süreçte öğrendiğimiz önemli dersleri de ele alacağız.

ChatGPT'nin piyasaya sürülmesinin ardından, trafik eşi benzeri görülmemiş bir hızla arttı. Bunu desteklemek için hem uygulama hem de PostgreSQL veritabanı katmanlarında hızla kapsamlı optimizasyonlar uyguladık, örnek boyutunu artırarak dikey ölçeklendirme yaptık ve daha fazla okuma replikası ekleyerek yatay ölçeklendirme gerçekleştirdik. Bu mimari bize uzun süre iyi hizmet etti. Sürekli yapılan iyileştirmelerle, gelecekteki büyüme için geniş bir hareket alanı sunmaya devam ediyor.

Tek bir birincil mimarinin OpenAI’ın ölçeğinin gereksinimlerini karşılayabilmesi şaşırtıcı gelebilir; ancak, bunu pratikte uygulamak basit değil. Postgres'in aşırı yüklenmesinden kaynaklanan birçok SEV gördük ve bunlar genellikle aynı modeli izliyor: yukarı akış sorunu, önbellekleme katmanı arızasından kaynaklanan yaygın önbellek kaçırmaları, CPU'yu doyuran pahalı çok yönlü birleştirme dalgası veya yeni bir özellik lansmanından kaynaklanan bir yazma fırtınası gibi veritabanı yükünde ani bir artışa neden oluyor. Kaynak kullanımı arttıkça sorgu gecikmesi artar ve istekler zaman aşımına uğramaya başlar. Yeniden denemeler yükü daha da artırır ve tüm ChatGPT ile API hizmetlerini bozabilecek bir kısır döngüyü tetikler.

PostgreSQL, okuma ağırlıklı iş yüklerimiz için iyi ölçekleniyor olsa da, yüksek yazma trafiği dönemlerinde hâlâ zorluklarla karşılaşıyoruz. Bu durum, PostgreSQL'in çok sürümlü eşzamanlılık kontrolü (MVCC) uygulamasından kaynaklanmaktadır ve bu da onu yazma ağırlıklı iş yükleri için daha az verimli kılmaktadır. Örneğin, bir sorgu bir demeti veya tek bir alanı güncellediğinde, yeni bir sürüm oluşturmak amacıyla tüm satır kopyalanır. Yoğun yazma yükleri altında bu durum, önemli ölçüde yazma amplifikasyonuna neden olur. Ayrıca, sorgular en son sürümü almak için birden fazla demet sürümünü (ölü demetler) taramak zorunda olduğundan, okuma amplifikasyonunu da artırır. MVCC, tablo ve dizin şişkinliği, artan dizin bakım ek yükü ve karmaşık otomatik vakum ayarı gibi ek zorluklar getirir. (Bu konulara ilişkin derinlemesine bir incelemeyi, Carnegie Mellon Üniversitesi'nden Prof. Andy Pavlo ile birlikte yazdığım The Part of PostgreSQL We Hate the Most⁠(yeni bir pencerede açılır) adlı blog yazısında bulabilirsiniz; PostgreSQL Wikipedia sayfasından alıntılanmıştır⁠(yeni bir pencerede açılır).)

Bu sınırlamaları azaltmak ve yazma baskısını azaltmak için, parçalanabilir (yani yatay olarak bölünebilen iş yükleri) ve yazma yoğunluğu yüksek iş yüklerini Azure Cosmos DB gibi parçalanmış sistemlere taşıdık ve taşımaya devam ediyoruz. Böylece, gereksiz yazma işlemlerini en aza indirmek için uygulama mantığını optimize ediyoruz. Mevcut PostgreSQL dağıtımına yeni tablolar eklenmesine artık izin vermiyoruz. Yeni iş yükleri varsayılan olarak parçalanmış sistemlere yönlendirilir.

Altyapımız geliştikçe bile PostgreSQL, tüm yazmalara hizmet eden tek bir birincil örnekle paylaşılmadan kaldı. Birincil gerekçe, mevcut uygulama iş yüklerini parçalamanın son derece karmaşık ve zaman alıcı olmasıdır; bu, yüzlerce uygulama uç noktasında değişiklik gerektirebilir ve potansiyel olarak aylar, hatta yıllar sürebilir. İş yüklerimiz ağırlıklı olarak okuma odaklı olduğu ve kapsamlı optimizasyonlar uyguladığımız için mevcut mimari, devam eden trafik artışını desteklemek için hâlâ yeterli kapasite sunuyor. Gelecekte PostgreSQL'i parçalamayı göz ardı etmiyoruz, ancak mevcut ve gelecekteki büyüme için yeterli alana sahip olduğumuzdan, bu yakın vadede bir öncelik değildir.

İlerleyen bölümlerde, karşılaştığımız zorlukları ve bunları ele almak ve gelecekteki kesintileri önlemek için uyguladığımız kapsamlı optimizasyonları inceleyecek, PostgreSQL'i sınırlarına kadar zorlayacak ve saniyede milyonlarca sorguya (QPS) ölçeklendireceğiz.

Zorluk: Yalnızca bir yazarla, tek birincil kurulum yazmaları ölçeklendiremez. Yoğun yazma artışları birincil sistemi hızla aşırı yükleyebilir ve ChatGPT ve API'miz gibi hizmetleri etkileyebilir.

Çözüm: Yazma yoğunluğunu en aza indirgemek için birincil sunucunun okuma ve yazma yükünü mümkün olduğunca azaltıyoruz. Böylece, yazma yoğunluğundaki ani artışları karşılayacak yeterli kapasiteye sahip olmasını sağlıyoruz. Okuma trafiği mümkün olan her yerde replikalara aktarılır. Ancak, bazı okuma sorguları yazma işlemlerinin bir parçası oldukları için birincil sunucuda kalmalıdır. Bunlar için verimli olmalarını ve yavaş sorgulardan kaçınmalarını sağlamaya odaklanıyoruz. Yazma trafiği için parçalanabilir, yazma ağırlıklı iş yüklerini Azure CosmosDB gibi parçalanmış sistemlere geçirdik. Parçalanması daha zor olan ancak yine de yüksek yazma hacmi oluşturan iş yüklerinin taşınması daha uzun sürer ve bu süreç hala devam etmektedir. Ayrıca yazma yükünü azaltmak için uygulamalarımızı agresif bir şekilde optimize ettik; örneğin, gereksiz yazmalara neden olan uygulama hatalarını düzelttik ve trafik artışlarını yumuşatmak için uygun olan yerlerde tembel yazmalar başlattık. Ayrıca, tablo alanlarını geri doldururken, aşırı yazma baskısını önlemek için katı oran sınırları uyguluyoruz.

Zorluk: PostgreSQL'de birkaç pahalı sorgu tespit ettik. Geçmişte, bu sorgulardaki ani hacim artışları büyük miktarda CPU tüketerek hem ChatGPT'yi hem de API isteklerini yavaşlatıyordu.

Çözüm: Çok sayıda tabloyu bir araya getirenler gibi birkaç pahalı sorgu, tüm hizmeti önemli ölçüde düşürebilir ve hatta çökertebilir. PostgreSQL sorgularını sürekli olarak optimize etmemiz gerekiyor. Böylece, bu sorguların verimli olmasını sağlayabilir ve yaygın Online İşlem İşleme (OLTP) anti-kalıplarından kaçınabiliriz. Örneğin, bir keresinde 12 tabloyu birleştiren son derece maliyetli bir sorgu tespit ettik; bu sorgudaki ani artışlar, geçmişteki yüksek önem dereceli SEV'lerden sorumluydu. Mümkün olduğunca karmaşık çoklu tablo birleştirmelerinden kaçınmalıyız. Birleştirmeler gerekliyse sorguyu parçalamayı ve bunun yerine karmaşık birleştirme mantığını uygulama katmanına taşımayı düşünmeyi öğrendik. Bu sorunlu sorguların çoğu Nesne İlişkisel Eşleme çerçeveleri (ORM'ler) tarafından oluşturulur, bu nedenle ürettikleri SQL'i dikkatlice incelemek ve beklendiği gibi davrandığından emin olmak önemlidir. PostgreSQL'de uzun süre çalışan boşta sorgular bulmak da yaygındır. idle_in_transaction_session_timeout gibi zaman aşımlarını yapılandırmak, otomatik vakumu engellemelerini önlemek için gereklidir.

Zorluk: Bir okuma kopyası çökerse, trafik hala diğer kopyalara yönlendirilebilir. Ancak, tek bir yazara güvenmek, tek bir hata noktasına sahip olmak anlamına gelir, eğer bu nokta çökerse, tüm hizmet etkilenir.

Çözüm: Çoğu kritik istek yalnızca okuma sorgularını içerir. Birincil sistemdeki tek hata noktasını azaltmak için okuma işlemlerini yazma düğümünden replikalara aktardık; böylece birincil sistem devre dışı kalsa bile bu isteklerin hizmet vermeye devam etmesini sağladık. Yazma işlemleri yine başarısız olsa da, bunun etkisi azalmıştır; okuma işlemleri kullanılabilir durumda kaldığı için artık SEV0 değildir.

Birincil arızaları azaltmak için birincil sunucuyu Yüksek Kullanılabilirlik (HA) modunda, trafiği devralmaya her zaman hazır olan, sürekli senkronize edilen bir yedekle çalıştırıyoruz. Birincil sistem devre dışı kalırsa veya bakım için çevrimdışı alınması gerekirse, kesinti süresini en aza indirmek amacıyla yedeği hızla birincil konuma getirebiliriz. Azure PostgreSQL ekibi, bu yük devretmelerin çok yüksek yük altında bile güvenli ve güvenilir kalmasını sağlamak amacıyla önemli çalışmalar gerçekleştirdi. Okuma replikası arızalarını yönetmek için her bölgede yeterli kapasite yedeği olan birden fazla replika dağıtarak, tek bir replika arızasının bölgesel kesintiye yol açmamasını sağlıyoruz.

Zorluk: Belirli isteklerin PostgreSQL örneklerinde orantısız miktarda kaynak tükettiği durumlarla sık sık karşılaşıyoruz. Bu durum, aynı örnekler üzerinde çalışan diğer iş yüklerinin performansında düşüşe neden olabilir. Örneğin, yeni bir özelliğin kullanıma sunulması, PostgreSQL CPU'sunu yoğun bir şekilde tüketen ve diğer kritik özelliklere yönelik istekleri yavaşlatan verimsiz sorgulara neden olabilir.

Çözüm: Gecikmeyi en aza indirmek için birden fazla coğrafi bölgede yaklaşık 50 okuma replikası işletiyoruz. Ancak mevcut mimariyle, birincil sunucu her replikaya WAL akışı sağlamak zorundadır. Şu anda çok büyük örnek türleri ve yüksek ağ bant genişliğiyle iyi ölçeklense de, birincil düğümü sonunda aşırı yüklemeden sonsuza kadar replika eklemeye devam edemeyiz. Bu durumu çözmek için, ara replikaların WAL'ı aşağı akış replikalarına aktardığı kademeli çoğaltma⁠(yeni bir pencerede açılır) konusunda Azure PostgreSQL ekibiyle iş birliği yapıyoruz. Bu yaklaşım, birincili zorlamadan potansiyel olarak yüzün üzerinde replikaya ölçeklenmemize olanak tanır. Bununla birlikte, özellikle yük devretme yönetimi konusunda ek operasyonel karmaşıklığı da beraberinde getirir. Bu özellik hâlâ test aşamasında; üretime geçmeden önce sağlam olduğundan ve güvenli bir şekilde devredilebildiğinden emin olacağız.

Zorluk: Belirli uç noktalarda ani trafik artışı, pahalı sorguların artması veya yeniden deneme fırtınası, CPU, I/O ve bağlantılar gibi kritik kaynakları hızla tüketebilir ve bu da yaygın hizmet bozulmasına neden olur.

Çözüm: Ani trafik artışlarının veritabanı örneklerini zorlamasını ve basamaklı arızaları tetiklemesini önlemek için birden fazla katmanda (uygulama, bağlantı havuzu, proxy ve sorgu) hız sınırlaması uyguladık. Yeniden deneme fırtınalarını tetikleyebilecek aşırı kısa yeniden deneme aralıklarından kaçınmak da çok önemlidir. Ayrıca ORM katmanını hız sınırlamasını destekleyecek ve gerektiğinde belirli sorgu özetlerini tamamen engelleyecek şekilde geliştirdik. Bu hedefli yük atma biçimi, pahalı sorguların ani dalgalanmalarından hızlı bir şekilde kurtulmayı sağlar.

Zorluk: Bir sütun türünü değiştirmek gibi küçük bir şema değişikliği bile tüm tablonun yeniden yazılmasını⁠(yeni bir pencerede açılır)tetikleyebilir . Bu nedenle şema değişikliklerini dikkatli bir şekilde uygularız; bunları hafif işlemlerle sınırlandırır ve tüm tabloları yeniden yazmaktan kaçınırız.

Çözüm: Yalnızca tam bir tablo yeniden yazımını tetiklemeyen belirli sütunların eklenmesi veya kaldırılması gibi küçük çaplı şema değişikliklerine izin verilir. Şema değişikliklerinde 5 saniyelik katı bir zaman aşımı uyguluyoruz. Dizinlerin eşzamanlı olarak oluşturulmasına ve bırakılmasına izin verilir. Şema değişiklikleri yalnızca mevcut tablolarla sınırlıdır. Yeni bir özellik ek tablolar gerektiriyorsa bunların PostgreSQL yerine Azure CosmosDB gibi alternatif parçalanmış sistemlerde olması gerekir. Bir tablo alanını geri doldururken, yazma ani artışlarını önlemek için katı hız sınırları uygularız. Bu süreç bazen bir haftadan fazla sürebilmesine rağmen, istikrar sağlar ve üretimin etkilenmesini önler.

Bu çaba, doğru tasarım ve iyileştirmelerle Azure PostgreSQL'in en büyük üretim iş yüklerini kaldıracak şekilde ölçeklendirilebileceğini göstermektedir. PostgreSQL, okuma ağırlıklı iş yükleri için milyonlarca QPS işleyerek OpenAI'ın ChatGPT ve API platformu gibi en kritik ürünlerine güç sağlar. Replikasyon gecikmesini sıfıra yakın tutarken yaklaşık 50 okuma replikası ekledik, coğrafi olarak dağıtılmış bölgelerde düşük gecikmeli okumaları sürdürdük ve gelecekteki büyümeyi desteklemek için yeterli kapasite boşluğu oluşturduk.

Bu ölçeklendirme, gecikmeyi en aza indirirken güvenilirliği artırarak çalışır. Üretimde sürekli olarak düşük çift haneli milisaniye p99 istemci tarafı gecikme süresi ve %99,999 kullanılabilirlik sunuyoruz. Ve son 12 ayda yalnızca bir SEV-0 PostgreSQL olayı yaşadık (ChatGPT ImageGen’in viral lansmanı⁠(yeni bir pencerede açılır) sırasında gerçekleşti; bir hafta içinde 100 milyondan fazla yeni kullanıcı kaydolunca yazma trafiği aniden 10 katından fazla arttı.)

PostgreSQL'in bizi getirdiği noktadan memnun olsak da, gelecekteki büyümemiz için yeterli alana sahip olduğumuzdan emin olmak için sınırlarını zorlamaya devam ediyoruz. Yazma ağırlıklı ve parçalanabilir iş yüklerini, CosmosDB gibi parçalanmış sistemlerimize çoktan taşıdık. Geriye kalan yazma ağırlıklı iş yüklerini parçalamak daha zordur; yazma işlemlerini PostgreSQL birincilinden daha fazla boşaltmak için bunları da aktif olarak taşıyoruz. Ayrıca, önemli ölçüde daha fazla okuma replikasına güvenle ölçeklenebilmemiz için kademeli çoğaltmayı etkinleştirmek üzere Azure ile de çalışıyoruz.

İleriye baktığımızda, altyapı ihtiyaçlarımız büyümeye devam ettikçe, sharded PostgreSQL veya alternatif dağıtık sistemler gibi daha fazla ölçeklenme için ek yaklaşımlar keşfetmeye devam edeceğiz.