Amazon Aurora MySQL Bài 46: Aurora Global Database Write Forwarding - Tối ưu hóa kiến trúc ghi đa vùng địa lý

Ở Bài 37, chúng ta đã tìm hiểu về kiến trúc Aurora Global Database giúp mở rộng cụm cơ sở dữ liệu ra nhiều châu lục với độ trễ đồng bộ lưu trữ cực thấp dưới 1 giây. Tuy nhiên, một thách thức kinh điển trong kiến trúc Multi-Region trước đây là: mọi câu lệnh ghi (INSERT, UPDATE, DELETE) bắt buộc phải định tuyến trực tiếp về cụm Primary Region, khiến các ứng dụng backend đặt ở vùng phụ (Secondary Region) gặp độ trễ mạng lớn khi phải gọi vòng quanh thế giới chỉ để thực hiện một lệnh ghi nhỏ.

Bài viết này sẽ mổ xẻ tính năng Write Forwarding (Chuyển tiếp lệnh ghi) – giải pháp đột phá cho phép ứng dụng gửi cả lệnh đọc lẫn lệnh ghi trực tiếp vào các Read Replicas ở vùng phụ.

1. Write Forwarding là gì và hoạt động thế nào?

Write Forwarding là tính năng cho phép một instance đọc (Read Replica) tại vùng phụ nhận các câu lệnh DML (INSERT/UPDATE/DELETE), sau đó tự động đóng gói và chuyển tiếp (forward) ngầm các câu lệnh đó về cho Writer instance chính xử lý.

• Cơ chế hoạt động:

  1. Ứng dụng backend ở vùng phụ (ví dụ đặt tại Frankfurt, châu Âu) kết nối thẳng vào Reader Endpoint tại địa phương thay vì gọi vòng về Singapore.

  2. Khi ứng dụng thực hiện lệnh ghi, Aurora tự động nhận diện và chuyển tiếp request đó qua mạng riêng tốc độ cao của AWS đến Writer chính.

  3. Writer chính thực hiện ghi dữ liệu và đồng bộ ngược trở lại hệ thống phân tán. Kết quả trả về cho ứng dụng ở vùng phụ ngay sau khi hoàn tất.

2. Cấu hình mức độ nhất quán dữ liệu (Read Consistency Levels)

Khi thực hiện write forwarding, bài toán lớn nhất là độ trễ đồng bộ (Read-after-write consistency). Aurora MySQL cho phép cấu hình tham số phiên làm việc aurora_replica_read_consistency với 3 mức độ linh hoạt:

• EVENTUAL (Nhất quán cuối cùng): Tốc độ xử lý nhanh nhất nhưng có thể đọc phải dữ liệu cũ trong tích tắc nếu client vừa ghi xong và đọc lại ngay lập tức ở một kết nối khác.

• SESSION (Nhất quán trong phiên làm việc - Mặc định): Đảm bảo ngay sau khi chính phiên làm việc đó thực hiện lệnh ghi, các câu lệnh đọc tiếp theo trong cùng phiên sẽ nhìn thấy ngay dữ liệu mới nhất.

• GLOBAL (Nhất quán toàn cục): Đảm bảo tính nhất quán tuyệt đối trên toàn bộ hệ thống, đồng nghĩa với việc sẽ mất thêm chút thời gian chờ đồng bộ hóa hoàn toàn trước khi trả về kết quả.

3. Lợi ích kiến trúc cho Backend Engineer

• Đơn giản hóa mã nguồn ứng dụng: Đội ngũ backend không cần phải xây dựng phức tạp logic phân tách đường dẫn kết nối riêng biệt cho Master (Write) và Replica (Read) trong tệp cấu hình ORM đối với một số nghiệp vụ đặc thù.

• Giảm thiểu độ trễ code ở vùng phụ: Các ứng dụng microservice triển khai phân tán ở các châu lục khác nhau có thể tương tác cục bộ mượt mà hơn với cụm đọc-ghi tích hợp tại chỗ.

4. Hạn chế và Lưu ý thực tế

• Không hỗ trợ lệnh DDL: Write Forwarding chỉ hỗ trợ các câu lệnh dữ liệu DML (INSERT, UPDATE, DELETE). Các câu lệnh định nghĩa cấu trúc như CREATE TABLE, ALTER TABLE bắt buộc phải chạy trực tiếp tại Primary Region.

• Độ trễ mạng vật lý: Dù AWS dùng mạng riêng tốc độ cao, các lệnh ghi toàn cầu vẫn phải chịu một khoảng trễ vật lý khứ hồi (cross-region round-trip latency) giữa hai châu lục. Do đó, tính năng này tối ưu nhất cho các hệ thống thiên về đọc (Read-heavy) có các giao dịch ghi thưa thớt, không phù hợp cho các workload ghi dồn dập xuyên lục địa.