Database Architecture 1: High Availability & Monitoring
Product Decode
•
1. Lời Nguyền Uptime & Bài Toán Đánh Đổi "Các Số 9"
High Availability (HA - Độ sẵn sàng cao) không phải là một chứng chỉ kỹ thuật để team Engineering khoe khoang; nó là một chỉ số đánh đổi kinh doanh (Business Trade-off). Khi PM yêu cầu "hệ thống không bao giờ sập", họ đang yêu cầu một thứ viễn vông và cực kỳ đốt tiền.
Mỗi một "số 9" thêm vào đòi hỏi chi phí hạ tầng và độ phức tạp kỹ thuật tăng theo cấp số nhân, trong khi lợi nhuận biên thu lại giảm dần. Để thấy rõ sự đánh đổi này, hãy nhìn vào quỹ thời gian sập (Error Budget) cho phép của các chuẩn SLA phổ biến:
Hãy tính toán thiệt hại thực tế: Một sàn E-commerce có Gross Merchandise Value (GMV) $1.5M/ngày. Nếu hệ thống sập 5 phút (tương đương toàn bộ quỹ thời gian của chuẩn 99.999% trong một năm), công ty bốc hơi trực tiếp ~$5,200 tiền doanh thu.
Tuy nhiên, con số này chỉ là "phần nổi". Thiệt hại thực sự nằm ở:
Hiệu ứng vết dầu loang: 30% giỏ hàng bị bỏ rơi vĩnh viễn vì khách hàng mất kiên nhẫn và chuyển sang đối thủ.
Burn Rate lãng phí: Tiền quảng cáo (Ads) vẫn chảy nhưng dẫn khách về một trang trắng.
Khủng hoảng vận hành: Hàng ngàn Support Tickets tạo ra áp lực khổng lồ lên đội ngũ CSKH, chi phí xử lý sự cố đôi khi cao hơn cả doanh thu mất đi.
Quy tắc của PM/BA: Đừng yêu cầu Uptime 100%. Hãy thiết lập Service Level Agreement (SLA) dựa trên Chi phí cơ hội của Downtime so với Chi phí đầu tư hạ tầng.
Anti-Pattern: Tư duy Vague (Mơ hồ) vs. Specific (Thực chiến)
Nhóm
Vague / Bad (Thiếu kinh nghiệm)
Good / Specific (Thực chiến)
Mục tiêu
"Cải thiện trải nghiệm người dùng bằng cách giảm downtime."
"Duy trì SLA 99.9% (dưới 43 phút downtime/tháng) để đảm bảo tỷ lệ Drop-off tại màn hình Checkout không vượt quá 2%."
Quyết định
"Hệ thống tool nội bộ (Backoffice) cũng cần thiết kế xịn và ổn định như App chính."
"Backoffice tool chỉ cần SLA 99% (chấp nhận sập 3 ngày/năm) để dồn ngân sách server và nhân lực cho Core Payment Engine."
Giám sát
"Báo động ngay khi hệ thống có lỗi."
"Thiết lập Error Budget: Nếu tỷ lệ lỗi vượt quá 0.1% trong 24h, dừng toàn bộ việc ra mắt tính năng mới để tập trung fix ổn định hệ thống."
2. Giải Phẫu Kiến Trúc: Nhận Diện SPOF (Single Point of Failure)
Kẻ thù lớn nhất của HA là SPOF. SPOF là mắt xích yếu nhất: nếu nó đứt, toàn bộ dây chuyền sản xuất ngừng hoạt động.
Sự khác biệt sinh tử mà PM cần hiểu nằm ở bản chất của việc mở rộng:
Web Servers là Stateless (Phi trạng thái): Việc scale cực kỳ rẻ và tuyến tính. Bạn có thể bật 100 server lúc sale Black Friday và tắt đi vào ngày hôm sau.
Database Server là Stateful (Có trạng thái): Nó ôm "sự thật" của hệ thống. Bạn không thể tùy tiện copy một database ra làm hai mà không có cơ chế đồng bộ phức tạp.
Dưới đây là một kiến trúc sơ khai chứa các điểm chết chết người:
Dù bạn có 3 Web Servers, nhưng 1 Load Balancer và 1 Database Server chính là các SPOF. Database chết -> Không ai mua được hàng. Load Balancer chết -> Mọi yêu cầu từ User bị chặn ngay từ cửa.
3. Khử SPOF Bằng Kiến Trúc Primary-Standby
Để tiêu diệt Database SPOF, chúng ta nâng cấp lên mô hình Active-Passive (Primary-Standby). Trong mô hình này, Primary xử lý toàn bộ các Business Rules (Read/Write), còn Standby âm thầm sao chép dữ liệu và sẵn sàng thay thế (Failover) khi Primary gục ngã.
4. Database Monitoring: Quyền Lực Của Sự Chủ Động
Một hệ thống Primary-Standby sẽ vô dụng nếu không có "con mắt" giám sát. Chờ đến lúc User gào thét trên mạng xã hội mới biết DB sập là sự thất bại của hệ thống Monitoring.
Anti-Pattern: Giám sát Vanity Metrics
Nhiều đội ngũ set alert (cảnh báo) khi "CPU > 90%". Đây là Vanity Metric. CPU cao không có nghĩa là hệ thống lỗi, nó có thể chỉ là do Traffic hợp lệ đang tăng.
Metrics Sống Còn (Actionable Metrics):
Query Latency (Độ trễ truy vấn): Nếu Latency trung bình tăng từ 20ms lên 2000ms (2s), tỷ lệ Conversion Rate (CR) có thể giảm mạnh tới 15%. Đây là metric báo hiệu trực tiếp đến doanh thu.
Disk IOPS: Tốc độ đọc/ghi vật lý của ổ cứng. Đây là nút thắt cổ chai tàn khốc nhất. Hết RAM thì DB chậm, hết IOPS thì DB "đứng hình".
Active Connections: Số lượng phiên kết nối. Nếu số này chạm trần (Max Connections), mọi User đăng nhập mới sẽ nhận lỗi 503 Service Unavailable.
Cách Monitoring Kích Hoạt Failover (The How)
Khi Primary sập, quá trình "thay tướng" (Failover) phải diễn ra tự động. Quá trình này được mô hình hóa bằng Business Rules chặt chẽ nhằm tránh việc đưa ra quyết định sai lầm.
5. Ứng Dụng Framework PEUF Cho Edge Cases
Lý thuyết thì hoàn hảo, nhưng thực chiến luôn đầy rẫy các góc chết. Hãy dùng framework PEUF (Permission, Empty/Extreme, Unavailability, Fraud) để audit hệ thống HA của bạn:
[P] Permission (Phân quyền Failover):
Rủi ro: Kỹ sư Junior lỡ tay trigger lệnh Manual Failover trong giờ cao điểm làm gián đoạn mọi transaction.
Giải pháp: Setup Role-Based Access Control (RBAC). Chỉ có DevOps/SRE Lead mới có quyền override hệ thống Failover tự động bằng khóa cứng (MFA).
[E] Extreme Traffic (Đỉnh điểm Traffic):
Rủi ro: Sự kiện Flash Sale làm CPU tăng vọt 100%, Monitoring lầm tưởng DB đã chết và liên tục kích hoạt Failover (Flapping), khiến hệ thống tê liệt hoàn toàn.
Giải pháp: Điều kiện Failover không bao giờ dựa trên CPU. Chỉ trigger Failover khi rớt Connection hoàn toàn (Ping rớt 3-5 lần liên tiếp).
Rủi ro: Cáp mạng giữa Primary và Monitoring bị đứt, nhưng Primary vẫn đang kết nối với Web Server. Monitoring tưởng Primary chết nên đưa Standby lên làm vua. Lúc này hệ thống có 2 Primary cùng nhận lệnh Write (Split-brain), gây xung đột dữ liệu thảm khốc.
Giải pháp: Áp dụng kỹ thuật STONITH (Shoot The Other Node In The Head) - Tự động sập nguồn điện hoặc cắt hẳn mạng vật lý của con Primary cũ trước khi phong vương cho con Standby.
[F] Fraud / Abuse (Bạo hành dữ liệu):
Rủi ro: Đối thủ dùng bot (Scraper) liên tục cào dữ liệu báo cáo nặng (Heavy Read Queries). Các query này nuốt trọn Disk IOPS, gián tiếp giết chết Primary và ảnh hưởng đến khách mua hàng thật.
Giải pháp: Thiết lập Rate Limit nghiêm ngặt ở tầng API Gateway dựa trên User_ID/IP, và điều hướng các query dạng báo cáo/thống kê sang một Replica dành riêng cho Read (sẽ học ở phần sau).
6. Lời Kết: Từ Phòng Thủ Sang Tấn Công Bài Toán Scale
Cấu trúc Primary-Standby kết hợp Monitoring chủ động đã giúp hệ thống phòng thủ thành công trước các điểm chết cục bộ (SPOF). Tuy nhiên, Standby lúc này chỉ là một "tấm khiên" dự phòng thụ động, gây lãng phí tài nguyên khổng lồ.
Khi lượng người dùng tăng vọt, hàng triệu request Đọc (Read) dội thẳng vào Primary DB sẽ khiến nút thắt cổ chai IOPS tái diễn. Làm thế nào để tận dụng các node Standby rảnh rỗi nhằm mở rộng tải trọng Đọc một cách mạnh mẽ mà không phá vỡ tính đồng bộ của hệ thống? Hãy cùng bước sang Bài 2: Database Replication - Đánh Đổi Giữa Nhất Quán Và Tốc Độ để khám phá chiến lược phân tải thực chiến và cách Senior PM trị tận gốc căn bệnh Replication Lag.
System ConceptApr 20, 2026
Database Architecture 4: Sharding: Phá Vỡ Giới Hạn Vật Lý & Nỗi Đau Vận Hành
Khi hệ thống chạm ngưỡng giới hạn Ghi (Write limit), Replication trở nên vô dụng. Khám phá chiến lược chọn Shard Key, cách né thảm họa Hotspot và những mặt tối đắt đỏ của Sharding.
Product Decode
