Zero Downtime Release: Disruption-free Load Balancing of a Multi-Billion User Website
Özet açıklama
-
Sunucular sık sık yeniden başlatılır: yükseltmeler, hata düzeltmeleri, güvenlik yamaları
-
Continuous Release'in devreye alınmasıyla birlikte
→ Facebook örneğinde 2007'de haftada 1 kez olan dağıtım, haftada 100'den fazla dağıtıma çıktı
→ Her gün milyonlarca sunucu yeniden başlatılıyor
→ AWS, Atlassian, Yelp, Ebay, Uber için de durum aynı
→ Health check'ler aralıklı olarak başarısız olmaya başlıyor
- Geleneksel dağıtım yöntemleri
- Blue/Green dağıtımı (AWS CodeDeploy, Kubernetes): iki makine grubuna ayrılır ve load balancer güncellemeden önce trafiği bir tarafa aktarır
→ Maliyeti yüksektir. Çok sayıda makinenin bulunduğu Edge için uygun değildir
- Rolling Updates (Envoy, NGINX, Apache, Kubernetes, AWS): makineler tek tek kademeli olarak güncellenirken load balancer trafiği ayarlar
→ Güncelleme süresince CPU kullanımı düşer ve iterasyon yavaştır.
- Hot Restart (HAProxy, Envoy): aynı makine içinde sürecin yeni sürümü başlatılır, mevcut süreçteki trafik kademeli olarak sona ererken yeni süreç trafiği devralır (SO_REUSEPORT, CMSG, SCM_RIGHTS)
→ Yalnızca TCP için mümkündür; UDP'de hatalı yönlendirme oluşabilir
"Sürüm güncellemeleri nasıl kesinti olmadan, hızlı iterasyonla ve hizmeti bozmadan yapılabilir?"
- Facebook'un Traffic Infrastructure'ı
- Edge PoP(L7 LB, ProxyGen) - Data Center(L7 LB, ProxyGen) - App. Server(HHVM,MQTT)
→ Katmanlar sırayla yeniden başlatılarak kesinti önlenir
→ Edge ve Data Center makineleri, yeni bir ProxyGen başlatarak "Socket TakeOver" yapar
→ Edge ile Data Center arasında "Downstream Connection Reuse" kullanılır
→ Data Center ile App Server arasındaki bağlantılarda "Partial Post Replay" kullanılır
- Socket Takeover: yeni bir süreç başlatılır ve TCP listening ile UDP VIP soketleri SCM_RIGHTS ve CMSG ile devralınır
→ SCM_RIGHTS: başka bir sürecin File Descriptor'larını devralmayı sağlayan soket türü
→ CMSG: sendmsg() işleviyle yerel süreçler arasında kontrol mesajları gönderilmesini sağlar
→ UDP tabanlı bağlantı olan QUIC için, mevcut bağlantılarda yeni süreç eski sürece QUIC ConnectionID'yi sorar ve ilgili paketi eski sürece forward eder
- Partial Post Replay (App sunucusunun yeniden başlatılması)
→ App sunucusunda iki tür iş yükü vardır: kısa API çağrıları, uzun HTTP POST çağrıları (Upload)
→ Bu app sunucusunda boş kaynak olmadığı için Socket Takeover'daki gibi yeni bir instance başlatıp soketi devretmek mümkün değildir; uzun upload süreleri de ayrıca sorundur
→ Uzun bir upload sırasında app sunucusu güncellenirse, proxy tüm içeriğe sahip olmadığından ilgili POST'u keser ve 379 koduyla birlikte o ana kadar aldığı veriyi tekrar proxy'ye döndürür
→ Proxy, eski app sunucusundan aldığı veriyle kalan veriyi birleştirip yeni makineye yeniden göndermeyi dener
- Zero Downtime Release'in avantajları
→ Rolling Update'e kıyasla yaklaşık %20 daha yüksek CPU kullanımı
→ Hot Restart'ın QUIC paketlerinde 20K'ya kadar hatalı yönlendirme yapmasına kıyasla, bunda neredeyse hiç hatalı yönlendirme yoktur
→ Facebook içinde Socket TakeOver 2013'ten beri, diğerleri ise 2015'ten beri kullanılıyor
1 yorum
Yukarıdaki içerik, şu 20 dakikalık açıklayıcı videoya dayanılarak özetlenmiştir: https://dl.acm.org/action/downloadSupplement/…
ProxyGen: Facebook’un C++ HTTP kütüphanesi https://github.com/facebook/proxygen