Cloudflare, Pingora Backend Router (PBR) hizmetindeki istek dağıtım algoritmasının bir bölümünü yeniden tasarladıktan sonra küresel ağında 100 terabayttan fazla RAM kurtarmayı başardı. İyileşme; hash noktalarının temsilinin sıkıştırılması, istatistiksel analize dayanarak noktaların sayısının azaltılması ve önbellekleme ile origin sunuculara yönelik trafiğin istikrarını koruyan kademeli bir geçişin birleşiminden kaynaklandı.
İstek dağıtımındaki sorun
Cloudflare, consistent hashing uygulamak için pingora-ketama kütüphanesini kullanıyor. Bu yöntem, önbelleğe alınabilir isteklerin mümkün olduğunca aynı sunucuya yönlendirilmesine yardımcı oluyor. Böylece dosyanın tek bir kopyası veri merkezinde tutulabiliyor ve dosyaya erişim için istikrarlı bir yol sağlanıyor.
Ancak her sunucu için tek bir hash noktası kullanılması, sunucuların hash halkasında sahip olduğu aralıkların boyutlarında büyük farklılıklara ve dolayısıyla iş yüklerinde dengesizliğe yol açabilir. Bu nedenle Pingora, depolama kapasitesiyle bağlantılı ağırlıklarla birlikte her sunucu için çok sayıda sanal hash kullanıyor; ayrıca farklı özellik ve kısıt grupları için ayrı halkalar oluşturuluyor. Bu halkaların birikmesi, bazı durumlarda işlem başına 6 gigabayta kadar bellek tüketimine yol açtı.
Veri temsilini iyileştirme ve hash sayısını azaltma
Halkadaki her noktayı temsil eden öğe, 32 bitlik bir hash değeri ve sunucuya yönelik 32 bitlik bir işaretçiden oluşuyordu; bu da bellekte sekiz bayt anlamına geliyordu. Cloudflare ekibi, hizmet aynı anda yaklaşık 65 bin sunucudan fazlasını düzenlemeyeceği için işaretçinin pratikte 16 bitten fazlasına ihtiyaç duymadığını gördü.
Rust'taki hizalama kuralları nedeniyle işaretçi türünü küçültmek tek başına yeterli olmadı; yapı yine sekiz bayt boyutunda kalacaktı. Bu nedenle Cloudflare, değeri ve işaretçiyi altı baytlık ham bir dizi içinde depolamaya ve her birine erişim sağlayan işlevler kullanmaya geçti. Bu değişiklik, hash'e ayrılan bellek tüketimini %25 oranında azalttı.
Daha büyük kazanım ise hash sayısının gözden geçirilmesiyle elde edildi. Hizmet, depolama kapasitesiyle bağlantılı sunucu ağırlığıyla çarpılan, sunucu başına 160 noktalık temel bir değer kullanıyordu. Analiz, hash sayısındaki büyük artışların hata payında azalan bir iyileşme sağladığını gösterdi; Cloudflare'ın ele aldığı örnekte son 90 bin hash'in eklenmesi hatayı yalnızca yaklaşık %0,7 azalttı.
Ayrıca 32 bitlik hash değerlerinin kullanılması, nokta sayısı arttıkça çakışmaları daha olası hâle getiriyor ve bu da dağıtıma beklenmedik bir hata ekleyebiliyor. Hesaplamalar ve simülasyonlar doğrultusunda Cloudflare, hata oranında gözle görülür bir artış olmadan sunucu başına hash sayısını %90 azalttı; bu da nihai tasarruflara katkıda bulundu.
Pratikte ne değişiyor?
Hash halkasını ağ genelinde tek seferde değiştirmek güvenli bir seçenek değildi; çünkü bu işlem istekleri yeniden dağıtacak ve önbelleklemenin etkinliğinin büyük bölümünün fiilen kaybedilmesine, ayrıca origin sunuculara yönelik trafiğin artmasına yol açabilecekti. Bu nedenle PBR, eski ve yeni halkaları geçici olarak bellekte tuttu ve her istek için bunlardan birini seçti; böylece net bir geri dönüş yolu sağlandı.
Geçiş, önce küçük doğrulama noktaları, ardından daha büyük veri merkezleriyle aşamalı olarak gerçekleştirildi. Yeni halkayı kullanan isteklerin oranının kontrolü, katılmasına izin verilen veri merkezlerinin belirlenmesinden de ayrıldı. Cloudflare; eski yol kaldırılmadan önce sunucu seçiminin etkilerini, halka sürümlerini, bağlantı hatalarını, bellek tüketimini, başlangıç süresini, önbellekleme davranışını ve origin sunuculara yönelik trafiği izledi.
Mühendislik açısından anlamı
Bu deneyim, bir veri yapısındaki alanın boyutunu seçmek veya uygun hash noktası sayısını belirlemek gibi düşük seviyeli iyileştirmelerin, binlerce sunucudan oluşan bir ağa uygulandığında etkilerinin büyüyebileceğini gösteriyor. Bununla birlikte sonuç, bellek azaltmanın her sistemde güvenli olduğu anlamına gelmiyor; dağıtım doğruluğu, çakışma olasılıkları, sunucu ağırlıkları, özellik kısıtlamaları ve geçişin uygulanma biçimi, değişiklikten önce ölçülmesi gereken faktörlerin tümünü oluşturuyor.
Değişiklikler, şu anda duyurulmamış bir Cargo özelliği aracılığıyla pingora-ketama paketinde kullanıma sunuldu. v2 sürümü sıkıştırılmış depolama biçimini, daha hızlı bir sıralama yöntemini ve temel hash sayısını ayarlama olanağını destekliyor; ayrıca v1 sürümünü koruyor, iki halkanın birlikte çalıştırılmasına ve kararın istek düzeyinde verilmesine olanak tanıyor.