Flannel: An Application-Level Edge Cache to Make Slack Scale

Slack · 2017 · 2. Tăng trưởng · Độ khó: Trung bình — bài gốc

Bối cảnh

Slack thiết kế cho team vài trăm người: khi khởi động, client gọi rtm.start nhận toàn bộ snapshot của team (user, channel, thành viên, tin mới nhất, DM...) rồi mở WebSocket nhận event real-time.
Với team hàng chục nghìn người: kết nối lâu, client tốn bộ nhớ, mỗi lần kết nối lại đắt như lần đầu, và cơn bão kết nối lại (cả văn phòng mất mạng rồi cùng vào) đè nặng backend: kết nối chậm hơn, nhiều retry hơn.

Flannel: cache ở tầng ứng dụng đặt tại các edge PoP. Client kết nối Flannel; Flannel gom dữ liệu khởi động đầy đủ, giữ một WebSocket tới server ở region chính để cập nhật theo event, và trả cho client bản rút gọn đủ để khởi động.
Tải lười theo nhu cầu: user, channel tải khi cần qua API truy vấn của Flannel (ví dụ Quick Switcher gửi truy vấn autocomplete khi gõ).
Đẩy trước: khi broadcast một tin có mention người mà một số client chưa tải gần đây, Flannel gửi dữ liệu user đó cho các client ấy ngay trước tin, bớt một round-trip.
Consistent hashing theo team: user cùng team, cùng vùng mạng vào cùng instance Flannel để cache hiệu quả; kết nối mới hoặc kết nối lại được phục vụ từ cache, giảm tác động của bão kết nối lên backend.
Số liệu (2017): 4 triệu kết nối đồng thời lúc đỉnh, 600.000 truy vấn client/giây. Payload khởi động giảm 7 lần ở team 1.500 người và 44 lần ở team 32.000 người.
Kế hoạch: đưa sang mobile; chuyển fan-out vào Flannel (gửi một bản cho mỗi server Flannel thay vì một bản cho mỗi người dùng đang kết nối); chuyển client sang pub/sub theo màn hình đang xem (presence chuyển sang pub/sub đã giảm 5 lần số event client nhận).

Chi phí "tải mọi thứ lúc khởi động" tăng theo kích thước team và nhân lên khi mọi người kết nối lại cùng lúc.

Snapshot đầy đủ lúc khởi động là thiết kế cho quy mô nhỏ; khi lớn, đổi sang tải lười + cache gần client.
Gom người dùng có chung dữ liệu vào cùng một node cache (affinity) vừa tăng hit vừa làm cache thành lớp đỡ bão kết nối lại.