Amazon Aurora MySQL Bài 19: Sử dụng Aurora Serverless v2: Khi nào nên dùng scale tự động theo tải thực tế?

Khi thiết kế hạ tầng cơ sở dữ liệu cho các ứng dụng có lượng truy cập biến động mạnh (ví dụ như các chiến dịch Flash Sale đột ngột tại Hasaki hoặc các hệ thống SaaS có lượng user thay đổi theo khung giờ trong ngày), bài toán chọn loại instance luôn nan giải: chọn instance nhỏ thì sợ sập khi quá tải, mà chọn instance khủng (như db.r6g.4xlarge) thì lãng phí tiền bạc phần lớn thời gian khi hệ thống ít người dùng.

Amazon Aurora Serverless v2 ra đời để giải quyết triệt để bài toán này. Bài viết này sẽ mổ xẻ cơ chế hoạt động và thời điểm vàng để đưa Serverless v2 vào môi trường thực tế.

1. Aurora Serverless v2 là gì? (Khác biệt hoàn toàn so với Serverless v1)

Nhiều kỹ sư khi nghe từ "Serverless" thường liên tưởng đến các dịch vụ scale-to-zero (tự động tắt hẳn khi không có request) và gặp hiện tượng "Cold Start" (độ trễ lớn khi có request đầu tiên đánh thức database).

• Aurora Serverless v1 (Thế hệ cũ): Từng bị phàn nàn vì khi không có tải, database sẽ tạm ngưng hoạt động (pause) và khi có request mới gọi vào, mất từ 5 đến 10 giây để "đánh thức" (resume), gây timeout cho ứng dụng.

• Aurora Serverless v2 (Thế hệ hiện tại): Được thiết kế hoàn toàn khác biệt dành cho Enterprise. Nó không bao giờ tạm ngưng (No Pause), luôn sẵn sàng 24/7 ở cấp độ kết nối mạng và tầng lưu trữ, nhưng có khả năng tự động co giãn tài nguyên tính toán (CPU và RAM) theo chiều dọc (Vertical Auto-scaling) theo từng mili-giây dựa trên tải thực tế của ứng dụng.

2. Cơ chế hoạt động dựa trên ACU (Aurora Capacity Units)

Aurora Serverless v2 đo lường sức mạnh tính toán thông qua một đơn vị gọi là ACU (Aurora Capacity Units):

• 1 ACU tương đương khoảng 2 GiB RAM cùng với lượng CPU và băng thông mạng tương ứng.

• Bạn cấu hình cho một instance Serverless v2 chạy trong một khoảng giới hạn, ví dụ từ Minimum ACU = 0.5 (1 GiB RAM) đến Maximum ACU = 64 (128 GiB RAM).

• Khi lượng truy vấn (SELECT, INSERT) tăng vọt, hệ thống tự động bơm thêm CPU và RAM vào instance trong vòng tích tắc mà không cần khởi động lại (Restart), không làm gián đoạn hay ngắt bất kỳ kết nối nào của ứng dụng backend đang chạy. Khi hết cao điểm, nó tự động co nhỏ lại để tiết kiệm chi phí.

3. Khi nào nên sử dụng Aurora Serverless v2?

Không phải mọi hệ thống đều phù hợp với Serverless v2. Dưới đây là các trường hợp "vàng" nên đưa vào kiến trúc:

a. Tải biến động mạnh theo giờ hoặc theo sự kiện (Spiky & Unpredictable Workloads)

• Ví dụ: Các trang thương mại điện tử có lượng truy cập cực lớn vào khung giờ vàng (12h trưa hoặc 20h tối) hoặc các đợt Flash Sale chớp nhoáng. Serverless v2 tự động phình to tài nguyên để gánh tải lúc cao điểm và tự động teo nhỏ lại vào ban đêm khi ít người mua hàng.

b. Môi trường Non-Production (Staging, Testing, Development)

• Các môi trường dev thường xuyên bỏ không vào ban đêm và cuối tuần. Thay vì giữ một cụm Provisioned tốn kém, dùng Serverless v2 với mức Minimum ACU thấp (ví dụ 0.5 ACU) giúp cắt giảm tới 60% - 80% chi phí hạ tầng cho công ty.

c. Hệ thống Multi-tenant hoặc các ứng dụng mới ra mắt (MVPs)

• Khi bạn chưa thể dự báo chính xác lượng user sẽ đăng ký và sử dụng trong 3 tháng tới, việc cấu hình một cụm Serverless v2 giúp hệ thống tự động lớn lên cùng doanh nghiệp mà không phải đau đầu lập kế hoạch nâng cấp phần cứng thủ công.

4. Kết hợp Provisioned và Serverless trong cùng một Cluster

Một điểm cực kỳ thông minh của Aurora là bạn có thể trộn lẫn các loại node trong cùng một cụm Aurora Cluster:

• Writer: Giữ nguyên một instance cố định loại Provisioned (db.r6g.xlarge) để đảm bảo hiệu năng ghi ổn định tuyệt đối không bị ảnh hưởng bởi độ trễ co giãn.

• Readers: Cấu hình các Read Replicas chạy dưới dạng Serverless v2. Khi lượng người dùng đổ xô vào xem sản phẩm (tác vụ đọc), các Reader Serverless sẽ tự động phình to RAM/CPU để gánh tải đọc khổng lồ, sau đó tự xẹp xuống khi hết giờ cao điểm.

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

• Thiết lập Guardrail cẩn thận: Luôn luôn đặt giới hạn Maximum ACU hợp lý. Đừng để mức Max quá cao mà không có cảnh báo (CloudWatch Alarm), vì nếu xảy ra lỗi code backend gây ra vòng lặp vô tận (infinite loop) gọi query liên tục, Serverless v2 sẽ tự động scale lên mức tối đa và tạo ra một "cú sốc hóa đơn" AWS vào cuối tháng.

• Chi phí ACU vs Provisioned: Hãy tính toán kỹ: Nếu hệ thống của bạn có tải cực kỳ phẳng, ổn định 24/7 ở mức cao (ví dụ luôn chạy 80% công suất), việc mua Reserved Instance theo mô hình Provisioned thường sẽ có giá tối ưu hơn so với dùng Serverless v2 liên tục ở mức cao.