Moving Velo to Multiple Container Sites: The Why, The How and The Lessons Learned

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

Bối cảnh

Velo (trước gọi là Corvid) cho người dùng Wix viết code backend và frontend cho site. Nó được thiết kế rất rẻ để phục vụ hàng chục triệu khách nhỏ: mỗi site chạy trên một container. Khách lớn xuất hiện thì cần chạy backend của một site trên nhiều container.
Lưới tính toán cũ chạy Docker container không có orchestrator cấp cao, nên Wix phải tự viết cơ chế điều phối, phức tạp và khó scale. Họ dựng lại thành Kore (Kubernetes Orchestrated Runtime Engine).

Hai cách ngây thơ không dùng được vì Wix có ràng buộc thời gian phản hồi chặt: tạo pod khi có request thì request đầu chậm (cold start); giữ một pod cho mỗi site thì lãng phí vì phân bố đuôi dài (ít site nhiều traffic, rất nhiều site ít traffic).
Pool pod ấm: pod ở trạng thái "pooled" đã sẵn mọi thứ để phục vụ nhưng chưa gắn với site nào. Request tới: Dispatcher hỏi Scheduler theo site_id; chưa có pod thì Scheduler chọn ngẫu nhiên một pod pooled, khoá nó cho site, ghi vào Pod Cache; pod cài code của người dùng rồi phục vụ. Pod chỉ phục vụ site đó tới khi bị thu hồi sau vài phút; còn traffic thì lấy pod pooled khác.
"Scale miễn phí": nhiều Scheduler không biết nhau; hai request đồng thời cho một site chưa có pod có thể tạo ra hai pod. Wix coi đó là hành vi bình thường: Pod Cache có nhiều pod cho một site thì chọn ngẫu nhiên.
Site nhiều pod: một service cấu hình số pod tối đa cho mỗi site. Việc thêm pod chạy bất đồng bộ ngoài đường tìm dịch vụ chính: so số pod đang chạy (Pod Cache) với số tối đa; thiếu thì chỉ thêm đúng một pod mỗi lần, để tăng dần và tránh nhiều Scheduler cùng cấp thừa. Chấp nhận thừa vài pod vì lợi cho ổn định.

Theo Wix, giải pháp này là bước tiến tự nhiên của hệ đang chạy, không bẻ kiến trúc, nên làm nhanh; và "chạm tường" sớm bằng cách đưa lên production với người dùng thật là cách tìm ra chỗ thiếu (Nền tảng nội bộ cho service (đường ray chung)).
Phân bố đuôi dài khiến chi phí của "một đơn vị cho mỗi tenant" lớn; pool dùng chung rồi gắn tạm theo nhu cầu giữ được latency mà không trả cho tenant nhàn rỗi (Hot partition và thundering herd).

Pool tài nguyên ấm + gắn tạm theo tenant là điểm giữa giữa cold start và giữ máy cho từng tenant.
Với nhiều scheduler không phối hợp, tăng từng bước một và chấp nhận thừa nhỏ dễ hơn phối hợp chặt.
Tách việc scale khỏi đường request chính để không làm chậm request.