Trong các hệ thống hiện đại, database là thành phần cốt lõi ảnh hưởng trực tiếp đến hiệu năng và khả năng mở rộng. Thay vì tự vận hành database phức tạp, các AWS Managed Database Services giúp đơn giản hóa việc quản lý thông qua các tính năng như backup, scaling và high availability.
AWS cung cấp nhiều dịch vụ database khác nhau, nổi bật như Amazon RDS, Amazon Aurora và Amazon ElastiCache, mỗi dịch vụ phù hợp với những use case riêng.
Chẳng hạn khi tự cài DB trên EC2, bạn phải lo toàn bộ: cài đặt, patching OS, patching DB engine, backup, replication, failover, monitoring, scaling… Đây là việc tốn thời gian và dễ sai sót.
Managed Database (RDS, Aurora, ElastiCache) — AWS xử lý hầu hết phần hạ tầng:
Bạn tự quản (EC2 + DB)
AWS managed (RDS/Aurora)
Cài đặt DB engine
✅ AWS
OS patching
✅ AWS
DB engine patching
✅ AWS
Automated backup
✅ AWS
Multi-AZ replication
✅ AWS
Failover tự động
✅ AWS
Schema, queries, data
Customer
Security Group, IAM
Customer
Encryption settings
Customer
Đánh đổi: bạn không thể SSH vào RDS instance. Không có OS-level access.
Trong bài viết này, chúng ta sẽ tìm hiểu tổng quan về managed database trên AWS, bao gồm kiến trúc, cách hoạt động và sự khác biệt giữa các dịch vụ này.
Application phải chủ động connect đến Read Replica endpoint để đọc
Có thể promote Read Replica thành standalone DB (mất replication)
Cross-region Read Replica: có data transfer cost
Use case điển hình:
Bạn có một database production đang chạy với tải bình thường
Bạn muốn chạy thêm một ứng dụng Reporting để thực hiện analytics
Tạo một Read Replica để xử lý workload mới này — không đụng vào Primary
Ứng dụng production không bị ảnh hưởng gì cả
Read Replica chỉ dùng cho câu lệnh SELECT (đọc) — không dùng cho INSERT, UPDATE, DELETE
RDS Backup
Automated Backups:
Bật mặc định, backup hàng ngày trong maintenance window
Lưu transaction logs mỗi 5 phút → có thể Point-in-Time Recovery đến bất kỳ giây nào trong retention period
Retention: 1–35 ngày (default 7 ngày)
Backup lưu trên S3 (bạn không thấy trực tiếp)
Manual Snapshots:
Bạn trigger thủ công bất kỳ lúc nào
Không tự xóa — tồn tại dù đã xóa RDS instance
Có thể copy sang Region khác, share với account khác
RDS Storage
RDS dùng EBS storage bên dưới:
gp2/gp3: General purpose SSD — dùng cho hầu hết workloads
io1/io2: Provisioned IOPS — dùng khi cần IOPS cao, ổn định (production critical)
Magnetic: Legacy, không khuyến nghị
Storage Auto Scaling: Bật tính năng này → RDS tự tăng storage khi gần đầy (không cần downtime). Đặt Maximum Storage Threshold để kiểm soát chi phí.
RDS Encryption
At rest: Dùng AWS KMS. Phải bật khi tạo instance — không thể bật sau cho instance đang chạy.
Cách bật encryption cho instance đang chạy: Snapshot → Copy snapshot (bật encrypt) → Restore từ encrypted snapshot
In transit: SSL/TLS — AWS cung cấp certificate, application phải configure để dùng
Amazon Aurora
Aurora là proprietary database engine của AWS — compatible với MySQL và PostgreSQL nhưng được viết lại từ đầu, tối ưu cho cloud.
Aurora vs RDS – Điểm khác biệt chính
Tiêu chí
RDS MySQL
Aurora MySQL-compatible
Storage
EBS, tăng manual
Tự động tăng đến 128TB
Read Replicas
Tối đa 5
Tối đa 15
Replication lag
Vài giây
< 10ms
Failover
1–2 phút
< 30 giây
Multi-AZ
1 standby
6 copies trên 3 AZ
Performance
Baseline
5x MySQL, 3x PostgreSQL
Cost
Thấp hơn
~20% cao hơn RDS
Aurora Storage Architecture
Đây là kiến trúc độc đáo nhất của Aurora:
6 copies trên 3 AZ — chịu được mất 2 copies mà không ảnh hưởng writes, mất 3 copies mà không ảnh hưởng reads
Storage tự heal khi phát hiện corruption
Auto-growing từ 10GB, tăng theo 10GB increment, tối đa 128TB
Aurora Endpoints
Aurora có nhiều loại endpoint:
Client kết nối qua 2 endpoint: Writer Endpoint luôn trỏ vào Master để xử lý ghi, Reader Endpoint tự động load balance các request đọc sang nhiều Reader instances (có thể Auto Scaling tăng/giảm theo tải).
Toàn bộ instances dùng chung một Shared Storage Volume tự mở rộng từ 10G → 128TB, đảm bảo dữ liệu nhất quán mà không cần replication truyền thống.
Aurora Serverless
Không cần provision capacity trước — Aurora tự scale ACUs (Aurora Capacity Units) theo traffic:
Aurora Serverless v2: Scale liên tục (không discrete bước), scale nhanh hơn v1
Use case: Workload không đoán được, development/test environments, ứng dụng có traffic spike
Aurora Global Database
Replication cross-region với latency < 1 giây:
Disaster Recovery: Promote secondary region thành primary trong < 1 phút
Reads gần users toàn cầu → giảm latency đáng kể
RDS Proxy
RDS Proxy là fully managed database proxy nằm giữa application và RDS/Aurora.
Tại sao cần RDS Proxy?
Vấn đề khi Lambda (hoặc ECS với nhiều tasks) connect thẳng đến RDS:
Đặc điểm RDS Proxy
Connection pooling: Duy trì pool connections đến DB, tái sử dụng thay vì tạo mới mỗi lần
Failover nhanh hơn: RDS Multi-AZ failover qua Proxy nhanh hơn 66% so với connect trực tiếp
IAM Authentication: Bắt buộc dùng IAM auth hoặc Secrets Manager — không cần hardcode credentials
Không thể truy cập từ internet: RDS Proxy chỉ accessible trong VPC (không có public endpoint)
# Application connect đến Proxy endpoint thay vì RDS endpoint
# Không cần đổi gì khác trong code
import pymysql
conn = pymysql.connect(
host='my-proxy.proxy-xxx.rds.amazonaws.com', # Proxy endpoint
user='admin',
password=get_secret(), # Từ Secrets Manager
database='mydb'
)
# Application connect đến Proxy endpoint thay vì RDS endpoint# Không cần đổi gì khác trong codeimport pymysqlconn = pymysql.connect( host='my-proxy.proxy-xxx.rds.amazonaws.com', # Proxy endpoint user='admin', password=get_secret(), # Từ Secrets Manager database='mydb')
Amazon ElastiCache
Tương tự như RDS là dịch vụ quản lý Relational Database, ElastiCache là dịch vụ quản lý in-memory cache — hiện hỗ trợ ba engine: Valkey, Redis OSS, và Memcached (AWS đã bổ sung Valkey từ 2024 như một lựa chọn ưu tiên thay thế Redis OSS).
Cache là database lưu trên RAM, cho phép truy xuất với độ trễ microsecond — nhanh hơn hàng chục lần so với đọc từ disk. ElastiCache phù hợp cho hai mục đích chính: giảm tải cho database chính ở workload đọc nhiều, và giúp application trở nên stateless bằng cách lưu session ra bên ngoài.
AWS quản lý toàn bộ hạ tầng bao gồm OS patching, tối ưu hoá, cấu hình, monitoring, failover và backup. Tuy nhiên cần lưu ý: tích hợp ElastiCache yêu cầu thay đổi code phía application — đây không phải drop-in replacement mà cần thiết kế caching logic rõ ràng.
ElastiCache Solution Architecture – DB Cache
Application query ElastiCache trước. Nếu có dữ liệu (cache hit) → trả về ngay, không cần đụng đến database. Nếu không có (cache miss) → query RDS, lấy kết quả về, ghi vào cache, rồi trả về cho user.
Lợi ích chính là giảm tải đáng kể cho RDS, đặc biệt với các query lặp đi lặp lại. Tuy nhiên cache cần có invalidation strategy — tức là cơ chế xóa hoặc cập nhật dữ liệu cũ trong cache khi database thay đổi, tránh trường hợp user nhận về dữ liệu lỗi thời.
ElastiCache Solution Architecture – User Session Store
Đây là pattern giúp application chạy stateless. Khi user đăng nhập vào bất kỳ instance nào, session được ghi vào ElastiCache. Khi user chuyển sang instance khác (do load balancer điều phối), instance đó đọc session từ ElastiCache và nhận ra user đã đăng nhập — không cần login lại.
Pattern này đặc biệt quan trọng trong môi trường auto scaling, nơi instance có thể bị thay thế bất kỳ lúc nào.
5.3 ElastiCache – Redis vs Memcached
Valkey / Redis OSS và Memcached dựa trên nội dung bạn cung cấp:
Chọn Valkey / Redis OSS khi cần hệ thống mạnh, linh hoạt, có HA, persistence, hoặc các feature nâng cao.
Chọn Memcached khi bạn chỉ cần một cache cực kỳ đơn giản, nhanh, và tối ưu CPU.
Pattern 1 — Lazy Loading / Cache-Aside
Đây là pattern phổ biến nhất. Application chỉ load data vào cache khi thực sự cần — không pre-populate.
Ưu điểm:
Cache chỉ chứa data thực sự được dùng, không lãng phí bộ nhớ
Node failure không gây crash hệ thống — chỉ tăng latency tạm thời trong lúc warm up lại cache
Nhược điểm:
Cache miss dẫn đến 3 round trips: đọc cache → đọc DB → ghi vào cache. Request đầu tiên bao giờ cũng chậm hơn
Dữ liệu có thể bị stale nếu DB được cập nhật nhưng cache chưa bị invalidate
Python pseudocode:
def get_user(user_id):
# Bước 1: kiểm tra cache
record = cache.get(user_id)
if record is None:
# Bước 2: cache miss → đọc từ DB
record = db.query("select * from users where id = ?", user_id)
# Bước 3: ghi vào cache cho lần sau
cache.set(user_id, record)
return record
else:
return record
# App code
user = get_user(17)
def get_user(user_id): # Bước 1: kiểm tra cache record = cache.get(user_id) if record is None: # Bước 2: cache miss → đọc từ DB record = db.query("select * from users where id = ?", user_id) # Bước 3: ghi vào cache cho lần sau cache.set(user_id, record) return record else: return record# App codeuser = get_user(17)
Pattern 2 — Write Through
Mỗi khi ghi vào DB, đồng thời ghi luôn vào cache. Cache luôn phản ánh trạng thái mới nhất của database.
Ưu điểm:
Data trong cache không bao giờ stale
Read luôn nhanh vì cache luôn có dữ liệu mới nhất
Write penalty thay vì Read penalty — user chấp nhận ghi chậm hơn một chút để đổi lại read luôn nhanh
Nhược điểm:
Data mới chưa được write lần nào sẽ không có trong cache (missing data). Giải pháp: kết hợp thêm Lazy Loading
Cache churn — nhiều data được ghi vào cache nhưng không bao giờ được đọc lại, lãng phí bộ nhớ
def save_user(user_id, values):
# Bước 1: ghi vào DB
record = db.query("update users ... where id = ?", user_id, values)
# Bước 2: ghi vào cache
cache.set(user_id, record)
return record
# App code
user = save_user(17, {"name": "Nate Dogg"})
def save_user(user_id, values): # Bước 1: ghi vào DB record = db.query("update users ... where id = ?", user_id, values) # Bước 2: ghi vào cache cache.set(user_id, record) return record# App codeuser = save_user(17, {"name": "Nate Dogg"})
Cache Eviction và Time-to-live (TTL)
Cache eviction xảy ra theo 3 cách: xóa thủ công bằng code, bị xóa tự động khi bộ nhớ đầy theo thuật toán LRU (Least Recently Used), hoặc hết TTL đã đặt.
TTL là công cụ đơn giản nhưng hiệu quả — phù hợp với hầu hết loại dữ liệu: leaderboard, bình luận, activity feed, kết quả tìm kiếm. TTL có thể đặt từ vài giây đến vài ngày tùy mức độ chấp nhận stale data của ứng dụng.
Nếu hệ thống liên tục xảy ra eviction do thiếu bộ nhớ → cần scale up (node lớn hơn) hoặc scale out (thêm node).
Best Practices
Lazy Loading là baseline dễ implement, phù hợp hầu hết trường hợp đặc biệt cho read workload
Write Through kết hợp với Lazy Loading cho các query quan trọng cần data luôn fresh
Luôn đặt TTL hợp lý — ngoại lệ duy nhất là khi dùng Write Through thuần túy vì cache đã tự cập nhật
Chỉ cache data thực sự có giá trị: user profile, kết quả tìm kiếm, blog content, aggregation
Ưu tiên Valkey nếu đang dùng Redis OSS — tiết kiệm 20–33% chi phí, tương thích hoàn toàn, hỗ trợ Vector Search từ phiên bản 8.2
So sánh tổng quan
Situation
Solution
Relational DB, budget thấp, đơn giản
RDS (MySQL/PostgreSQL)
Cần performance cao, scale lớn, managed
Aurora
Lambda + RDS, quá nhiều connections
RDS Proxy
Giảm tải DB reads, cache đơn giản
ElastiCache Memcached
Session, leaderboard, pub/sub, cần persist
ElastiCache Redis
DR across regions, < 1s replication
Aurora Global Database
Unpredictable traffic, dev/test
Aurora Serverless v2
Multi-AZ vs Read Replica
Multi-AZ
Read Replica
Mục đích chính
High Availability (HA)
Scale reads
Replication
Synchronous
Asynchronous
Standby nhận traffic?
Không
Có (reads only)
Tự động failover?
Có
Không (manual promote)
Cross-region?
Không
Có
Chi phí
2x instance cost
Thêm instance cost
Kết luận
Việc sử dụng managed database giúp đơn giản hóa đáng kể quá trình vận hành hệ thống, từ việc đảm bảo tính sẵn sàng, sao lưu dữ liệu đến khả năng mở rộng khi tải tăng cao. Thay vì tập trung vào hạ tầng, bạn có thể dành nhiều thời gian hơn cho việc phát triển và tối ưu ứng dụng.
Mỗi giải pháp đều có những đặc điểm và trade-off riêng, phù hợp với từng loại workload và kiến trúc hệ thống khác nhau. Vì vậy, lựa chọn đúng công nghệ không chỉ dựa trên tính năng, mà còn phụ thuộc vào bài toán cụ thể và cách bạn thiết kế hệ thống tổng thể.
Hiểu rõ cách các thành phần này hoạt động sẽ giúp bạn đưa ra quyết định tốt hơn khi xây dựng và vận hành hệ thống trên cloud.
