Amazon Aurora MySQL Bài 44: Deep Dive vào Aurora Serverless v2: Cơ chế co giãn ACU và chiến lược tối ưu chi phí cho hệ thống tải biến động

Trong các hệ thống thương mại điện tử hoặc dịch vụ trực tuyến, lượng truy cập của người dùng không bao giờ đứng yên mà luôn biến động mạnh theo khung giờ (ví dụ: bùng nổ traffic vào giờ nghỉ trưa, khung giờ vàng buổi tối, hoặc sụt giảm sâu vào ban đêm). Việc lựa chọn cấu hình instance cố định (Provisioned Instances) thường dẫn đến hai bài toán khó xử: hoặc tốn kém lãng phí tài nguyên khi hệ thống ít khách, hoặc bị quá tải sập nguồn khi flash sale diễn ra đột ngột.

Bài viết này sẽ mổ xẻ chi tiết kiến trúc Aurora Serverless v2 và cách tinh chỉnh cơ chế co giãn tài nguyên tự động chuẩn xác.

1. Sự lột xác của Aurora Serverless v2 so với v1

Ở phiên bản Serverless v1 trước đây, khi hệ thống chuyển đổi trạng thái tải từ thấp sang cao (hoặc ngược lại), cơ sở dữ liệu thường gặp hiện tượng tạm ngưng (Pause/Resume) hoặc mất vài phút để scale, gây gián đoạn kết nối không phù hợp cho môi trường Production lớn.

Aurora Serverless v2 khắc phục triệt để các nhược điểm đó bằng một kiến trúc hoàn toàn mới:

• Co giãn tinh tế theo ACU (Aurora Capacity Unit): Mỗi ACU tương đương khoảng 2 GiB RAM kết hợp với vCPU và tài nguyên mạng tương ứng. Serverless v2 có thể co giãn dung lượng từ mức tối thiểu đến tối đa cực kỳ mịn màng.

• Thời gian co giãn tính bằng giây: Khả năng tăng/giảm tài nguyên diễn ra ngay lập tức dưới vài giây mà không làm gián đoạn các kết nối hiện tại hay làm thay đổi endpoints của cơ sở dữ liệu.

2. Cơ chế co giãn ACU bên dưới hoạt động như thế nào?

Khi ứng dụng của bạn nhận một lượng request khổng lồ đột ngột:

1. Phát hiện tải: Aurora liên tục giám sát các chỉ số sử dụng CPU, số lượng kết nối đồng thời và lượng dữ liệu trong Buffer Pool của instance.

2. Scale-up tức thì: Ngay khi phát hiện ngưỡng tài nguyên hiện tại sắp chạm trần, Aurora tự động cấp phát thêm vCPU và mở rộng RAM mà không cần khởi động lại (reboot) tiến trình MySQL bên dưới.

3. Scale-down thông minh: Khi qua khung giờ cao điểm, lượng request giảm xuống, Serverless v2 sẽ từ từ thu hẹp ACU trở lại mức tối thiểu để tiết kiệm chi phí tối đa cho doanh nghiệp.

3. Cấu hình Serverless v2 thực tế qua Terraform

Trong hạ tầng chuẩn, bạn có thể kết hợp cụm Aurora gồm cả Provisioned Writer và Serverless v2 Reader, hoặc cấu hình toàn bộ cụm chạy hoàn toàn trên Serverless v2:

Terraform

resource "aws_rds_cluster" "serverless_v2_cluster" {
  cluster_identifier     - "hieu-aurora-serverless-cluster"
  engine                 - "aurora-mysql"
  engine_version         - "8.0.mysql_aurora.3.04.2"
  
  # Cấu hình chế độ Serverless v2 cho cụm
  serverlessv2_scaling_configuration {
    min_capacity = 0.5 # Mức ACU tối thiểu khi ít traffic (tương đương ~1 GiB RAM)
    max_capacity = 64.0 # Mức ACU tối đa khi cao điểm (tương đương ~128 GiB RAM)
  }

  master_username        = "admin_hieu"
  master_password        = "SuperSecuredPassword123!"
  skip_final_snapshot    = true
}

4. Chiến lược Tối ưu chi phí (Cost Optimization) và Best Practices

• Thiết lập min_capacity hợp lý: Không nên để min_capacity quá thấp (như 0.5 ACU) cho các hệ thống có lượng request nền (background workers, cronjobs) diễn ra liên tục ban đêm, vì việc co giãn liên tục có thể tạo ra độ trễ nhỏ không cần thiết. Ngược lại, đặt min_capacity quá cao sẽ làm lãng phí tiền bạc.

• Kết hợp với AWS RDS Proxy: Đối với Serverless v2, việc kết hợp thêm AWS RDS Proxy là bắt buộc để ngăn chặn tình trạng sốc kết nối (Connection Storm) khi lượng container auto-scaling phình to cùng lúc với lượng ACU đang co giãn.

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

• Giám sát chỉ số ServerlessDatabaseCapacity trên CloudWatch: Hãy luôn theo dõi biểu đồ ACU thực tế để biết hệ thống của bạn đang tiêu thụ bao nhiêu tài nguyên trong các khung giờ khác nhau, từ đó điều chỉnh dải min_capacity và max_capacity cho tối ưu nhất với ngân sách công ty.