Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn là kỹ sư vận hành cho một sàn thương mại điện tử Việt Nam. Đúng 12 giờ trưa ngày sale lớn, khi hàng chục nghìn người đang bấm "Thanh toán", trung tâm dữ liệu đặt máy chủ của bạn bất ngờ mất điện lưới, máy phát dự phòng khởi động chậm. Trong 40 phút, toàn bộ website "trắng màn hình". Doanh thu bốc hơi, khách hàng chửi trên fanpage, và sếp gọi điện liên tục.
Câu chuyện này không hiếm. Điều làm nên khác biệt giữa một hệ thống "sập là mất tất cả" và một hệ thống "một chỗ hỏng nhưng vẫn chạy" chính là High Availability (HA) — tính sẵn sàng cao. Và trong thế giới cloud, công cụ nền tảng nhất để đạt được HA là mô hình Multi-AZ (nhiều Availability Zone).
Bài học này sẽ giúp bạn hiểu bản chất của HA, phân biệt rõ AZ với Region, nắm được các pattern kiến trúc kinh điển để loại bỏ điểm chết đơn (single point of failure), và biết cách thiết kế một hệ thống mà khi một trung tâm dữ liệu "chết", người dùng của bạn thậm chí không hề nhận ra. Đây là kiến thức xương sống mà bất kỳ ai làm DevOps hay Cloud đều phải thành thạo — vì downtime không chỉ là vấn đề kỹ thuật, nó là tiền, là uy tín thương hiệu.
Khái niệm cốt lõi
High Availability là gì?
High Availability (HA) là khả năng của một hệ thống tiếp tục hoạt động bình thường (hoặc gần như bình thường) ngay cả khi một hay nhiều thành phần gặp sự cố. HA không có nghĩa là "không bao giờ hỏng" — mọi thứ đều có thể hỏng. HA nghĩa là khi có thứ hỏng, dịch vụ tổng thể vẫn không gián đoạn với người dùng.
Người ta thường đo HA bằng con số "số 9":
| Mức sẵn sàng | Downtime tối đa mỗi năm | Downtime mỗi tháng |
|---|---|---|
| 99% (hai số 9) | ~3.65 ngày | ~7.2 giờ |
| 99.9% (ba số 9) | ~8.76 giờ | ~43 phút |
| 99.99% (bốn số 9) | ~52.6 phút | ~4.3 phút |
| 99.999% (năm số 9) | ~5.26 phút | ~26 giây |
Nguyên tắc vàng: loại bỏ Single Point of Failure
Single Point of Failure (SPOF) — điểm chết đơn — là bất kỳ thành phần nào mà khi nó hỏng, toàn bộ hệ thống ngừng chạy. Triết lý cốt lõi của HA gói gọn trong một câu:
> HA = không có điểm chết đơn.
Muốn vậy, bạn phải phân tán (distribute) ba lớp tài nguyên chính qua nhiều vị trí độc lập:
- Compute (máy chủ, container, function) — không đặt tất cả trên một máy.
- Data (database, storage) — dữ liệu phải có bản sao ở nơi khác.
- Network (load balancer, DNS, đường truyền) — đường vào cũng không được là điểm chết.
Region và Availability Zone — phân biệt cho rõ
Đây là phần nhiều người mới học nhầm lẫn, nên hãy nắm thật chắc.
Region (vùng) là một khu vực địa lý lớn, ví dụ ap-southeast-1 (Singapore) của AWS, hay asia-southeast1 (Singapore) của GCP. Các region cách nhau hàng trăm đến hàng nghìn km.
Availability Zone (AZ) là một hoặc nhiều trung tâm dữ liệu vật lý riêng biệt bên trong một region. Mỗi AZ có nguồn điện, hệ thống làm mát và kết nối mạng độc lập với AZ khác. Tuy nhiên, các AZ trong cùng một region được nối với nhau bằng đường truyền tốc độ cao, độ trễ cực thấp (thường dưới 1-2ms).
Hãy hình dung như thế này:
Region: ap-southeast-1 (Singapore)
│
├── AZ ap-southeast-1a ← Trung tâm dữ liệu #1 (điện, mạng riêng)
├── AZ ap-southeast-1b ← Trung tâm dữ liệu #2 (điện, mạng riêng)
└── AZ ap-southeast-1c ← Trung tâm dữ liệu #3 (điện, mạng riêng)
↕ nối với nhau bằng cáp riêng, độ trễ < 2ms
Ý nghĩa thiết kế: nếu AZ 1a bị cháy, mất điện, hay ngập nước, thì AZ 1b và 1c vẫn hoạt động bình thường vì chúng độc lập về hạ tầng vật lý. Đó chính là "linh hồn" của Multi-AZ.
Multi-AZ pattern — mô hình kinh điển
Mẫu kiến trúc HA cơ bản nhất trong cloud trông như sau:
Internet
│
┌────────▼────────┐
│ Load Balancer │ (trải trên nhiều AZ)
└───┬─────────┬───┘
│ │
┌─────────┴──┐ ┌──┴─────────┐
│ AZ 1a │ │ AZ 1b │
│ ┌──────┐ │ │ ┌──────┐ │
│ │ App │ │ │ │ App │ │ ← compute nhân bản
│ │ EC2 │ │ │ │ EC2 │ │
│ └──────┘ │ │ └──────┘ │
│ ┌──────┐ │ │ ┌──────┐ │
│ │ DB │──┼───┼─▶│ DB │ │ ← DB primary + standby
│ │primary│ │ │ │standby│ │ (đồng bộ sang AZ khác)
│ └──────┘ │ │ └──────┘ │
└────────────┘ └────────────┘
Ba lớp phối hợp để tạo HA:
- Load Balancer đứng trước, nhận traffic và phân phối đều tới các máy app ở cả hai (hoặc ba) AZ. Bản thân load balancer của cloud (như AWS ALB) đã là dịch vụ managed chạy đa AZ, nên không phải SPOF.
- Compute nhân bản: mỗi AZ có ít nhất một máy app. Nếu AZ 1a chết, load balancer tự động ngừng gửi traffic tới đó và dồn hết sang 1b.
- Database Multi-AZ: một instance primary ở AZ 1a, một standby ở AZ 1b được đồng bộ dữ liệu liên tục. Nếu primary hỏng, cloud tự động "failover" — thăng standby lên làm primary — thường chỉ mất 60-120 giây.
Đồng bộ vs Bất đồng bộ — điểm mấu chốt của dữ liệu
Với compute thì nhân bản dễ, nhưng với dữ liệu thì phức tạp hơn. Có hai kiểu sao chép:
- Synchronous replication (đồng bộ): mỗi giao dịch ghi phải được xác nhận ở cả primary lẫn standby trước khi báo thành công cho ứng dụng. Ưu điểm: không mất dữ liệu khi failover. Nhược điểm: tăng độ trễ một chút. Đây là cách RDS Multi-AZ dùng — và vì các AZ gần nhau (độ trễ thấp) nên đồng bộ vẫn khả thi. Đây cũng là lý do tại sao HA đa AZ thường nằm trong cùng region, chứ không phải đa region.
- Asynchronous replication (bất đồng bộ): primary ghi xong báo thành công ngay, standby đồng bộ theo sau. Nhanh hơn nhưng có nguy cơ mất một ít dữ liệu gần nhất khi failover đột ngột. Kiểu này thường dùng cho sao chép giữa các region xa nhau.
Health check và tự động failover
HA không thể thiếu cơ chế health check — kiểm tra sức khỏe liên tục. Load balancer định kỳ "ping" từng máy app (ví dụ gọi endpoint /health mỗi 10 giây). Nếu một máy không phản hồi sau vài lần thử, nó bị đánh dấu "unhealthy" và bị loại khỏi vòng phân phối traffic. Khi máy khỏe lại, nó tự động được đưa trở lại. Cơ chế tự động này là điều khiến HA "sống" mà không cần con người ngồi canh 24/7.
Tình huống thực tế
Ví dụ 1: Sàn TMĐT Việt Nam sống sót qua sự cố AZ
Một công ty thương mại điện tử tại TP.HCM (gọi là "ShopViet") chạy toàn bộ hệ thống trên AWS region Singapore. Ban đầu, để tiết kiệm chi phí, họ đặt tất cả web server và database trên một AZ duy nhất — ap-southeast-1a. Mọi thứ chạy êm cho đến một ngày AZ đó gặp sự cố mạng khu vực, và website ShopViet "chết" trọn 55 phút giữa giờ cao điểm. Ước tính thiệt hại: khoảng 1,2 tỷ đồng doanh thu bị mất, cộng với hàng nghìn khách bỏ giỏ hàng.
Sau sự cố, đội DevOps tái kiến trúc: đặt web server trên cả 1a, 1b, 1c; bật RDS Multi-AZ (primary ở 1a, standby ở 1b); dùng Application Load Balancer trải đa AZ. Sáu tháng sau, chính AZ 1a lại gặp trục trặc phần cứng. Lần này, load balancer tự động dồn traffic sang 1b và 1c, database failover sang standby trong 90 giây. Người dùng chỉ thấy một khoảnh khắc lag rất ngắn khi đang thanh toán, không ai phàn nàn. Bài học rút ra: chi phí tăng thêm cho Multi-AZ (khoảng 40-60% cho tầng database vì phải trả cho instance standby) là khoản bảo hiểm cực rẻ so với 1,2 tỷ mất trong một giờ.
Ví dụ 2: Ngân hàng số và yêu cầu "bốn số 9"
Một ngân hàng số ở Đông Nam Á cam kết SLA 99.99% cho ứng dụng mobile banking — tức chỉ được phép "chết" tối đa khoảng 52 phút mỗi năm. Với yêu cầu này, kiến trúc một AZ là hoàn toàn không thể chấp nhận. Họ triển khai: cụm ứng dụng chạy trên ba AZ với auto-scaling, database dùng cấu hình đồng bộ đa AZ, cache (Redis) cũng ở chế độ replica đa AZ, và mọi lớp đều có health check.
Điểm tinh tế: đội kiến trúc tính toán "N+1 capacity". Nếu hệ thống cần 6 máy app để chịu tải đỉnh và trải trên 3 AZ (2 máy mỗi AZ), thì khi một AZ chết, chỉ còn 4 máy — không đủ. Vì vậy họ chạy dư: 9 máy (3 mỗi AZ), để khi mất một AZ vẫn còn 6 máy đủ tải. Bài học rút ra: HA không chỉ là "có mặt ở nhiều AZ", mà phải dư đủ công suất để khi mất một AZ, phần còn lại vẫn gánh được toàn bộ tải. Trải AZ mà không tính dư công suất thì khi failover hệ thống sẽ quá tải và... sập theo cách khác.
Ví dụ 3: Startup và cái bẫy "database một điểm chết"
Một startup fintech nhỏ tự tin rằng họ đã "làm HA" vì chạy 4 web server trên hai AZ. Nhưng họ tiết kiệm bằng cách dùng một database instance đơn lẻ trên 1a, không bật Multi-AZ. Một đêm, ổ đĩa của database instance đó hỏng. Web server vẫn sống nhăn trên cả hai AZ, load balancer vẫn khỏe — nhưng mọi request đều lỗi vì không đọc được dữ liệu. Toàn bộ dịch vụ "chết" dù compute hoàn hảo. Downtime 3 tiếng để khôi phục từ backup, mất một phần giao dịch trong ngày.
Bài học rút ra: HA là chuỗi mắt xích — chỉ mạnh bằng mắt xích yếu nhất. Bạn phải rà từng lớp (compute, data, network, cache, DNS) và tự hỏi: "Nếu thành phần này chết, chuyện gì xảy ra?" Bỏ sót một SPOF duy nhất là đủ để xóa sổ mọi công sức làm HA ở các lớp khác. Database thường là SPOF bị bỏ quên nhất vì nó khó nhân bản hơn compute.
Hướng dẫn từng bước
Dưới đây là quy trình thiết kế một hệ thống HA Multi-AZ cơ bản trên cloud.
Bước 1 — Xác định mục tiêu SLA. Trước tiên hỏi: hệ thống này cần mấy số 9? Một dịch vụ nội bộ có thể 99%, cổng thanh toán cần 99.99%. Con số này quyết định bạn cần bao nhiêu AZ và mức dư công suất.
Bước 2 — Vẽ sơ đồ và săn SPOF. Vẽ toàn bộ kiến trúc, đi qua từng thành phần từ DNS → load balancer → app → cache → database → storage. Với mỗi thành phần, đánh dấu: "Nếu cái này hỏng thì sao?" Mọi thành phần chỉ có một bản đều là SPOF cần xử lý.
Bước 3 — Chọn tối thiểu 2 (nên 3) AZ. Chọn một region có ít nhất 3 AZ. Dùng 2 AZ là mức tối thiểu cho HA; 3 AZ tốt hơn vì nếu mất 1 AZ bạn vẫn còn 2, tránh tình trạng "chia đôi não" (split-brain) trong các hệ thống bầu chọn cần đa số phiếu (như quorum của cơ sở dữ liệu phân tán).
Bước 4 — Đặt load balancer đa AZ. Cấu hình load balancer (ALB/NLB trên AWS, hoặc tương đương) trải trên tất cả các AZ đã chọn. Đây là điểm vào duy nhất, và dịch vụ LB managed của cloud đã tự HA sẵn.
Bước 5 — Nhân bản compute và tính dư công suất. Triển khai app trên mọi AZ. Áp dụng nguyên tắc N+1: đảm bảo khi mất một AZ, số máy còn lại vẫn đủ gánh tải đỉnh. Kết hợp auto-scaling để hệ thống tự thêm máy khi tải tăng.
Bước 6 — Bật database Multi-AZ. Với RDS/Cloud SQL, bật tùy chọn Multi-AZ (primary + standby đồng bộ ở AZ khác). Đảm bảo cache (Redis/Memcached) cũng ở chế độ replica đa AZ nếu cache là thành phần quan trọng.
Bước 7 — Cấu hình health check. Tạo endpoint /health cho app, cấu hình load balancer kiểm tra định kỳ. Health check nên kiểm tra cả kết nối tới database, không chỉ "app có chạy không".
Bước 8 — Diễn tập failover. Đừng chờ sự cố thật. Chủ động tắt một máy, hoặc mô phỏng mất một AZ (chaos engineering) trong môi trường staging để xác nhận hệ thống thực sự failover đúng như thiết kế.
Lỗi thường gặp & mẹo
Lỗi 1 — Nhầm Multi-AZ với Multi-Region. Multi-AZ bảo vệ khỏi sự cố một trung tâm dữ liệu trong cùng region. Nó KHÔNG bảo vệ khỏi sự cố toàn region (cực hiếm nhưng có thật). Nếu region chết, cần Multi-Region — nhưng đó là chủ đề của bài khác (Disaster Recovery và Multi-Region). Đừng kỳ vọng Multi-AZ chống được thảm họa cấp region.
Lỗi 2 — Quên tính dư công suất. Như ví dụ ngân hàng, trải AZ mà không chạy dư sẽ khiến hệ thống quá tải khi một AZ chết. Luôn thiết kế để phần còn lại gánh được 100% tải.
Lỗi 3 — Database là SPOF bị bỏ quên. Rất nhiều người làm HA cho compute nhưng để database một instance. Luôn bật Multi-AZ cho tầng dữ liệu — đây là mắt xích dễ quên nhất.
Lỗi 4 — Health check quá hời hợt. Health check chỉ trả về "200 OK" mà không kiểm tra kết nối database sẽ khiến load balancer gửi traffic tới máy "sống nhưng vô dụng". Health check tốt phải kiểm tra được các phụ thuộc chính.
Lỗi 5 — Không diễn tập. Kiến trúc trên giấy trông hoàn hảo nhưng chưa bao giờ test failover thực tế. Đến khi sự cố thật, mới phát hiện standby cấu hình sai. Hãy diễn tập định kỳ.
Mẹo hay:
- Ưu tiên dịch vụ managed (RDS, ALB, ElastiCache) vì chúng đã tích hợp sẵn HA đa AZ, đỡ phải tự dựng.
- Đặt tài nguyên lưu trạng thái (session, file) ra ngoài compute — dùng cache tập trung hoặc object storage — để máy app trở nên "stateless", dễ thay thế khi một AZ chết.
- Cân nhắc chi phí: standby database "ngồi không" vẫn tính tiền. Với hệ thống ít quan trọng, có thể chấp nhận downtime ngắn thay vì trả gấp đôi.
Bài tập thực hành
- Tính downtime: Một dịch vụ cam kết SLA 99.95%. Tính xem mỗi tháng nó được phép "chết" tối đa bao nhiêu phút. (Gợi ý: 0.05% của số phút trong 30 ngày.)
- Săn SPOF: Cho kiến trúc sau — 1 DNS, 1 load balancer managed đa AZ, 3 web server trên 3 AZ, 1 database instance đơn trên AZ-1a, 1 Redis cache trên AZ-1a. Hãy liệt kê tất cả các SPOF và đề xuất cách khắc phục từng cái.
- Thiết kế dư công suất: Hệ thống của bạn cần 8 máy app để chịu tải đỉnh, muốn trải trên 4 AZ và chịu được mất 1 AZ. Hỏi: mỗi AZ cần bao nhiêu máy, tổng cộng bao nhiêu máy?
- So sánh replication: Giải thích bằng lời tại sao RDS Multi-AZ dùng đồng bộ (synchronous) được, trong khi sao chép giữa Singapore và Tokyo thường phải dùng bất đồng bộ (asynchronous).
- Kịch bản failover: Viết ra từng bước điều gì xảy ra (theo trình tự thời gian) từ khoảnh khắc AZ-1a chết cho tới khi hệ thống ổn định trở lại, trong một kiến trúc Multi-AZ đầy đủ.
Tóm tắt
- High Availability (HA) là khả năng hệ thống tiếp tục chạy khi một phần gặp sự cố; đo bằng "số 9" — mỗi số 9 tăng thêm đắt hơn nhiều.
- Nguyên tắc cốt lõi: loại bỏ mọi Single Point of Failure bằng cách phân tán compute, data và network qua nhiều vị trí độc lập.
- Availability Zone (AZ) là trung tâm dữ liệu vật lý riêng biệt (điện, mạng, làm mát độc lập) bên trong một Region; các AZ trong cùng region nối với nhau độ trễ cực thấp.
- Multi-AZ pattern kinh điển: load balancer đa AZ + compute nhân bản trên nhiều AZ + database primary/standby đồng bộ với tự động failover.
- Dữ liệu dùng đồng bộ trong cùng region (không mất data) và bất đồng bộ khi khoảng cách xa; health check là cơ chế giúp failover tự động.
- Nhớ ba bài học vàng: (1) database là SPOF hay bị quên nhất — luôn bật Multi-AZ; (2) phải dư đủ công suất để mất một AZ vẫn gánh được tải; (3) Multi-AZ khác Multi-Region — nó không chống được sự cố toàn region.