Cloudflare'in 100TB bellek tasarrufu nasıl gerçekleşti
Cloudflare, 1.1.1.1 DNS çözümleyici servisinin arkasında çalışan Big Pineapple cache altyapısında cache kayıtlarını 953 bayttan 420 bayta indirerek toplam 100TB RAM serbest bıraktı. Bu, şirkete yeni donanım satın almadan 768GB DDR5-6400 RAM'e sahip yaklaşık 130 Gen 13 sunucu dengi ekstra kapasite kazandırdı. Tasarruf beş Rust kod değişikliğinden geldi; tek bir gereksiz bayt bile Cloudflare'in ölçeğinde 250GB'ı aşkın kayba neden oluyor, çünkü sistemde her an 250 milyardan fazla DNS kaydı tutuluyor.
Mayıs-Temmuz 2024 arasında sahaya alınan optimizasyonlar yalnızca bellek kullanımını düşürmedi. Insert throughput 625.000 giriş/saniyeden 893.000 giriş/saniyeye çıktı (%43 artış), lookup latency 828 nanosekundeden 670 nanosekundeleye düştü (%19 azalış). Cloudflare, serbest kalan RAM'i daha büyük DNS cache'leri için kullanmayı ve cache hit oranlarını artırarak yetkili (authoritative) DNS sunucularına giden trafiği azaltmayı planlıyor.
Rust'ın Vec ve String türlerini sabit boyutlu slices ile değiştirme
Cloudflare mühendisleri Big Pineapple'ın veri yapılarını inceleyip beş kritik kod değişikliği yaptı. En etkili adım, Rust'ın dinamik boyutlu Vec ve String türlerinin sabit boyutlu boxed slice yapılarıyla değiştirilmesiydi. Bu tek değişiklik 15TB'tan fazla RAM tasarrufu sağladı.
Vec ve String, Rust'ta boyutları çalışma zamanında değişebilen koleksiyonlar. Her biri kapasite (capacity), uzunluk (length) ve veri göstericisi (pointer) için ek metadata tutar. Cloudflare'in cache kaydı yapısında bu türler, boyutları zaten tahmin edilebilen DNS verisi için kullanılıyordu; A ve AAAA kayıtları Cloudflare'in DNS trafiğinin %80'inden fazlasını oluşturuyor ve bunların boyutları sabittir. Dinamik yeniden boyutlandırma kapasitesi gereksizdi.
Mühendisler, bu koleksiyonları bellekte doğrudan ayrılmış (boxed) sabit boyutlu byte dizilerine dönüştürerek hem metadata overhead'ini hem de kullanılmayan kapasite ayırmasını ortadan kaldırdı. Bir Vec<u8>, tip üzerinde en az 24 bayt metadata taşır; sabit boyutlu bir Box<[u8]> ise sadece pointer ve uzunluk bilgisi tutar ve kapasite alanı gerektirmez. 250 milyar kayıtta bu fark terabaytlarca boşa giden belleğe dönüşüyor.
Diğer dört kod değişikliği veri hizalaması (alignment), struct padding optimizasyonları ve gereksiz field'ların kaldırılmasını içeriyordu. Toplam etki cache entry başına 533 bayt tasarruf oldu.
Bir baytın küresel ölçekte maliyeti: 250 milyar DNS kaydı
Cloudflare'in Big Pineapple sistemi şu anda 250 milyardan fazla DNS kaydını bellekte tutuyor. Bu boyut, sistemin global edge lokasyonlarına yayılan, eşzamanlı olarak güncellenen dağıtık bir cache olmasından kaynaklanıyor. Tek bir cache girdisindeki bir baytlık gereksiz kullanım, filoda 250GB'tan fazla bellek kaybına yol açıyor.
Bu ölçek etkisi yazılım mühendisliği disiplininin altyapı maliyetlerine doğrudan bağını gösteriyor. Cloudflare'in mühendisleri bu optimizasyonları yapmak için yeni donanım, yeni veri merkezi veya sermaye harcaması (CapEx) gerektirmedi; daha derine inmek için yalnızca teknik yetkinlik ve inceleme zamanı harcadı. Oysa klasik ölçekleme stratejisi artan yük veya veri hacmine yanıt olarak donanım satın almayı önerir. Cloudflare'in yaklaşımı bunun tersine mevcut donanımın CPU ve bellek kapasitesinden daha fazla değer çıkardı.
100TB RAM'in donanım cinsinden karşılığı yaklaşık 130 Gen 13 sunucuya denk gelir; her sunucu 768GB DDR5-6400 RAM taşıyor. Bu yalnızca bellek maliyeti değil: sunucu gövdesi, işlemci, güç kaynağı, ağ donanımı, raf alanı, soğutma maliyeti, datacenter kira bedeli ve işletme giderleri (OpEx) de dahil. Yazılım optimizasyonu bu maliyetleri tamamen ortadan kaldırmasa da azaltabilir.
CPU cache verimliliği ve latency azalması
Optimizasyon, sadece bellek tasarrufu getirmedi; performans metriklerini de iyileştirdi. Insert throughput %43 artarak 893.000 giriş/saniyeye çıktı; lookup latency 828 nanosekundeden 670 nanosekundeleye (%19 düşüş) geriledi.
Daha küçük cache girdileri, CPU cache'lerinde daha fazla veri sığmasını sağlıyor. Modern işlemciler sık kullanılan verileri L1, L2 ve L3 cache'lerinde tutar; bu önbelleklere erişim ana RAM erişiminden yüzlerce kat daha hızlıdır. 953 baytlık bir cache entry, L1/L2'ye sığmayan daha büyük bir cache line kaplıyor; 420 baytlık entry daha verimli sığıyor ve daha çok entry'nin CPU cache'inde kalmasını mümkün kılıyor. Bu lookup sırasında RAM'e gitme sıklığını azaltıp latency'yi düşürüyor.
Insert throughput artışı bellek allocation overhead'inin azalmasından geliyor. Dinamik Vec ve String türleri büyürken yeni bellek allocation çağrıları yapar; sabit boyutlu diziler ise tek bir allocation ile işini halleder. Allocation manuel bellek yönetimine sahip dillerde bile CPU ve lock contention maliyeti taşır; bunu azaltmak throughput'u artırır.
Freed RAM'i nasıl kullanacak: daha büyük cache ve hit rate iyileştirmesi
Cloudflare, serbest bıraktığı 100TB belleği boş bırakmayı planlamıyor. Bu kaynağı daha büyük DNS cache'leri için kullanarak cache hit rate'i artırmayı ve yetkili (authoritative) DNS sunucularına gitmesi gereken trafik miktarını azaltmayı hedefliyor.
Cache hit rate, bir DNS çözümleyicinin bellekteki yanıtı doğrudan sunabilme oranıdır. Hit olduğunda, Cloudflare yanıtı nanosaniyeler içinde verir; miss olduğunda kaydı upstream authoritative sunucudan alması gerekir ve bu milisaniyeler sürebilir. Cache'in kapasitesi arttıkça, daha fazla kayıt bellekte kalır ve hit rate yükselir; bu hem latency'yi düşürür hem de upstream sunuculara yük bindirmez.
Büyük cache'ler ayrıca DDoS saldırılarına karşı dayanıklılığı artırır. Cloudflare saldırganların binlerce domain için eşzamanlı DNS sorguları gönderdiği DNS amplification saldırılarına sık maruz kalıyor. Bellekteki cache ne kadar büyükse, upstream sunuculara yönlendirilen query oranı o kadar az olur; bu da authoritative sunucuları yükten korur.
Yazılım optimizasyonu neden donanım satın almaktan daha etkili oldu
Cloudflare'in başarısı yazılım optimizasyonunun bazen donanım satın almaktan daha etkili olabileceğini gösteriyor. Ancak bu strateji her koşulda doğru değil. Cloudflare gibi global ölçekte çalışan şirketler için ufak optimizasyonlar dev tasarruf getirir; ölçek her baytı milyarlarca kez çarpar. Daha küçük sistemlerde mühendislik zamanı maliyeti genellikle tasarruftan fazladır.
Cloudflare'in durumunda Big Pineapple zaten merkezi bir kod tabanı; optimizasyonlar bir kez yapılıp tüm edge node'larına yayılıyor. Ölçekte tekrarlanabilirlik yazılım optimizasyonunun ekonomik anlamını güçlendiriyor.
Donanım satın almanın gizli maliyetleri de vardır. Yeni sunucular satın alma fiyatının ötesinde güç tüketimi, soğutma, ağ bağlantısı, fiziksel yer ve bakım maliyeti gerektirir. Cloudflare gibi şirketler için elektrik faturası OpEx bütçesinin büyük bir kısmını oluşturur. Yazılım optimizasyonu bu maliyetleri tamamen ortadan kaldırmasa da azaltabilir.
Yazılım optimizasyonu risksiz değil. Kod değişiklikleri hata riski taşır; bellekte daha sıkı yapılar kullanmak buffer overflow veya memory corruption riskini artırabilir. Cloudflare'in Rust kullanması bu riski önemli ölçüde azaltıyor; Rust derleyicisi bellek güvenliği hatalarını derleme zamanında yakalar. C veya C++ ile benzer bir optimizasyonu yapmak çok daha tehlikeli olabilirdi.
