Cách Thay Thế Database Sequence Tại Quy Mô Lớn Không Gây Gián Đoạn Hơn 100 Dịch Vụ

Giải quyết bài toán "Sequence" ẩn giấu

Trong các hệ thống quy mô lớn, việc di chuyển từ cơ sở dữ liệu quan hệ sang NoSQL thường gặp rào cản lớn. Đối với đội ngũ của Coupang, rào cản đó nằm ở tính năng Database Sequences – những bộ đếm tự động tạo ra các số nhận dạng duy nhất (ID) tăng dần. Hơn 100 đội nhóm phụ thuộc vào tính năng này cho khóa chính, và khi chuyển sang DynamoDB (không hỗ trợ sequence gốc), hệ thống bị tê liệt nếu không có giải pháp thay thế.

Thiết kế đơn giản hơn là thông minh

Các kỹ sư thường nghĩ giải pháp sequence phân tán cần các giao thức phức tạp như đồng thuận (consensus) hoặc đồng hồ vector (vector clocks). Tuy nhiên, đội ngũ Coupang đã chọn hướng đi ngược lại: tập trung vào sự đơn giản và hiệu suất thực tế hơn là vẻ đẹp trên giấy trắng.

Mục tiêu của họ là tối thiểu hóa sự phối hợp, chấp nhận các khoảng trống (gaps) trong số ID là chấp nhận được, và đẩy caching ra biên (edge) để giảm thiểu số lần gọi mạng. Kết quả là một kiến trúc giúp việc tạo ID diễn ra giống như việc tăng biến cục bộ, không cần chờ gọi API hay truy vấn database.

Kiến trúc hai tầng cache

Hệ thống được thiết kế với ba lớp chính: DynamoDB là nguồn dữ liệu gốc, lớp cache phía máy chủ, và thick client (khách hàng dày) lưu cache cục bộ.

Mô hình luồng yêu cầu đi qua hai lớp cache trước khi đến DynamoDB

DynamoDB làm nguồn chân lý: Mỗi sequence là một mục dữ liệu duy nhất trong DynamoDB. Thay vì lấy từng cái một, dịch vụ sẽ lấy theo khối (block), tối ưu hóa chi phí và độ trễ.

Cache phía máy chủ: Dịch vụ giữ các khối ID trong bộ nhớ để phục vụ các yêu cầu nhanh chóng. Nếu máy chủ gặp sự cố, các ID đã phát hành vẫn được đảm bảo duy nhất nhờ cơ chế phân bổ không trùng lặp.

Client-side caching: Đây là chìa khóa của hiệu suất. Thư viện tích hợp trực tiếp vào ứng dụng cho phép các request 99% chỉ đơn giản là tăng một số trong bộ nhớ cục bộ. Yêu cầu mạng chỉ xảy ra khi cache cục bộ gần cạn.

Ba kịch bản trong trình tự: Hầu hết các yêu cầu không rời khỏi quy trình ứng dụng

Thuật toán cửa sượt trượt (Sliding Window)

Để tránh việc cache bị cạn trước khi làm mới, hệ thống sử dụng thuật toán sliding window. Thay vì chờ đến khi hết, hệ thống sẽ dự đoán nhu cầu và bắt đầu làm mới khối ID trong nền (background) trước khi cache hiện tại cạn.

Cửa sổ trượt dự đoán việc làm mới trước khi cạn kiệt

Cơ chế này giúp đảm bảo độ trễ cực thấp (thường dưới 1ms) và khả năng chịu lỗi cao. Thậm chí trong trường hợp DynamoDB gặp sự cố, hệ thống vẫn có thể hoạt động nhờ vào các lớp cache, giữ cho ứng dụng khách hàng không bị gián đoạn.

Kết quả đạt được

Kiến trúc này đã cho kết quả ấn tượng:

• Hiệu suất: Khoảng 99% các yêu cầu được đáp ứng ngay lập tức từ client cache, chỉ có khoảng 0.1% cần gọi đến DynamoDB.
• Khả năng chịu lỗi: Nếu dịch vụ sequence gặp sự cố, client cache có thể duy trì hoạt động trong thời gian dài. Nếu DynamoDB gặp sự cố, server cache vẫn đảm bảo khả năng phục vụ trong vài phút.
• Sự đơn giản: Việc bảo trì và gỡ lỗi tại 3 giờ sáng trở nên dễ dàng hơn nhờ kiến trúc rõ ràng và dễ hiểu.

"Ưu tiên thiết kế có thể gỡ lỗi vào lúc 3 giờ sáng hơn là thiết kế đẹp trên giấy trắng." – Quan điểm cốt lõi của dự án.

Với giải pháp này, đội ngũ Orders đã chuyển đổi 12 dịch vụ chỉ trong 3 tuần mà không cần sửa đổi logic ứng dụng, chứng minh rằng việc thấu hiểu yêu cầu thực tế và áp dụng caching đúng cách có thể giải quyết các bài toán phức tạp hiệu quả hơn là các giải pháp kỹ thuật cầu kỳ.