Cloudflare 100 TB RAM kazandı: Donanım değil, veri düzeni değişti
Cloudflare, 27 Ağustos 2026’da 1.1.1.1’in arkasındaki DNS önbelleğinde yaptığı beş Rust veri düzeni değişikliğiyle filo genelindeki çalışma kümesini yaklaşık 100 TB küçülttüğünü duyurdu. Cloudflare’ın teknik açıklaması, sentetik testte kayıt başına bellek ayak izinin 953 bayttan 420 bayta indiğini, üretim dağıtımının 18 Mayıs’ta başlayıp 6 Temmuz 2026’da tamamlandığını ve yerleşik üretim ölçümlerinde yaklaşık 100 TB kapasitenin serbest kaldığını gösteriyor.
Sonuç yeni sunucu eklemekten veya fiziksel RAM modüllerini değiştirmekten değil, önbellekteki DNS yanıtlarının bellekte temsil edilme biçiminden kaynaklandı. 29 Ağustos 2026 tarihli TechSpot haberi de Big Pineapple platformunda beş Rust değişikliği yapıldığını, kayıt ayak izinin yarıdan fazla küçüldüğünü ve yaklaşık 100 TB RAM kapasitesinin serbest kaldığını aktarıyor.
Değişmeyen veri için büyüme payı kaldırıldı
İlk optimizasyon, önbelleğe girdikten sonra değişmeyen veriyi büyüyebilir koleksiyonlarda tutmamaktı. Rust’taki Vec<T> ve String, veri adresi ve uzunluğun yanında gelecekteki büyüme için kapasite bilgisi taşır. DNS yanıtı önbelleğe yazıldıktan sonra genişletilmediğinden bu metadata ile ayrılmış fakat kullanılmayan alan kalıcı bir maliyete dönüşüyordu.
Cloudflare bu alanları sabit boyutlu Box<[T]> ve Box<str> yapılarıyla değiştirdi. Her kayıttaki sekiz ilgili alandan kapasite bilgisinin çıkarılması kayıt başına 64 bayt kazandırdı; 250 milyardan fazla kayıt ölçeğinde yalnızca bu değişikliğin toplam etkisi 15 TB’ı aştı.
Bu optimizasyonun ilkesi küçük sistemlere de aktarılabilir: oluşturulduktan sonra değişmeyen bir koleksiyon, büyüme kapasitesi taşımak zorunda değildir. Ancak veri sonradan genişleyecekse sabit boyutlu gösterim yeni ayırma ve kopyalama maliyeti doğurabilir. Cloudflare’daki toplam kazancın büyüklüğü ölçeğe özgü, değişmez veriye uygun yapı seçme kararı ise genel nitelikte.
Üç liste tek tamponda toplandı, tekrar eden adlar atıldı
İkinci değişiklik, DNS yanıtının answer, authority ve additional bölümlerini ayrı listelerde tutmak yerine tek bir tamponda birleştirdi. Bölümlerin başlangıç noktaları küçük ofsetlerle işaretlendi; ayrı listelerin işaretçi ve uzunluk alanları ortadan kalktı. Boolean değerlerin bit bayraklarında toplanması da Rust’ın hizalama için eklediği boşluğu azalttı.
Bu düzen, bölümlerin birbirinden bağımsız değiştirilmesini zorlaştırıyor. Big Pineapple’daki kayıtlar önbelleğe alındıktan sonra değişmediği için Cloudflare bu esnekliğe ihtiyaç duymuyordu. Yöntemin başka bir sisteme aktarılabilmesi, verinin gerçekten değişmez olmasına ve bölüm sınırlarının seçilen ofset türüne sığmasına bağlı.
Üçüncü optimizasyon tekrar eden kayıt sahibi adlarını kaldırdı. Bir kaydın sahibi sorgulanan alan adıyla aynıysa ad ayrıca saklanmıyor; yanıt oluşturulurken önbellek anahtarından geri getiriliyor. CNAME zinciri gibi sahibin sorgulanan addan farklı olduğu durumlarda ise tam ad korunuyor.
Bu yaklaşım yalnızca atılan bilginin başka bir alandan hatasız üretilebildiği veri modellerinde güvenli. Bellek kazancının karşılığında kayıt artık tek başına eksiksiz değil; doğru biçimde yorumlanması için önbellek anahtarına ihtiyaç duyuyor. Bağımsız taşınması veya anahtardan ayrı okunması gereken kayıtlarda aynı tercih uygun olmayabilir.
En büyük enum varyantının faturası yaygın kayıtlardan silindi
Dördüncü değişiklik Rust enum’larının en büyük varyant kadar alan ayırması sorununa odaklandı. Cloudflare’ın eski temsilinde seyrek kullanılan NAPTR verisi enum’un toplam boyutunu belirliyor; çok daha küçük A ve AAAA kayıtları da aynı geniş yerleşimin maliyetini taşıyordu. Üstelik A ve AAAA, iş yükündeki kayıtların büyük çoğunluğunu oluşturuyordu.
Ara çözümde büyük varyantlar ayrı yığın tahsislerine taşındı, küçük ve sık kullanılan türler enum içinde bırakıldı. Bu seçim yaygın kayıtları küçülttü; buna karşılık nadir NAPTR türüne işaretçi ve tahsis ek yükü getirdi. Sonuç, her kayıt türünü eşit ölçüde iyileştiren bir tasarım değil, gerçek trafik dağılımını esas alan bilinçli bir değiş tokuştu.
Box kullanımı daha fazla tahsis ve daha zayıf CPU önbellek yerelliği yarattığı için beşinci değişiklik ara çözümün maliyetini de kaldırdı. Kayıt verileri, uzunluk önekleriyle ayrılan ham DNS wire-format baytları halinde tek bir bitişik tamponda saklandı. Ayrı enum nesneleri kalktı; birçok kayıt türü yanıt hazırlanırken alan alan yeniden serileştirilmek yerine doğrudan kopyalanabilir hale geldi.
Bu düzen rastgele erişim yerine tamponun sırayla taranmasını gerektiriyor. Cloudflare’ın iş yükünde kayıt başına öğe sayısı az olduğundan maliyet sınırlı kaldı; alan adı sıkıştırması gerektiren bazı türlerin yine ayrıştırılması gerekiyor. Dolayısıyla ham biçimde saklama, küçük kayıt grupları ve sıralı okuma yolu için uygun; genel amaçlı rastgele erişim gereken veri kümeleri için otomatik bir üstünlük sağlamıyor.
Sentetik kayıt testi ile üretim belleği farklı şeyleri ölçtü
953 bayttan 420 bayta düşüş, üretim trafik dağılımına yaklaşan sentetik bir önbellek testinin sonucu. Bu test veri yapısının kendi maliyetini karşılaştırıyor; gerçek süreç belleğinde ise önbellek dışındaki veriler, tahsis edicinin durumu, doluluk oranı ve trafik karışımı da bulunuyor.
Üretimde ölçülen resident memory düşüşünün sentetik kayıttaki yüzde 56’lık küçülmeyle bire bir aynı olmaması bu kapsam farkından kaynaklanıyor. Dağıtım boyunca yeniden başlatılan örneklerin önbellekleri önce boş olduğundan Cloudflare ilk düşüşler yerine önbellekler dolduktan sonra oluşan kararlı seviyeleri karşılaştırdı.
Hız sonuçları da Cloudflare’ın kendi benchmark’larına ait. Tom’s Hardware’ın aktardığı ölçümlerde ekleme kapasitesi saniyede 625 bin kayıttan 893 bine çıkarak yüzde 43 arttı, arama gecikmesi ise 828 nanosaniyeden 670 nanosaniyeye inerek yüzde 19 azaldı; üretimde p99 resident memory değeri de 9,3 GB’tan 5,3 GB’a düştü.
Bellek ile hızın birlikte iyileşmesi, daha az yığın tahsisi ve verilerin birbirine daha yakın tutulmasıyla açıklanıyor. Yine de bu rakamlar uçtan uca kullanıcı DNS gecikmesini değil, önbelleğin ekleme ve arama yolunu ölçüyor. Sonucu doğrudan farklı donanımlara veya veri dağılımlarına taşımak için aynı iş yükünde yeniden ölçüm gerekir.
100 TB yeni RAM değil, yeniden kullanılabilecek kapasite
Başlıktaki “100 TB kazandı” ifadesi satın alınmış yeni bellek anlamına gelmiyor. Cloudflare’ın mevcut filosunda aynı hizmet daha küçük bir çalışma kümesiyle çalıştığı için yaklaşık 100 TB kapasite başka kullanım için serbest kaldı. Şirket fiziksel bellek yapılandırmasını küçültmek yerine bu alanı daha büyük DNS önbelleklerine ayırmayı planlıyor.
Daha büyük bir önbellek teorik olarak daha fazla yanıtın yerel tutulmasını, isabet oranının yükselmesini ve yetkili DNS sunucularına gönderilen üst akış sorgularının azalmasını sağlayabilir. Ancak şirket henüz bu sonraki kapasite artışının önbellek isabet oranına veya kullanıcıların gördüğü uçtan uca DNS gecikmesine etkisini gösteren ayrı bir üretim sonucu yayımlamadı. Şimdilik doğrulanan sonuç, beş veri yerleşimi değişikliğinin filo çalışma kümesini yaklaşık 100 TB azaltması ve şirket benchmark’larında önbellek işlemlerini hızlandırmasıdır.
Ayrıca okuyun:
Bültenimize abone olun
En son Web3, yapay zekâ ve kripto haberleri doğrudan gelen kutunuza gelsin.