Cloudflare 100 TB RAM Tasarrufu Sağladı: Sunucu Hash'lerini %90 Azalttı

Bellek Optimizasyonunda Yeni Bir Başarı Hikayesi

Cloudflare, geçtiğimiz günlerde 100 TB RAM tasarrufu sağladığını duyurmuştu; bu kez aynı başarıyı farklı bir yöntemle tekrarladı. Şirket, bu kez hız optimizasyonu yerine bellek optimizasyonuna odaklanarak hash haritalama algoritmasını yeniden düzenledi. Tom's Hardware'in haberine göre, Cloudflare mühendisleri sunucu başına kullanılan hash sayısını 100.000'den 10.000'e indirerek ciddi bir bellek şişkinliğinin önüne geçti.

Cloudflare'in en büyük iş kollarından biri veri önbellekleme. Yani bir URL'yi canlı siteden çekmek yerine doğrudan bellekten veya diskten sunmak. Bu işlem için şirket, kendi geliştirdiği açık kaynaklı Pingora çerçevesini ve Ketama algoritmasını kullanıyor. Amaç basit görünse de, arka uç sunucularının sürekli devreye girip çıktığı bir ortamda bu iş oldukça karmaşık bir hal alıyor.

Hash Haritalama Neden Bu Kadar Bellek Yiyor?

Gelen bir URL, tıpkı dosyalarda CRC-32 gibi bir hash işlemine tabi tutuluyor ve elde edilen sayı bir sunucuya yönlendiriliyor. İlk akla gelen yöntem, her URL'yi sırayla bir sunucuya atamak. Ancak burada ilk sorun ortaya çıkıyor: Aynı URL'ler her zaman aynı sunucuya gitmiyor. Çözüm olarak sunucunun IP adresi ve ismiyle bir hash oluşturulup, iki hash sayısal yakınlığa göre eşleştiriliyor. Bu yöntem, URL hash'lerinin dağılımı rastgele olduğu için adil bir yönlendirme sağlıyor.

Fakat ikinci sorun kapıda: Diyelim ki dört sunucunuz var ve her biri isteklerin %25'ini karşılıyor. 2 numaralı sunucu birinin güç kablosuna takılması sonucu devre dışı kalırsa, onun üzerindeki yük hash haritasında en yakın sunucuya, yani 3 numaraya kayıyor. Bu da 3 numaralı sunucunun aşırı yüklenmesine, 1 ve 4'ün ise boş kalmasına neden oluyor. Çözüm, her sunucu için birden fazla hash ekleyip bunları rastgele karıştırmak. Böylece bir sunucu çöktüğünde yük kalan sunuculara eşit dağılıyor.

100.000 Hash'ten 10.000'e: Azalan Verim Noktası

Ancak bu yöntem ciddi bellek tüketiyor. Üstelik ağırlık kuralları (büyük sunucuların daha fazla istek alması) ve içerik kısıtlamaları nedeniyle her sunucunun her isteği karşılayamaması gibi etkenlerle birlikte iş daha da içinden çıkılmaz hale geliyor. Cloudflare, makine başına 100.000'e kadar sunucu hash'i çalıştırıyordu ve bu da RAM gereksinimlerini şişiriyordu.

Cloudflare mühendisleri, biraz cebir ve temel istatistik uygulayarak 100.000 hash'in azalan verim noktasını çoktan aştığını fark etti. Yapılan hesaplamalara göre, bu sayının sadece %10'u neredeyse aynı sonuçları veriyordu; çünkü 10.000'in üzerindeki her kat artışta hata oranı neredeyse hiç düşmüyordu. Ekip ayrıca Rust veri yapılarını ustalıkla düzenleyerek hash-sunucu haritasındaki her giriş için 2 bayt tasarruf sağladı. Kulağa önemsiz gelse de milyarlarca kayıtla bu tasarruf hızla büyüyor.

Tüm bunların sonucunda Cloudflare ekibi toplamda yaklaşık 100 TB RAM tasarrufu elde etti. Güvenli tarafta kalmak için ekip, bu "v2" algoritmasını mevcut kodun yerine koymak yerine ayrı bir kod yolu olarak ekledi. Böylece bir sorun çıkarsa tek bir hamleyle eski algoritmaya dönülebiliyor.

Bu optimizasyon, yazılım dünyasında kaynak kullanımının ne kadar akıllıca yönetilebileceğinin çarpıcı bir örneği. Keşke tüm modern yazılımlar kaynak kullanımı konusunda bu kadar özenli olsa.