Câu trả lời ngắn
Kiến trúc cloud phù hợp cho doanh nghiệp là phương án đơn giản nhất mà vẫn đáp ứng năm ràng buộc thực tế: dữ liệu được phép nằm ở đâu, người dùng ở đâu và cần phản hồi nhanh đến mức nào, đội ngũ vận hành được gì, chi phí bị đẩy bởi yếu tố nào, và hệ thống cần sẵn sàng đến mức nào.
Bài viết đưa ra bảng chấm điểm năm ràng buộc, so sánh các phương án phổ biến (một nhà cung cấp, đa vùng, hybrid; serverless, container hay máy ảo) và các quy định về nơi lưu dữ liệu tại Việt Nam cần kiểm tra trước khi chọn vùng.
Vì sao bắt đầu từ ràng buộc, không từ công nghệ
Kiến trúc phức tạp chỉ đáng giá khi giải quyết một vấn đề có thật. Một dịch vụ cấu hình tốt, có sao lưu và giám sát thường hơn một hệ thống phân tán mà không ai trong đội hiểu hết.
Google Cloud Well-Architected Framework cũng khuyến nghị dùng dịch vụ quản lý toàn phần khi khả thi, và với hệ thống mới thì bắt đầu đơn giản, xây sản phẩm khả dụng tối thiểu (MVP), tránh thiết kế quá mức. Vì vậy bảng chấm điểm bên dưới bắt đầu từ ràng buộc vận hành chứ không từ danh sách dịch vụ.
Năm ràng buộc quyết định kiến trúc
1. Nơi lưu dữ liệu và pháp lý
Dữ liệu nào là dữ liệu cá nhân, dữ liệu nào phải lưu tại Việt Nam, dữ liệu nào được đưa ra nước ngoài và cần thủ tục gì. Ràng buộc này có thể loại ngay một số vùng hoặc nhà cung cấp nên cần xét đầu tiên (xem phần pháp lý bên dưới).
2. Độ trễ và vị trí người dùng
Người dùng ở một thành phố, cả nước hay nhiều quốc gia? Thao tác cần phản hồi tức thì (thanh toán tại quầy, điều khiển thiết bị) hay chấp nhận vài giây (báo cáo)? Chi nhánh có cần chạy khi mất mạng không? Câu trả lời quyết định vùng triển khai, CDN, xử lý tại biên hay chế độ ngoại tuyến.
3. Năng lực đội ngũ
Ai vận hành hệ thống hằng ngày, kể cả lúc nửa đêm, và đội đã quen công nghệ nào? Kiến trúc mà đội không vận hành được là rủi ro, dù trên giấy tốt đến đâu. Đội nhỏ thường hợp với dịch vụ quản lý; chỉ khi có kỹ sư nền tảng mới nên cân nhắc tự vận hành Kubernetes hay hạ tầng tại chỗ.
4. Yếu tố đẩy chi phí
Chi phí đến từ tài nguyên chạy liên tục hay theo yêu cầu, lượng dữ liệu lưu và thời gian giữ, lưu lượng ra ngoài và giữa các vùng, giấy phép phần mềm và thời gian của con người. Tải ổn định hay biến động mạnh sẽ quyết định nên trả theo mức dùng hay đặt trước. Xem thêm tối ưu chi phí cloud.
5. Tuân thủ và mức độ sẵn sàng
Hệ thống ngừng một giờ thì thiệt hại gì? Mất dữ liệu của bao lâu thì chấp nhận được? Hai câu hỏi này là mục tiêu thời gian khôi phục (RTO) và điểm khôi phục (RPO), quyết định có cần nhiều vùng sẵn sàng, nhiều vùng địa lý hay chỉ cần sao lưu tốt. Xem sao lưu và khôi phục thảm họa cho doanh nghiệp vừa và nhỏ. Yêu cầu từ khách hàng doanh nghiệp, nhật ký kiểm tra và phân quyền cũng thuộc nhóm này.
Bảng chấm điểm 5 ràng buộc
Chấm mỗi ràng buộc từ 1 (yêu cầu thấp) đến 3 (yêu cầu cao). Cột cuối cho biết điểm cao đẩy kiến trúc theo hướng nào. Đây là công cụ hỗ trợ thảo luận, không phải công thức: hai ràng buộc điểm 3 mâu thuẫn nhau là tín hiệu cần trao đổi kỹ giữa kinh doanh và kỹ thuật.
| Ràng buộc | 1 điểm | 3 điểm | Điểm cao thì nghiêng về |
|---|---|---|---|
| Nơi lưu dữ liệu và pháp lý | Không có dữ liệu cá nhân hoặc dữ liệu nhạy cảm | Dữ liệu cá nhân, dữ liệu phải lưu tại Việt Nam, chuyển ra nước ngoài cần thủ tục | Vùng hoặc nhà cung cấp có hạ tầng tại Việt Nam, hybrid, phân loại dữ liệu rõ |
| Độ trễ và người dùng | Người dùng nội bộ, chấp nhận vài giây | Thao tác tức thì, nhiều chi nhánh, mạng không ổn định | Vùng gần người dùng, CDN, xử lý tại biên, chế độ ngoại tuyến |
| Năng lực đội ngũ | Có kỹ sư nền tảng, trực vận hành | Đội nhỏ, không có người trực hạ tầng | Dịch vụ quản lý, serverless, ít thành phần tự vận hành |
| Yếu tố chi phí | Tải ổn định, dự đoán được | Tải biến động mạnh hoặc lượng dữ liệu truyền ra lớn | Trả theo dùng, tự co giãn, đặt dữ liệu gần nơi xử lý |
| Tuân thủ và sẵn sàng | Ngừng vài giờ vẫn chấp nhận được | Ngừng vài phút đã gây thiệt hại, cần nhật ký và phân quyền chặt | Nhiều vùng sẵn sàng, đa vùng địa lý, kế hoạch khôi phục đã diễn tập |
Các phương án kiến trúc và khi nào phù hợp
Một nhà cung cấp, dùng dịch vụ quản lý
Một vùng, nhiều vùng sẵn sàng (availability zone), cơ sở dữ liệu và hàng đợi do nhà cung cấp vận hành. Phù hợp với phần lớn doanh nghiệp vừa và nhỏ vì ít việc vận hành, dễ giám sát. Đánh đổi là phụ thuộc một nhà cung cấp, nên cần kế hoạch rời đi ở lớp dữ liệu.
Đa vùng địa lý
Chạy ở hai vùng trở lên để chịu được sự cố cả vùng hoặc phục vụ người dùng nhiều quốc gia. Độ sẵn sàng tăng nhưng kéo theo đồng bộ dữ liệu, chi phí truyền giữa vùng và khả năng dữ liệu cá nhân đi ra nước ngoài. Chỉ chọn khi điểm sẵn sàng hoặc độ trễ thực sự cao.
Hybrid hoặc tại chỗ
Một phần chạy trên máy chủ tại doanh nghiệp hoặc trung tâm dữ liệu trong nước, phần còn lại trên cloud. Hợp khi có dữ liệu phải ở lại tại chỗ, chi nhánh cần chạy khi mất mạng hoặc hạ tầng hiện có còn khấu hao. Đổi lại, doanh nghiệp tự vận hành phần cứng và phải thiết kế đồng bộ cẩn thận.
Đa cloud
Dùng nhiều nhà cung cấp cho cùng một hệ thống hiếm khi là điểm khởi đầu tốt cho doanh nghiệp vừa và nhỏ: mỗi nền tảng cần kỹ năng, giám sát và bảo mật riêng. Thường hợp lý hơn khi dùng mỗi nhà cung cấp cho một mục đích rõ ràng.
Serverless, container hay máy ảo
Đây là lựa chọn ở tầng chạy ứng dụng, độc lập với việc chọn nhà cung cấp.
- Gợi ý mặc định cho đội nhỏ: dịch vụ container hoặc serverless được quản lý, cơ sở dữ liệu được quản lý.
- Chỉ tự vận hành Kubernetes khi có người chịu trách nhiệm nền tảng và có lý do cụ thể.
| Mô hình | Hợp với | Ưu điểm | Cần lưu ý |
|---|---|---|---|
| Serverless (hàm, container được quản lý) | Tải theo sự kiện, biến động, đội nhỏ | Không quản lý máy chủ, co giãn theo yêu cầu, có thể về 0 khi không dùng | Giới hạn thời gian chạy, khởi động lạnh, phụ thuộc dịch vụ riêng của nhà cung cấp |
| Container (Kubernetes hoặc dịch vụ container quản lý) | Nhiều dịch vụ, cần chuẩn hóa triển khai, muốn dễ chuyển nhà cung cấp | Đóng gói nhất quán, chuyển giữa môi trường dễ hơn | Kubernetes tự vận hành đòi hỏi kỹ năng và thời gian đáng kể |
| Máy ảo | Phần mềm cũ, cần kiểm soát hệ điều hành, tải ổn định | Quen thuộc, kiểm soát đầy đủ | Tự vá lỗi, sao lưu, mở rộng; dễ để máy chạy không tải |
Dùng Well-Architected Framework để rà soát
Sau khi chọn phương án, hãy rà soát theo bộ khung của nhà cung cấp. Ba bộ khung có trụ cột gần giống nhau:
- AWS Well-Architected Framework: sáu trụ cột gồm vận hành xuất sắc, bảo mật, độ tin cậy, hiệu quả hiệu năng, tối ưu chi phí và bền vững.
- Azure Well-Architected Framework: năm trụ cột gồm độ tin cậy, bảo mật, tối ưu chi phí, vận hành xuất sắc và hiệu quả hiệu năng.
- Google Cloud Well-Architected Framework: các trụ cột về bảo mật, độ tin cậy, hiệu năng, chi phí, vận hành và bền vững.
Cách dùng thực tế
Đừng cố đạt mọi khuyến nghị cùng lúc. Chọn trụ cột gắn với ràng buộc điểm 3 của bạn, ghi lại các rủi ro tìm được, quyết định rủi ro nào sửa ngay, rủi ro nào chấp nhận có ghi chép. Microsoft Learn cũng nhấn mạnh các trụ cột có đánh đổi với nhau, ví dụ tăng độ tin cậy thường tăng chi phí.
Lưu ý về nơi lưu dữ liệu theo pháp luật Việt Nam
Luật Bảo vệ dữ liệu cá nhân số 91/2025/QH15 có hiệu lực từ ngày 01/01/2026. Theo khoản 1 Điều 20, chuyển dữ liệu cá nhân xuyên biên giới bao gồm: chuyển dữ liệu cá nhân đang lưu tại Việt Nam đến hệ thống lưu trữ đặt ngoài lãnh thổ Việt Nam; tổ chức tại Việt Nam chuyển dữ liệu cá nhân cho tổ chức, cá nhân ở nước ngoài; và dùng nền tảng ngoài lãnh thổ Việt Nam để xử lý dữ liệu cá nhân thu thập tại Việt Nam. Nói cách khác, đặt dữ liệu khách hàng trên vùng cloud ở nước ngoài có thể thuộc diện này.
Khoản 2 Điều 20 yêu cầu bên chuyển dữ liệu lập hồ sơ đánh giá tác động chuyển dữ liệu cá nhân xuyên biên giới và gửi cơ quan chuyên trách trong 60 ngày kể từ ngày đầu tiên chuyển, trừ các trường hợp tại khoản 6. Một trường hợp miễn trong khoản 6 là tổ chức lưu trữ dữ liệu cá nhân của chính người lao động của mình trên dịch vụ điện toán đám mây. Chi tiết về hồ sơ do Chính phủ quy định; xem bài Luật Bảo vệ dữ liệu cá nhân 2025.
Về lưu trữ dữ liệu tại Việt Nam: Luật An ninh mạng số 116/2025/QH15 có hiệu lực từ ngày 01/7/2026, thay thế Luật An ninh mạng 2018 và Luật An toàn thông tin mạng 2015. Điều 25 của luật mới có hai quy định cần biết. Điểm d khoản 2 yêu cầu doanh nghiệp trong nước và nước ngoài cung cấp dịch vụ trên mạng viễn thông, Internet và dịch vụ gia tăng trên không gian mạng tại Việt Nam lưu trữ thông tin cá nhân và dữ liệu do người dùng tạo ra (tên tài khoản, thời gian sử dụng, thông tin thanh toán, địa chỉ IP truy cập…) trong thời gian luật định sau khi người dùng ngừng dùng dịch vụ. Khoản 3 yêu cầu doanh nghiệp có hoạt động thu thập, khai thác, phân tích, xử lý dữ liệu cá nhân, dữ liệu về mối quan hệ và dữ liệu do người dùng tại Việt Nam tạo ra phải lưu trữ dữ liệu này tại Việt Nam trong thời gian Chính phủ quy định; doanh nghiệp nước ngoài thuộc diện này phải đặt chi nhánh hoặc văn phòng đại diện. Theo phân tích trên Tạp chí Luật sư Việt Nam, không phải mọi trường hợp đều bắt buộc lập chi nhánh. Chính phủ quy định chi tiết các khoản này; Nghị định 53/2022/NĐ-CP là văn bản hướng dẫn theo luật cũ, nên hãy kiểm tra văn bản hướng dẫn đang có hiệu lực khi triển khai.
Hệ quả cho kiến trúc: phân loại dữ liệu ngay từ đầu (dữ liệu cá nhân, dữ liệu người dùng tạo ra, dữ liệu vận hành), ghi rõ vùng lưu trữ của từng loại kể cả bản sao lưu và nhật ký, và kiểm tra các dịch vụ có tự sao chép dữ liệu sang vùng khác không.
Bài viết mang tính thông tin, không phải tư vấn pháp lý.
Tránh bị khóa nhà cung cấp mà không phải trả giá hai lần
Khả năng chuyển đổi quan trọng nhất ở lớp dữ liệu và lớp định danh: dùng định dạng chuẩn, có cách xuất dữ liệu đã thử, tránh tính năng riêng của nhà cung cấp khi lợi ích không đáng kể. Chuyển đổi hoàn toàn không miễn phí, nên hãy chọn phần bắt buộc phải chuyển được.
Viết một trang kế hoạch rời đi: dữ liệu ở đâu, xuất ra thế nào, ai làm được, phần nào hỏng trước nếu nhà cung cấp gặp sự cố. Kế hoạch này rẻ và cũng là một buổi rà soát thiết kế hữu ích.
Quy trình 6 bước để ra quyết định
Ví dụ minh họa: một chuỗi bán lẻ nhiều cửa hàng, mạng ở một số điểm không ổn định, đội IT ba người. Độ trễ, năng lực đội ngũ và pháp lý (do có dữ liệu khách hàng) đều ở mức 3. Phương án hợp lý là một nhà cung cấp có vùng đáp ứng yêu cầu lưu trữ, cơ sở dữ liệu được quản lý và ứng dụng bán hàng có chế độ ngoại tuyến. Đây là kịch bản giả định, không phải dự án của khách hàng cụ thể.
- Liệt kê khối lượng công việc và dữ liệu, phân loại dữ liệu cá nhân và dữ liệu phải lưu tại Việt Nam.
- Chấm điểm 5 ràng buộc cùng đại diện kinh doanh và kỹ thuật.
- Chọn phương án đơn giản nhất đáp ứng các ràng buộc điểm 3.
- Đặt mục tiêu RTO, RPO và kiểm tra phương án sao lưu, khôi phục.
- Rà soát theo Well-Architected Framework của nhà cung cấp đã chọn.
- Ghi lại quyết định kiến trúc (bối cảnh, phương án, lựa chọn, hệ quả) và kế hoạch rời đi; xem lại khi ràng buộc thay đổi.
EYC hỗ trợ thế nào
EYC tư vấn và triển khai hạ tầng cloud và dữ liệu cho doanh nghiệp, bắt đầu từ ràng buộc vận hành thay vì từ công nghệ. Xem giải pháp hạ tầng đám mây và dữ liệu, phần mềm và SaaS, hoặc liên hệ EYC.
Câu hỏi thường gặp
Nên chọn kiến trúc cloud nào cho doanh nghiệp vừa và nhỏ?
Thường là một nhà cung cấp, dịch vụ quản lý, nhiều vùng sẵn sàng trong một vùng địa lý, kèm sao lưu đã thử khôi phục. Chỉ thêm đa vùng, hybrid hay Kubernetes khi bảng chấm điểm cho thấy cần.
Serverless hay container tốt hơn?
Không có lựa chọn tốt hơn chung. Serverless hợp với tải theo sự kiện và đội nhỏ; container hợp khi có nhiều dịch vụ cần chuẩn hóa triển khai hoặc muốn dễ chuyển nhà cung cấp. Nhiều hệ thống dùng cả hai.
Đặt dữ liệu trên cloud nước ngoài có vi phạm luật không?
Không mặc nhiên vi phạm, nhưng có thể thuộc diện chuyển dữ liệu cá nhân xuyên biên giới theo Điều 20 Luật 91/2025/QH15, cần lập hồ sơ đánh giá tác động trừ các trường hợp được miễn. Doanh nghiệp cung cấp dịch vụ trên mạng tại Việt Nam còn có thể thuộc diện phải lưu trữ dữ liệu tại Việt Nam theo khoản 3 Điều 25 Luật An ninh mạng 2025. Nên tham khảo tư vấn pháp lý cho trường hợp cụ thể.
Khi nào cần hybrid cloud?
Khi có dữ liệu phải ở lại tại chỗ, chi nhánh cần chạy khi mất mạng, hoặc hạ tầng hiện có còn giá trị sử dụng. Nếu không, hybrid thường thêm việc vận hành mà không thêm giá trị.
Well-Architected Framework là gì?
Là bộ nguyên tắc và câu hỏi rà soát kiến trúc do AWS, Microsoft Azure và Google Cloud công bố, chia theo các trụ cột như bảo mật, độ tin cậy, hiệu năng, chi phí và vận hành. Dùng để rà soát sau khi đã chọn phương án.