Amazon Aurora MySQL Bài 12: Aurora Storage Auto-Scaling: Không bao giờ lo lắng về cạn kiệt dung lượng ổ cứng

Một trong những nỗi ám ảnh lớn nhất của các Database Administrator (DBA) và Backend Engineer vận hành hệ thống truyền thống là bài toán cạn kiệt dung lượng ổ cứng (Disk Full). Khi một bảng dữ liệu lớn phình ra do log hoặc dữ liệu người dùng tăng vọt, ổ đĩa EBS đầy bất ngờ sẽ làm sập toàn bộ hệ thống (MySQL went away hoặc crash đột ngột).

Với Amazon Aurora MySQL, bài toán này được giải quyết triệt để nhờ cơ chế Storage Auto-Scaling. Bài viết này sẽ mổ xẻ cách cơ chế tự động mở rộng dung lượng này hoạt động ở tầng sâu.

1. Vấn đề của cơ chế cấp phát ổ cứng truyền thống (Provisioned Storage)

• Ở MySQL truyền thống (RDS / EC2):

  • Bạn phải mua trước một dung lượng cố định cho ổ cứng (ví dụ: cấp phát 500 GB ổ EBS).

  • Nếu hệ thống phát triển nhanh và chạm ngưỡng 500 GB, bạn phải thủ công (hoặc bật tính năng RDS Storage Auto-Scaling nhưng vẫn phải chờ AWS resize volume) thao tác mở rộng. Quá trình resize này đôi khi gây ra độ trễ I/O hoặc rủi ro khi hệ thống đang chịu tải cao.

  • Nếu cấp dư dung lượng từ đầu (ví dụ mua 2 TB nhưng chỉ dùng 100 GB), công ty sẽ lãng phí một khoản tiền lớn hàng tháng cho phần dung lượng bỏ không.

• Ở Amazon Aurora MySQL:

  • Không bao giờ có khái niệm "chọn dung lượng ổ cứng ban đầu".

  • Bạn khởi tạo cụm Aurora mà không cần chỉ định kích thước dung lượng lưu trữ (storage size). Hệ thống tự động quản lý mọi thứ từ dưới nền.

2. Cơ chế Storage Auto-Scaling hoạt động như thế nào?

Tầng lưu trữ của Aurora (như đã phân tích ở các bài trước) được cấu trúc thành một tập hợp các phân đoạn lưu trữ ảo hóa (virtual storage segments) dung lượng mỗi khối là 10 GB.

• Mở rộng tự động theo thời gian thực (Pay-as-you-go Storage):

  • Khi cơ sở dữ liệu của bạn sinh ra dữ liệu mới (INSERT, UPDATE, tạo bảng mới, ghi log), Aurora tự động cấp phát thêm các khối 10GB mới vào Aurora Storage Volume ngay lập tức mà không gây ra bất kỳ khoảng dừng hay gián đoạn nào (zero-downtime scaling).

  • Khởi điểm, dung lượng có thể chỉ vài GB. Khi hệ thống lớn dần, nó tự động scale mượt mà cho đến giới hạn hiện tại là 128 TB (tăng từ giới hạn 64TB trước đây).

• Thu hẹp tự động (Shrinking):

  • Không giống như ổ cứng EBS truyền thống (khi bạn DELETE hàng triệu bản ghi, dung lượng ổ cứng vẫn giữ nguyên mức cũ và bạn phải chạy lệnh OPTIMIZE TABLE hoặc thu hẹp thủ công rất phức tạp), Aurora tự động thu hồi dung lượng lưu trữ khi dữ liệu thực tế bên trong bị xóa hoặc giảm đi.

  • Bạn chỉ trả tiền chính xác cho số dung lượng dữ liệu đang thực sự tồn tại trên đĩa (storage consumed), giúp tối ưu hóa chi phí lưu trữ một cách triệt để.

3. Giới hạn tối đa (Maximum Storage Size) và Cảnh báo

Mặc dù Aurora tự động scale dung lượng, AWS vẫn yêu cầu bạn đặt một thông số gọi là Maximum Storage Size khi thiết lập cấu hình ban đầu hoặc thông qua Terraform:

• Thông số này đóng vai trò như một chốt chặn an toàn (Guardrail) nhằm ngăn chặn các sự cố rò rỉ dữ liệu hoặc câu lệnh INSERT lặp vô tận (infinite loop) do lỗi code backend khiến dung lượng phình to bất thường vượt quá ngân sách cho phép của công ty.

• Nếu dung lượng thực tế chạm đến ngưỡng Maximum này, Aurora sẽ chặn việc ghi dữ liệu mới và phát cảnh báo. Do đó, bạn nên cấu hình mức Maximum rộng rãi (ví dụ: 64TB hoặc 128TB tùy quy mô) và thiết lập cảnh báo CloudWatch Alarm nếu dung lượng đạt tới 80% mức dự kiến.

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

• Giải phóng khỏi nỗi lo Disk Full: Các kỹ sư backend hoàn toàn có thể yên tâm viết các câu lệnh lưu trữ log hệ thống, lịch sử giao dịch lớn vào cơ sở dữ liệu mà không cần phải đau đầu tính toán bài toán dung lượng đĩa cứng mỗi dịp cao điểm (như sự kiện Flash Sale, Black Friday).

• Kiểm soát chi phí qua CloudWatch: Hãy thiết lập các AWS CloudWatch Alarms theo dõi metric VolumeBytesUsed để nắm bắt tốc độ tăng trưởng dữ liệu hàng tháng của hệ thống, giúp team Product và Data có kế hoạch dự phóng tài nguyên chính xác.