1 milyardan fazla ChatGPT kullanıcısı için çevrimiçi depolamayı hızla ölçeklendirmek

Birinin oturum açmasından Codex ayarlarını kontrol etmesine veya ChatGPT’de yeni bir sohbet başlatmasına kadar her OpenAI ürünü, verilere hızlı ve güvenilir erişime dayanır. Ürünün yanıt verebilmesi için bu eylemlerin her biri çok sayıda ayrı veri araması gerektirebilir. Bu istekler yavaşsa ürün de yavaş hissettirir. Bu istekler başarısız olursa ürün tamamen çalışmayı durdurur.

Habitat, OpenAI ürünlerinin ihtiyaç duyduğu bilgilere hızla ve güvenilir biçimde erişebilmesi için geliştirdiğimiz çevrimiçi depolama platformudur. Habitat artık yaklaşık 40 coğrafi bölgede, her hafta 1 milyardan fazla kişinin kullandığı ürünleri destekleyerek saniyede 70 milyondan fazla isteği işliyor. Habitat ilk olarak DevDay 2023’te GPT’leri desteklemek üzere, tek bir veri tabanına bağlı basit bir Python istemci kitaplığı olarak kullanıma sunuldu. Bugün 500 petabayttan fazla veriye hizmet veren karmaşık ve dağıtık bir sistemdir.

Bu ölçekte altyapı kurmak ve işletmek kolay değildir ama tek başına olağanüstü zor da sayılmaz. Durumumuzu benzersiz kılan, olgun bir platform kurarken olağanüstü kullanıcı büyümesini ve ürün talebini desteklemek için benzeri görülmemiş bir hızla ölçeklenmek zorunda kalmamızdı. Sistem mühendisleri çoğu zaman 10 kat ölçeğe göre sistem kurar ve sonraki 10 kata hazırlanırken bunun birkaç yıl dayanmasını umar. Biz ise son üç yıldır yıldan yıla 10 kattan fazla büyüdük. Bu nedenle Habitat’ı kurup işletmek, bir yandan depolama ve işlem kapasitesi darboğazlarını savuşturup temel yatırımlara zaman kazandırırken diğer yandan mevcut sistemimizden en yüksek verimi almak için her bileşeni en alt düzeyde anlamayı gerektiren bir dizi taktik karar ve sıralama çalışması oldu.

OpenAI büyürken Habitat da büyümek zorundaydı: Önce kritik ürün trafiği için yeterince güvenilir, ardından küresel kullanıcılar için yeterince hızlı ve son olarak devasa ölçekte etkin biçimde çalışabilir hâle geldi. Bu yazı, çevrimiçi depolamayı nasıl ölçeklendirdiğimizi anlatan iki bölümlük dizinin ilkidir. Bu yazıda Habitat’ın nasıl geliştiğini, onu neden bir kitaplıktan hizmete dönüştürdüğümüzü ve hizmet sistemlerinde alışılmadık bir dil olan Python ile yazılmış bir hizmeti nasıl güvenilir bir depolama platformu katmanına dönüştürdüğümüzü paylaşacağız.

Gelecekteki bir yazıda büyük ölçekte çok kiracılı güvenilirliği nasıl sağladığımızı, okuma performansını optimize etmeye yönelik katmanlı stratejimizi ve benzeri görülmemiş talebi güvenilir biçimde karşılamak için Azure Cosmos DB ile ortaklığımızı nasıl ölçeklendirdiğimizi ayrıntılarıyla ele alacağız.

Habitat basit bir fikirden doğdu: Ürün mühendisleri veri tabanı yönetimini düşünmek zorunda kalmamalı. Habitat ilk olarak DevDay 2023’te GPT’leri desteklemek üzere ChatGPT’nin ana sunucusuyla etkileşime giren küçük bir Python kitaplığı olarak kullanıma sunuldu. Arka planda Azure Cosmos DB veri tabanı uygulamasına eşlenen sınırlı sayıda işlemi destekliyordu.

Kitaplığın görevi, ürün ekiplerinin altta yatan ayrıntılarda uzmanlaşmadan verileri kolayca saklayıp alabilmesini sağlamaktı. Habitat gerekli işleri üstleniyordu: Verinin türünü, nereden geleceğini veya nereye gideceğini, isteğe izin verilip verilmediğini ve benzeri ayrıntıları belirliyordu.

Ürün mühendislerinin şema arama, yönlendirme, yetkilendirme, şifreleme, serileştirme, istek biçimlendirme ve bağlantı havuzlama gibi konularla ilgilenmesi gerekmiyordu. Verilerin Azure Cosmos DB’den, önbelleklerden veya başka depolama türlerinden hangisinden geldiğini düşünmeleri bile gerekmiyordu.

Self servis Postgres ve Azure Cosmos DB kullanımından uzaklaşmaya yönelik merkezi bir girişim olmamasına rağmen bu Python kitaplığı iyi çalıştı ve Habitat, OpenAI’daki ürün mühendisleri arasında hızla benimsendi.

Ürün ihtiyaçları geliştikçe ürün geliştiriciler istemci tarafı önbelleğe alma, sıkıştırma veya şifreleme gibi özelliklerin desteğini ortak kitaplığa kolayca ekleyebiliyordu.

2025’in ortalarında Habitat, istemci tarafı uygulaması olarak sınırlarına ulaşmıştı. Habitat katmanı karmaşıklaştıkça ve OpenAI’ın hizmet sayısı arttıkça geriye dönük uyumlu protokol değişiklikleri uygulanamaz hâle gelmişti.

Bir keresinde en kritik veri kümelerimizi bölgelere dağıtılmış Azure Cosmos DB hesaplarına taşıyarak tek bir bölgedeki kesintinin etki alanını azaltmak istedik. Bu değişiklik için istemciye özellik bayrağı arkasında devre dışı tutulan ek yönlendirme mantığı eklemek, bunu tüm istemcilere dağıtmak ve ardından özellik bayrağını etkinleştirmek gerekiyordu.

Dağıtımları onlarca hizmet arasında koordine etmek ve kullanıma almak için her ekiple çalışmak günler sürdü. Bunu etkinleştirmeden önce bölümleme mantığının doğru çalıştığından emin olmak için gölgeleme eklemek istediğimizi fark ettik. Bunun kullanıma alınması da birkaç gün daha sürdü. Yanlış olduğunu fark ettiğimiz bir şey için hata düzeltmesi mi? Birkaç gün daha. Sonunda bayrağı etkinleştirmeye hazırdık. Ancak ekiplerden biri ilgisiz nedenlerle hizmetini önceden hata içeren bir istemciye geri alınca önlemek için büyük çaba harcadığımız kesinti yaşandı.

İstemci kitaplığındaki değişiklikler onlarca hizmet arasında karmaşık koordinasyon gerektiriyordu; bu süreç giderek kırılgan, verimsiz ve operasyonel hatalara açık hâle gelmişti. Gelecekteki dağıtımlarımızda bu operasyonel yayılımı azaltmak için Habitat’ı ayrı bir hizmete dönüştürmeye karar verdik.

Depolama mantığını bağımsız bir hizmete ayırarak dağıtımlar, gözlemlenebilirlik ve platform iyileştirmeleri için tek bir denetim noktası oluşturduk. Parçalı güncellemeleri yönetmek yerine iyileştirmeleri merkezi olarak uygulayabiliyor ve tüm OpenAI ürünlerine anında fayda sağlayabiliyorduk.

Merkezi bir hizmet, en güçlü veri güvenliği ve gizlilik yapı taşlarını sunmak için bize tek bir denetim noktası da sağlar. Erişim denetimi politikalarını merkezi olarak uygulayabildiğimiz, denetim günlükleri tutabildiğimiz ve Azure Cosmos DB gibi temel depolama kaynaklarına erişimi sınırlayabildiğimiz yer Habitat hizmetidir. Habitat, kullanıcı verilerini korumada ve haricî, dâhilî ya da ajan aktörlerin yetkisiz erişimini önlemede kritik rol oynar.

Bir hizmete ihtiyacımız olduğunu biliyorduk ancak Python’ın hizmet olarak getirdiği ek yüke rağmen henüz Python’dan geçiş yapmak istemiyorduk. Yüksek işlem kapasiteli bir hizmette Python kullanmak, yerel kitaplık yürütmesine kıyasla ağ gecikmesini, CPU ve bellek ölçeklendirme maliyetlerini önemli ölçüde artırdı. Üstelik Python’ın verimsizliklerinin 100 kat ölçekte kabul edilemeyeceğini biliyorduk; dolayısıyla sonunda hizmeti yeniden yazmamız neredeyse kesindi.

Yine de bunu, teknik borca bilinçli ve stratejik bir yatırım olarak gördük. O dönemde temel hedefimiz maliyet veya kaynak optimizasyonu değil, ürün geliştiricilerin önünü açmak ve platform kararlılığını sağlamaktı. Kısa vadede Python hizmetinin performans ödünlerini kabul ederek daha acil sorunlara öncelik verebildik, temel API’lerimizi oluşturduk ve sağlam bir altyapı kurduk.

Ayrıca kendi kodlama modellerimizin hızla gelişmesinin gelecekte teknik süreci kolaylaştıracağı yönünde hesaplı bir risk aldık. Python’dan tamamen geçmemiz gerektiğinde Codex ve GPT’nin bu geçişi mümkün kılacağına güvendik. Sonunda haklı çıktık.

Habitat’ı Python hizmeti olarak çalıştırmak performans açısından ideal değildi ama gerekliydi. Python hızlı ilerlememizi sağlıyor; ancak bu, tedbiri elden bırakıp belirgin ölçüde daha kötü gecikmeleri kabul edebileceğimiz anlamına gelmiyor. Ortalama bir kullanıcı isteği yüzlerce veri tabanı çağrısına yol açtığında kullanıcı en yavaş çağrının gecikmesini hisseder. Bu ölçekte Python hizmeti çalıştırmanın başlıca zorluğunun kuyruk gecikmelerini yönetmek olduğunu gördük.

Asyncio, Python’ın G/Ç ağırlıklı iş yüklerini eşzamanlı yürütmesine yardımcı olur ancak Python GIL engelini aşarak CPU paralelliği sağlamaz. Habitat, G/Ç ağırlıklı istek proxy’lemenin yanı sıra yönlendirme, sıkıştırma, şifreleme, sağlama toplamı, alt sistem sağlık denetimi, istek gölgeleme ve gecikmeyi azaltmak için aynı isteğin ek kopyalarını gönderme (hedging) gibi birçok CPU ağırlıklı sorumluluğu ve arka plan görevini üstlenir.

Hizmetimizde bu kadar çok CPU ağırlıklı iş yükü ve arka plan görevi varken asyncio zamanlama gecikmesi, isteklerin kuyruk gecikmesinde kolayca baskın hâle gelebilir. İlk hizmet lansmanımızdan önce yaptığımız ayarlarda, p99 ve üzeri gecikmeli isteklerin izlerinde alt depolama sistemi hızla yanıt verse de yanıtı ayrıştıracak coroutine’in yeniden zamanlanması beklenirken isteklerin sık sık durduğunu gördük.

OpenAI’daki Python hizmetlerinde bellek, CPU, ağ ve disk kullanımına ilişkin standart kullanım ve doygunluk ölçümlerinin yanı sıra asyncio döngüsünü ve yoğunluğunu izleyip buna göre ayarlama yapmanın kritik olduğunu görüyoruz.

Arka plan görevlerini düzenli aralıklarla zamanlayıp beklenen ve gerçek yürütme zamanı arasındaki farkı kaydederek olay döngüsü zamanlama gecikmesini gerçek zamanlı ve deneysel olarak ölçebiliyoruz. Kullanım yüksek ve maliyetli görev sayısı fazlayken süreç başına az sayıda eşzamanlı istek bile yüzlerce milisaniyeye, bazı uç durumlarda ise birkaç saniyeye varan ciddi zamanlama sapmaları yaratabilir.

Bu nedenle her sürecin yalnızca az sayıda eşzamanlı isteğe hizmet vermesini sağlıyor, bunun yerine Python çalışan süreçlerinin sayısını büyük ölçüde artırıyoruz.

İlk hizmet lansmanımızda canlı CPU profillemesi sayesinde yüksek asyncio gecikmesinin ve dolayısıyla yüksek kuyruk gecikmelerinin temel nedenlerinden birini bulduk: Özellik bayraklarını yöneten, A/B testleri ve daha fazlası için kullanılabilen Statsig üzerinden özellik bayrağı yapılandırmalarımızın düzenli olarak JSON ayrıştırmasından geçirilmesi.

Statsig varsayılan olarak yenilenen yapılandırmaları her dakika, zamanlama sapması olmadan yoklayacak şekilde ayarlanmıştı ve yapılandırma tüm hizmetlerdeki bütün üretim kurallarını içeriyordu. Ayrıca CPU kullanımını artırmak ve gecikmeleri düşürmek için pod başına en fazla 8 Python süreci çalıştırılması yönünde mimari bir karar alınmıştı. Bu iki durum birleşince her podda dakikada bir kez tüm çalışanların devam eden istekleri işlemeyi durdurup CPU döngülerini devasa bir yapılandırma dosyasını ayrıştırmaya harcadığı bir an oluşuyordu.

CPU profillemesi sorunun temel nedenini bulmamızı sağlayınca çözüm basitti: Daha küçük ve hedefli bir yapılandırma dağıtmak, yenileme aralığını uzatmak ve bu tür arka plan görevlerine zamanlama sapması eklemek.

Asyncio gecikmesini düşük tutmak için istekleri sunucu süreçleri arasında iyi dengelemek de kritik önem taşır; bağlantı havuzlama da ayarlanmadığında bu amaca ters düşebilir.

İstemci tarafı bağlantı havuzlamada çok sayıda eşzamanlı istek gönderen tek bir istemci süreci yalnızca birkaç sunucu bağlantısı kurabilir ve bunun sonucunda tüm yükünü yalnızca birkaç sürece gönderebilir. Yük dengeleme yöntemimizi ayarlamadan önce hizmetimizin kullanım oranları büyük farklılık gösteriyordu; yük dağılımının üst ucundaki bazı süreçler ortalamanın 5-10 katı eşzamanlı isteğe hizmet veriyordu.

Bunu tesadüfi bir olayda keşfettik: Hizmetimizin bir bölümünü aşırı yükleyen istemciyi durdurmamıza rağmen bazı süreçlerin performansı ani trafik sona erdikten çok sonra bile düşük kaldı. Hatta bu süreçlerin kontrolden çıkarak kötüleştiğini ve yeniden başlatılana kadar giderek daha fazla istek aldığını fark ettik. Bir pod aşırı yüklendiğinde bazı davranışlar daha fazla trafiği bu poda sabitliyordu. Bu, bazı ekip arkadaşlarımızın önceki çalışmalarından yakından tanıdığı bir hata sınıfıydı: yarı kararlı hata⁠(yeni bir pencerede açılır).

Bağlantı havuzundan şüphelendik ve azami bağlantı yeniden kullanım süresini sınırlayarak bunu test ettik. Bu değişiklik bozulmayı gerçekten sınırlandırdı ve araştırma yönümüzü doğruladı. Daha ayrıntılı araştırmada Python’ın aiohttp TCPConnector bileşeninin varsayılan olarak LIFO bağlantı yeniden kullanımını tercih ettiğini bulduk: Sonraki istek için en son dönen bağlantı seçiliyordu. Bu normalde makul bir varsayılandır: Son kullanılan bağlantıların yeniden kullanılması, ani trafiği karşılamak için oluşturulan ek bağlantıların boşta kalma zaman aşımına uğramasını sağlayarak bu bağlantıları korumanın yükünü azaltır. Ancak bu durumda bizim için yarı kararlı bir hata yarattı. Ani istek yükü sırasında daha yavaş ve aşırı yüklü sunuculara gönderilen isteklerin bağlantıları havuza daha geç dönüyor, dolayısıyla sonraki istekler bu bağlantıları daha sık seçiyor ve trafiği giderek zaten zorlanan podlarda yoğunlaştırıyordu. Bağlantı havuzunu FIFO yeniden kullanımı uygulayacak şekilde değiştirmek bu geri bildirim döngüsünü kırdı ve kararlı durumdaki istek değişkenliğimizi de azalttı.

Bugün OpenAI altyapısının genelinde bağlantı havuzlama ve sunucu yükünü daha iyi gözeten dengeleme stratejileri sağlamak, böylece bu sorunu tamamen önlemek için çoğunlukla Istio ve Envoy’a güveniyoruz.

Düşük asyncio gecikmesi için ayarlama yapmanın ve çok sayıda Python süreci çalıştırmanın bir yan etkisi, alt sistem bağımlılıklarını muazzam sayıdaki bağlantıyla kolayca boğabilmesidir. Bu durum “gürleyen sürü” olarak bilinir.

Yavaş olacak şekilde ayarlanmazsa sıradan bir günlük dağıtım, bağlantıların sürekli yenilenmesi nedeniyle CPU’da ciddi dalgalanmalara yol açabilir. Bağlantı sızıntısı da NAT ağ geçidini doyurarak ağı devre dışı bırakabilir. Bunlar diğer hizmetler için de alışılmadık sorunlar değildir; ancak süreç sayısının bir büyüklük mertebesi fazla olması tetikleme eşiğini önemli ölçüde düşürür ve istemcilerin yalnızca işlem kapasitesine bakarak kararlı durumda yönetmeyi beklemediği ağ kaynaklarını sık sık doyurur.

Bağlantı birleştirmeyi en üst düzeye çıkarmak için Envoy’dan da yararlanıyoruz. Çoklamadan yararlanmak için Python’ın HTTP/1 bağlantılarını HTTP/2’ye yükseltmek, ardından bu bağlantıları havuzlayıp kullanım sürelerini uzatmak için Envoy’u kullanıyoruz. Envoy ayrıca her bağımsız Python sürecinde daha az etkili olacak hız sınırlarını ve devre kesicileri uygulayabileceğimiz merkezi bir yer sağlar.

Python’ı bu kadar ölçekleyebilmemizin nedenlerinden biri, istek maliyetini öngörülebilir tutan kısıtlı Habitat API’siydi. Habitat, istemcilerin büyük tablo taramalarına veya çok sayıda tablo arasında birleştirmelere yol açabilecek gelişigüzel SQL sorguları oluşturmasına izin vermek yerine basit bir NoSQL API’si sunar. Güçlü bir API’nin bulunmaması, Habitat tasarımında bilinçli bir ödündür.

Basit, öngörülebilir ve sabit miktarda iş gerektiren istekler için optimizasyon hedefliyoruz. Deneyimlerimize göre bu sistemlerin ölçeklendirilmesi çok daha kolaydır; yanlış kullanılması veya hatalı uygulanması ise zordur. Öngörülemeyen yayılıma sahip istekler operasyonel açıdan tehlikelidir: Yalıtımı ve yük dengelemeyi karmaşıklaştırır; hem hizmet hem de istemcileri açısından ölçeklendirilmesi güç ani gecikme artışlarına yol açar.

Habitat ve Azure Cosmos DB’ye geçmeden önce OpenAI’ın çevrimiçi verilerinin çoğu Postgres’te saklanıyordu. O dönemde üretime göndermeden önce tüm sorgu ve şema değişikliklerini inceleyerek düzgün çalıştıklarından ve dizinlenmiş veriler üzerinde işlem yaptıklarından emin olmak kolaydı. Ekip ve ürünler büyüdükçe bu süreç hızla yönetilemez hâle geldi; yoğun kullanılan bir yoldaki tek bir yeni ve maliyetli sorgunun veri tabanını devre dışı bırakması sık sık kesintilere yol açtı.

Buradaki sorun maliyet dengesizliğidir: Çalıştırılması pahalı ve zor SQL sorguları yazmak ucuz ve kolaydır. Habitat’ta bunu önlüyor ve pahalı sorguları istemci tarafında son derece belirgin kılıyoruz. Habitat’ı aşırı yükleyebilecek sınırsız sorgular yoktur. Karmaşık birleştirmeler ve grafik geçişleri, ürün ekiplerinin ağır işlerin bir kısmını üstlenmesini gerektirir; bu da genel olarak daha verimli tasarımlara yönelmeyi sağlar.

Habitat, TAO⁠(yeni bir pencerede açılır)’dan esinlenerek istemcinin tanımladığı nesne ve kenar türleri etrafında modellenmiş bir NoSQL API’si sunar. İstemciler nesneleri, kenarları ve aralarındaki ilişkileri önceden tanımlar; ancak her türün içeriğini tanımlamaz. Ortaya çıkan ilişkiler bir grafiğe benzer ancak Habitat, belirli bir nesnenin doğrudan kenarlarını sorgulama dışında tipik grafik geçişi sorgularını desteklemez.

Bu grafiği, her nesne ve ilgili kenarları depolama düzeyindeki aynı bölümde bulunacak şekilde bölümlendiriyoruz; ancak nesnelerle kenarlarının işaret ettiği uzaktaki nesneleri aynı yerde tutmak için veri tabanı düzeyinde özel bir çaba göstermiyoruz. Sonuçta model yatay ölçeklendirme için kolayca bölümlendirilebiliyor; ancak nesneler arasındaki herhangi bir adım, farklı bölgelerdeki iki ayrı Azure Cosmos DB hesabından veri almayı gerektirebildiği için grafik geçişleri verimsiz kalıyor.

Daha karmaşık sorgulama ihtiyaçları olan istemcilere Habitat’ın Rockset üzerinden sunulan çevrimdışı ikincil görünümünü de sağlıyoruz. Çevrimiçi depolamadaki değişiklikleri neredeyse gerçek zamanlı olarak yalıtılmış Rockset örneklerine aktarmak için değişiklik verisi yakalamayı (CDC) kullanıyoruz. Her istemci ekibi, karmaşık sorgulama ihtiyaçları için kendi Rockset örneğini ölçeklendirmekten sorumludur.

Bu Rockset sağlama süreci istemcilerimize ek yük getiriyor; ancak şu an için doğru ödünün bu olduğunu düşünüyoruz: Basit sorguları varsayılan kılarken karmaşık sorgulara ihtiyaç duyanlara alternatif bir yol sunmak. Bu tasarım, çevrimiçi depolamamızı okuma ağırlıklı analitik ve arama iş yüklerinden yalıtır.

Python ile yazılmış sistemi yeniden yazmayı bir yıl ertelemek, hızlı büyüme dönemimizde daha acil ve etkili sorunlara odaklanmamızı sağladı. Platform olgunlaşırken büyümemiz hızlanmayı sürdürüyordu. Çekirdek sayısı bakımından OpenAI’ın ikinci büyük hizmeti, Envoy ayak izi bakımından da dördüncüsü olduğumuz için Python’ı geride bırakmanın zamanı gelmişti. Python, zirvede saniyede 20 milyondan fazla isteğe hizmet vermemizi sağladı.

2026’nın ikinci çeyreğinde yalnızca 2 mühendis, Codex ve GPT‑5.5 ile tüm hizmeti Rust’ta yeniden yazabildik. Bu yeni Rust hizmeti artık üretim isteklerimizin %95’ini işliyor; önümüzdeki haftalarda Python’ı tamamen kullanımdan kaldıracağız. Verilerimiz, Rust hizmetinin Python sürümüne göre CPU kullanımında 6, bellek kullanımında 15 kat daha verimli olduğunu; ortalama ve kuyruk gecikmelerinin de önemli ölçüde düşük olduğunu gösteriyor. Gelecekteki bir blog yazısında daha fazla öğrendiklerimizi paylaşmayı planlıyoruz.

Önce Python, şimdi ise Rust ile çalışan hizmet Habitat’ın yalnızca bir yönüdür. Çevrimiçi depolamamızı 1 milyardan fazla ChatGPT kullanıcısına hizmet verecek şekilde nasıl hızla ölçeklendirdiğimizi anlattığımız bu dizinin ikinci bölümünde depolama katmanını ve Habitat’ın 500 petabayttan fazla veriyi ve saniyede 70 milyondan fazla isteği nasıl işlediğini ele alacağız.

En üst seviye ölçekte OLTP sistemleri üzerinde çalışmak istiyor ve bu tür mühendislikle ilgileniyorsanız ekibimizdeki bu açık pozisyona göz atın⁠.