Maximum Warp: Building Migrations for Slack Enterprise Grid

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

Bối cảnh

• Mô hình dữ liệu Slack: mọi dữ liệu của một team nằm trên cùng một shard MySQL, băm theo ID 64-bit của team. Dàn tải tốt, nhưng khó với dữ liệu vượt ranh giới một team.
• Enterprise Grid (thiết kế từ 2015, ra mắt 1/2017) nối nhiều, có khi hàng nghìn, team thành một organization với kênh dùng chung. DM và group DM phải thấy được dù đăng nhập vào team nào; mỗi user có một ID toàn organization.

Thay đổi chính

• Organization có shard riêng, dữ liệu trên đó băm theo ID 64-bit của organization. Mỗi team trỏ tới organization cha, nên ứng dụng định tuyến về shard của team hay của organization tuỳ loại dữ liệu.
• Migration dữ liệu cũ: DM, group DM chuyển từ shard team sang shard organization; mọi team ID trong cột hoặc trong blob phẳng đổi thành organization ID; mọi user ID cũ đổi thành ID mới.
• Khung handler chung thay cho script dùng một lần: mỗi loại dữ liệu (file, kênh, user, emoji tuỳ chỉnh…, tìm ra bằng rà soát code backend) có handler với ba giao diện validate, transform, insert; loại mới chỉ cần "điền chỗ trống". Mọi handler idempotent, lỗi giữa chừng thì chạy lại handler đó.
• Tốc độ an toàn: ứng dụng chạy nhanh hơn sức DB chịu; theo dõi CPU, replication lag, số thread, iowait. Dùng lại hệ rate limit vốn để chặn request bên ngoài cho chính migration nội bộ; có GUI để đội Customer Experience tự chỉnh tốc độ mà không cần kỹ sư.
• Chạy trên job queue (Slack 2017) với queue và pool worker riêng để không ảnh hưởng job khác. Thêm job queue inspector: gắn tag cho task của từng migration, đếm việc còn lại, alert khi task lỗi, tự chuyển pha; nhờ đó migration chạy tự động không cần người trực.
• Báo cho người khác: bot đăng lịch, phê duyệt, tiến độ (cập nhật mỗi phút bằng chat.update) vào kênh công khai cho Sales/Customer Success; metric qua StatsD → Graphite → Grafana.
• Migrate team nội bộ của Slack trước, thêm kiểm tra dữ liệu tự động sau migration; theo Slack, từ cuối 2016 đã chuyển nhiều khách hàng lớn nhất với downtime tối thiểu và không mất dữ liệu.

Vì sao

• Sản phẩm mới đòi một đơn vị phân mảnh mới (organization) trên nền mô hình shard theo team đã có; chuyển dữ liệu là việc lặp lại cho từng khách hàng, nên đáng xây thành khung.

Bài học cho SWE

• Shard key gắn với một khái niệm sản phẩm (team); khi sản phẩm thêm cấp trên (organization), dữ liệu xuyên cấp cần chỗ ở mới và việc đổi ID lan vào mọi nơi lưu ID, kể cả blob.
• Migration nội bộ cũng là tải; dùng lại rate limiter cho chính mình.
• Migration theo từng khách hàng nên được tự động hoá đến mức đội phi kỹ thuật vận hành được, với tiến độ hiển thị công khai.

Liên quan

• Multi-tenancy và cô lập tenant
• Sharding và tách database · Migration không downtime
• Sau này Slack chuyển sang Vitess, shard theo nhiều khoá: Slack 2020