Using the Gini Coefficient to Plan Edge Capacity

Fastly · 2026 · 3. Quy mô lớn · Độ khó: Trung bình — bài gốc

Bài của nhà cung cấp, kể bởi người xây mô hình; số liệu sai số do Fastly tự đo, ghi "theo Fastly".

Bối cảnh

• Một POP của Fastly là máy bare-metal chạy lẫn nhiều loại tải (video live, API, security, tải phần mềm, Compute wasm), phần cứng nhiều đời. Không có một con số "capacity": cùng một POP có thể dư thừa hôm nay và nghẹt hôm khác dù tải bề ngoài giống nhau.
• Câu hỏi cần trả lời là giả định: POP này chịu được một bản phát hành game tuần sau không, vùng này nhận thêm bao nhiêu tải download, nếu Compute và Security tăng nhanh gấp đôi thì nhóm tiến trình nào chạm trần CPU trước, khi khách chuyển traffic từ nhà cung cấp khác sang lúc failover thì sao.
• Thử AutoML, neural net, mô hình cây, ensemble, mô hình time-series, cả LLM: tốt cho ngày bình thường nhưng sai đúng vào những ngày bất thường, mà capacity planning được định nghĩa bởi chính những ngày đó.

Thay đổi chính

• Bất bình đẳng traffic là tín hiệu chính: dùng hệ số Gini trên tỉ lệ traffic của các khách lớn nhất. Một bản phát hành lớn làm vài khách chiếm phần lớn traffic → độ phổ biến cao → cache hit cao → mỗi request rẻ CPU hơn. Hai POP cùng tổng traffic có thể có hành vi cache rất khác.
• Chuỗi mô hình: traffic mix → dự đoán cache hit ratio (front-end) → dự đoán CPU → headroom.
  • Cache: a·sqrt(gini) + b·top_N_ratio + c, robust regression trên lịch sử gần; căn bậc hai vì những dấu hiệu tập trung đầu tiên quan trọng nhất; loại phần traffic vốn không cache được.
  • CPU: robust regression theo bit/giây, request/giây, số task Compute, mức 1 phút, train theo từng POP và từng nhóm CPU, nhân với hệ số cache; bỏ các dòng CPU thấp, tăng trọng số mẫu CPU cao.
• Headroom: chọn một kịch bản và một mốc nền, tìm nhị phân mức traffic ngay dưới ngưỡng CPU; xuất nhóm CPU giới hạn, Gbps/RPS còn thêm được; câu trả lời cuối còn xét NIC, peering, transit.
• Chọn mốc nền "bình thường" bằng seasonal naive forecasting; mô hình phức tạp hơn (kiểu Prophet) không giúp quyết định tốt hơn.
• Theo Fastly, mô hình chạy production hơn một năm (dùng cho các bản phát hành game lớn, xây POP mới), sai số trong khoảng 5% CPU thật, trong khi mô hình phức tạp thường lệch 25% trở lên.
• Từ dự đoán sang sắp đặt: với tải phù hợp, cố ý dồn traffic để tăng locality cache, nhất là trên phần cứng cũ; có giới hạn vì dồn tải tạo hot spot và giảm cô lập lỗi.

Bài học cho SWE

• Capacity của một hệ có cache phụ thuộc hình dạng tải (tập trung hay dàn trải), không chỉ tổng lượng (Cache và invalidation).
• Tập trung không chỉ là rủi ro hot spot: với cache, nó cũng là nguồn hiệu quả; quyết định dồn hay rải phải đo được đánh đổi (Hot partition và thundering herd).
• Mô hình nhỏ, giải thích được, chạy được kịch bản giả định tức thì có thể tốt hơn mô hình lớn khi những ngày quan trọng là ngày hiếm (Chi phí hạ tầng và build vs buy).

Liên quan

• Chi phí hạ tầng và build vs buy · Cache và invalidation · Hot partition và thundering herd