Amazon Aurora MySQL Bài 2: Kiến trúc lưu trữ phân tán của Aurora: Storage Layer hoạt động ra sao?

1. Vấn đề của mô hình lưu trữ cơ sở dữ liệu truyền thống (Monolithic Storage) Ở các hệ thống RDBMS truyền thống (như MySQL chạy trên EC2 gắn ổ cứng EBS hoặc On-Premise Disk):

• Gắn kết chặt chẽ (Tight Coupling): Tính toán (Compute - CPU/RAM) và Lưu trữ (Storage - Disk I/O) nằm chung trên một node vật lý hoặc một dịch vụ block storage đơn lẻ.

• Nút thắt cổ chai I/O: Khi ứng dụng thực hiện các câu lệnh INSERT, UPDATE khối lượng lớn, tiến trình ghi log (Redo Log, Binlog) và ghi dữ liệu xuống đĩa gây áp lực cực lớn lên IOPS của ổ cứng.

• Chi phí sao lưu và scale: Khi cần tạo Read Replica để gánh tải đọc, hệ thống phải sao chép toàn bộ dữ liệu qua mạng hoặc đồng bộ qua binlog truyền thống, dẫn đến tốn băng thông và phát sinh độ trễ (Replication Lag).

2. Kiến trúc lưu trữ phân tán độc lập (Distributed Storage Architecture) của Aurora Amazon Aurora thiết kế lại hoàn toàn tầng lưu trữ bằng cách tách biệt hoàn toàn compute và storage. Tầng lưu trữ của Aurora không phải là một ổ đĩa cứng vật lý đơn lẻ, mà là một phân vùng lưu trữ ảo hóa, phân tán quy mô lớn (Virtual Distributed Storage Volume).

• Cơ chế phân đoạn (Segmented Storage):

  • Dung lượng lưu trữ của một cụm Aurora được tự động chia thành các khối nhỏ (mỗi khối mặc định có dung lượng cố định là 10 GB).

  • Các khối 10GB này được phân tán và trải đều trên hàng chục hoặc hàng trăm thiết bị lưu trữ vật lý độc lập trong một AWS Region.

• Độ bền siêu cao (High Durability):

  • Không giống như ổ cứng thông thường phụ thuộc vào một phần cứng, dữ liệu của mỗi phân khúc 10GB được tự động nhân bản thành 6 bản sao (6-way replication) nằm trên 3 Availability Zones (AZs) khác nhau.

  • Cấu trúc phân phối này đảm bảo ngay cả khi có đồng thời 2 AZs hoặc một thiết bị phần cứng vật lý gặp sự cố nghiêm trọng, dữ liệu của cụm vẫn hoàn toàn nguyên vẹn và không bị gián đoạn.

3. Chuyển dịch gánh nặng I/O: Biến Log thành Database (The Log is the Database) Một trong những điểm thông minh nhất của Aurora MySQL ở tầng storage là thay đổi cách ghi dữ liệu:

• MySQL truyền thống: Ghi dữ liệu bẩn (dirty pages) xuống buffer pool, sau đó ghi redo log, rồi định kỳ flush toàn bộ trang dữ liệu (data pages) xuống đĩa. Việc này sinh ra lượng I/O rất lớn qua mạng (nếu dùng EBS) và trên đĩa.

• Aurora MySQL: Giảm thiểu tối đa lượng dữ liệu ghi qua mạng. Writer instance chỉ truyền tải các log record (thay vì toàn bộ các trang dữ liệu thay đổi) xuống tầng lưu trữ phân tán.

• Tầng storage phân tán của Aurora sẽ tự động nhận các log record này, áp dụng chúng để tái tạo các trang dữ liệu ở dưới nền (background) một cách song song. Nhờ vậy, băng thông mạng tiết kiệm được hàng ngàn lần và hiệu năng ghi (Write Throughput) tăng vọt.

4. Góc nhìn vận hành cho Backend Engineer

• Không còn khái niệm "phân mảnh ổ cứng thủ công": Bạn không cần đau đầu tính toán dung lượng Volume hay lo lắng việc phân chia các bảng lớn vào các ổ cứng khác nhau. Aurora tự động scale dung lượng từ vài GB lên đến 128 TB mà không làm gián đoạn hệ thống.

• Tối ưu hóa tài nguyên: Vì tầng storage tự xử lý việc nhân bản và persist dữ liệu bằng các tiến trình phân tán riêng biệt, CPU và RAM của các Aurora Instance (Writer/Reader) được giải phóng hoàn toàn để tập trung xử lý câu lệnh SQL và logic từ ứng dụng backend của bạn.