Uber tái thiết kế cơ chế sharding của M3DB bằng subcluster để giảm thiểu tác động khi hệ thống gặp sự cố

Uber vừa công bố thiết kế mới cho cơ chế phân bổ shard (shard placement) trong M3DB, hệ thống cơ sở dữ liệu chuỗi thời gian do chính công ty phát triển. Mục tiêu của lần tái thiết kế này là giới hạn phạm vi ảnh hưởng khi một node gặp sự cố, khi cụm phải bảo trì hoặc khi mở rộng quy mô.

Vấn đề của cách phân bổ shard truyền thống

Trong các hệ thống cơ sở dữ liệu phân tán, mỗi bản ghi dữ liệu thường được gán vào một shard, và mỗi shard lại được sao chép (replica) trên nhiều node khác nhau để đảm bảo tính sẵn sàng. Khi số lượng node và shard tăng lên, các mối quan hệ phụ thuộc giữa chúng trở nên chằng chịt.

Hệ quả là chỉ cần một node gặp sự cố, rất nhiều shard có thể bị ảnh hưởng cùng lúc. Việc bảo trì định kỳ hay thêm node mới cũng kéo theo nhu cầu di chuyển dữ liệu trên diện rộng, gây tốn băng thông và tiềm ẩn rủi ro mất cân bằng tải.

Subcluster có kích thước cố định: chìa khóa của giải pháp

Uber giải quyết bài toán này bằng cách chia cụm M3DB thành các subcluster có kích thước cố định. Thay vì phân bổ shard trên toàn bộ cụm như trước, mỗi shard chỉ được đặt trong một phạm vi node xác định.

Cách tiếp cận này mang lại ba lợi ích chính:

• Giới hạn số lượng phụ thuộc giữa các shard, nhờ đó sự cố ở một node chỉ tác động tới một tập hợp hữu hạn các shard thay vì lan rộng khắp cụm.
• Bảo toàn tính cô lập của bản sao, đảm bảo các replica của cùng một shard không bao giờ nằm chung trong một subcluster — điều kiện quan trọng để duy trì khả năng chịu lỗi.
• Kiểm soát tốt hơn khi mở rộng, vì việc thêm node mới chỉ ảnh hưởng tới một số subcluster nhất định thay vì buộc toàn bộ cụm phải tái phân bổ.

Thuật toán tham lam thay thế cho bước tái cân bằng riêng biệt

Một điểm đáng chú ý trong thiết kế mới là Uber sử dụng thuật toán tham lam (greedy algorithm) để chọn ra các shard cần di chuyển. Thay vì chạy một bước tái cân bằng (rebalancing) độc lập sau mỗi thay đổi, hệ thống đưa ra quyết định di chuyển ngay trong quá trình phân bổ.

Cách làm này giúp loại bỏ bước tái cân bằng riêng biệt và tránh những đợt di chuyển dữ liệu không thực sự cần thiết.

Đây là điểm khác biệt quan trọng so với nhiều hệ thống lưu trữ phân tán khác, nơi việc tái cân bằng thường diễn ra như một giai đoạn hậu xử lý và có thể gây ra những đợt dao động hiệu năng không mong muốn.

Ý nghĩa đối với hạ tầng quy mô lớn

Với các hệ thống phục vụ hàng triệu yêu cầu mỗi giây như hạ tầng của Uber, việc giới hạn bán kính ảnh hưởng của sự cố là yếu tố sống còn. Một node hỏng không nên biến thành sự cố toàn cụm.

Đối với các kỹ sư vận hành hệ thống tại Việt Nam — dù chạy trên Kubernetes, các cụm Cassandra, TiDB hay các cơ sở dữ liệu chuỗi thời gian như Prometheus, VictoriaMetrics — bài học từ M3DB vẫn rất đáng tham khảo. Nguyên tắc cốt lõi là thiết kế sao cho phạm vi ảnh hưởng của lỗi luôn bị chặn trên (bounded blast radius) ngay từ khâu phân bổ dữ liệu, chứ không phải xử lý sau khi sự cố đã xảy ra.

Việc kết hợp giữa subcluster cố định, đảm bảo cô lập bản sao và thuật toán chọn di chuyển tối giản cho thấy một hướng tiếp cận thực dụng: giảm độ phức tạp vận hành thay vì liên tục bù đắp bằng các cơ chế tái cân bằng phức tạp.