Bài 15 — Relational Database — RDS, Cloud SQL

Mở đầu — vì sao bài này quan trọng

Nếu bạn từng làm việc với một ứng dụng web thật sự — dù là sàn thương mại điện tử, app đặt xe, hay hệ thống quản lý bán hàng cho chuỗi cửa hàng — thì gần như chắc chắn trái tim của hệ thống đó là một cơ sở dữ liệu quan hệ (relational database). Đơn hàng, tài khoản người dùng, giao dịch thanh toán, tồn kho... tất cả đều nằm trong những bảng có quan hệ chặt chẽ với nhau, được ràng buộc bởi tính toàn vẹn dữ liệu và các giao dịch (transaction) đảm bảo "được ăn cả, ngã về không".

Trong nhiều năm, việc vận hành một database như MySQL hay PostgreSQL là công việc của những DBA (Database Administrator) giàu kinh nghiệm: họ tự cài đặt, tự cấu hình replication, tự lên lịch backup, tự vá lỗi bảo mật lúc 2 giờ sáng khi có CVE mới. Đây là công việc cực kỳ tốn công, dễ sai sót, và khi sai thì hậu quả rất lớn — mất dữ liệu là mất niềm tin của khách hàng.

Đó chính là lý do các nhà cung cấp cloud tạo ra Managed Relational Database — dịch vụ database quan hệ được quản lý. Amazon có RDS (Relational Database Service), Google có Cloud SQL, Microsoft Azure có Azure Database. Bài học này sẽ giúp bạn hiểu rõ managed database là gì, nó gánh giúp bạn những phần việc nào, khi nào nên dùng, và những cạm bẫy cần tránh. Nắm vững nội dung này, bạn sẽ tự tin đưa ra quyết định kiến trúc cho bất kỳ dự án nào có dữ liệu quan trọng.

Khái niệm cốt lõi

Managed Relational Database là gì?

Về bản chất, nhà cung cấp cloud chạy giúp bạn một hệ quản trị cơ sở dữ liệu (DBMS) — thường là MySQL, PostgreSQL, MariaDB, hoặc SQL Server — dưới dạng một dịch vụ được quản lý. Bạn vẫn dùng đúng cái database engine quen thuộc, viết đúng câu SQL như trước, ứng dụng của bạn kết nối bằng đúng driver cũ. Điểm khác biệt nằm ở chỗ: những công việc vận hành nặng nhọc phía dưới đã có nhà cung cấp lo.

Cụ thể, một managed database sẽ gánh giúp bạn:

• Provisioning — bạn chỉ cần chọn phiên bản engine, kích thước máy, dung lượng ổ đĩa, rồi bấm tạo. Vài phút sau bạn có một database sẵn sàng, thay vì mất cả ngày cài đặt thủ công trên server trống.
• Patching — khi engine ra bản vá bảo mật hoặc phiên bản mới, nhà cung cấp tự động (hoặc theo lịch bạn đặt) cập nhật. Bạn không phải thức đêm canh CVE nữa.
• Backup — tự động sao lưu hàng ngày, giữ lại các bản snapshot, và quan trọng nhất là hỗ trợ Point-in-Time Recovery (PITR) — khôi phục về đúng thời điểm bất kỳ trong quá khứ, ví dụ "10:37 sáng thứ Ba tuần trước".
• Replication — dễ dàng tạo bản sao (replica) để tăng khả năng chịu tải đọc, hoặc để dự phòng khi máy chính gặp sự cố.
• Monitoring — cung cấp sẵn các biểu đồ về CPU, bộ nhớ, số kết nối, IOPS, độ trễ truy vấn, giúp bạn phát hiện vấn đề sớm.

Hãy nhớ một câu để phân biệt rõ ranh giới trách nhiệm: nhà cung cấp lo phần "chạy database", bạn lo phần "thiết kế và dùng database cho đúng". Họ không thiết kế bảng giúp bạn, không viết index giúp bạn, và không sửa câu SQL chậm giúp bạn.

Vì sao là "quan hệ" (relational) và không phải cái khác?

Cơ sở dữ liệu quan hệ tổ chức dữ liệu thành các bảng (table) gồm hàng và cột, với schema rõ ràng (mỗi cột có kiểu dữ liệu cố định). Sức mạnh của nó nằm ở:

• Tính toàn vẹn nhờ ràng buộc khóa ngoại (foreign key), khóa chính (primary key), và các constraint.
• Giao dịch ACID — Atomicity, Consistency, Isolation, Durability — đảm bảo một chuỗi thao tác hoặc thành công trọn vẹn, hoặc quay lại như chưa từng xảy ra. Đây là lý do ngân hàng, ví điện tử, sàn thương mại luôn chọn relational cho dữ liệu tiền bạc.
• SQL — ngôn ngữ truy vấn mạnh mẽ, chuẩn hóa, cho phép join nhiều bảng, tổng hợp, lọc phức tạp.

(Lưu ý: NoSQL, data warehouse hay cache là những công cụ khác cho bài toán khác — chúng ta sẽ không bàn ở đây, vì bài này tập trung riêng vào relational được quản lý.)

Các lựa chọn engine phổ biến

Trên RDS và Cloud SQL, bạn thường chọn một trong bốn engine:

• MySQL — phổ biến nhất, cộng đồng lớn, hợp với web app truyền thống, WordPress, các hệ thống PHP.
• PostgreSQL — mạnh về tính năng nâng cao (JSON, geospatial với PostGIS, full-text search), ngày càng được ưa chuộng cho ứng dụng hiện đại.
• MariaDB — nhánh mở của MySQL, tương thích cao, một số tổ chức chọn vì lý do license và cộng đồng.
• SQL Server — của Microsoft, thường gặp ở doanh nghiệp dùng hệ sinh thái .NET.

Ngoài ra, AWS còn có Aurora — phiên bản tương thích MySQL/PostgreSQL nhưng được viết lại phần lưu trữ để đạt hiệu năng và độ bền cao hơn. Aurora là một cấp độ cao hơn của managed, phù hợp khi bạn cần khả năng mở rộng lớn.

Mô hình trách nhiệm chung (Shared Responsibility)

Điều quan trọng nhất cần khắc cốt ghi tâm: managed không có nghĩa là "khỏi lo hết". Bạn vẫn phải chịu trách nhiệm về:

• Thiết kế schema và đánh index hợp lý.
• Tối ưu câu truy vấn (query) chậm.
• Cấu hình bảo mật mạng — đặt database trong mạng riêng, chỉ cho phép ứng dụng kết nối, không phơi ra Internet.
• Quản lý user, phân quyền trong database.
• Chọn đúng kích thước máy để không lãng phí tiền hoặc không bị nghẽn.

Tình huống thực tế

Tình huống 1 — Sàn thương mại điện tử ở TP.HCM chuyển từ self-managed sang RDS

Một startup thương mại điện tử tại TP.HCM (gọi là "ShopViet") ban đầu tự chạy MySQL trên một VM thuê ngoài. Đội kỹ thuật chỉ có 4 người, không ai chuyên sâu về DBA. Vào đợt sale 12/12, lượng đơn hàng tăng gấp 8 lần. Server database bị nghẽn, và tệ hơn — do trước đó backup được cấu hình sai (chỉ sao lưu file mà không kiểm tra khôi phục), khi ổ đĩa đầy khiến MySQL crash, họ mất 6 giờ dữ liệu đơn hàng.

Sau sự cố đau đớn đó, họ chuyển sang Amazon RDS for MySQL. Kết quả:

• Backup tự động hàng ngày, bật PITR, giữ 7 ngày. Không còn nỗi lo backup lỗi thầm lặng.
• Trước mỗi đợt sale, họ chỉ cần scale up instance từ db.t3.medium lên db.r5.large bằng vài cú click, và tạo thêm read replica để gánh lưu lượng đọc trang sản phẩm.
• Việc vá lỗi bảo mật diễn ra tự động trong khung giờ bảo trì 3 giờ sáng.

Bài học rút ra: Với đội nhỏ, thiếu chuyên gia DBA, chi phí trả thêm cho managed database rẻ hơn rất nhiều so với cái giá của một lần mất dữ liệu. Điều họ mua không chỉ là server, mà là sự an tâm và thời gian để tập trung vào sản phẩm.

Tình huống 2 — Fintech chọn PostgreSQL trên Cloud SQL với High Availability

Một công ty fintech Đông Nam Á cung cấp ví điện tử cần đảm bảo mỗi giao dịch nạp/rút tiền là chính xác tuyệt đối. Họ chọn PostgreSQL trên Google Cloud SQL vì cần các tính năng transaction mạnh và kiểu dữ liệu chính xác cho tiền tệ.

Điểm mấu chốt trong thiết kế của họ:

• Bật cấu hình High Availability với node dự phòng ở một zone khác. Khi node chính gặp sự cố phần cứng, Cloud SQL tự động failover sang node dự phòng trong khoảng một đến hai phút, ứng dụng chỉ cần kết nối lại.
• Mọi cột số tiền dùng kiểu NUMERIC (decimal) chứ không dùng FLOAT, để tránh sai số làm tròn — một nguyên tắc vàng khi làm việc với tiền.
• Kết nối database hoàn toàn qua private IP trong VPC, không bao giờ mở ra Internet công cộng, và bắt buộc mã hóa đường truyền.

Có một tháng, một zone của Google gặp sự cố hạ tầng. Nhờ HA, hệ thống của họ chỉ gián đoạn khoảng 90 giây rồi tự phục hồi, khách hàng gần như không nhận ra.

Bài học rút ra: Với dữ liệu quan trọng như tiền bạc, High Availability không phải tính năng xa xỉ mà là bắt buộc. Managed database biến việc thiết lập failover — vốn cực kỳ phức tạp nếu tự làm — thành một tùy chọn bật/tắt.

Tình huống 3 — Bài học về chi phí và over-provisioning

Một công ty SaaS B2B ở Hà Nội tạo một RDS instance loại db.r5.2xlarge "cho chắc ăn" ngay từ đầu, kèm 500 GB storage loại IOPS cao. Sau 3 tháng, khi rà soát hóa đơn, họ phát hiện database này ngốn gần 900 USD/tháng, trong khi mức sử dụng CPU trung bình chỉ 8% và dung lượng dữ liệu thực tế mới 40 GB.

Họ đã: hạ instance xuống db.t3.large, chuyển storage sang loại tiêu chuẩn với auto-scaling storage bật sẵn, và mua Reserved Instance 1 năm cho phần tải cơ bản. Hóa đơn giảm còn khoảng 220 USD/tháng — tiết kiệm hơn 75%.

Bài học rút ra: Managed database rất dễ tạo, nên cũng rất dễ tạo quá to và quên lãng. Hãy bắt đầu nhỏ, theo dõi số liệu thực tế, rồi mới scale lên. Tiền lãng phí ở database thường âm thầm nhưng tích lũy rất lớn.

Hướng dẫn từng bước

Dưới đây là quy trình chuẩn để đưa một managed relational database vào dự án — áp dụng được cho cả RDS lẫn Cloud SQL:

• Chọn engine và phiên bản. Xác định MySQL, PostgreSQL hay engine khác dựa trên ứng dụng của bạn. Chọn phiên bản major được hỗ trợ dài hạn, tránh chọn bản quá cũ sắp hết vòng đời.

• Chọn kích thước ban đầu — nhỏ thôi. Bắt đầu với instance vừa phải (ví dụ loại t3/t4g cho tải nhẹ). Bật storage auto-scaling để ổ đĩa tự nới khi gần đầy, tránh sự cố "hết dung lượng làm crash database".

• Đặt database trong mạng riêng. Tạo hoặc chọn VPC, đặt instance trong private subnet, tắt "public accessibility". Ứng dụng kết nối qua private IP. Đây là bước bảo mật quan trọng nhất, đừng bỏ qua.

• Cấu hình quyền truy cập. Chỉ cho phép các máy/ dịch vụ cần thiết kết nối tới cổng database (3306 cho MySQL, 5432 cho PostgreSQL). Tạo user riêng cho ứng dụng với quyền tối thiểu, không dùng tài khoản admin cho app.

• Bật backup và Point-in-Time Recovery. Đặt thời gian giữ backup phù hợp (ví dụ 7–14 ngày). Đặt khung giờ backup và bảo trì vào lúc ít tải nhất.

• Bật High Availability nếu là hệ thống quan trọng. Với môi trường production của dịch vụ không được phép chết, hãy bật Multi-AZ (RDS) hoặc HA (Cloud SQL) để có node dự phòng tự động failover.

• Thiết lập monitoring và cảnh báo. Đặt alert cho các ngưỡng: CPU cao kéo dài, dung lượng ổ đĩa gần đầy, số kết nối chạm trần, độ trễ replica. Phát hiện sớm luôn rẻ hơn xử lý khủng hoảng.

• Kiểm thử khôi phục. Đây là bước hầu hết mọi người bỏ quên: định kỳ thử khôi phục một bản backup ra instance mới để chắc chắn backup dùng được thật. Backup chưa từng được khôi phục thử thì không nên tin.

• Thêm read replica khi tải đọc tăng. Khi các truy vấn đọc (báo cáo, trang danh sách) gây áp lực, tạo read replica và trỏ luồng đọc sang đó, giữ máy chính cho ghi.

Lỗi thường gặp & mẹo

Lỗi 1 — Phơi database ra Internet công cộng. Rất nhiều sự cố rò rỉ dữ liệu xuất phát từ việc bật "public accessibility" cho tiện, kèm mật khẩu yếu. Đừng bao giờ. Database luôn nằm trong mạng riêng.

Lỗi 2 — Nghĩ managed là "khỏi cần biết SQL". Nhà cung cấp không tối ưu câu truy vấn giúp bạn. Một câu SQL thiếu index có thể khiến instance mạnh nhất cũng nghẽn. Hãy học đọc query plan và đánh index đúng chỗ.

Lỗi 3 — Không bật auto-scaling storage. Ổ đĩa đầy là một trong những nguyên nhân crash database phổ biến nhất. Bật auto-scaling storage ngay từ đầu.

Lỗi 4 — Quên khung giờ bảo trì. Nhà cung cấp có thể khởi động lại instance để vá lỗi. Nếu bạn không chủ động đặt khung giờ, việc restart có thể rơi vào giờ cao điểm. Hãy đặt vào lúc ít người dùng.

Lỗi 5 — Nhầm HA với backup. High Availability giúp bạn không sập khi phần cứng hỏng, nhưng không cứu bạn khi ai đó lỡ tay DELETE nhầm dữ liệu — vì lệnh xóa được nhân bản ngay sang node dự phòng. Backup và PITR mới là thứ cứu bạn trong trường hợp này. Bạn cần cả hai.

Mẹo về cạn kết nối: Nếu app tạo quá nhiều kết nối trực tiếp (thường gặp với serverless), hãy dùng connection pooler như RDS Proxy hoặc pgBouncer để tránh tình trạng "too many connections".

Mẹo về chi phí: Với tải ổn định dài hạn, mua Reserved Instance / Committed Use tiết kiệm 30–60% so với trả theo giờ. Nhưng chỉ mua sau khi đã biết kích thước thực sự cần.

Bài tập thực hành

• Thiết kế quyết định: Bạn đang xây một app quản lý phòng khám với dữ liệu bệnh nhân và hóa đơn. Hãy chọn engine (MySQL hay PostgreSQL) và giải thích, đồng thời quyết định có bật HA hay không và vì sao.

• Tạo và bảo mật: Trên một tài khoản cloud (dùng free tier nếu có), tạo một instance managed database nhỏ nhất. Đặt nó trong private subnet, tắt public access, tạo một user riêng cho ứng dụng với quyền chỉ trên một schema.

• Kịch bản khôi phục: Bật PITR, tạo một bảng và chèn vài dòng dữ liệu. Ghi lại thời điểm. Sau đó "vô tình" xóa bảng, rồi thực hành khôi phục về đúng thời điểm trước khi xóa ra một instance mới. Viết lại các bước bạn đã làm.

• Rà soát chi phí: Cho một instance db.r5.2xlarge với CPU trung bình 8%, hãy đề xuất phương án tối ưu chi phí và ước lượng mức tiết kiệm.

• Chẩn đoán: Ứng dụng báo lỗi "too many connections" vào giờ cao điểm dù CPU database vẫn thấp. Hãy liệt kê các nguyên nhân khả dĩ và hướng xử lý.

Tóm tắt

Managed Relational Database — RDS, Cloud SQL, Azure Database — là cách nhà cung cấp cloud chạy giúp bạn các engine quen thuộc như MySQL, PostgreSQL, MariaDB, SQL Server dưới dạng dịch vụ được quản lý. Họ gánh phần việc nặng nhọc: provisioning, patching, backup, replication, monitoring — để bạn không phải làm DBA thủ công.

Nhưng managed không có nghĩa là hết trách nhiệm: bạn vẫn phải thiết kế schema tốt, đánh index đúng, tối ưu truy vấn, và cấu hình bảo mật mạng chặt chẽ. Ba nguyên tắc cần nhớ mãi: đặt database trong mạng riêng, phân biệt rõ HA (chống sập phần cứng) với backup/PITR (chống mất dữ liệu do lỗi người), và bắt đầu nhỏ rồi scale theo số liệu thực tế để không đốt tiền vô ích.

Khi nắm chắc những điều này, bạn đã có nền tảng vững để đưa ra quyết định kiến trúc dữ liệu cho bất kỳ dự án nào — từ một app khởi nghiệp ở TP.HCM đến một hệ thống fintech phục vụ hàng triệu người dùng.