Cloudflare, Tutarlı Hashing Algoritmasındaki Değişikliklerle 100TB RAM Geri Kazandı
Cloudflare, Pingora Backend Router'da pingora-ketama kaynaklı aşırı bellek kullanımını gidermek için tutarlı hashing algoritmasında değişiklikler yaptı. Yapı ve hash sayısı optimizasyonlarıyla küresel olarak 100TB'den fazla RAM geri kazanıldı.
Cloudflare, dünya genelinde binlerce sunucusu, petabaytlarca RAM'i ve milyonlarca CPU çekirdeği olduğunu belirtiyor. Bu ölçekte küçük iyileştirmeler bile büyük etki yaratabiliyor. Şirketin mühendislik ekibi, Pingora tabanlı bir hizmetin bellek kullanımını tek bir algoritmadaki değişikliklerle önemli ölçüde azalttı ve küresel olarak 100TB'den fazla RAM geri kazandı.
Sorunun Tespiti
Ivan, Pingora Backend Router'da (PBR) pingora-ketama kaynaklı aşırı bellek kullanımı olduğunu tespit eden bir ticket açtı. Tespit edilen aşırı bellek kullanımı bazı durumlarda 6GB'a ulaştı. PBR, önbelleğe alınabilir istekleri URL'ye göre sunuculara yönlendirmek için tutarlı hashing kullanıyor. Bu yöntem, her dosyanın yalnızca bir kopyasının bir veri merkezinde saklanmasını sağlıyor ve her dosyanın konumunu bulmak için istikrarlı bir yol sunuyor.
Uyumluluk gereksinimleri ve özellik kombinasyonları nedeniyle düzinelerce ayrı tutarlı hash halkası oluşuyor. Her özellik kombinasyonu potansiyel olarak kendi özel halkasını gerektiriyor. Bu durum, bellekte depolanması gereken çok sayıda hash'e yol açıyor.
Yapısal İyileştirmeler
Zaidoon, hash indeksini 32 bit yerine 16 bit olarak saklayan bir yapı önerdi. PBR'nin aynı anda 65 binden fazla sunucuyu koordine etmesi olası değil, bu nedenle 16 bitlik bir tamsayı yeterli. Ancak Rust'ın hizalama kuralları, bir yapının bellekteki boyutunun en büyük alanının katı olmasını gerektiriyor. Bu nedenle indeks boyutunu 16 bite düşürmek tek başına bellek kullanımını azaltmıyor.
Hash ve indeksi ham bir bayt dizisi olarak depolayan yapı değişikliği, tutarlı hashing için kullanılan belleği %25 azalttı.
Hash Sayısının Optimizasyonu
NGINX'te sunucu başına varsayılan hash sayısı 160 olarak sabitlenmiştir ve Pingora aynı değeri varsayılan olarak kullanıyor. Pingora ekibi, iş yükünü ölçeklemek için sunucu disk alanını ağırlık olarak kullanıyor. Ağırlık faktörü 625 ve temel 160 hash ile sunucu başına toplam 100.000 hash elde ediliyor.
Ancak eklenen son 90.000 hash, hata oranında yalnızca %0,7'lik bir azalma sağlıyor. Ayrıca 32 bit hash'lerde çakışma olasılığı hash sayısı arttıkça hızla yükseliyor. 2048 sunuculu veri merkezlerinde, sunucu başına 10.000 ila 100.000 hash arasında hata oranı artıyor. Bu nedenle ekip, belirgin bir hata oluşturmadan sunucu başına üretilen hash sayısını %90 azaltmaya karar verdi.
100 sunucu ve sunucu başına 160 hash kullanıldığında varyasyon katsayısı yaklaşık %99'dan yaklaşık %8'e düşüyor.
Geçiş Süreci ve Sonuç
Hash halkasını değiştirmek, bazı önbelleğe alınabilir isteklerin nereye gittiğini değiştiriyor. Geçiş sırasında PBR, eski ketama halkası ve yeni daha küçük halka olmak üzere her iki sürümü bellekte tuttu. Geçiş, önce küçük doğrulama lokasyonlarından başlayarak aşamalı olarak daha büyük veri merkezi gruplarına yayıldı.
v2 halkası sıkıştırılmış depolama formatı, daha hızlı sıralama yöntemi ve düğüm başına temel hash sayısını ölçeklendirme yeteneği sunuyor. v1 halkası pingora ketama'nın her zaman kullandığıyla aynıdır ve kütüphane her ikisini aynı anda çalıştırmaya olanak tanıyor. Tüm değişiklikler pingora-ketama crate'inde deneysel bir cargo özelliği olarak mevcut.
Yapılan değişiklikler PBR'nin kullandığı belleği 100TB azalttı. Bu, DNS ekibinin geçen ay kurtardığı 100TB belleğe ek olarak gerçekleşti.
