Cloudflare, Pingora'daki consistent hashing'i yeniden çalışarak 100TB RAM geri kazandı

Ne oldu

Cloudflare, tek bir algoritmada — Pingora tabanlı hizmetlerinden birinin içindeki consistent hashing uygulamasında — yapılan küçük değişikliklerle küresel ağında 100TB'den fazla RAM'i nasıl geri kazandığını anlatan bir mühendislik derinlemesine inceleme yayınladı. Cloudflare bloguna göre, bu tasarruf, şirketin DNS ekibinin bir ay önce elde ettiği ayrı bir 100TB'lık azaltmanın üzerine geldi.

Şirket ölçeğini açıkça ortaya koyuyor: dünya çapında binlerce sunucu, petabaytlarca RAM ve milyonlarca CPU çekirdeği, her hizmetin her düğümde çalışması bekleniyor. Bu kadar devasa kaynaklar bile sınırlı ve bu ölçekte yüzde birlik iyileştirmeler bile kutlamaya değer. Burada anlatılan değişiklik, ağa 100TB'den fazla bellek geri kazandırdı.

Her şeyi başlatan ticket

Çalışma, Ivan adlı bir mühendisin açtığı bir performans ticket'ıyla başladı. Ivan, Cloudflare'in Pingora Backend Router'ı içinde kullanılan pingora-ketama'nın beklenenden çok daha fazla bellek tükettiğini bildirdi. Backend Router — kısaca PBR — Cloudflare'in iç yük dengeleme hizmetidir ve pingora-ketama da consistent hashing için kullandığı açık kaynak kütüphanedir. O kütüphaneyle ilişkili yapılar şişkinliğin kaynağıydı.

Consistent hashing nasıl çalışır

Consistent hashing, görevleri sunucular arasında; sunucular katıldığında veya ayrıldığında büyük çaplı yeniden dağıtım yaşanmayacak şekilde dağıtır. Cloudflare bunu PBR'de önbelleğe alınabilir istekleri URL'ye göre sunuculara yönlendirmek için kullanır; bu, her dosyanın veri merkezi başına tek bir kopyasını tutmayı ve ona ulaşmak için kararlı bir yol sağlar.

Mekanizma, hash fonksiyonlarının bir özelliğine dayanır: herhangi bir girdiyi kabul ederler ama tek bir işaretsiz tamsayı üretirler — fonksiyona göre 32, 64 veya 128 bit. Blog, alışılmış ring görselleştirmesini atlıyor ve çıktı uzayını bir sayı doğrusu olarak ele alıyor. Sunucular ve görevler, temsilî değerlerin hash'lenmesiyle — sunucular için IP adresleri, görevler için cache key'ler gibi — bu doğru üzerine yerleştirilir. Bir görevi atamak, solundaki ilk sunucuyu bulmaktan ibarettir; son sunucuya ait aralık sıfıra geri sarar, ring imgesi de buradan gelir.

Dengesizlik sorunu

Hash'ler esasen rastgele sayılar olduğu için sunucuların kapsadığı aralıklar eşitsiz çıkar ve bir sunucunun hallettiği isteklerin payı, aralığının büyüklüğüyle orantılıdır. Yazı, N sunucudan birinin doğru üzerinde kapladığı payın istatistiklerini inceliyor: beklenen değer 1/N ve standart sapma, (N−1)/(N+1)'in karekökünün (1/N) katıdır.

100 sunucu için beklenen pay %1 ve standart sapma toplamın kabaca %0,99'u. Sapmayı ortalamaya göre ölçeklemek varyasyon katsayısını verir; N=100'de bu yaklaşık %99 çıkar. Somut terimlerle, bazı sunucular hakkının yaklaşık iki katı istekle uğraşırken diğerleri neredeyse hiçbir şey yapmayabilir.

Consistent hashing'in kısıtları içinde çare, daha fazla hash'tir. Her sunucu doğru üzerinde tek bir nokta yerine birden çok noktayla temsil edilir ve çok sayıdaki küçük segmentler birbirini dengeler — iş başındaki büyük sayılar yasası. NGINX temel değeri olarak sunucu başına 160 hash'i sabit kodlar ve Pingora da aynı değeri varsayılan olarak benimser. Sunucu başına 160 noktayla, 100 sunuculuk varyasyon katsayısı yaklaşık %99'dan yaklaşık %8'e düşer; yazı bunu önemli bir iyileşme olarak nitelendiriyor.

Yazının incelediği gerilim

Daha iyi denge bedava değildir: sunucu başına eklenen her nokta, Ivan'ın ticket'ında işaret ettiği ketama yapılarında saklanmak zorundadır ve PBR binlerce makineyle ölçülen bir filonun her düğümünde çalışmak zorundadır. Blog oradan devam ediyor: hash sayısı daha da arttıkça ne olduğunu soruyor ve hem ayarlamanın ardındaki olasılık hem de bellek tasarrufunu mümkün kılan Rust uygulamasıyla ilgili dersler vaat ediyor. Manşet sonuç şu: bu tek algoritmada yapılan küçük değişiklikler, hizmetin ayak izini küresel ölçekte 100TB'den fazlasını geri verecek kadar daralttı.

Neden önemli

Consistent hashing, dağıtık sistemlerin büyük bir bölümünün temelini oluşturur — CDN önbellekleri, key-value store'lar, shard'lanmış veritabanları — ve NGINX'ten devralınan 160 noktalık varsayılan yaygındır. Az operatör, bu sabitin tüm bir filo çarpıldığında bellekte gerçekte ne kadara mal olduğunu denetler; Cloudflare'in rakamları bunun devasa olabileceğini gösteriyor.

Tasarruflar ayrıca soyut bir kavram değil somut bir kapasite: ağa geri verilen 100TB, yeni donanım olmadan yeni hizmetler için bir hareket alanı demek ve karşılaştırılabilir bir DNS ekibi azaltımının hemen ardından gelmesi, yapısal israfın peşine düşülen tekrarlanabilir bir uygulama olduğunu gösteriyor.

Belki de en aktarılabilir olan şey yöntemdir: bir performans ticket'ı, beklenen ile gerçek yükün ilk ilkelerle modellenmesi ve hedefli bir algoritma değişikliği — tek bir edge ağının çok ötesine genelleşen bir mühendislik.