Facebook के zero downtime release तरीके पर एक पेपर

Zero Downtime Release: Disruption-free Load Balancing of a Multi-Billion User Website

सारांश

• सर्वर अक्सर restart होते हैं: upgrade, bug fix, security patch

• Continuous Release के आने से

→ Facebook के मामले में 2007 में हफ्ते में 1 बार से बढ़कर, हफ्ते में 100 बार से अधिक deployment होने लगा

→ हर दिन लाखों सर्वर restart होते हैं

→ AWS, Atlassian, Yelp, Ebay, Uber में भी यही स्थिति है

→ health check बीच-बीच में fail होने लगते हैं

• पारंपरिक deployment तरीके

1. Blue/Green deployment (AWS CodeDeploy, Kubernetes): मशीनों को दो समूहों में बांटकर load balancer पहले update किए गए एक समूह की ओर traffic शिफ्ट करता है

→ इसकी लागत बहुत अधिक है। बहुत बड़ी संख्या वाली machines के Edge पर यह उपयुक्त नहीं है

2. Rolling Updates (Envoy, NGINX, Apache, Kubernetes, AWS): एक-एक करके धीरे-धीरे update करते हुए load balancer traffic समायोजित करता है

→ update अवधि के दौरान CPU उपयोग घट जाता है, और iteration धीमी होती है.

3. Hot Restart (HAProxy, Envoy): एक मशीन के भीतर process का नया version चलाया जाता है, और जैसे-जैसे पुराने process का traffic खत्म होता है, नया process traffic लेना शुरू करता है (SO_REUSEPORT, CMSG, SCM_RIGHTS)

→ यह केवल TCP पर संभव है और UDP में गलत routing हो सकती है

"रिलीज़ update को बिना downtime, तेज iteration के साथ, और बिना रुकावट कैसे किया जाए?"

• Facebook का Traffic Infrastructure

• Edge PoP(L7 LB, ProxyGen) - Data Center(L7 LB, ProxyGen) - App. Server(HHVM,MQTT)

→ बाधा से बचने के लिए tier के हिसाब से restart किया जाता है

→ Edge और Data Center की मशीनें alag-alag नया ProxyGen चलाकर "Socket TakeOver" करती हैं

→ Edge और Data Center के बीच "Downstream Connection Reuse"

→ Data Center और App Server के बीच कनेक्शन में "Partial Post Replay"

• Socket Takeover: नया process चलाकर SCM_RIGHTS और CMSG के जरिए TCP Listening, UDP VIP socket अपने पास लेता है

→ SCM_RIGHTS: ऐसा socket type जो दूसरे process का File Descriptor प्राप्त करने देता है

→ CMSG: sendmsg() फीचर जो local processes के बीच control message भेजने देता है

→ QUIC जैसे UDP-आधारित connection के लिए, मौजूदा connection के मामले में नया process पुराने process से QUIC ConnectionID पूछकर उस packet को पुराने process की ओर forward करता है

• Partial Post Replay (App server restart)

→ App server पर दो तरह के workload होते हैं: छोटे API calls, लंबे HTTP POST calls (Upload)

→ इस app server पर उपलब्ध resource नहीं होते, इसलिए Socket Takeover की तरह नया instance उठाकर socket transfer करना संभव नहीं, और लंबे upload समय भी समस्या हैं

→ अगर लंबे upload के बीच app server update हो जाए, तो proxy के पास उसकी पूरी सामग्री नहीं होती, इसलिए वह उस POST को रोककर 379 code के साथ अब तक प्राप्त data वापस proxy को लौटा देता है

→ proxy पुराने app server से मिले data और बचे हुए data को मिलाकर फिर नई machine को दोबारा भेजने की कोशिश करता है

• Zero Downtime Release के फायदे

→ Rolling Update की तुलना में लगभग 20% अधिक CPU उपयोग

→ Hot Restart में जहाँ QUIC packet 20K तक misroute हो रहे थे, उसकी तुलना में इसमें लगभग कोई misrouting नहीं होती

→ Facebook के भीतर Socket TakeOver 2013 से, और बाकी तकनीकें 2015 से उपयोग में हैं

[xguru]

ऊपर की सामग्री इस 20 मिनट के व्याख्यात्मक वीडियो के आधार पर संक्षेपित की गई है https://dl.acm.org/action/downloadSupplement/…

ProxyGen : Facebook की C++ HTTP Library https://github.com/facebook/proxygen