RDS, Aurora & ElastiCache – Database được quản lý

1. Amazon RDS là gì?

RDS viết tắt của Relational Database Service — dịch vụ database được AWS quản lý (managed) dành cho các database dùng SQL làm ngôn ngữ truy vấn. Thay vì bạn tự dựng một máy chủ, cài PostgreSQL, cấu hình backup, theo dõi disk đầy… bạn chỉ chọn engine và cấu hình, AWS làm phần còn lại.

RDS hỗ trợ các engine sau:

Postgres
MySQL
MariaDB
Oracle
Microsoft SQL Server
IBM DB2
Aurora (database độc quyền của AWS)

Lợi thế của RDS so với tự cài database trên EC2

Câu hỏi “tại sao không tự cài MySQL trên một EC2 rồi xong?” xuất hiện rất nhiều trong đề thi. Lý do là RDS là một managed service, nó tặng bạn hàng loạt thứ miễn công sức:

Tự động provisioning và patch hệ điều hành.
Backup liên tục và khả năng restore về một mốc thời gian cụ thể — gọi là Point in Time Restore.
Dashboard giám sát (monitoring).
Read replica để tăng hiệu năng đọc.
Cấu hình Multi AZ cho DR (Disaster Recovery).
Maintenance window cho việc nâng cấp.
Khả năng scaling (cả dọc và ngang).
Storage nằm trên EBS.
NHƯNG bạn không thể SSH vào instance của RDS.

RDS – Storage Auto Scaling

Tính năng này giúp bạn tăng dung lượng lưu trữ của RDS DB instance một cách động. Khi RDS phát hiện bạn đang sắp hết dung lượng trống, nó tự scale — bạn không phải ngồi canh và scale tay nữa.

Bạn phải đặt Maximum Storage Threshold (giới hạn trên cho dung lượng DB).
RDS tự động thay đổi storage khi thỏa cả ba điều kiện:
- Dung lượng trống nhỏ hơn 10% dung lượng đã cấp (allocated storage).
- Tình trạng thiếu dung lượng đó kéo dài ít nhất 5 phút.
- Đã 6 giờ kể từ lần thay đổi trước.
Hữu ích cho các ứng dụng có tải không dự đoán được.
Hỗ trợ tất cả các RDS database engine.

2. RDS Read Replicas – scale phần đọc

Hãy tưởng tượng database chính của bạn đang phục vụ cả việc ghi (đặt hàng) lẫn việc đọc (xem sản phẩm, chạy báo cáo). Phần đọc thường chiếm phần lớn tải. Read Replica là các bản sao chỉ đọc của database, giúp bạn chuyển tải đọc sang đó và giải phóng database chính.

Tối đa 15 Read Replica.
Có thể nằm trong cùng AZ, khác AZ (Cross AZ), hoặc khác Region (Cross Region).
Replication là ASYNC (bất đồng bộ), nên dữ liệu đọc được là eventually consistent (có thể chậm hơn bản chính một chút).
Replica có thể được promote thành một database độc lập của riêng nó.
Ứng dụng phải cập nhật connection string để thực sự dùng được read replica — nó không tự động chia tải.

Use case tiêu biểu

Kịch bản kinh điển trong slide:

Bạn có một production database đang chịu tải bình thường.
Bạn muốn chạy một ứng dụng reporting để làm analytics.
Bạn tạo một Read Replica và chạy tải mới ở đó.
Ứng dụng production không bị ảnh hưởng.

Điều quan trọng: read replica chỉ dùng cho các câu lệnh dạng SELECT (đọc) — không dùng cho INSERT, UPDATE, DELETE.

Chi phí mạng của Read Replica

Trên AWS, khi dữ liệu đi từ AZ này sang AZ khác thì có phí mạng. Nhưng với RDS Read Replica có một ngoại lệ đáng nhớ:

Tình huống	Chi phí
Read Replica cùng Region, khác AZ (ví dụ `us-east-1a` → `us-east-1b`)	Miễn phí
Read Replica khác Region (ví dụ `us-east-1a` → `eu-west-1b`)	Có phí ($$$)

3. RDS Multi AZ – cho Disaster Recovery

Multi AZ trông giống Read Replica nhưng mục đích hoàn toàn khác: nó không dùng để scale, mà dùng để sống sót qua thảm họa.

Replication là SYNC (đồng bộ) — mọi ghi phải được xác nhận ở cả hai bên.
Một DNS name duy nhất — ứng dụng tự động failover sang máy standby.
Tăng tính sẵn sàng (availability).
Failover khi mất AZ, mất network, lỗi instance hoặc lỗi storage.
Không cần can thiệp thủ công trong ứng dụng.
Không dùng để scaling — máy standby không nhận traffic đọc.
Lưu ý: bản thân các Read Replica cũng có thể được cấu hình Multi AZ để phục vụ DR.

Mô hình: RDS Master DB instance ở AZ A nhận cả writes và reads; RDS DB instance standby ở AZ B nhận dữ liệu qua SYNC replication và ngồi chờ.

Chuyển từ Single-AZ sang Multi-AZ

Đây là một thao tác không có downtime — không cần dừng database:

Bạn chỉ cần bấm “modify” trên database.
Bên trong, AWS lần lượt làm những việc sau:
1. Một snapshot được tạo.
2. Một database mới được restore từ snapshot đó trong một AZ mới.
3. Synchronization được thiết lập giữa hai database.

4. RDS Custom

RDS Custom là database Oracle và Microsoft SQL Server được quản lý, nhưng cho phép bạn tùy biến cả OS lẫn database. Nó nằm giữa “RDS thuần” và “tự cài trên EC2”.

RDS: tự động hóa việc setup, vận hành và scaling database trên AWS.
Custom: cho bạn truy cập vào database và OS bên dưới, nhờ đó bạn có thể:
- Cấu hình các setting.
- Cài patch.
- Bật các native feature.
- Truy cập EC2 instance bên dưới bằng SSH hoặc SSM Session Manager.
Muốn tùy biến thì phải tắt Automation Mode; nên chụp DB snapshot trước khi làm.

So sánh nhanh: RDS = toàn bộ database và OS do AWS quản lý; RDS Custom = bạn có full admin access vào OS bên dưới và database.

5. Amazon Aurora

Aurora là công nghệ độc quyền của AWS (không phải open source). Nó được thiết kế riêng cho cloud và là lựa chọn mặc định cho các hệ thống cần hiệu năng và HA cao.

Hỗ trợ Postgres và MySQL dưới dạng Aurora DB — nghĩa là driver của bạn hoạt động y như thể Aurora là một database Postgres hoặc MySQL thật.
Aurora được “tối ưu cho AWS cloud” và tuyên bố hiệu năng gấp 5 lần MySQL trên RDS, gấp hơn 3 lần Postgres trên RDS.
Storage của Aurora tự động lớn lên theo bước 10 GB, tối đa 128 TB.
Aurora có thể có tới 15 replica, và quá trình replication nhanh hơn MySQL — độ trễ replica dưới 10 ms.
Failover trong Aurora là tức thời (instantaneous). HA là tính chất native của nó.
Aurora đắt hơn RDS khoảng 20% — nhưng hiệu quả hơn.

High Availability và Read Scaling của Aurora

Đây là phần kiến trúc quan trọng nhất của Aurora, và cũng là phần hay được hỏi nhất:

6 bản sao dữ liệu trải trên 3 AZ:
- Cần 4 trong 6 bản sao để ghi.
- Cần 3 trong 6 bản sao để đọc.
Self healing nhờ replication peer-to-peer — dữ liệu hỏng tự được vá.
Storage được striped trên hàng trăm volume.
Một Aurora instance nhận writes (master).
Failover tự động cho master trong dưới 30 giây.
Master + tối đa 15 Aurora Read Replica cùng phục vụ reads.
Hỗ trợ Cross Region Replication.

Writer Endpoint và Reader Endpoint

Aurora DB Cluster ngồi trên một Shared storage Volume tự mở rộng từ 10 GB tới 128 TB, và cung cấp cho client hai endpoint:

Writer Endpoint — luôn trỏ tới master. Kể cả khi failover đổi master, endpoint này vẫn đúng, ứng dụng không cần biết.
Reader Endpoint — thực hiện connection load balancing, tự chia kết nối ra các read replica.

Nhờ đó Aurora có Replica Auto Scaling: khi client gửi rất nhiều request và CPU usage của các replica tăng, Aurora thêm replica mới và Reader Endpoint được mở rộng để bao gồm cả replica mới — ứng dụng không phải đổi gì.

Custom Endpoints

Bạn có thể định nghĩa một tập con các Aurora Instance thành một Custom Endpoint.

Ví dụ: chạy các truy vấn analytical trên những replica cụ thể — chẳng hạn hai replica loại db.r5.2xlarge mạnh hơn, trong khi các replica db.r3.large phục vụ traffic thường.
Sau khi định nghĩa Custom Endpoint, Reader Endpoint thường không còn được dùng nữa.

Các tính năng khác của Aurora

Automatic fail-over
Backup and Recovery
Isolation and security
Industry compliance
Push-button scaling
Automated Patching with Zero Downtime
Advanced Monitoring
Routine Maintenance
Backtrack: phục hồi dữ liệu về bất kỳ thời điểm nào mà không cần dùng tới backup.

Aurora Serverless

Aurora Serverless tự lo việc khởi tạo và scale database cho bạn:

Tự động khởi tạo database và auto-scaling dựa trên mức sử dụng thực tế.
Phù hợp cho các workload không thường xuyên, ngắt quãng hoặc không dự đoán được.
Không cần capacity planning.
Trả tiền theo giây, có thể tiết kiệm hơn đáng kể.

Về kiến trúc, client kết nối tới một Proxy Fleet do Aurora quản lý, phía sau là shared storage volume.

Aurora và multi-region

Có hai cách để Aurora vươn ra nhiều region:

Aurora Cross Region Read Replicas:

Hữu ích cho disaster recovery.
Đơn giản để triển khai.

Aurora Global Database (được khuyến nghị):

1 Primary Region (read / write).
Tối đa 10 secondary region (chỉ đọc), độ trễ replication dưới 1 giây.
Tối đa 16 Read Replica cho mỗi secondary region.
Giúp giảm latency cho người dùng ở xa.
Promote một region khác (cho disaster recovery) có RTO dưới 1 phút.
Replication cross-region điển hình mất dưới 1 giây.

Aurora Machine Learning

Tính năng này cho phép bạn thêm dự đoán dựa trên ML vào ứng dụng thông qua SQL — tích hợp đơn giản, được tối ưu và bảo mật giữa Aurora và các dịch vụ ML của AWS.

Các dịch vụ được hỗ trợ: Amazon SageMaker (dùng với bất kỳ ML model nào) và Amazon Comprehend (phân tích cảm xúc – sentiment analysis).
Bạn không cần có kinh nghiệm về ML.
Use case: phát hiện gian lận (fraud detection), nhắm quảng cáo (ads targeting), phân tích cảm xúc, gợi ý sản phẩm.

Luồng hoạt động: ứng dụng gửi một SQL query (“sản phẩm gợi ý?”) tới Aurora; Aurora gửi dữ liệu (profile người dùng, lịch sử mua hàng…) tới SageMaker / Comprehend; nhận về prediction (“áo đỏ, quần xanh…”); rồi trả kết quả query cho ứng dụng.

Babelfish for Aurora PostgreSQL

Babelfish cho phép Aurora PostgreSQL hiểu được các câu lệnh dành cho MS SQL Server (ví dụ T-SQL).

Nhờ đó, ứng dụng viết cho Microsoft SQL Server có thể chạy trên Aurora PostgreSQL.
Không cần hoặc cần rất ít thay đổi code, vì vẫn dùng chính driver client của MS SQL Server.
Sau khi migrate database (bằng AWS SCT và DMS), vẫn dùng được nguyên các ứng dụng cũ.

Aurora PostgreSQL với Babelfish nhận cả hai kiểu client: ứng dụng dùng SQL Server Client Driver nói T-SQL, và ứng dụng PostgreSQL dùng PostgreSQL Driver nói PL/pgSQL.

6. Backup, restore và cloning

RDS Backups

Automated backups:

Full backup hàng ngày của database (trong backup window).
Transaction log được backup mỗi 5 phút bởi RDS.
⇒ nhờ đó bạn có thể restore về bất kỳ thời điểm nào, từ bản backup cũ nhất cho tới 5 phút trước.
Thời gian giữ (retention) từ 1 đến 35 ngày; đặt 0 để tắt automated backup.

Manual DB Snapshots:

Do người dùng tự kích hoạt.
Giữ backup bao lâu cũng được.

Một mẹo đáng nhớ: với một RDS database đã stop, bạn vẫn phải trả tiền cho storage. Nếu định dừng nó trong thời gian dài, hãy snapshot rồi restore lại sau thay vì để nó stop.

Aurora Backups

Automated backups: từ 1 đến 35 ngày và không thể tắt; cho phép point-in-time recovery trong khoảng đó.
Manual DB Snapshots: do người dùng tự kích hoạt, giữ bao lâu cũng được.

Các phương án restore

Điều đầu tiên cần nhớ: restore một backup hoặc snapshot của RDS / Aurora luôn tạo ra một database MỚI — không ghi đè lên database cũ.

Restore một MySQL RDS database từ S3:

Tạo backup của database on-premises.
Lưu nó trên Amazon S3 (object storage).
Restore file backup đó vào một RDS instance mới chạy MySQL.

Restore một MySQL Aurora cluster từ S3:

Tạo backup của database on-premises bằng Percona XtraBackup.
Lưu file backup trên Amazon S3.
Restore file backup đó vào một Aurora cluster mới chạy MySQL.

Aurora Database Cloning

Cloning tạo một Aurora DB Cluster mới từ một cluster đang có — và nó nhanh hơn snapshot & restore.

Dùng giao thức copy-on-write:
- Ban đầu, cluster mới dùng chung data volume với cluster gốc — nhanh và hiệu quả, không cần copy gì cả.
- Khi dữ liệu ở cluster mới bị thay đổi, storage bổ sung mới được cấp và dữ liệu mới được copy ra để tách biệt.
Rất nhanh và tiết kiệm chi phí.
Hữu ích để tạo một database “staging” từ database “production” mà không ảnh hưởng tới production.

7. Bảo mật RDS & Aurora

At-rest encryption (mã hóa khi lưu):
- Mã hóa master & replica bằng AWS KMS — phải được định nghĩa ngay lúc launch.
- Nếu master không được mã hóa thì read replica cũng không thể được mã hóa.
- Muốn mã hóa một database đang chưa mã hóa, phải đi qua đường DB snapshot & restore dưới dạng đã mã hóa.
In-flight encryption (mã hóa trên đường truyền): TLS-ready mặc định; dùng AWS TLS root certificate ở phía client.
IAM Authentication: dùng IAM role để kết nối vào database thay cho username/password.
Security Groups: kiểm soát truy cập ở tầng network vào RDS / Aurora DB.
Không có SSH, ngoại trừ RDS Custom.
Audit Logs có thể được bật và gửi tới CloudWatch Logs để lưu lâu hơn.

8. Amazon RDS Proxy

RDS Proxy là một database proxy được quản lý hoàn toàn cho RDS. Nó giải quyết một bài toán rất thực tế: hàng nghìn Lambda function cùng mở kết nối tới database và làm database kiệt sức.

Cho phép ứng dụng pool và chia sẻ (share) các kết nối DB đã thiết lập với database.
Tăng hiệu quả của database bằng cách giảm áp lực lên tài nguyên DB (ví dụ CPU, RAM) và giảm số kết nối mở (cùng các timeout kèm theo).
Serverless, autoscaling, highly available (multi-AZ).
Giảm thời gian failover của RDS & Aurora tới 66%.
Hỗ trợ RDS (MySQL, PostgreSQL, MariaDB, MS SQL Server) và Aurora (MySQL, PostgreSQL).
Không cần thay đổi code với phần lớn ứng dụng.
Có thể bắt buộc dùng IAM Authentication cho DB, và lưu credential an toàn trong AWS Secrets Manager.
RDS Proxy không bao giờ truy cập được từ Internet — bắt buộc phải truy cập từ trong VPC.

9. Amazon ElastiCache

Công thức để nhớ ElastiCache rất gọn: RDS là để có Relational Database được quản lý, thì ElastiCache là để có Redis hoặc Memcached được quản lý.

Cache là các in-memory database — hiệu năng rất cao, độ trễ thấp.
Giúp giảm tải cho database với các workload đọc nhiều (read intensive).
Giúp ứng dụng của bạn trở nên stateless.
AWS lo phần bảo trì / patch OS, tối ưu, setup, cấu hình, monitoring, khôi phục khi lỗi và backup.
Nhưng: dùng ElastiCache đòi hỏi thay đổi code ứng dụng khá nhiều.

Kiến trúc 1 – DB Cache

Đây là use case phổ biến nhất:

Ứng dụng truy vấn ElastiCache trước; nếu không có (cache miss) thì lấy từ RDS và ghi vào ElastiCache.
Giúp giảm tải cho RDS.
Cache phải có một invalidation strategy để đảm bảo chỉ dữ liệu mới nhất được dùng.

Kiến trúc 2 – User Session Store

Người dùng đăng nhập vào một trong các instance của ứng dụng.
Ứng dụng ghi dữ liệu session vào ElastiCache.
Người dùng tiếp theo rơi vào một instance khác của ứng dụng.
Instance đó lấy lại dữ liệu session và người dùng vẫn đang ở trạng thái đã đăng nhập.

Đây chính là cách làm cho một web app stateless mà vẫn giữ được session.

Redis vs Memcached

REDIS	MEMCACHED
Multi AZ với Auto-Failover	Multi-node để phân mảnh dữ liệu (sharding)
Read Replica để scale reads và có high availability	Không có high availability (không replication)
Data Durability nhờ AOF persistence	Không lưu bền (non persistent)
Có tính năng Backup and restore	Backup and restore (Serverless)
Hỗ trợ Sets và Sorted Sets	Kiến trúc multi-threaded

Nói ngắn gọn: Redis = replication, Memcached = sharding.

Bảo mật cho ElastiCache

ElastiCache hỗ trợ IAM Authentication cho Redis.
IAM policy trên ElastiCache chỉ dùng cho bảo mật ở tầng AWS API — không phải để kiểm soát truy cập vào dữ liệu trong cache.
Redis AUTH:
- Bạn có thể đặt một “password/token” khi tạo Redis cluster.
- Đây là một lớp bảo mật bổ sung cho cache, nằm trên security group.
- Hỗ trợ SSL in-flight encryption.
Memcached: hỗ trợ xác thực dựa trên SASL (mức nâng cao).

Các pattern dùng cache

Lazy Loading: mọi dữ liệu đọc đều được cache; dữ liệu trong cache có thể bị cũ (stale).
Write Through: thêm hoặc cập nhật dữ liệu vào cache ngay khi ghi vào DB — không có dữ liệu cũ.
Session Store: lưu dữ liệu session tạm thời trong cache (dùng tính năng TTL).

Slide còn dẫn một câu nói vui rất đúng: trong khoa học máy tính chỉ có hai việc khó là cache invalidation và đặt tên.

Use case của Redis – Gaming Leaderboard

Bảng xếp hạng game (Gaming Leaderboard) là bài toán tính toán phức tạp nếu làm bằng database thường, nhưng lại rất tự nhiên với Redis:

Redis Sorted Set đảm bảo cả tính duy nhất (uniqueness) lẫn thứ tự của phần tử.
Mỗi lần thêm một phần tử mới, nó được xếp hạng theo thời gian thực rồi chèn vào đúng vị trí.

Kết quả là một Real-time Leaderboard với nhiều node ElastiCache for Redis cùng phục vụ.

Tóm tắt nhanh

Chủ đề	Cần nhớ
RDS engine	Postgres, MySQL, MariaDB, Oracle, MS SQL Server, IBM DB2, Aurora
RDS managed	Auto provisioning, OS patching, backup liên tục + Point in Time Restore, read replica, Multi AZ, maintenance window; không SSH được
Storage Auto Scaling	Cần Maximum Storage Threshold; kích hoạt khi free < 10%, kéo dài 5 phút, cách lần trước 6 giờ
Read Replica	Tối đa 15; ASYNC, eventually consistent; chỉ `SELECT`; phải đổi connection string; cùng region thì miễn phí traffic inter-AZ
Multi AZ	SYNC, một DNS name, tự failover, dùng cho DR chứ không để scale; bật không cần downtime
RDS Custom	Chỉ Oracle & MS SQL Server; có SSH / SSM Session Manager; phải tắt Automation Mode
Aurora	Postgres & MySQL compatible; 5x MySQL, 3x Postgres; storage tăng 10 GB tới 128 TB; 15 replica, lag < 10 ms; đắt hơn RDS 20%
Aurora storage	6 bản sao trên 3 AZ; 4/6 để ghi, 3/6 để đọc; self healing; failover master < 30 giây
Aurora endpoint	Writer Endpoint (master) · Reader Endpoint (load balancing) · Custom Endpoint (tập con instance)
Aurora Global Database	1 primary + tối đa 10 secondary region, lag < 1 giây, 16 replica/region, promote với RTO < 1 phút
Backup	RDS automated: 1–35 ngày, đặt 0 để tắt, transaction log mỗi 5 phút. Aurora automated: 1–35 ngày, không tắt được
Aurora Cloning	copy-on-write, nhanh hơn snapshot & restore, dùng để tạo staging từ production
Bảo mật	KMS at-rest phải bật lúc launch; master không mã hóa ⇒ replica không mã hóa được; TLS-ready; IAM Authentication; audit log → CloudWatch Logs
RDS Proxy	Pool connection, giảm failover tới 66%, serverless multi-AZ, chỉ truy cập từ VPC
ElastiCache	Managed Redis / Memcached; giảm tải DB, làm app stateless; cần sửa code nhiều
Redis vs Memcached	Redis: Multi AZ + auto-failover, read replica, AOF persistence, Sorted Sets · Memcached: sharding, không HA, non persistent, multi-threaded
Cache pattern	Lazy Loading (có thể stale) · Write Through (không stale) · Session Store (dùng TTL)