Agoda thay thế bộ đệm giá 72 shard SQL Server bằng DragonflyDB

Agoda vừa hoàn tất một trong những dự án di trú hạ tầng đáng chú ý nhất trong năm: chuyển toàn bộ bộ đệm giá (Price Cache) khách sạn nặng 1,5 TB từ 72 shard SQL Server sang DragonflyDB. Thay đổi này giúp nền tảng du lịch trực tuyến xử lý khối lượng đọc và ghi ngày càng lớn mà vẫn giữ được độ trễ thấp.

Vì sao Agoda phải thay đổi?

Bộ đệm giá là thành phần sống còn của bất kỳ nền tảng đặt phòng nào. Mỗi khi người dùng tìm kiếm khách sạn, hệ thống phải truy xuất giá phòng gần như tức thời. Với Agoda, khối lượng truy vấn này tăng liên tục theo quy mô người dùng và số lượng đối tác khách sạn.

Kiến trúc cũ dựa trên 72 shard SQL Server dần bộc lộ giới hạn:

• Chi phí vận hành và mở rộng ngày càng cao
• Độ trễ đọc tăng khi lưu lượng đỉnh điểm
• Việc phân mảnh (sharding) phức tạp, khó cân bằng tải
• Khó đáp ứng yêu cầu ghi dữ liệu giá theo thời gian thực

DragonflyDB — lựa chọn thay thế

DragonflyDB là một kho dữ liệu trong bộ nhớ (in-memory) tương thích với giao thức Redis nhưng được thiết kế cho kiến trúc đa luồng hiện đại. Nhờ tận dụng tốt phần cứng nhiều lõi, DragonflyDB thường đạt thông lượng cao hơn đáng kể so với các giải pháp truyền thống trên cùng một cấu hình máy chủ.

Điểm hấp dẫn với Agoda nằm ở khả năng xử lý song song, độ trễ thấp và mô hình vận hành đơn giản hơn so với việc duy trì hàng chục shard cơ sở dữ liệu quan hệ.

Cách Agoda thực hiện di trú

Agoda không chuyển đổi đột ngột mà áp dụng chiến lược di trú theo giai đoạn, hạn chế tối đa rủi ro gián đoạn dịch vụ:

• Đọc kép (dual reads): hệ thống đọc đồng thời từ cả SQL Server và DragonflyDB để so sánh kết quả
• Kiểm tra tính tương đồng (parity validation): xác minh dữ liệu trả về từ hai nguồn khớp nhau trước khi tin tưởng hệ thống mới
• Chuyển dịch lưu lượng dần dần: tăng tỷ lệ truy vấn đi vào DragonflyDB theo từng bước nhỏ
• Phát hiện lỗi phi tập trung: cơ chế failover không phụ thuộc vào một điểm kiểm soát trung tâm, giúp hệ thống phản ứng nhanh khi có sự cố

Cách tiếp cận này cho phép Agoda quay lui (rollback) bất cứ lúc nào trong quá trình chuyển đổi mà không ảnh hưởng đến trải nghiệm người dùng cuối.

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

Theo Agoda, độ trễ đọc P99 giảm khoảng tám lần sau khi chuyển sang DragonflyDB. Đây là chỉ số quan trọng bậc nhất với hệ thống đặt phòng, bởi P99 phản ánh trải nghiệm của nhóm người dùng chịu độ trễ cao nhất — thường là những truy vấn phức tạp hoặc vào thời điểm tải nặng.

Bên cạnh đó, Agoda vận hành hai cụm DragonflyDB song song để đảm bảo tính sẵn sàng cao (high availability), giảm thiểu rủi ro downtime.

Việc thay thế 72 shard SQL Server bằng một kiến trúc in-memory hiện đại cho thấy xu hướng tách biệt lớp lưu trữ nóng (hot storage) khỏi cơ sở dữ liệu quan hệ đang ngày càng rõ nét trong các hệ thống quy mô lớn.

Ý nghĩa với cộng đồng kỹ thuật

Câu chuyện của Agoda mang lại vài bài học thực tiễn cho các đội ngũ kỹ thuật, kể cả những nhóm nhỏ hơn nhiều:

• Không cần "big bang": di trú lớn vẫn có thể an toàn nếu chia nhỏ giai đoạn và kiểm chứng liên tục
• Đọc kép là công cụ đắc lực: so sánh song song hai hệ thống giúp phát hiện sai lệch trước khi người dùng gặp phải
• Chọn công nghệ theo bài toán: SQL Server phù hợp với giao dịch phức tạp, nhưng bộ đệm đọc nhiều với độ trễ thấp lại hợp với kho dữ liệu in-memory
• Failover phi tập trung: giảm nguy cơ "single point of failure" trong hệ thống phân tán

Với các doanh nghiệp Việt Nam đang xây dựng nền tảng thương mại điện tử, đặt vé hay gọi xe, mô hình di trú này đáng để tham khảo. Khi lưu lượng tăng, việc giữ nguyên một kiến trúc cơ sở dữ liệu quan hệ phân mảnh phức tạp thường trở thành gánh nặng kỹ thuật và chi phí — trong khi các giải pháp in-memory hiện đại có thể giải phóng đáng kể nguồn lực cho đội ngũ phát triển.