Cloudflare, 1.1.1.1, Gateway DNS, DNS Firewall, AS112 ve diğer bazı DNS hizmetlerini çalıştıran Big Pineapple platformundaki DNS deposunda gerçekleştirilen bir dizi düşük seviyeli iyileştirmenin sonuçlarını açıkladı. Platform herhangi bir anda 250 milyardan fazla DNS girdisi depoluyor; bu nedenle giriş başına bir baytın ortadan kaldırılması, filo genelinde 250 gigabayttan fazla bellek tasarrufu sağlıyor.
Rust ile yazılmış veri yapısında art arda yapılan beş değişiklik, tek bir girişin boyutunu 953 bayttan 420 bayta, yani %56 oranında düşürdü. Değişikliklerin genel kullanıma sunulmasının ardından Cloudflare filosunda kullanılan çalışma kümesinin belleği yaklaşık 100 terabayt azaldı; üstelik performanstan ödün verilmedi: giriş ekleme hızı %43 arttı ve depo arama süresi %19 azaldı.
DNS girişinin boyutu neden önemliydi?
Big Pineapple çalıştırıldığında boş bir depoyla başlar, ardından sorgular geldikçe depo dolar ve kapasite sınırına ulaştığında en eski veya en az kullanılan girişler kaldırılır. Deponun boyutu veri merkezlerine göre değişir. Ayrıca EDNS Client Subnet kullanımı, authoritative sunucular istemcinin ağına göre farklı yanıtlar sunabildiğinden, aynı sorgu için birden fazla yanıtın depolanmasına yol açabilir.
Her giriş; alan adını, kayıt türünü ve bazı özellikleri belirleyen bir anahtardan ve DNS yanıtını, authority ve additional bölümlerini, ayrıca oluşturulma zamanı, kullanım sayacı ve TTL süresi gibi meta verileri içeren bir değerden oluşur. Bu ölçekte, fazladan alanlar veya ayrılmış alan artık küçük iç ayrıntılar olmaktan çıkar ve devasa bir operasyonel maliyete dönüşür.
Tasarruflar nereden geldi?
Cloudflare, yanıt depolandıktan sonra veriler daha sonra değiştirilmediği için büyüyebilen Vec ve String yapılarını sabit yapılar olan Box<[T]> ve Box<str> ile değiştirdi. Bu değişiklik, büyüyebilen yapıların tuttuğu kapasite alanını ortadan kaldırdı ve kullanılmayan ayrılmış alanı da sınırladı. Her giriş bu türden sekiz alan içerdiğinden, giriş başına 64 bayt tasarruf edildi; bu da tüm depo genelinde 15 terabayttan fazla tasarruf anlamına geliyor.
Yanıt, authority ve additional bölümlerinin listeleri de tek bir listede birleştirildi; daha büyük işaretçiler ve uzunluklar yerine u16 türünde uzaklıklar kullanıldı. Bu sayede giriş başına 28 bayt tasarruf edildi. Yapı ayrıca birden fazla mantıksal alanı tek bir bitflag içinde birleştirmekten yararlandı ve böylece Rust'ın yapılar içinde zorunlu kıldığı bellek hizalamasından kaynaklanan israfı azalttı.
Çoğu DNS kaydında kaydın sahibi, sorgulanan alan adıyla aynıdır. Bu nedenle Cloudflare, bu durumlarda sahibin adını artık tam olarak saklamıyor; yanıt oluşturulurken adı depolama anahtarından geri elde ediyor. CNAME kayıtlarında olduğu gibi ad farklı olduğunda ise tam ad depolanıyor. Böylece sahip adlarının çoğu için bellek tahsisleri ortadan kaldırılırken, ada gerçekten ihtiyaç duyulan durumlar korunuyor.
Büyük kayıt türlerinin maliyetini azaltmak
RecordData yapısı, etiket ve hizalama hesaba katıldığında 144 baytlık en büyük kayıt türü olan NAPTR'nin boyutuna eşit bir enum kullanıyordu. Bunun sonucunda yalnızca 4 bayta ihtiyaç duyan A kayıtları ve 16 bayta ihtiyaç duyan AAAA kayıtları, ihtiyaçlarından çok daha fazla alan kaplıyordu; oysa A ve AAAA, test trafiğinin %80'inden fazlasını oluşturuyordu.
Büyük türleri ayrı bir Box içine yerleştirme yöntemi denendi. Bu, A ve AAAA kayıtlarındaki israfı azalttı; ancak ayrı tahsisler ve bellek yerelliğiyle ilgili sorunlar ekledi. Nihai çözüm, kayıt verilerini her kayıt için iki baytlık uzunluk önekiyle birlikte Box<[u8]> içinde bitişik ham baytlar olarak depolamak oldu. Bu yöntem enum maliyetini ve çoklu tahsisleri ortadan kaldırdı ve işlemcinin depolama önbelleğinden yararlanmasını iyileştirdi.
Bu tercih, kayıtların artık rastgele indekslenememesi ve bunun yerine sıralı olarak taranması anlamına geliyor. Cloudflare, tek bir girişteki kayıt sayısı az olduğu için maliyetin sınırlı olduğunu belirtiyor. A, AAAA, TXT ve DNSSEC kayıtları da dahil olmak üzere türlerin çoğu doğrudan giden DNS mesajına kopyalanabilir. Buna karşılık CNAME, NS, MX ve SOA gibi alan adları içeren türlerin, DNS ad sıkıştırmasının uygulanabilmesi için hâlâ ayrıştırılması gerekiyor.
Pratikte ne değişti?
Üretim ölçümleri, 99. yüzdelik dilimde yerleşik belleğin 9,3 gigabayttan 5,3 gigabayta, yani %43 oranında düştüğünü; 90. yüzdelik dilimde ise 6,5 gigabayttan 3,8 gigabayta, yani %42 oranında azaldığını gösterdi. Giriş başına tahsisler 1,1 kilobayttan 461 bayta düşerken, ekleme hızı saniyede 625 bin girişten 893 bine yükseldi ve arama süresi 828 nanosaniyeden 670 nanosaniyeye geriledi.
Değişikliklerin kullanıma sunulması 18 Mayıs 2026'da başladı ve tüm hizmetlerde 6 Temmuz 2026'da tamamlandı. Cloudflare, üretimdeki yerleşik belleğin deponun yanı sıra başka verileri de içerdiğini, bu nedenle işlem düzeyindeki gerçek düşüş oranının giriş başına yapılan yalıtılmış ölçümün sonucundan daha düşük olduğunu belirtiyor. Şirket ayrıca, bellek tüketimini artırmadan depo kapasitesini yükseltmek ve önbellek isabet oranlarını iyileştirerek üst düzey sunuculara gönderilen sorguları azaltmak amacıyla serbest kalan belleği yeniden kullanmayı planlıyor.
Bu örneğin önemi, hizmet yüz milyarlarca öğe üzerinde çalışırken gereksiz kapasitenin kaldırılması, tahsislerin birleştirilmesi ve yerelliğin iyileştirilmesi gibi veri yapısı optimizasyonlarının doğrudan ek donanım kaynakları eklemekten daha büyük bir etki yaratabileceğini göstermesinde yatıyor. Ancak bazı ödünleşimler sürüyor: ham depolama kayıtlarla çalışmayı daha karmaşık hâle getiriyor, sahip adlarının yeniden oluşturulması için depolama anahtarından geri alma işlemi gerekli oluyor ve test sonuçları, üretimle tamamen örtüşmeyen belirli bir trafik karışımına dayanıyor. Bu nedenle, bu tür iyileştirmeler değerlendirilirken en önemli referans yalnızca teorik rakamlar değil, üretim ölçümleri olmaya devam ediyor.