Mẫu kiến trúc: sẵn sàng cao, khôi phục thảm hoạ, tách rời
Multi-AZ, multi-Region, 4 chiến lược DR theo RTO / RPO, kiến trúc serverless và hướng sự kiện, caching nhiều tầng.
- DomainThiết kế chịu lỗi
- DomainThiết kế hiệu năng cao
- 9 sơ đồ
- 10 tình huống
- 16 dịch vụ
5 phút phải nhớ
- RPO là lượng dữ liệu tối đa chấp nhận mất (tính theo thời gian); RTO là thời gian tối đa chấp nhận để khôi phục dịch vụ.RPO 15 phút nghĩa là bản sao dữ liệu không được cũ hơn 15 phút. Đề cho RPO / RTO và ngân sách, bạn chọn chiến lược DR.
- Sẵn sàng cao (HA) trong một Region = trải mọi tầng qua ít nhất 2 AZ. Khôi phục thảm hoạ (DR) = có phương án ở Region khác.ALB + Auto Scaling group nhiều AZ + RDS Multi-AZ chịu được mất một AZ. Mất cả Region mới cần DR.
- Backup & restore: chỉ sao lưu dữ liệu (và cấu hình) sang Region khác; rẻ nhất, RTO / RPO dài nhất (cỡ vài giờ).Muốn dựng lại nhanh và không sai, hạ tầng phải viết bằng IaC (CloudFormation, CDK); sao lưu cả AMI và cấu hình.
- Pilot light: dữ liệu được sao chép liên tục và luôn chạy ở Region DR; máy chủ ứng dụng "tắt" (chưa triển khai hoặc 0 máy), bật khi cần.RTO cỡ hàng chục phút. Elastic Disaster Recovery chính là kiểu pilot light cho máy chủ.
- Warm standby: một bản thu nhỏ nhưng chạy đủ chức năng ở Region DR, nhận traffic được ngay, chỉ cần scale up.Khác pilot light: pilot light phải bật máy trước khi phục vụ, warm standby phục vụ được ngay ở công suất thấp.
- Multi-site active/active: chạy đủ công suất ở nhiều Region cùng lúc; RTO gần 0, đắt và phức tạp nhất.Dữ liệu bị xoá / hỏng vẫn lan sang mọi Region: vẫn cần backup theo thời điểm.
- Aurora Global Database: sao chép sang Region khác thường dưới 1 giây, promote Region phụ thành chính trong dưới 1 phút.RPO giây, RTO phút cho database quan hệ đa Region. DynamoDB global tables cho phép ghi ở mọi Region (bản ghi sau cùng thắng).
- Chuyển traffic khi có sự cố: Route 53 failover (health check), Application Recovery Controller (công tắc failover chủ động), Global Accelerator (IP tĩnh, đổi endpoint ngay).Route 53 phụ thuộc TTL của DNS; Global Accelerator không bị cache DNS. CloudFront origin failover chỉ thử origin phụ cho từng request lỗi.
- Tách rời bằng SQS: bên gửi bỏ việc vào hàng đợi, worker xử lý theo sức; hàng đợi hấp thụ đỉnh tải.Worker trong Auto Scaling group co giãn theo số tin nhắn chờ (ApproximateNumberOfMessagesVisible / backlog per instance).
- Fan-out: một sự kiện tới nhiều bên xử lý độc lập → SNS gửi tới nhiều hàng đợi SQS (hoặc EventBridge với nhiều rule).Mỗi bên có hàng đợi riêng nên bên chậm / lỗi không ảnh hưởng bên khác.
- Ứng dụng stateless: không giữ session trên máy; đưa session vào ElastiCache hoặc DynamoDB.Auto Scaling thêm / bớt / thay máy tự do; không cần sticky session.
- Cache nhiều tầng: CloudFront ở edge, ElastiCache trước database, DAX trước DynamoDB, read replica cho tải đọc.Đề hỏi giảm độ trễ đọc / giảm tải database: chọn tầng cache gần với chỗ đang nghẽn.
- Serverless (API Gateway + Lambda + DynamoDB + S3) tự co giãn, trả theo mức dùng, không quản máy chủ."Tải không đều, đội ít người vận hành, trả tiền theo dùng" → serverless.
Sơ đồ
Sẵn sàng cao trong một Region: mọi tầng trải 2 AZ
Từng bước
- ALB chia tải cho máy ở cả hai AZ và bỏ qua máy không khoẻ.
- RDS ghi đồng bộ sang standby ở AZ kia; AZ a hỏng thì standby được nâng lên tự động, Auto Scaling bù máy ở AZ b.
DR kiểu backup & restore
Từng bước
- AWS Backup sao lưu EC2, RDS… theo lịch: tần suất sao lưu quyết định RPO.
- Bản sao lưu được copy sang Region DR.
- Thảm hoạ: chạy CloudFormation dựng hạ tầng rồi khôi phục dữ liệu; RTO tính bằng giờ.
DR kiểu pilot light
Từng bước
- Bình thường mọi traffic tới Region chính.
- Dữ liệu sao chép liên tục sang Region DR (RPO giây).
- Failover: tăng Auto Scaling từ 0, promote Aurora ở Region DR, chuyển DNS. RTO cỡ hàng chục phút.
DR kiểu warm standby
Từng bước
- Region chính phục vụ toàn bộ traffic.
- Region DR chạy sẵn một bản nhỏ, dữ liệu sao chép liên tục.
- Health check hỏng: Route 53 chuyển sang Region DR; bản nhỏ phục vụ ngay, Auto Scaling tăng dần. RTO vài phút.
Multi-site active/active với DynamoDB global tables
Từng bước
- Route 53 trả Region có độ trễ thấp nhất với từng người dùng.
- Mỗi Region tự xử lý và ghi vào bản global table của mình.
- DynamoDB sao chép hai chiều; một Region hỏng thì Route 53 bỏ Region đó, RTO gần 0.
Tách rời bằng SQS: worker co giãn theo hàng đợi
Từng bước
- Web bỏ đơn vào hàng đợi và trả lời khách ngay.
- Worker lấy tin, xử lý, xoá tin khi xong.
- Số tin chờ trên mỗi worker tăng thì Auto Scaling thêm worker.
- Tin lỗi quá số lần cho phép chuyển sang dead-letter queue để xem lại.
Fan-out: SNS tới nhiều hàng đợi SQS
Từng bước
- Dịch vụ đơn hàng chỉ phát một sự kiện, không cần biết ai nghe.
- SNS gửi bản sao vào từng hàng đợi đã đăng ký.
- Mỗi bên xử lý theo tốc độ riêng, lỗi thì thử lại trong hàng đợi của mình.
Cache nhiều tầng và session ngoài máy chủ
Từng bước
- Nội dung cache được thì CloudFront trả ngay ở edge; phần còn lại mới về ALB.
- App tìm trong ElastiCache trước (cache-aside); session cũng ở đây nên app không giữ trạng thái.
- Cache trượt mới truy vấn database rồi ghi lại vào cache; read replica gánh thêm tải đọc.
Ứng dụng web serverless
Từng bước
- Trang tĩnh được cache ở edge, lấy từ S3 riêng tư.
- Gọi API: API Gateway kích hoạt Lambda, Lambda đọc ghi DynamoDB. Không có máy chủ nào chạy khi không có request.
So sánh nhanh
4 chiến lược khôi phục thảm hoạ
| Chiến lược | Ở Region DR có gì | RPO / RTO thường gặp | Chi phí | Dịch vụ hay dùng |
|---|---|---|---|---|
| Backup & restore | Chỉ bản sao lưu | Vài giờ | Thấp nhất | AWS Backup (copy sang Region khác), snapshot, S3 CRR, CloudFormation |
| Pilot light | Dữ liệu chạy và sao chép liên tục; app server tắt | Hàng chục phút | Thấp | Aurora Global Database, RDS read replica khác Region, Elastic Disaster Recovery |
| Warm standby | Bản thu nhỏ chạy đủ chức năng | Vài phút | Trung bình | Như pilot light + Auto Scaling, Route 53 failover |
| Multi-site active/active | Bản đầy đủ, cùng phục vụ | Gần như 0 | Cao nhất | DynamoDB global tables, Aurora Global Database, Route 53 / Global Accelerator |
Nhân bản database: chịu lỗi hay mở rộng đọc?
| RDS Multi-AZ (instance) | Read replica | Aurora Global Database | DynamoDB global tables | |
|---|---|---|---|---|
| Mục đích | Chịu lỗi trong Region | Mở rộng đọc (và DR nếu khác Region) | DR đa Region, đọc gần người dùng | Ghi / đọc ở nhiều Region |
| Sao chép | Đồng bộ | Bất đồng bộ | Bất đồng bộ, thường dưới 1 giây | Bất đồng bộ |
| Bản phụ phục vụ đọc | Không (standby) | Có | Có | Có, cả ghi |
| Chuyển đổi | Tự động failover | Promote bằng tay | Promote Region phụ (dưới 1 phút) | Không cần: Region nào cũng ghi được |
Tách rời: chọn cách truyền việc
| SQS | SNS | EventBridge | Kinesis Data Streams | |
|---|---|---|---|---|
| Kiểu | Hàng đợi (một bên xử lý mỗi tin) | Pub/sub đẩy tới nhiều bên | Bus sự kiện, lọc theo nội dung | Luồng có thứ tự, đọc lại được |
| Hợp với | Hấp thụ đỉnh tải, worker co giãn | Fan-out, thông báo | Tích hợp dịch vụ AWS / SaaS, rule | Dữ liệu thời gian thực khối lượng lớn |
| Giữ tin | Tới 14 ngày | Không giữ | Có thể lưu trữ và phát lại (archive) | 24 giờ – 365 ngày |
Cache ở đâu
| Tầng | Dịch vụ | Giảm cái gì |
|---|---|---|
| Edge (gần người dùng) | CloudFront | Độ trễ và tải về origin cho nội dung tĩnh / API cache được |
| Ứng dụng | ElastiCache (Redis OSS / Valkey / Memcached) | Truy vấn database lặp lại, lưu session |
| Trước DynamoDB | DAX | Độ trễ đọc xuống micro giây |
| Database | Read replica | Tải đọc trên bản chính |
Tình huống đề hay gặp
1Ứng dụng web chạy trên một EC2 ở một AZ; cần chịu được mất một AZ với chi phí hợp lý.
Xem đáp án
Đúng: ALB + Auto Scaling group trải ít nhất 2 AZ, database RDS Multi-AZ
Mỗi tầng có mặt ở hai AZ; AZ hỏng thì ALB chỉ gửi tới máy khoẻ, RDS tự failover.
Sai: Chuyển sang instance lớn hơn
Vẫn là một máy, một AZ.
Sai: Dựng bản sao ở Region khác
Quá mức cho yêu cầu mất một AZ, đắt hơn.
2Hệ thống nội bộ chấp nhận RPO 24 giờ và RTO 8 giờ khi mất cả Region; muốn chi phí DR thấp nhất.
Xem đáp án
Đúng: Backup & restore: AWS Backup sao chép bản sao lưu sang Region khác, hạ tầng viết bằng CloudFormation
RPO / RTO tính bằng giờ thì backup & restore là đủ và rẻ nhất.
Sai: Warm standby
Chạy liên tục một bản thu nhỏ: đắt hơn mức cần.
3Cần RPO vài giây và RTO khoảng 30 phút cho ứng dụng dùng Aurora MySQL khi mất Region; chi phí thấp nhất có thể.
Xem đáp án
Đúng: Pilot light: Aurora Global Database sang Region DR; app server dựng sẵn bằng IaC nhưng không chạy, bật lên khi failover
Dữ liệu sao chép liên tục (RPO giây), phần còn lại chỉ phải bật lên (RTO hàng chục phút).
Sai: Backup & restore với snapshot hằng ngày
RPO tới một ngày.
Sai: Multi-site active/active
Đáp ứng được nhưng tốn kém hơn nhiều.
4Ứng dụng phải phục vụ lại trong vài phút khi mất Region, chấp nhận chạy công suất thấp lúc đầu.
Xem đáp án
Đúng: Warm standby: bản thu nhỏ chạy sẵn ở Region DR, Route 53 failover, Auto Scaling tăng công suất sau khi chuyển
Nhận traffic ngay, chỉ cần scale up.
Sai: Pilot light
App server đang tắt, phải bật và cấu hình trước khi phục vụ được.
5Ứng dụng toàn cầu cần RTO gần như 0 và người dùng ở châu Á, châu Âu đều được phục vụ từ Region gần nhất; dữ liệu phải ghi được ở mọi nơi.
Xem đáp án
Đúng: Multi-site active/active với DynamoDB global tables và Route 53 latency routing
Mọi Region đều đọc / ghi; Region hỏng thì Route 53 bỏ Region đó.
Sai: Aurora Global Database với ghi ở Region chính
Chỉ một Region nhận ghi (các Region khác chỉ đọc hoặc chuyển tiếp ghi).
6Đơn hàng dồn dập vào giờ khuyến mãi làm hệ thống xử lý phía sau quá tải và mất đơn.
Xem đáp án
Đúng: Đặt SQS giữa web và worker; worker Auto Scaling theo số tin nhắn chờ
Hàng đợi giữ đơn an toàn, worker xử lý theo sức và co giãn theo backlog.
Sai: Tăng kích thước instance của worker
Vẫn có giới hạn, và tốn tiền lúc thấp điểm.
7Mỗi đơn hàng mới cần đồng thời gửi email, cập nhật kho và ghi phân tích; một bên lỗi không được làm hỏng bên khác.
Xem đáp án
Đúng: SNS topic gửi tới ba hàng đợi SQS, mỗi bên một hàng đợi
Fan-out: mỗi bên nhận bản riêng, xử lý và thử lại độc lập.
Sai: Một hàng đợi SQS cho cả ba bên
Mỗi tin nhắn chỉ một consumer xử lý.
8Người dùng bị đăng xuất mỗi khi Auto Scaling thay máy.
Xem đáp án
Đúng: Lưu session vào ElastiCache (hoặc DynamoDB), giữ máy ứng dụng stateless
Máy nào cũng đọc được session; thêm / bớt máy không ảnh hưởng người dùng.
Sai: Bật sticky session trên ALB
Máy bị thay vẫn mất session; tải cũng lệch giữa các máy.
9Database quan hệ quá tải vì cùng một số truy vấn đọc lặp lại liên tục.
Xem đáp án
Đúng: ElastiCache trước database (cache-aside), thêm read replica nếu cần
Truy vấn lặp lại được trả từ bộ nhớ; database chỉ còn tải ghi và truy vấn hiếm.
Sai: Thêm IOPS cho ổ đĩa
Không giải quyết việc lặp truy vấn.
10API có lượng gọi rất thất thường, đội nhỏ không muốn quản máy chủ.
Xem đáp án
Đúng: API Gateway + Lambda + DynamoDB
Tự co giãn tới 0, trả theo request.
Sai: EC2 Auto Scaling với instance lớn chạy thường trực
Trả tiền cả lúc không có ai gọi, phải quản OS.
Chọn nhanh
Bạn cần chịu được gì, nhanh tới đâu?
| Khi cần | Dùng |
|---|---|
| Mất một AZ | Multi-AZ: ALB + Auto Scaling nhiều AZ, RDS Multi-AZ · xem sơ đồ |
| Mất Region, RPO / RTO tính bằng giờ, rẻ nhất | Backup & restore (AWS Backup copy sang Region khác + IaC) · xem sơ đồ |
| Mất Region, RPO giây, RTO hàng chục phút | Pilot light · xem sơ đồ |
| Mất Region, RTO vài phút | Warm standby · xem sơ đồ |
| RTO gần 0, phục vụ toàn cầu | Multi-site active/active · xem sơ đồ |
| Đỉnh tải làm phía sau quá tải | SQS + worker co giãn theo hàng đợi · xem sơ đồ |
| Một sự kiện, nhiều bên xử lý | SNS → nhiều SQS (fan-out) hoặc EventBridge · xem sơ đồ |
| Đọc chậm, database quá tải | CloudFront / ElastiCache / DAX / read replica · xem sơ đồ |
| Tải thất thường, không muốn quản máy chủ | Serverless: API Gateway + Lambda + DynamoDB · xem sơ đồ |
| Failover DNS chủ động, an toàn khi sự cố | Application Recovery Controller + Route 53 |
Bẫy hay gặp
- Nhầm HA với DR: Multi-AZ không bảo vệ khi mất cả Region.
- Chọn RDS read replica để chịu lỗi tự động trong Region: đó là Multi-AZ; read replica để mở rộng đọc và phải promote bằng tay.
- Nhầm pilot light và warm standby: pilot light phải bật app server trước khi phục vụ, warm standby phục vụ được ngay.
- Làm backup & restore mà không có IaC: dựng lại bằng tay thì không kịp RTO.
- Tin rằng active/active hoặc sao chép liên tục thay được backup: dữ liệu bị xoá / hỏng cũng được sao chép đi.
- Không kiểm thử DR định kỳ: kế hoạch chưa từng chạy thì không biết có đạt RTO không.
- Dùng sticky session thay cho việc đưa session ra ngoài máy.
- Một hàng đợi SQS cho nhiều bên cần cùng nhận một sự kiện: cần fan-out bằng SNS / EventBridge.
- Co giãn worker theo CPU trong khi việc thật nằm ở độ dài hàng đợi.
- Quên rằng failover bằng DNS phụ thuộc TTL: cần độ trễ chuyển đổi thấp, không phụ thuộc cache DNS thì dùng Global Accelerator.
- Quên quota dịch vụ ở Region DR: đến lúc scale up mới phát hiện không đủ giới hạn.
Dịch vụ trong module
Route 53DNS, trỏ tên miền
Application Recovery Controllerđiều khiển failover đa vùng
Global Acceleratortăng tốc mạng toàn cầu
ELBchia tải request
EC2 Auto Scalingtự thêm/bớt máy
AuroraSQL hiệu năng cao của AWS
DynamoDBNoSQL key-value cực nhanh
ElastiCachebộ nhớ đệm (Redis)
SQShàng đợi tin nhắn
SNSphát thông báo (pub/sub)
CloudFrontCDN, cache gần người dùng
API Gatewaycổng vào cho API
Lambdachạy code theo sự kiện
DRSkhôi phục thảm hoạ cho server
Backupsao lưu tập trung
CloudFormationhạ tầng bằng code
Số liệu dễ thay đổi (đã kiểm với tài liệu AWS)
- Pilot light không phục vụ được request khi chưa bật thêm tài nguyên; warm standby phục vụ ngay ở công suất thấp, chỉ cần scale up. kiểm ngày 2026-10-16 ↗
- Aurora Global Database sao chép sang Region phụ với độ trễ thường dưới 1 giây và promote Region phụ trong dưới 1 phút. kiểm ngày 2026-10-16 ↗
- DynamoDB global tables cho đọc và ghi ở mọi Region, giải quyết ghi đồng thời theo nguyên tắc bản ghi sau cùng thắng (last writer wins). kiểm ngày 2026-10-16 ↗
- AWS Elastic Disaster Recovery sao chép liên tục ở mức block và dùng chiến lược pilot light. kiểm ngày 2026-10-16 ↗
- CloudFront origin failover chuyển từng request lỗi sang origin phụ; các request sau vẫn tới origin chính. kiểm ngày 2026-10-16 ↗
- AWS Backup sao chép bản sao lưu sang Region và tài khoản khác; không tự khôi phục theo lịch. kiểm ngày 2026-10-16 ↗