Cloudflare, 1.1.1.1 DNS önbelleğini optimize ederek 100 terabayt bellek tasarrufu sağladı

Cloudflare mühendisleri, DNS önbelleğinin kullandığı belleği art arda yapılan beş depolama optimizasyonuyla yarıdan fazla azalttı. Şirketin blogunda 27 Ağustos'ta yayımlanan yazı, 1.1.1.1 genel çözümleyicisinin yanı sıra Gateway DNS, DNS Firewall ve AS112 hizmetlerini çalıştıran Big Pineapple platformunu ele alıyor.

250 milyar kayıtlık bir önbellek

Big Pineapple her an 250 milyardan fazla DNS önbellek kaydı tutuyor. Her kayıt yüzlerce veri merkezinde aynı anda bulunduğu için, kayıt başına harcanan tek bir bayt filo genelinde 250 gigabayttan fazla belleğe karşılık geliyor. Önbellekteki her öğe bir anahtar-değer çifti: anahtar neyin sorgulandığını (ad, kayıt tipi, kimlik doğrulama bayrağı, etiket) tanımlarken değer yanıtın kendisini saklıyor; answer, authority ve additional bölümleri ile oluşturma zamanı, isabet sayacı ve TTL gibi meta veriler.

Önbellek boyutu veri merkezine göre değişiyor. EDNS Client Subnet (ECS) kullanıldığında yetkili sunucular istemcinin ağına göre farklı yanıtlar döndürdüğü için Cloudflare aynı sorgunun birkaç sürümünü saklıyor.

Depolama yapısındaki beş değişiklik

Ekip etkiyi, üretim trafiğine yakın rastgele üretilmiş kayıtlarla ölçtü: %56 A, %25 AAAA ve %19 TXT; her öğede bir ile dört kayıt.

Vec ve String alanlarının Box<[T]> ve Box<str> ile değiştirilmesi capacity alanını ve büyüme için ayrılan yığın alanını ortadan kaldırıyor: alan başına 8 bayt, kayıt başına 64 bayt ve filo genelinde 15 terabayttan fazla. answer, authority ve additional bölümlerini üç ayrı liste yerine 2 baytlık ofsetlerle tek listede saklamak kayıt başına 28 bayt daha kazandırıyor. Kayıtların çoğunda owner alanı sorgulanan alan adıyla aynı olduğu için bu alan artık saklanmıyor ve ad, okuma sırasında önbellek anahtarından geri kuruluyor.

Diğer iki değişiklik Rust enum boyutlarıyla ilgili. Enum olarak saklanan kayıt verisi her zaman en büyük varyantın boyutundaydı — NAPTR için 144 bayt — oysa bir A kaydı yalnızca 4 bayt gerektiriyor, yani kayıtların çoğu 120 bayttan fazlasını boşa harcıyordu. Büyük varyantları yığına taşımak bunu çözdü ama ayırıcı yuvarlaması ve dağınık ayırmalar ekledi. Son adım, kayıt verisini 2 baytlık uzunluk önekleriyle tek bir tamponda ham tel formatında saklıyor; bu, belleksel yakınlığı geri getiriyor ve kayıtların çoğunun yanıta doğrudan kopyalanmasını sağlıyor.

Üretim sonuçları

Benchmarklarda kayıt başına hacim 953 bayttan 420 bayta (−%56), ayırmalar ise 1,1 kilobayttan 461 bayta (−%58) düştü. Ekleme hızı saniyede 625 binden 893 bin kayda (+%43) çıkarken arama gecikmesi 828 nanosaniyeden 670 nanosaniyeye (−%19) geriledi.

Dağıtım 18 Mayıs ile 6 Temmuz 2026 arasında adım adım tamamlandı. p99'da örnek başına yerleşik bellek 9,3 GB'tan 5,3 GB'a (−%43), p90'da 6,5 GB'tan 3,8 GB'a (−%42) indi. Filo genelindeki toplam çalışma kümesi belleği yaklaşık 100 terabayt azaldı; bu, Cloudflare'ın 130 adet Gen 13 sunucusundaki RAM'e denk. Şirket, serbest kalan belleği daha büyük önbelleklere yatırmayı planlıyor; bu da isabet oranını artırıp üst kaynaklara giden sorgu hacmini düşürecek.