Rethinking site capacity projections with Capacity Analyzer

LinkedIn · 2021 · 3. Quy mô lớn · Độ khó: Khó — bài gốc

Bối cảnh

• LinkedIn load test hằng ngày trên production bằng cách dồn traffic của các DC khác vào DC cần test; mục tiêu đặt theo dự báo QPS của quý.
• Vài năm trước bài viết, traffic tăng chưa từng có làm trượt load test ở các DC: site vẫn khoẻ ở đỉnh hiện tại nhưng không chắc gánh nổi tải dự báo. Câu hỏi: làm sao bắt được hồi quy của service chưa gây sự cố nhưng sẽ gây ở tải cao hơn?

Thay đổi chính

• Bước đầu, thống kê: theo Little's law, so latency và lỗi của service với Site QPS; tương quan tuyến tính hoặc dưới tuyến tính thì an toàn, siêu tuyến tính thì sẽ vỡ. Phát hiện bất thường bằng trung bình trượt, rồi tương quan trên CallGraph để phân biệt backend là nguyên nhân với frontend/mid-tier chỉ là triệu chứng. Hiệu quả rồi bão hoà.
• Thêm tín hiệu: ngoài latency còn mức dùng threadpool, CPU, số lần và thời gian GC (dịch vụ JVM có GC bất thường là dấu hiệu sớm). Dựng golden dataset hơn ba tháng hồi quy capacity đã xác nhận để đánh giá.
• Các kỹ thuật cuối cùng:
  • Latency severity score: baseline latency theo Site QPS cho mỗi endpoint, chấm độ lệch, trọng số theo độ quan trọng học từ CallGraph.
  • Call path grouping + leaf node: hồi quy ở nút lá của đồ thị gọi có xác suất là nguyên nhân gốc cao hơn nhiều; top 10 cải thiện 71%.
  • Slope change filter: so độ dốc latency theo QPS trong cửa sổ test với trước đó, kiểm định t hai mẫu.
  • Generalized severity: LSTM autoencoder trên chuỗi thời gian nhiều chiều; kèm slope filter, top 10 cải thiện gần 80%.
  • MetaRank: XGBoost (100 cây, sâu 3) xếp hạng lại từ các bảng xếp hạng trên, học từ nhãn nguyên nhân gốc của 34 lần load test; top 5 cải thiện hơn 150%.
• Kết quả: tỉ lệ qua load test trên 95%; sự cố do thiếu capacity giảm 73%. Thử nghiệm phân tích tác động phía dưới tìm đúng nguyên nhân gốc ở hơn 77% lần load test.

Vì sao

• Load test chỉ báo qua/trượt; cần biết service nào sẽ vỡ ở mục tiêu tiếp theo để sửa trước.

Bài học cho SWE

• Đo độ dốc latency theo tải, không chỉ giá trị tuyệt đối: service sắp vỡ thường bẻ cong trước khi lỗi.
• Trong đồ thị gọi, triệu chứng lan lên trên; ưu tiên nút lá khi tìm nguyên nhân.
• Cần một bộ dữ liệu sự cố đã gán nhãn để biết kỹ thuật phát hiện nào thật sự tốt hơn.

Liên quan

• LinkedIn 2019 · LinkedIn 2015 (call graph) · LinkedIn 2019
• Load test và kiểm chứng capacity · Observability và monitoring