Dropbox’un şirket içi yük dengeleme hizmeti Robinhood

• Robinhood, Dropbox’un şirket içi yük dengeleme hizmetidir ve 2020’de devreye alındı
• Sunucular arasındaki iç trafiği yönlendirerek hizmet yükünü dengeli biçimde dağıtır
• Robinhood’dan önce Dropbox hizmetlerinin çoğu, backend’ler arasında dengesiz yük dağılımı nedeniyle zorluk yaşıyordu
• Donanım farklılıkları ve önceki yük dengeleme algoritmalarının sınırlamaları nedeniyle, aşırı yüklenen instance’ların yol açtığı güvenilirlik sorunları ortaya çıkıyordu
• Bunu çözmek için hizmet filosunu gereğinden fazla provision etmek gerekiyordu ve bu da donanım maliyetlerini artırıyordu

Robinhood’un yeni özellikleri

• PID(Proportional-Integral-Derivative) denetleyicisi kullanılarak yük dengesizliği daha hızlı ve etkili şekilde yönetilebilir hale geldi
• Bu, altyapı güvenilirliğinde iyileşme ve önemli ölçüde donanım maliyeti tasarrufu sağladı
• En yeni akıllı özellikleri çalıştıran yapay zeka iş yükleri arttıkça, GPU kaynaklarına olan talebin etkili şekilde yönetilmesi her zamankinden daha önemli hale geliyor

Dropbox’ta yük dengeleme zorlukları

• Dropbox’un hizmet keşif sistemi, dünya genelindeki birden fazla veri merkezine yayılmış yüz binlerce host’a ölçeklenebiliyor
• Bazı Dropbox hizmetlerinin milyonlarca istemcisi var, ancak her istemcinin tüm sunucu instance’larına bağlanmasına izin verilemez
  • Çünkü bu, sunucular üzerinde çok fazla bellek baskısı oluşturur ve sunucu yeniden başlatmalarında TLS handshake nedeniyle sunucuların aşırı yüklenmesine yol açabilir
• Bunun yerine, her istemciye bağlanacağı sunucu alt kümesini hizmet keşif sistemi sağlar
• İstemcilerin kullanabileceği en iyi yük dengeleme stratejisi, hizmet keşif sisteminin sağladığı adres listesini round robin ile dolaşmaktır
  • Ancak bu yöntemle her sunucu instance’ındaki yük oldukça dengesiz olabilir
  • Alt küme boyutunu artırmak kolay bir hafifletme yöntemidir, ancak dengesizliği tamamen ortadan kaldırmaz ve hizmet sahiplerine sadece ek bir parametre sunar
• Daha derin sorun, her sunucuya aynı sayıda istek gönderilse bile alttaki donanımın sunucudan sunucuya farklı olabilmesidir
  • Yani istekler, farklı donanım sınıflarında farklı miktarda kaynak tüketir
• Temel sorun, istemcilerin sunucu yükü üzerinde görünürlüğe sahip olmamasıdır
• Geçmişte bu sorunu çözmek için sunucuların yanıt başlıklarına yük bilgisini eklemesi denenmişti
  • İstemciler, adres alt kümesi içindeki en az yüklü endpoint’i seçerek yük dengelemeyi kendileri yapabiliyordu
  • Sonuçlar umut vericiydi, ancak hâlâ bazı dezavantajlar vardı
    • Özel yük header’ı için hem sunucu hem istemci tarafında kod değişikliği gerektiğinden küresel çapta benimsenmesi zordu
    • Sonuçlar iyiydi, ama yeterince iyi değildi

Robinhood’u geliştirme kararı

• 2019’da Robinhood’u geliştirme kararı resmen alındı
• Bu yeni hizmet, mevcut şirket içi hizmet keşif sistemi üzerine inşa edildi; sunuculardan yük bilgisi topluyor ve bunu yönlendirme bilgisine ekliyor
• Robinhood, Envoy’un Endpoint Discovery Service özelliğini kullanarak yük bilgisini endpoint ağırlıklarına entegre ediyor; böylece istemciler ağırlıklı round robin uygulayabiliyor
• gRPC topluluğu Envoy xDS protokolünü benimsediği için Robinhood hem Envoy hem de gRPC istemcileriyle uyumlu
• O dönemde Dropbox’un gereksinimlerini karşılayan mevcut bir yük dengeleme çözümü bulunmadığından yeni bir hizmet geliştirmeye karar verildi

Robinhood’un sonuçları

• Üretim ortamında birkaç yıl kullanıldıktan sonra umut verici sonuçlar gösterdi
• Bazı büyük ölçekli hizmetlerde filo boyutunu %25 azaltmayı başardı ve bu da her yıl önemli donanım maliyeti tasarrufu sağladı
• Aşırı kullanılan süreçlerin azalmasıyla güvenilirlik de arttı

Robinhood’un mimarisi

• Her veri merkezine bir Robinhood instance’ı dağıtılır ve sistem üç bölümden oluşur: yük dengeleme hizmeti, proxy ve yönlendirme veritabanı

Yük dengeleme hizmeti (LBS)

• Robinhood’un çekirdeğidir
• Yük bilgisi toplar ve endpoint ağırlıklarını içeren yönlendirme bilgisi üretir
• Birden fazla instance aynı anda bir hizmetin yönlendirme bilgisini güncellediği için, her hizmet için birincil worker atamak amacıyla dahili bir shard manager kullanır
• Her hizmet bağımsız olduğundan LBS, hizmet bazında bölünebilir ve yatay olarak ölçeklenebilir

Proxy

• Hizmetlerin yük bilgisini veri merkezi içindeki ilgili LBS partition’ına yönlendirmekle görevlidir
• Proxy kullanımı, doğrudan LBS süreçlerine bağlanan bağlantı sayısını da azaltır
  • Proxy olmasa tüm LBS süreçlerinin altyapıdaki tüm düğümlere bağlanması gerekirdi
  • Bunun yerine LBS süreçleri yalnızca proxy’lere bağlandığından LBS üzerindeki bellek baskısı büyük ölçüde azalır
• Proxy yalnızca aynı veri merkezi içindeki düğümlere bağlandığı için yatay olarak ölçeklenebilir
• Bu desen, hizmetleri çok fazla TLS bağlantısı almaktan korumak için altyapının birçok yerinde kullanılır

Yönlendirme veritabanı

• Host adı, IP adresi ve LBS’nin ürettiği ağırlıklar gibi hizmete ait yönlendirme bilgilerini saklayan ZooKeeper/etcd tabanlı bir veritabanıdır
• ZooKeeper ve etcd, düğüm/anahtar değişikliklerini gerçek zamanlı olarak tüm watcher’lara bildirebilir ve Dropbox’un okuma ağırlıklı hizmet keşfi kullanım senaryosuna çok uygundur
• ZooKeeper/etcd’nin sağladığı eventual consistency, hizmet keşfi için de yeterlidir

Yük dengeleme hizmetine daha yakından bakış

• Yük dengelemenin amacı, tüm düğümlerin kullanım oranını ortalama kullanım oranına eşitlemektir
• PID denetleyicisi kullanılarak her düğümün kullanım oranı ortalama kullanım oranına neredeyse eşit tutulur
• LBS, her düğüm için bir PID denetleyicisi oluşturur ve ortalama kullanım oranını setpoint olarak kullanır
• LBS, PID denetleyicisinin çıktısını endpoint ağırlıkları için delta olarak kullanır ve hizmetin tüm endpoint’leri arasında ağırlıkları normalize eder
• Yeni düğümlerin ortalama kullanım oranına yakınsaması için birkaç ayarlama gerekse de PID denetleyicisi yük dengelemede oldukça etkilidir

LBS çalışma senaryoları

• LBS, düğüm yeniden başlatmalarından yük raporlarının eksik gelmesine kadar yük dengelemeyi etkileyebilecek çeşitli senaryoları ele alacak şekilde tasarlanmıştır
• En iyi performansı korumak için LBS, bu istisnai durumları ele alan çeşitli stratejiler uygular

LBS başlangıcı

• LBS, yük bilgisini ve PID denetleyicisi durumunu bellekte tutar
• LBS yeniden başlatılırken, yük raporları gelene kadar hemen ağırlık güncellemesine başlamaz ve kısa bir süre bekler
• PID denetleyicisi ağırlıkları için LBS, endpoint ağırlıklarını yönlendirme veritabanından okuyarak geri yükler

Cold Start düğümleri

• Hizmet filosuna sık sık yeni düğümler katıldığından, Thundering Herd sorununu önlemek önemlidir
• Yeni düğümlerin başlangıç kullanım oranı genellikle 0 olduğundan LBS, yeni düğümlerin ağırlığını düşük bir endpoint ağırlığına ayarlar ve PID denetleyicisinin düğümü ortalama kullanım oranına çekmesini sağlar

Eksik yük raporları

• Dağıtık sistem ortamlarında arızalar yaygındır
• Ağ tıkanıklığı veya donanım arızası nedeniyle bazı düğümlerin yük raporları gecikebilir ya da hiç ulaşmayabilir
• LBS, ağırlık güncellemesi sırasında bu düğümleri atlar; dolayısıyla bu düğümlerin endpoint ağırlıkları değişmez
• Ancak çok sayıda yük raporu eksikse ortalama kullanım oranı hesabı hatalı olabilir
• Güvenlik için LBS bu durumda ağırlık güncelleme adımını tamamen atlar

Kullanım oranı metrikleri

• CPU kullanım oranı, Dropbox’ta en yaygın kullanılan yük dengeleme metriğidir
• CPU’nun darboğaz oluşturmadığı hizmetlerde, devam eden istek sayısı iyi bir alternatif ölçümdür
• LBS, CPU ve/veya devam eden istek sayısına dayalı yük dengelemeyi destekleyecek şekilde uygulanmıştır

Sınırlamalar

• PID denetleyicisi, düğümün kullanım oranını hedef değere (ortalama kullanım oranı) yakın tutmak için bir geri besleme döngüsü oluşturur
• Trafiği çok düşük olan hizmetlerde veya dakikalar düzeyinde ölçülen çok yüksek gecikmeli isteklerde olduğu gibi geri beslemenin neredeyse hiç olmadığı durumlarda yük dengeleme etkili olmaz
• Yüksek gecikmeli istekleri olan hizmetler asenkron olmalıdır

Veri merkezleri arası yönlendirme

• LBS instance’ları veri merkezi içindeki yük dengelemeyi yönetir
• Veri merkezleri arası yönlendirmede farklı hususlar vardır
  • Örneğin, isteklerin gidiş-dönüş süresini azaltmak için istekleri en yakın veri merkezine yönlendirmek istenir
• Bunun için, hedef veri merkezleri arasındaki trafik bölüşümünü tanımlayan bir locality yapılandırması kullanılır

Yük dengeleyici performans değerlendirmesi

• Yük dengeleme performansı max/avg oranıyla ölçülür
  • Hizmet sahibi CPU tabanlı yük dengelemeyi seçerse performans metriği olarak maxCPU/avgCPU kullanılır
  • Bunun nedeni, hizmet sahiplerinin genellikle hizmeti düğümler arasındaki en yüksek kullanım oranına göre provision etmesi ve yük dengelemenin temel amacının filo boyutunu küçültmek olmasıdır
• PID denetleyici yük dengeleme stratejisi, max/avg oranını 1'e yakın tutabilir

Yük dengeleme performans değerlendirme grafikleri

• Envoy proxy kümeleri içindeki en büyük kümenin max/avg CPU ve p95/avg CPU değerlerini gösteren grafik
  • PID denetleyici tabanlı yük dengeleme etkinleştirildikten sonra her iki metrik de 1'e yakın seviyeye düştü
  • max/avg oranı 1,26'dan 1,01'e düşerek %20 iyileşme gösterdi
• Düğüm bazında CPU kullanım oranının yüzdelik analizini gösteren grafik
  • PID denetleyici tabanlı yük dengeleme etkinleştirildikten sonra max, p95, avg ve p5 neredeyse tek bir çizgide birleşti
• Veritabanı frontend kümeleri içindeki en büyük kümenin max/avg CPU ve p95/avg CPU değerlerini gösteren başka bir grafik
  • PID denetleyici tabanlı yük dengeleme etkinleştirildikten sonra her iki metrik de 1'e yakın seviyeye düştü
  • max/avg oranı 1,4'ten 1,05'e düşerek %25 iyileşme gösterdi
• Düğüm bazında CPU kullanım oranının yüzdelik analizini gösteren bir başka grafik
  • PID denetleyici tabanlı yük dengeleme etkinleştirildikten sonra max, p95, avg ve p5 bir kez daha neredeyse tek bir çizgide birleşti

Config Aggregator neden oluşturuldu

• Robinhood, hizmet sahiplerinin seçebileceği birden fazla seçenek sunar ve değişiklikleri dinamik olarak da uygulayabilir
• Hizmet sahipleri, kod tabanındaki hizmet dizininde kendi hizmetleri için Robinhood yapılandırmasını oluşturur ve günceller
• Bu ayarlar, Robinhood yapılandırmasındaki değişiklikleri gerçek zamanlı alan kullanışlı bir kütüphane olan yapılandırma yönetim hizmetinde saklanır
• Ancak bazı sorunlar nedeniyle kod tabanından Robinhood'un mega yapılandırmasını düzenli olarak derleyip göndermek mümkün değildir
  • Yapılandırma gönderimiyle bir değişiklik geldiğinde rollback düğmesine basmak risklidir
    • Çünkü son gönderimden sonra başka kaç hizmetin değiştiği bilinmez
  • Robinhood'dan sorumlu ekip, her mega yapılandırma gönderiminden de sorumludur
    • Bu da Robinhood ekibinin tüm değişiklik yapılandırması gönderimlerine dahil olması gerektiği anlamına gelir ve mühendislik zamanının boşa harcanmasına yol açar
    • Çünkü çoğu incident, hizmet sahibi tarafından çözülebilir
  • Olası riski en aza indirmek için her gönderimin birden fazla veri merkezine dağıtılması saatler alır
• Bu sorunları çözmek için Config Aggregator adlı başka bir küçük hizmet oluşturuldu

Config Aggregator

• Config Aggregator, hizmet bazlı tüm yapılandırmaları toplar ve LBS'nin kullanacağı mega yapılandırmayı oluşturur
• Config Aggregator, hizmet bazlı yapılandırmaları izler ve değişiklikleri gerçek zamanlı olarak mega yapılandırmaya yansıtır
• Config Aggregator ayrıca bir hizmetin Robinhood yapılandırmasının yanlışlıkla silinmesini önlemek için tombstone özelliği de sunar
  • Hizmet sahibi Robinhood yapılandırmasından bir hizmeti silen bir değişikliği gönderdiğinde Config Aggregator, hizmet girdisini hemen kaldırmak yerine tombstone ile işaretler
  • Gerçek kaldırma işlemi birkaç gün sonra gerçekleşir
  • Bu özellik ayrıca Robinhood yapılandırması ile diğer routing yapılandırmaları (örneğin Envoy yapılandırması) arasındaki farklı gönderim döngülerinden kaynaklanabilecek race condition sorununu da çözer
• Yapılandırma yönetim hizmetinin dezavantajı, şu anda sürüm kontrolüne sahip olmamasıdır
• LBS yapılandırmasının bilinen iyi bir duruma geri döndürülmesi gerekirse diye mega yapılandırma periyodik olarak yedeklenir

Migration stratejisi

• Yük dengeleme stratejisini tek seferde değiştirmek riskli olabilir
• Robinhood'un bir hizmet için birden fazla yük dengeleme stratejisinin yapılandırılmasına izin vermesinin nedeni budur
• Dropbox'ta yüzde tabanlı bir özellik geçidi bulunduğundan, istemcinin iki yük dengeleme stratejisinin ürettiği ağırlıkların ağırlıklı toplamını endpoint ağırlığı olarak kullandığı karma bir strateji uygulandı
• Bu sayede tüm istemciler endpoint'ler için aynı ağırlık atamasını görürken yeni yük dengeleme stratejisine kademeli olarak geçiş yapılabilir

Öğrenilenler

• Robinhood tasarlanıp uygulanırken neyin işe yaradığına ve neyin yaramadığına dair bazı temel dersler çıkarıldı
• Sadelik önceliklendirilerek, istemci değişiklikleri en aza indirilerek ve migration baştan planlanarak LBS'nin geliştirilmesi ve devreye alınması sadeleştirildi ve maliyetli tuzaklardan kaçınıldı

Yapılandırma mümkün olduğunca basit olmalı

• Robinhood, hizmet sahiplerinin yapılandırabileceği çok sayıda seçenek sundu
• Ancak çoğu durumda ihtiyaç duydukları şey, sağlanan varsayılan ayarlardır
• İyi ve basit bir varsayılan yapılandırma (ya da daha da iyisi hiç yapılandırma gerekmemesi) çok büyük miktarda mühendislik zamanı tasarrufu sağlayabilir

İstemci değişiklikleri de basit tutulmalı

• Dahili istemcilere değişiklik rollout'u yapmak aylar sürebilir
  • Çoğu dağıtım haftalık olarak gönderilir, ancak birçok dağıtım ayda bir yapılır ya da yıllarca hiç yapılmaz
• LBS'ye taşınabilecek değişiklik ne kadar fazlaysa o kadar iyidir
  • Örneğin, başlangıçta istemci tasarımında weighted round robin kullanmaya karar verildi ve o zamandan beri bu değiştirilmedi
  • Bu, ilerleme hızını ciddi biçimde artırdı
• Değişikliklerin çoğunu LBS ile sınırlamak kararlılık riskini de azaltır
  • Çünkü gerekirse LBS'deki değişiklikler birkaç dakika içinde geri alınabilir

Migration, projenin tasarım aşamasında planlanmalı

• Migration çok büyük miktarda mühendislik zamanı gerektirir
• Dikkate alınması gereken kararlılık riskleri de vardır
• Eğlenceli değildir ama kritik bir iştir
• Yeni bir hizmet tasarlanırken mevcut kullanım senaryolarının yeni hizmete nasıl sorunsuz taşınacağı mümkün olduğunca erken düşünülmelidir
• Hizmet sahibinden ne kadar çok şey talep edilirse migration o kadar kâbusa dönüşür
  • Özellikle temel altyapı bileşenlerinde bu daha da geçerlidir
• Robinhood'un migration süreci baştan iyi tasarlanmadığı için süreçlerin yeniden uygulanmasına ve yapılandırmaların yeniden tasarlanmasına beklenenden çok daha fazla zaman harcandı
• Migration için gereken mühendislik zamanı, başarının temel göstergelerinden biri olmalıdır

Robinhood'un etkisi

• Prodüksiyon ortamında yaklaşık 1 yılın ardından Robinhood'un en güncel sürümünün Dropbox'ın uzun süredir devam eden yük dengeleme sorunlarını etkili biçimde çözdüğü söylenebilir
• Temelindeki PID denetleyici algoritması umut verici sonuçlar verdi ve en büyük hizmetlerde kayda değer performans artışı gösterdi
• Dropbox ölçeğinde bir yük dengeleme hizmetinin tasarlanması ve işletilmesine dair değerli içgörüler elde edildi

Dipnotlar

1. N, M ve s sırasıyla sunucu sayısı, istemci sayısı ve adres alt kümesinin boyutu olsun. Bir sunucuya bağlanan istemci sayısı, ikili dağılım B(M, s/n) örneklerini izler. Daha önce de belirtildiği gibi istemciler, hizmet keşfinin sağladığı adres kümesi üzerinde basit round robin uygular. Bu nedenle her istemci yaklaşık aynı miktarda istek gönderirse sunucu tarafındaki yük dağılımı ikili dağılıma benzer.

2. Mevcut hizmet keşif sistemi, gRPC xDS protokolünü (A27) destekleyecek şekilde genişletildi. Bu blogun yazıldığı tarih itibarıyla gRPC istemcileri, kontrol düzlemindeki endpoint ağırlıkları için weighted round robin desteklemediğinden, en erken son tarih öncelikli zamanlamaya dayalı özel bir weighted round robin seçici uygulandı.

3. Hizmetin zaman zaman performansı düşmüş I/O nedeniyle tıkandığı ilginç bir durum ortaya çıktı. Böyle durumlarda ilgili düğümün CPU kullanımı düşük kalır ve LBS, CPU'yu ortalamaya yükseltmeye çalışarak düğümün ağırlığını artırır; bu da bir ölüm sarmalına yol açar. Çözüm olarak, hizmeti dengelemek için yük ölçümü olarak CPU ile in-flight isteklerin maksimumu kullanılmaya başlandı.

GN⁺ görüşü

• Robinhood, Dropbox’un yük dengeleme sorunlarını etkili biçimde çözen çok başarılı bir hizmet gibi görünüyor. PID denetleyicisinin kullanılması etkileyici.
• Çok büyük ölçekli küresel altyapılarda yük dengelemenin ne kadar zor bir mesele olduğunu iyi gösteren bir örnek. Donanım farklılıkları, dengesiz yük dağılımı, ağ tıkanıklığı gibi dikkate alınması gereken çok sayıda unsur var.
• Tüm bileşenlerin organik biçimde birbirine bağlı çalışacak şekilde tasarlanması önemli görünüyor. LBS, proxy ve routing DB ayrı olsa da gerçek zamanlı olarak sıkı biçimde etkileşime giriyor.
• Yük dengeleme performansını nicel olarak değerlendiren ve iyileştirmeleri görselleştiren grafikler etkileyici. Özellikle max/avg oranının 1’e yakın tutulmasının fleet size optimizasyonu için ne kadar önemli olduğunu iyi gösteriyor.
• Config Aggregator eklenerek servis bazlı yapılandırmaların ayrıştırılması da iyi bir fikir gibi görünüyor. Bu, servis sahiplerinin kendi değişikliklerini bağımsız olarak yönetebilmesini sağlıyor.
• tombstone gibi güvenlik önlemlerinin hazırlanmış olması da incelikli bir detay. Yanlışlıkla yapılandırma silinmesini önlemek önemli.
• Migrasyon stratejisine dair çıkarımlar da faydalı görünüyor. Başından itibaren migrasyon düşünülmezse daha sonra çok zaman harcanabiliyor.
• Genel olarak Robinhood, Dropbox ölçeğinde yük dengeleme için sistematik ve rafine bir çözüm gibi görünüyor. Büyük ölçekli altyapıya sahip diğer şirketler için de incelenmeye değer bir örnek.

Benzer çözümler:

• AWS’nin Elastic Load Balancing(ELB) hizmeti veya Google Cloud’un Cloud Load Balancing hizmeti de büyük ölçekli yük dengeleme için yönetilen servisler sunuyor.
• Kubernetes tarafında yerleşik bir load balancer (kube-proxy) bulunsa da Istio ya da Linkerd gibi service mesh çözümleri kullanılırsa daha güçlü yük dengeleme ve trafik yönetimi özelliklerinden yararlanılabilir.
• Netflix’in Zuul’ü veya Lyft’in Envoy’u da proxy tabanlı yük dengeleme işlevleri sunuyor.

Devreye alma sırasında dikkat edilmesi gerekenler:

• Mevcut altyapı ve servislerle uyumluluğun doğrulanması gerekir. Migrasyon gerekiyorsa bir strateji oluşturulmalıdır.
• Performans ve kararlılık üzerindeki etkiler yeterince test edilmeli ve izlenmelidir. Yük dengeleme mantığındaki hatalar kritik olabilir.
• Ekip yetkinlikleri göz önünde bulundurularak devreye alma kapsamı ve hızı belirlenmelidir. Her yere aceleyle uygulamak yerine kademeli geçiş daha iyi olur.
• Uzun vadede sürekli optimizasyon ve iyileştirme çabası gerekir. Yük dengeleme algoritmalarını duruma göre ayarlamak ve darboğazları gidermek gibi çalışmalar faydalı olacaktır.

[kbumsik]

Yazılım tarafında PID kontrolcüsünü duyduğuma şaşırdım :)