Scaling for Tsunami traffic

Disney Hotstar · 2019 · 3. Quy mô lớn · Độ khó: Dễ — bài gốc

Bối cảnh

Traffic của Hotstar (streaming ở Ấn Độ) có dạng "sóng thần": khi đội tuyển cricket Ấn Độ ra sân, lượng user đồng thời tăng vọt trong vài phút.
Trước đây Hotstar cho rằng auto-scaling không hợp với kiểu traffic này, nên scale lên trước sự kiện một cách bi quan (dư nhiều headroom) và tốn rất nhiều chi phí hạ tầng.
2019: trên nền Kubernetes mới (Disney Hotstar 2020), họ thử auto-scaler tự viết.

Thay đổi chính

Ba tham số cho mỗi service:
- trigger: CPU, độ dài hàng đợi, phổ biến nhất là số request đang xử lý;
- thời gian scale-up: từ lúc quyết định tới lúc máy mới phục vụ được (thêm node, lập lịch, khởi động app, làm ấm). Đây là thứ cần tối ưu nhất;
- buffer: mức tăng traffic tối đa có thể xảy ra trong khoảng thời gian scale-up.
Hai chính sách:
- theo traffic cho service có metric request/luồng đang xử lý, hợp với tải khó đoán;
- theo bậc thang (mặc định) theo mỗi 1 triệu user đồng thời (1M, 2M… 25M), hợp với tải đoán được.
"Infradashboard": app nội bộ để các team khai báo chính sách và tham số; hệ thống scale gọi API nên không phụ thuộc nhà cung cấp hạ tầng.
Con số: thêm node ~90 giây + tạo container và khởi động app ~75 giây + thu thập metric và ra quyết định, tổng ~4 phút, tức là "lỡ khoảng 2 triệu người". Vì vậy trong sự kiện live, buffer được đặt cao: +2 triệu user với chính sách bậc thang, +30% traffic với chính sách theo traffic.

Kết quả

Theo Hotstar: với IPL 2019 họ xử lý hơn 2 lần tải với lượng compute ít hơn 10 lần so với năm trước. Nhưng họ cho rằng phần lớn là nhờ tinh chỉnh service gọn hơn chứ không chỉ nhờ auto-scaling.

Bài học cho SWE

Với đỉnh dồn dập, thời gian scale-up quyết định độ lớn buffer; rút ngắn khởi động thì rẻ hơn giữ dư.
Đỉnh đoán được (lịch thi đấu) dùng bậc thang theo số user; đỉnh khó đoán dùng metric tải thực.
Auto-scaling không thay được việc làm service gọn. Cùng ý với Twitter 2013: thiết kế cho đỉnh (Twitter 2013).