Scaling Datastores at Slack with Vitess

Slack · 2020 · 3. Quy mô lớn · Độ khó: Nâng cao — bài gốc

Bối cảnh

Slack bắt đầu bằng LAMP. Mọi dữ liệu trên MySQL, gồm ba loại cluster:
- Shards chứa dữ liệu khách hàng, shard theo workspace id: mọi dữ liệu của một workspace nằm trên một shard.
- Metadata để tra workspace nằm ở shard nào.
- Kitchen sink cho dữ liệu không gắn với workspace.
Routing nằm trong monolith "webapp". Mỗi shard có ≥2 MySQL ở hai data center, active-active (cả hai nhận ghi), replicate bất đồng bộ.
Ưu điểm: availability cao (lỗi thì thử bên kia); thiết kế tính năng trực quan; debug nhanh (nối một báo cáo của khách tới host DB trong vài phút); scale dễ (thêm shard cho team mới).
Nhược điểm khi lớn lên:
- Khách doanh nghiệp lớn chạm trần phần cứng lớn nhất.
- Enterprise Grid và Slack Connect phá giả định "một team, một shard".
- Hot spot ở vài shard trong khi phần lớn fleet bị cấp dư.
- Một shard sập thì mọi khách trên shard đó mất toàn bộ Slack.
- Cấu hình MySQL không chuẩn, phải tự viết nhiều công cụ; không dùng được replica.
Mùa thu 2016: hàng trăm nghìn QPS, hàng nghìn host MySQL.

Cân nhắc "sửa tại chỗ hay thay thế":
- Tự xây sharding linh hoạt trong webapp đã được prototype, nhưng logic app dính chặt vào cách lưu dữ liệu; cách này cũng không giải vấn đề vận hành và replica.
- Loại NoSQL (DynamoDB, Cassandra) và NewSQL (Spanner, CockroachDB) vì có hàng nghìn query, nhiều cú pháp riêng của MySQL, và nhiều năm quy trình vận hành viết cho MySQL.
- Theo Slack: họ bảo thủ với công nghệ mới ở phần sống còn, và đội infra nhỏ ưu tiên ít thành phần.
Chọn Vitess: lõi vẫn là MySQL; sharding linh hoạt không cần logic trong app; tự failover và backup; mã nguồn mở (Go), sửa được.
Prototype end-to-end bằng một tính năng nhỏ (RSS feed vào channel). Phải làm lại quy trình provisioning, service discovery, backup, topology, credential. Họ xây: điểm tích hợp để route query, backfill + ghi kép, đọc kép và so sánh (diff) để chắc hai bên cùng ngữ nghĩa.
Slack thành một trong những người đóng góp lớn nhất cho Vitess (topology đa vùng, tương thích MySQL, công cụ migrate, load test).
Khoá shard mới theo dữ liệu, ví dụ tin nhắn shard theo channel id thay vì workspace. Mỗi keyspace gom dữ liệu tăng cùng một hệ số (user, team, channel). Về sau họ đổi từ migrate từng bảng sang migrate cả shard.

Bắt đầu 2017; sau đúng 3 năm Vitess phục vụ 99% traffic MySQL (dự kiến xong cuối 2020).
Đỉnh 2,3 triệu QPS (2M đọc, 300K ghi); latency median 2ms, p99 11ms.
3/2020 (COVID): query tăng 50% trong một tuần; họ tách ngang một keyspace bận nhất bằng workflow split của Vitess. Theo Slack, kiến trúc cũ sẽ không scale nổi cho khách lớn nhất.
Lợi ích không định trước: service mới dùng chung tầng lưu trữ; data residency ở 6 vùng ra mắt nhanh.

Khoá shard hợp lý lúc đầu có thể sai khi sản phẩm đổi. Shard theo khách hàng dễ, nhưng tạo hot spot với khách lớn và chặn tính năng xuyên khách hàng.
Đặt sharding vào một tầng riêng (proxy), không để trong app. Như vậy mọi service mới đều được hưởng.
Đổi càng ít càng tốt: giữ MySQL, đổi tầng phía trên.
Kiểm chứng bằng ghi kép + đọc kép có diff, bắt đầu từ một tính năng nhỏ.
Đánh đổi: phải đầu tư công sức đáng kể để vá chỗ thiếu của Vitess cho nhu cầu riêng.