Aurora là dịch vụ cơ sở dữ liệu SQL được thiết kế, phát triển, và tối ưu hoá để chạy trên hạ tầng của AWS, cung cấp hiệu năng, sự linh hoạt và khả năng mở rộng cao hơn RDS và các CSDL truyền thống. Aurora cung cấp hai lựa chọn triển khai chính: Provisioned DB Cluster và Serverless, cùng tìm hiểu chi tiết dưới đây.
Trong bài này:
1. Aurora DB Cluster
1.1. Kiến trúc Aurora Cluster
Khác với RDS triển khai dưới dạng DB Instance đơn hoặc Multi-AZ, Aurora cung cấp sẵn triển khai dưới dạng Cluster (cụm Instance). Một Aurora Cluster gồm:
- Một Primary Instance hỗ trợ cả đọc và ghi dữ liệu.
- Tối đa 15 Aurora Replica chỉ hỗ trợ đọc dữ liệu, giúp tăng khả năng chịu tải đọc và tính khả dụng. Khi Primary Instance gặp sự cố, Aurora tự động thăng cấp một trong các Replica thành Primary Instance mới. Việc thăng cấp này diễn ra rất nhanh, trong vòng vài giây, nhanh hơn nhiều so với tạo lại Primary Instance mới từ bản sao lưu.
- Một ổ lưu trữ chung của cụm (Cluster Volume), chia sẻ dữ liệu giữa Primary Instance và Replica, lưu trữ và sao lưu trên 3 AZ trong một Region. Dung lượng lưu trữ tự động tăng thêm khi dữ liệu cần lưu trữ tăng. Ổ cứng lưu trữ sử dụng là SSD, IOPS cao, độ trễ thấp.
Khác biệt với RDS: Aurora Replica tăng cường cả tính khả dụng (tự động chuyển đổi dự phòng) và khả năng chịu tải đọc, trong khi Read Replica của RDS chủ yếu tăng khả năng chịu tải đọc, tính khả dụng kém hơn do yêu cầu chuyển đổi dự phòng thủ công, cần sử dụng thêm cấu hình Multi-AZ nếu muốn tự động.
1.2. Aurora Endpoint
Aurora cung cấp nhiều loại endpoint để kết nối đến Cluster, để người dùng có thể chọn lựa phù hợp với nhu cầu sử dụng:
- Cluster Endpoint: đây là endpoint chính của cluster, kết nối đến Primary Instance, hỗ trợ cả đọc và ghi.
- Reader Endpoint: kết nối đến các Replica, chỉ hỗ trợ đọc dữ liệu, dùng cho các tác vụ truy vấn. Aurora tự động phân phối tải đọc (load balancing) giữa các Replica để tối ưu hiệu năng. Reader Endpoint rất hữu ích khi ứng dụng nặng thao tác đọc, hoặc cần chạy nhiều truy vấn phân tích, báo cáo nội bộ.
- Instance Endpoint: mỗi Instance (Primary hoặc Replica) đều có endpoint riêng, thường chỉ dùng khi cần kết nối trực tiếp để kiểm tra trạng thái, gỡ lỗi, bảo trì.
- Custom Endpoint: người dùng có thể tạo endpoint tuỳ chỉnh, gồm một nhóm các Instance tuỳ ý. Cách này hỗ trợ phân phối tải đọc theo nhu cầu riêng, ví dụ như nhóm các Replica ở một AZ cụ thể, hoặc có cấu hình cao. Bạn đọc có thể tìm hiểu thêm tại đây.
1.3. Sao lưu, Phục hồi, Nhân bản
Giống RDS, Aurora cũng cung cấp hai phương thức sao lưu:
-
Sao lưu tự động (Automated Backup): Aurora tự động sao lưu toàn bộ Cluster Volume, với retention period từ 1 đến 35 ngày. Việc sao lưu không ảnh hưởng đến hiệu năng. Khi cần phục hồi, có thể khôi phục toàn bộ Cluster về một thời điểm cụ thể trong retention period, tạo ra một Cluster mới. Nếu muốn khôi phục về thời điểm ngoài retention period, phải sử dụng snapshot thủ công, vì các bản sao lưu tự động chỉ được giữ trong khoảng thời gian đó.
-
Snapshot thủ công (Manual Snapshot): người dùng có thể tự tạo snapshot của Aurora Cluster bất cứ lúc nào. Snapshot được tạo theo cơ chế tăng dần, tức chỉ snapshot đầu tiên là đầy đủ, các snapshot sau lưu các thay đổi so với snapshot trước đó, để tiết kiệm dung lượng lưu trữ. Snapshot thủ công sẽ được giữ cho đến khi người dùng xóa nó, không bị mất khi xoá Cluster.
Cũng có thể dùng AWS Backup để quản lý việc sao lưu Aurora Cluster. Snapshot do AWS Backup tạo ra được xem là snapshot thủ công, không tính vào giới hạn snapshot Aurora của tài khoản.
Ngoài ra, Aurora hỗ trợ nhân bản (clone) một cluster đang chạy thành một cluster mới, thay vì phải phục hồi từ bản sao lưu hoặc snapshot. Aurora sử dụng cơ chế copy-on-write để nhân bản. Khi nhân bản, cluster mới sẽ chia sẻ cùng dữ liệu vật lý với cluster gốc, chỉ khi có thay đổi mới ghi dữ liệu mới. Cách này giúp tiết kiệm thời gian và dung lượng lưu trữ so với việc phục hồi từ snapshot. Tính năng này hữu ích để tạo môi trường thử nghiệm nhanh từ dữ liệu thực tế mà không lo ảnh hưởng đến dữ liệu gốc.
1.4. Quay lui
Thay vì dùng bản sao lưu hoặc snapshot để khôi phục cluster về trạng thái ở một thời điểm nào đó, Aurora hỗ trợ tính năng quay lui (backtrack), cho phép trực tiếp đưa trạng thái của cluster về một thời điểm trong vòng 72 giờ gần nhất mà không cần tạo cluster mới.
Tính năng này rất hữu ích khi cần khôi phục dữ liệu sau các thao tác ghi nhầm hoặc lỗi ứng dụng, nhanh hơn nhiều (vài phút) so với việc phục hồi từ sao lưu hoặc snapshot (có thể tốn hàng giờ). Một vài lưu ý:
- Tính năng này muốn dùng phải được bật khi tạo cluster, không thể bật cho cluster đang chạy.
- Không thể quay lui một cluster nhân bản (clone) về thời điểm trước khi nó được tạo ra, phải thực hiện ở cluster gốc.
- Khi thực hiện quay lui, các kết nối đến cluster sẽ bị gián đoạn. Trong quá trình quay lui, Aurora tạm dừng CSDL, ngắt kết nối, và loại bỏ các thao tác dữ liệu chưa được hoàn thành (uncommitted transaction).
2. Aurora Serverless
Đây là lựa chọn triển khai Aurora mà không cần cấp phát và quản lý cluster cụ thể nào, chỉ cần chỉ định cấu hình về dung lượng tính toán và bộ nhớ cần thiết. Aurora Serverless tự động bật, tắt, điều chỉnh tài nguyên dựa trên tải thực tế của ứng dụng.
Khái niệm cốt lõi trong Aurora Serverless là Aurora Capacity Unit (ACU). Mỗi ACU tương đương với 2 GiB RAM và lượng CPU, mạng tương ứng. Khi tạo một cluster Aurora Serverless, người dùng chỉ định số ACU tối thiểu (ít nhất là 0.5 ACU) và tối đa (128 hoặc 256 ACU tuỳ DB Engine) mà cluster có thể sử dụng. Aurora Serverless tự động điều chỉnh số ACU để đáp ứng nhu cầu tải trong phạm vi đã định.
Tại thời điểm viết bài, ở us-east-1, mỗi ACU có giá $0.12/giờ cho Aurora Standard và $0.156/giờ cho Aurora I/O-Optimized (một cấu hình tối ưu cho các ứng dụng cần IOPS cao).
Khi nào nên dùng Aurora Serverless?
- Ứng dụng có lưu lượng truy cập không ổn định, biến động lớn theo thời gian, có thể cao đột biến trong một thời gian ngắn, sau đó giảm mạnh hoặc không có truy cập. Ngược lại, nếu ứng dụng có lưu lượng truy cập ổn định, liên tục, thì nên dùng Aurora Cluster, chi phí sẽ thấp hơn.
- Làm CSDL cho việc kiểm thử hoặc phát triển, khi không cần cluster hoạt động liên tục, chỉ cần trả phí khi sử dụng.
3. Aurora Global Database
Mặc định, mỗi Aurora Cluster (cả cấp phát và serverless) chỉ hoạt động trong một Region duy nhất. Nếu cần khả năng phục hồi cao hơn, hoặc muốn giảm độ trễ truy cập trong trường hợp ứng dụng có quy mô toàn cầu, có thể sử dụng Aurora Global Database. Tính năng này cho phép tạo các tối đa 10 cluster phụ (secondary cluster) ở các Region khác, tự động đồng bộ dữ liệu với cluster chính qua mạng toàn cầu của AWS với độ trễ thấp (dưới 1 giây).
Chỉ có Primary Instance trong cluster chính mới hỗ trợ đọc và ghi dữ liệu, các cluster phụ chỉ hỗ trợ đọc dữ liệu qua Replica (tối đa 15 Replica trên cluster chính và 16 Replica trên cluster phụ).
Khi cluster chính gặp sự cố, có thể thăng cấp một trong các cluster phụ thành cluster chính mới để tiếp tục hoạt động. RPO thường chỉ tính bằng giây, mất mát một lượng nhỏ dữ liệu.
Tài liệu tham khảo
- Tổng quan về Aurora Cluster
- Aurora Endpoint
- Nhân bản Aurora Cluster
- Aurora Serverless v2 - Jeremy Daly
- Aurora Global Database
Qua loạt bài vừa rồi, mình đã trình bày tổng quan về các dịch vụ CSDL SQL trên AWS, bao gồm RDS và Aurora, cùng các tính năng chính cần ghi nhớ. Tiếp theo, nhân việc đã đề cập đến khái niệm Serverless, hãy tìm hiểu kỹ hơn về mô hình này, cùng với một kiến trúc liên quan mà hẳn bạn đã từng nghe đến: Microservice. Đầu tiên, tất nhiên sẽ là Lambda.