Geosharded Recommendations Part 2: Architecture

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

Phần 2 của series 3 phần. Phần 1 (cách chia shard): Tinder 2019; phần 3 (consistency, bài sheet trỏ tới): Tinder 2019.

Bối cảnh

Phần 1 đã chốt thuật toán chia geoshard trên S2 và đóng gói thành một microservice nội bộ. Phần 2 trả lời ba câu hỏi triển khai: "shard" cụ thể là gì trong Elasticsearch, cluster cần cỡ nào, và cân tải ra sao.

Thay đổi chính

Luồng:
- user đổi vị trí → location service xác định có phải dời shard không → ghi tới data node theo route;
- lấy gợi ý → tầng logic tính số shard cần query theo vị trí và bán kính → query song song → gộp kết quả.
Multi-index trong một cluster, không multi-cluster.
- Multi-cluster cách ly tốt hơn, scale riêng từng shard dễ hơn, nhưng Elasticsearch khi đó chưa query được qua nhiều cluster, nên phải tự fan-out và tự dời document giữa cluster.
- Họ chọn multi-index vì đơn giản hơn nhiều cho server và vận hành; shard nóng thì thêm replica.
Chọn cỡ bằng performance test (JMeter), chốt từng biến một thay vì thử mọi tổ hợp:
- bắt đầu từ cỡ shard: gom vùng đông user nhất vào một shard để giảm query xuyên shard;
- seed dữ liệu giả theo phân bố tuổi và bộ lọc tuổi thật;
- tăng traffic tới khi CPU/RAM của node query hoặc node data chạm trần;
- sau đó mới đổi số replica, loại instance AWS, cấu hình JVM.
Lệch múi giờ: user cùng geoshard thường cùng múi giờ, nên giờ cao điểm của các shard lệch nhau. Tại một thời điểm, RPS giữa các shard có thể chênh hơn 10 lần.
- Xếp tay nhiều shard lên cùng node cho tải đều là bài toán NP-hard, và phải tính lại mỗi lần reshard.
- Họ rải ngẫu nhiên primary/replica lên các host, biến bài toán thành xác suất "hai bi cùng màu rơi vào một ngăn kéo". Chỉnh số replica cho tới điểm cân bằng.
- Đánh đổi: nhiều replica thì tải đều hơn, nhưng mỗi host tốn thêm năng lực ghi và RAM.
Kiến trúc cuối: 3 master node; một ASG chỉ gồm coordinating node (nhận mọi request), một ASG gồm data node. Mỗi data node giữ ngẫu nhiên 4 index, có cái là primary của shard này, có cái là replica của shard khác.

Kết quả

Theo Tinder (2019): index geoshard xử lý gấp 20 lần lượng tính toán so với thiết lập cũ.

Bài học cho SWE

Cách triển khai shard (index hay cluster) là đánh đổi giữa mức cách ly và độ phức tạp vận hành; cái gì hệ thống bên dưới hỗ trợ sẵn thường thắng.
Shard theo địa lý kéo theo lệch theo thời gian: cân đều về dung lượng chưa đủ, phải tính cả giờ cao điểm.
Ngẫu nhiên hoá placement là lời giải thực dụng cho bài toán xếp chỗ NP-hard, đổi lại tốn thêm replica.
Performance test với dữ liệu giả mô phỏng phân bố thật là bước bắt buộc trước khi chốt cỡ cluster.