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 ví điện tử lớn ở Việt Nam. Toàn bộ hệ thống chạy trên một region duy nhất tại Singapore của nhà cung cấp cloud. Một buổi sáng, region đó gặp sự cố mạng lõi — không phải server của bạn hỏng, mà là cả một vùng hạ tầng của nhà cung cấp bị "sập". Trong ba tiếng đồng hồ, hàng triệu người dùng không nạp được tiền, không thanh toán được, và tổng đài chăm sóc khách hàng cháy máy. Bạn không thể làm gì cả, vì "trứng để hết trong một giỏ".
Đó chính là lý do multi-region architecture (kiến trúc đa vùng) tồn tại. Khi hệ thống của bạn trải rộng trên nhiều region địa lý khác nhau, một region gặp thảm họa không còn đồng nghĩa với việc toàn bộ dịch vụ ngừng hoạt động. Nhưng multi-region không phải là "bật công tắc" — nó là một quyết định kiến trúc với chi phí, độ phức tạp và trade-off rất rõ ràng. Câu hỏi cốt lõi mà bài này trả lời là: bạn nên chọn mô hình Active-Passive hay Active-Active? Hai mô hình này khác nhau về chi phí, độ phức tạp, thời gian phục hồi và cả cách bạn xử lý dữ liệu. Chọn sai, bạn hoặc là trả tiền gấp đôi cho thứ không cần, hoặc là tưởng mình an toàn nhưng thực ra vẫn "chết" khi region chính sập.
Trong bài này, chúng ta tập trung riêng vào kiến trúc đa vùng và sự đối lập giữa Active-Active với Active-Passive. Những khái niệm liên quan như RTO/RPO, backup, load balancing hay high availability trong một region đã và sẽ được các bài khác đào sâu — ở đây ta chỉ dùng chúng như công cụ bổ trợ.
Khái niệm cốt lõi
Region là gì và tại sao lại "đa vùng"
Một region là một cụm trung tâm dữ liệu (data center) đặt tại một vị trí địa lý, ví dụ ap-southeast-1 (Singapore) hay ap-southeast-3 (Jakarta) của AWS. Bên trong một region thường có nhiều Availability Zone (AZ) — các data center tách biệt về nguồn điện, làm mát, mạng, nhưng vẫn gần nhau về địa lý. Triển khai multi-AZ giúp bạn chống lại sự cố ở một tòa nhà data center. Nhưng multi-AZ không cứu được bạn khi cả region sập (mất mạng lõi, sự cố region-wide, hoặc thảm họa thiên nhiên diện rộng). Multi-region mới là lớp bảo vệ ở cấp độ đó.
Active-Passive: một region phục vụ, một region chờ
Trong mô hình Active-Passive (còn gọi là active-standby, hoặc hot/warm/cold standby tùy mức độ sẵn sàng):
- Chỉ một region (primary/active) thực sự nhận và xử lý traffic của người dùng.
- Một region thứ hai (passive/standby) được dựng sẵn nhưng ở trạng thái chờ — không phục vụ traffic thật.
- Dữ liệu được replicate liên tục từ primary sang standby (thường là replication một chiều: primary → standby).
- Khi primary "chết", ta thực hiện failover: chuyển traffic sang standby và "thăng cấp" (promote) nó thành primary mới. Failover có thể thủ công (con người bấm nút) hoặc tự động (health check phát hiện lỗi và tự chuyển).
Nhược điểm: khi failover, sẽ có downtime (thời gian gián đoạn) — thời gian để phát hiện lỗi, promote standby, và chuyển hướng traffic. Ngoài ra, tài nguyên ở standby đa phần thời gian "ngồi chơi", nên có sự lãng phí nhất định.
Các cấp độ standby thường gặp:
- Cold standby: hạ tầng gần như tắt, cần dựng lại khi cần. Rẻ nhất, phục hồi chậm nhất.
- Warm standby: hạ tầng chạy sẵn ở quy mô nhỏ, dữ liệu đã đồng bộ. Cân bằng chi phí và tốc độ.
- Hot standby: hạ tầng chạy đầy đủ quy mô, chỉ chờ nhận traffic. Đắt hơn nhưng failover gần như tức thì.
Active-Active: nhiều region cùng phục vụ
Trong mô hình Active-Active, cả hai (hoặc nhiều) region đều đồng thời nhận và xử lý traffic thật. Traffic được phân phối tới region gần người dùng nhất (thường qua DNS geo-routing hoặc global load balancer). Khi một region sập, traffic tự động dồn về các region còn lại — về lý thuyết là không có downtime, chỉ có việc giảm dung lượng.
Ưu điểm:
- Không (hoặc gần như không) downtime khi mất một region.
- Latency thấp hơn cho người dùng ở nhiều vị trí địa lý, vì họ được phục vụ từ region gần.
- Tận dụng được tài nguyên ở mọi region, không có phần "ngồi chơi".
- Xung đột ghi (write conflict): hai region cùng sửa một bản ghi cùng lúc thì ai thắng?
- Độ trễ replication: dữ liệu ghi ở region A cần thời gian để xuất hiện ở region B → dẫn tới eventual consistency (nhất quán cuối cùng, không phải tức thì).
- Chi phí và độ phức tạp cao hơn hẳn: chạy full quy mô ở mọi region, cộng thêm chi phí truyền dữ liệu liên vùng (cross-region data transfer thường tính phí không rẻ).
Bảng so sánh nhanh
| Tiêu chí | Active-Passive | Active-Active |
|---|---|---|
| Region phục vụ traffic | 1 | Tất cả |
| Downtime khi mất region | Có (thời gian failover) | Gần như không |
| Chi phí | Thấp hơn | Cao hơn |
| Độ phức tạp | Thấp/trung bình | Cao |
| Xử lý ghi dữ liệu | Đơn giản (1 nơi ghi) | Khó (conflict, consistency) |
| Latency cho user toàn cầu | Không tối ưu | Tối ưu |
Tình huống thực tế
Ví dụ 1 — Ví điện tử "MoMoPay" (giả định) chọn Active-Passive
Một ví điện tử tại Việt Nam xử lý khoảng 8 triệu giao dịch/ngày, chủ yếu phục vụ người dùng trong nước. Đội kỹ sư đứng trước quyết định: đi active-active hay active-passive giữa Singapore (primary) và Jakarta (standby)?
Họ chọn Active-Passive với warm standby. Lý do:
- Giao dịch tài chính đòi hỏi tính nhất quán mạnh (strong consistency) — không thể chấp nhận cảnh hai region cùng trừ tiền một tài khoản rồi xung đột. Active-active với multi-master write sẽ mở ra rủi ro double-spend cực kỳ nguy hiểm.
- Người dùng gần như đều ở Việt Nam, latency từ Singapore đã đủ tốt, nên lợi ích "phục vụ từ region gần" của active-active gần như bằng không.
- Chi phí active-active gấp gần đôi mà không mang lại giá trị tương xứng.
Bài học: với hệ thống có yêu cầu nhất quán tài chính cao và người dùng tập trung một vùng địa lý, active-passive thường là lựa chọn đúng cả về kỹ thuật lẫn chi phí. Đừng chọn active-active chỉ vì nghe "sang" hơn.
Ví dụ 2 — Nền tảng nội dung "VStream" (giả định) chọn Active-Active
Một nền tảng phát video học tập phục vụ người dùng ở Việt Nam, Thái Lan, Indonesia và Philippines, khoảng 3 triệu người xem đồng thời vào giờ cao điểm. Traffic của họ 99% là đọc (xem video, xem danh sách khóa học), phần ghi chỉ là tiến độ học và bình luận.
Họ chọn Active-Active giữa Singapore và Jakarta, với global load balancer định tuyến theo geo. Với đặc thù đọc-nhiều-ghi-ít, active-active phát huy tối đa:
- Người dùng Indonesia được phục vụ từ Jakarta, latency giảm từ ~70ms xuống ~15ms.
- Phần ghi (tiến độ học) chấp nhận eventual consistency — nếu tiến độ đồng bộ chậm vài giây thì không ai chết cả.
- Khi một region gặp sự cố, load balancer tự dồn traffic sang region còn lại; người dùng chỉ thấy chậm hơn một chút chứ không mất dịch vụ.
Bài học: active-active tỏa sáng khi workload thiên về đọc, chấp nhận được eventual consistency, và người dùng phân tán địa lý. Chìa khóa là thiết kế mô hình dữ liệu để chịu được eventual consistency, chứ không phải ép mọi thứ phải nhất quán tức thì.
Ví dụ 3 — Sàn TMĐT khu vực và mô hình lai
Một sàn thương mại điện tử Đông Nam Á (giả định giống Shopee/Lazada về quy mô) dùng mô hình lai (hybrid): active-active cho catalog sản phẩm và trang chủ (đọc nhiều, dễ cache, chấp nhận eventual consistency), nhưng active-passive cho hệ thống thanh toán và quản lý tồn kho (cần nhất quán mạnh để không bán vượt số lượng hàng thực có).
Kết quả: người dùng duyệt sản phẩm cực nhanh từ region gần, trong khi luồng đặt hàng đi qua một "write region" duy nhất để đảm bảo tồn kho chính xác. Khi write region gặp sự cố, chỉ luồng thanh toán tạm dừng và failover trong ít phút, còn phần duyệt sản phẩm vẫn chạy bình thường.
Bài học: đừng nghĩ phải chọn một trong hai cho toàn bộ hệ thống. Chia hệ thống theo từng thành phần và áp mô hình phù hợp cho từng phần là cách các công ty lớn thực sự làm.
Hướng dẫn từng bước
Dưới đây là quy trình thực tế để đưa ra và triển khai quyết định multi-region.
Bước 1 — Phân loại workload theo đặc tính đọc/ghi và yêu cầu nhất quán. Với mỗi dịch vụ, tự hỏi: nó chủ yếu đọc hay ghi? Nó cần nhất quán mạnh (như số dư tài khoản) hay chấp nhận eventual consistency (như số lượt xem)? Đây là yếu tố quyết định lớn nhất giữa hai mô hình.
Bước 2 — Xác định yêu cầu về gián đoạn và mất dữ liệu (RTO/RPO ở mức cao). Bạn chấp nhận downtime bao lâu khi mất một region? Nếu câu trả lời là "vài phút cũng được" thì active-passive đủ dùng. Nếu là "gần như không được phép gián đoạn" thì mới cân nhắc active-active. (Cách định lượng RTO/RPO chi tiết thuộc về bài Disaster Recovery.)
Bước 3 — Chọn chiến lược replication dữ liệu. Với active-passive: replication một chiều primary → standby. Với active-active: cần cơ chế multi-master hoặc phân vùng ghi theo region (sharding theo địa lý) để tránh xung đột. Quyết định rõ ai là "nguồn sự thật" (source of truth) cho mỗi loại dữ liệu.
Bước 4 — Thiết kế cơ chế định tuyến traffic. Thường dùng DNS với health check (ví dụ Route 53 health check + failover routing cho active-passive; geolocation/latency-based routing cho active-active) hoặc global load balancer. Lưu ý TTL của DNS: TTL cao khiến failover chậm vì client còn cache bản ghi cũ.
Bước 5 — Định nghĩa quy trình failover rõ ràng. Với active-passive, viết runbook chi tiết: ai được quyền quyết định failover, các bước promote standby, cách xác nhận dữ liệu đã đồng bộ tới đâu. Quyết định failover thủ công hay tự động — tự động nhanh hơn nhưng dễ gây "failover nhầm" khi chỉ là sự cố mạng thoáng qua.
Bước 6 — Kiểm thử failover định kỳ (đây là bước bị bỏ quên nhiều nhất). Một standby chưa từng được failover thử là một standby bạn không thể tin. Hãy diễn tập failover trên môi trường thật (hoặc gần thật) theo lịch cố định — hàng quý là mức tối thiểu hợp lý.
Bước 7 — Giám sát độ trễ replication và tình trạng đồng bộ. Đo replication lag liên tục và cảnh báo khi nó vượt ngưỡng. Với active-passive, replication lag chính là RPO thực tế của bạn khi thảm họa xảy ra.
Lỗi thường gặp & mẹo
Lỗi 1 — Coi multi-AZ là multi-region. Rất nhiều đội tưởng mình "đa vùng" nhưng thực chất chỉ đa AZ trong một region. Khi cả region sập, họ mới ngã ngửa. Hãy phân biệt rõ hai lớp bảo vệ này.
Lỗi 2 — Standby không bao giờ được kiểm thử. Standby dựng xong rồi để đó, cấu hình drift dần, replication âm thầm hỏng. Đến khi thảm họa thật thì failover thất bại. Mẹo: đưa diễn tập failover vào lịch định kỳ và coi nó là bắt buộc như backup.
Lỗi 3 — DNS TTL quá cao. Bạn failover trong 2 phút nhưng client vẫn gọi region chết suốt 1 tiếng vì TTL DNS đặt 3600 giây. Mẹo: với bản ghi phục vụ failover, đặt TTL thấp (30–60 giây) và dùng health-check-based routing.
Lỗi 4 — Chọn active-active nhưng không giải quyết được xung đột ghi. Đội bật multi-master rồi phát hiện dữ liệu bị "ghi đè lẫn nhau" một cách khó lường. Mẹo: nếu buộc phải active-active có ghi, hãy phân vùng ghi theo region (mỗi bản ghi thuộc về một "home region") hoặc dùng CRDT/last-write-wins một cách có chủ đích, và chấp nhận eventual consistency ngay từ khâu thiết kế.
Lỗi 5 — Quên chi phí truyền dữ liệu liên vùng. Cross-region replication và data transfer có thể ngốn ngân sách bất ngờ. Mẹo: ước lượng lưu lượng replication trước, và cân nhắc chỉ replicate dữ liệu thực sự cần thiết.
Lỗi 6 — Split-brain khi failover tự động. Nếu chỉ là mất kết nối mạng tạm thời giữa hai region, failover tự động có thể tạo ra hai primary cùng lúc — cực kỳ nguy hiểm với dữ liệu. Mẹo: dùng cơ chế quorum/witness hoặc fencing để đảm bảo tại một thời điểm chỉ có đúng một primary được phép ghi.
Mẹo tổng quát: bắt đầu đơn giản. Rất nhiều hệ thống Việt Nam chỉ cần active-passive được diễn tập kỹ là đã đủ tin cậy. Đừng "over-engineer" active-active khi bạn chưa thực sự cần độ sẵn sàng đó.
Bài tập thực hành
- Phân loại workload. Lấy một hệ thống bạn quen thuộc (hoặc hình dung một app đặt đồ ăn). Liệt kê 5 thành phần chính (ví dụ: danh sách nhà hàng, giỏ hàng, thanh toán, thông báo, đánh giá). Với mỗi thành phần, đánh dấu: đọc-nhiều hay ghi-nhiều, cần nhất quán mạnh hay chấp nhận eventual consistency. Từ đó đề xuất active-active, active-passive hay hybrid cho từng phần.
- Thiết kế sơ đồ. Vẽ kiến trúc multi-region cho hệ thống ở bài 1: chỉ rõ region nào phục vụ traffic, hướng replication dữ liệu, và cơ chế định tuyến (DNS/global LB). Đánh dấu "write region" cho các thành phần cần nhất quán mạnh.
- Viết runbook failover. Soạn một runbook ngắn cho tình huống primary region sập trong mô hình active-passive: ai quyết định, các bước promote standby, cách kiểm tra replication lag trước khi chuyển, và cách rollback nếu primary hồi phục.
- Ước tính trade-off. Giả sử active-active tốn gấp 1,8 lần chi phí so với active-passive nhưng giảm downtime kỳ vọng khi mất region từ 15 phút xuống gần 0. Với hệ thống của bạn, mức downtime đó gây thiệt hại bao nhiêu? Từ con số này, hãy lập luận xem chi phí tăng thêm có đáng không.
Tóm tắt
Multi-region architecture là lớp bảo vệ chống lại sự cố ở cấp độ cả một region — điều mà multi-AZ không giải quyết được. Hai mô hình cốt lõi:
- Active-Passive: một region phục vụ, một region chờ; dữ liệu replicate liên tục; failover (thủ công hoặc tự động) khi primary sập. Rẻ hơn, đơn giản hơn, xử lý ghi dễ hơn, nhưng có downtime khi failover. Phù hợp với hệ thống cần nhất quán mạnh và người dùng tập trung một vùng.
- Active-Active: mọi region cùng phục vụ traffic; gần như không downtime, latency thấp cho người dùng phân tán. Nhưng đắt và phức tạp hơn nhiều, đặc biệt ở bài toán xung đột ghi và eventual consistency. Phù hợp với workload đọc-nhiều, chấp nhận nhất quán cuối cùng.