Enhancing Bandaid load balancing with real-time backend server load information

Bài tóm tắt Dropbox 2019 3. Quy mô lớn Độ khó: Nâng cao

Dropbox · 2019 · 3. Quy mô lớn · Độ khó: Nâng cao — bài gốc

Phần tiếp của Dropbox 2018.

Bối cảnh

  • Request của user qua GSLB (DNS) tới hơn 20 PoP, qua L4 rồi edge proxy L7, vào data center thì Bandaid định tuyến tới service. Bandaid đang dùng random N choices (N = 2) theo số request đang mở mà chính instance đó thấy, nhưng tải giữa các backend vẫn lệch, vài máy chạm 100% lúc đỉnh.
  • Vấn đề chung khi có hàng chục, hàng trăm instance LB: mỗi LB chỉ biết tải do chính nó gửi; các LB nhận lượng request khác nhau; subsetting ngẫu nhiên tạo phân bố lệch; chi phí mỗi request khác nhau.

Thay đổi chính

  • Cân nhắc ba hướng: controller tập trung, chia sẻ state giữa LB, gắn thông tin tải của server vào response. Chọn hướng thứ ba vì đơn giản và hợp với random N choices sẵn có.
  • Backend tính utilization = request đang xử lý / số request tối đa đồng thời, ghi vào header X-Bandaid-Utilization. QPS cao nên thông tin luôn tươi, không cần probe chủ động.
  • Điểm của mỗi server là tổng có trọng số của utilization, lỗi 5xx gần đây (để server fail nhanh không hút thêm request) và số request đang mở cục bộ. Giá trị utilization cũ phân rã theo đường sigmoid ngược để server từng bận không bị bỏ đói mãi.
  • Rollout: sửa backend báo utilization trước, rồi bật phương pháp mới theo từng service, từ service ít rủi ro nhất; tune trọng số ở đợt đầu rồi dùng chung.
  • Kết quả: phân bố tổng thời gian xử lý giữa các backend hẹp lại; số request mỗi server lại lệch hơn (đúng ý, bù cho chi phí request khác nhau). Với service có subsetting, tốc độ request tới server cũng đều hơn. Đã chạy production vài tháng.

Vì sao

  • Theo Dropbox, cùng ý tưởng với bài edge load balancing của Netflix và chương load balancing trong sách SRE của Google; Dropbox góp thêm số liệu production.

Bài học cho SWE

  • LB phân tán chỉ thấy tải cục bộ; để server tự báo tải trong response là cách rẻ để có thông tin toàn cục.
  • Thông tin tải cần cơ chế quên (decay) và cần tính đến lỗi, nếu không server hỏng sẽ trông như rảnh.
  • Đo cân bằng bằng thời gian bận của backend, không bằng số request.

Liên quan