Zero Downtime Release: Cân bằng tải không gián đoạn cho một website phục vụ hàng tỷ người dùng
Tóm tắt
-
Máy chủ thường xuyên được khởi động lại: nâng cấp, sửa lỗi, vá bảo mật
-
Với việc áp dụng Continuous Release
→ Trường hợp của Facebook, từ mức 1 lần/tuần vào năm 2007 đã tăng lên hơn 100 lần triển khai mỗi tuần
→ Hàng triệu máy chủ được khởi động lại mỗi ngày
→ AWS, Atlassian, Yelp, Ebay, Uber đều tương tự
→ Health check bắt đầu thất bại gián đoạn
- Các phương pháp triển khai truyền thống
- Triển khai Blue/Green (AWS CodeDeploy, Kubernetes): chia thành hai nhóm máy và load balancer sẽ chuyển traffic sang bên đã cập nhật trước
→ Tốn kém chi phí. Không phù hợp với Edge nơi có số lượng máy rất lớn
- Rolling Updates (Envoy, NGINX, Apache, Kubernetes, AWS): cập nhật dần từng máy một, trong khi load balancer điều chỉnh traffic
→ Trong thời gian cập nhật, mức sử dụng CPU giảm và vòng lặp triển khai chậm.
- Hot Restart (HAProxy, Envoy): khởi chạy tiến trình phiên bản mới trên cùng một máy, khi traffic của tiến trình cũ dần kết thúc thì tiến trình mới sẽ nhận traffic (SO_REUSEPORT, CMSG, SCM_RIGHTS)
→ Chỉ áp dụng được cho TCP, còn UDP có thể gây định tuyến sai
"Làm thế nào để có thể thực hiện cập nhật phát hành mà không downtime, với vòng lặp nhanh và không gián đoạn?"
- Hạ tầng traffic của Facebook
- Edge PoP(L7 LB, ProxyGen) - Data Center(L7 LB, ProxyGen) - App. Server(HHVM,MQTT)
→ Khởi động lại theo từng tầng để tránh gián đoạn
→ Các máy ở Edge và Data Center mỗi bên khởi chạy ProxyGen mới để thực hiện "Socket TakeOver"
→ "Downstream Connection Reuse" giữa Edge và Data Center
→ Kết nối giữa Data Center và App Server là "Partial Post Replay"
- Socket Takeover: khởi chạy tiến trình mới và dùng SCM_RIGHTS cùng CMSG để nhận chuyển giao TCP Listening, UDP VIP socket
→ SCM_RIGHTS: kiểu socket cho phép nhận File Descriptor của tiến trình khác
→ CMSG: cho phép gửi control message giữa các tiến trình cục bộ thông qua hàm sendmsg()
→ Với QUIC là kết nối dựa trên UDP, đối với các kết nối hiện có, tiến trình mới sẽ hỏi QUIC ConnectionID từ tiến trình cũ rồi chuyển tiếp packet tương ứng về tiến trình cũ
- Partial Post Replay (khởi động lại App server)
→ App server có hai loại workload: gọi API ngắn và gọi HTTP POST dài (upload)
→ App server này không có tài nguyên dư nên không thể khởi chạy instance mới rồi chuyển socket như Socket Takeover, và thời gian upload dài cũng là một vấn đề
→ Nếu App server được cập nhật giữa chừng khi đang upload dài, do proxy không giữ toàn bộ nội dung đó, nó sẽ ngắt POST đó và trả lại cho proxy phần dữ liệu đã nhận đến thời điểm đó kèm mã 379
→ Proxy sẽ ghép dữ liệu nhận từ App server cũ với phần dữ liệu còn lại rồi thử gửi lại sang máy mới
- Ưu điểm của Zero Downtime Release
→ Mức sử dụng CPU cao hơn khoảng 20% so với Rolling Update
→ So với Hot Restart từng định tuyến sai tới 20K packet QUIC, phương pháp này gần như không có định tuyến sai
→ Trong Facebook, Socket TakeOver đã được dùng từ năm 2013, còn các phần còn lại từ năm 2015
1 bình luận
Nội dung trên được tóm tắt dựa trên video giải thích dài 20 phút này https://dl.acm.org/action/downloadSupplement/…
ProxyGen : thư viện HTTP C++ của Facebook https://github.com/facebook/proxygen