Cloud DE 7 — Chi phí, độ tin cậy & Well-Architected

Một khung tư duy chung: Well-Architected Framework

Sáu bài trước đã lắp ráp nền tảng dữ liệu từ lưu trữ, tính toán, mạng & bảo mật, dịch vụ managed và hạ tầng bằng mã (IaC). Nhưng "dựng được" chưa phải "vận hành tốt". Câu hỏi bây giờ là: làm sao biết kiến trúc của mình đủ tốt? Ba nhà cung cấp lớn đều trả lời bằng một khung chung tên là Well-Architected Framework — một bộ tiêu chí để tự soi kiến trúc theo nhiều trụ (pillar).

• AWS Well-Architected: 6 trụ.
• Azure Well-Architected Framework (WAF): 5 trụ.
• GCP Architecture Framework: các nguyên tắc tương đương.

Dù cách gọi khác nhau, sáu trụ hội tụ như sau:

Framework không phải checklist để "đạt điểm tuyệt đối". Bản chất nó buộc ta đánh đổi có ý thức giữa các trụ: tăng độ tin cậy thường tốn tiền; cắt chi phí quá đà có thể phá độ tin cậy. Bài này đào sâu hai trụ chưa bàn kỹ — Reliability và Cost — vì đó là hai nơi đội dữ liệu ngân hàng dễ sai nhất: hoặc thiếu DR khi sự cố thật, hoặc đốt tiền không kiểm soát.

Trụ Reliability — Độ tin cậy

Độ tin cậy là khả năng hệ thống thực hiện đúng chức năng khi cần và tự phục hồi khi có lỗi. Với ngân hàng, đây là trụ ưu tiên số một cùng bảo mật: báo cáo cuối ngày, đối soát, chấm điểm rủi ro không được phép "hôm nay lake sập nên chưa có số".

Multi-AZ và multi-region

Đơn vị nền tảng của độ tin cậy trên cloud là cách phân bố tài nguyên theo địa lý:

• Availability Zone (AZ): một hoặc vài trung tâm dữ liệu độc lập (điện, mạng, làm mát riêng) trong cùng một region, cách nhau vài km. Sự cố một AZ (mất điện, cháy) không lan sang AZ khác.
• Region: một khu vực địa lý (ví dụ ap-southeast-1 Singapore) gồm nhiều AZ. Các region cách nhau hàng trăm–nghìn km.

Nguyên tắc thực chiến: Multi-AZ là mặc định cho production. Ví dụ Amazon RDS bật Multi-AZ sẽ có một replica đồng bộ ở AZ khác, tự failover khi AZ chính chết. Object storage (S3, GCS, ADLS) đã tự nhân bản trong region — nhưng replication liên region phải bật rõ ràng và tính thêm tiền.

Redundancy & tự phục hồi (self-healing)

Độ tin cậy đến từ dự phòng (redundancy) — không có điểm chết đơn (single point of failure) — cộng với khả năng tự phục hồi:

• Health check + auto-replacement: load balancer kiểm tra sức khoẻ; instance hỏng bị thay bằng instance mới (Auto Scaling Group, managed instance group). Xem thêm vận hành production trên Kubernetes.
• Managed service tự phục hồi: BigQuery/serverless tự phân phối lại tác vụ khi node lỗi — bạn không thấy gì.
• Stateless + external state: giữ compute stateless, đẩy trạng thái ra object storage/DB để có thể giết và tạo lại instance bất kỳ lúc nào.

Backup & khôi phục

Backup là lưới an toàn cuối cùng — bảo vệ khỏi cả lỗi kỹ thuật lẫn lỗi con người (xoá nhầm bảng) và mã độc/ransomware — điều mà multi-AZ replication không cứu được (vì lỗi được nhân bản luôn).

• Snapshot định kỳ: RDS/Redshift/EBS snapshot tự động theo lịch, giữ theo chính sách retention.
• Point-in-time recovery (PITR): khôi phục DB về đúng một thời điểm (ví dụ "trước lúc job chạy sai 03:14"). RDS, DynamoDB, Cloud SQL đều hỗ trợ.
• Object versioning + lifecycle: bật versioning trên bucket để mọi ghi đè/xoá đều có bản cũ; kết hợp Object Lock (WORM — write once read many) để chống xoá cả bản backup, đáp ứng yêu cầu lưu trữ bất biến của ngân hàng.
• Quy tắc 3-2-1: 3 bản sao, 2 loại phương tiện, 1 bản ở nơi khác (region/tài khoản khác).

Nguyên tắc vàng: backup chưa test khôi phục = chưa có backup. Phải diễn tập restore định kỳ và đo thời gian thực tế.

Disaster Recovery (DR): RTO, RPO và bốn chiến lược

Disaster Recovery là kế hoạch phục hồi khi mất cả một region hoặc sự cố nghiêm trọng. Hai chỉ số định lượng mọi thứ:

• RTO — Recovery Time Objective: bao lâu để khôi phục dịch vụ (đo bằng thời gian ngừng chấp nhận được). RTO = 1 giờ nghĩa hệ thống phải sống lại trong vòng 1 giờ.
• RPO — Recovery Point Objective: mất bao nhiêu dữ liệu chấp nhận được (đo bằng thời gian). RPO = 15 phút nghĩa chỉ được phép mất tối đa 15 phút dữ liệu gần nhất.

RTO/RPO càng nhỏ thì DR càng tốn tiền. Bốn chiến lược kinh điển, từ rẻ-chậm đến đắt-nhanh:

Chọn chiến lược theo giá trị nghiệp vụ, không cào bằng: hệ thống cổng thanh toán có thể cần Active-Active; kho dữ liệu phân tích (data warehouse) tính lại được từ nguồn thường chỉ cần Pilot Light hoặc Backup & Restore vì có thể re-ingest từ core banking.

Thiết kế chịu lỗi (fault-tolerant) cho pipeline dữ liệu

Độ tin cậy không chỉ là hạ tầng — pipeline phải tự chịu lỗi ở tầng ứng dụng:

• Retry với exponential backoff: gọi lại khi lỗi tạm thời (throttling, timeout mạng), giãn thời gian giữa các lần thử để không "đập" thêm vào dịch vụ đang yếu.
• Idempotent (bất biến khi lặp): chạy lại một bước phải cho cùng kết quả, không nhân đôi dữ liệu. Thực hiện bằng khoá tự nhiên + MERGE/upsert, hoặc ghi theo partition rồi ghi đè cả partition thay vì INSERT chồng. Đây là điều kiện sống còn để retry an toàn.
• Queue / buffer để decouple: chèn hàng đợi (SQS, Pub/Sub, Kafka) giữa producer và consumer. Khi consumer chết, message không mất mà xếp hàng chờ; khi hồi phục thì xử lý tiếp.
• Dead-letter queue (DLQ): message xử lý mãi không được đẩy sang hàng đợi riêng để điều tra, không chặn cả luồng.
• Checkpoint: job Spark/Flink lưu điểm kiểm tra để chạy lại từ chỗ dở, không làm lại từ đầu.

SLA, SLO, SLI

• SLI (Indicator): chỉ số đo được — ví dụ tỷ lệ pipeline chạy thành công, độ trễ dữ liệu (data freshness).
• SLO (Objective): mục tiêu tự đặt cho SLI — ví dụ "99.5% ngày báo cáo cuối ngày sẵn sàng trước 07:00".
• SLA (Agreement): cam kết có ràng buộc với bên dùng (thường kèm bồi thường), thường lỏng hơn SLO một bậc để có biên an toàn.

Ngân hàng nên đặt SLO theo giá trị nghiệp vụ: bảng phục vụ báo cáo NHNN có SLO chặt hơn nhiều so với dashboard nội bộ. SLO định hướng đầu tư — chỉ trả tiền cho độ tin cậy ở nơi thực sự cần.

Trụ Cost Optimization — Tối ưu chi phí

Trụ này được bàn kỹ trong series FinOps; ở đây tóm tắt và neo vào Well-Architected. Điểm mấu chốt của cloud: mô hình trả theo lượng dùng (pay-as-you-go) — không CAPEX mua máy trước, mà OPEX theo giờ/byte/query. Sức mạnh này là con dao hai lưỡi: rẻ khi tối ưu, đốt tiền khi buông lỏng.

Các đòn bẩy chính

Vài lưu ý thực chiến:

• Spot chỉ cho tải chịu gián đoạn: job batch, Spark có checkpoint — không dùng cho DB trạng thái. Kết hợp với idempotent (đã nói ở trên) để job bị thu hồi giữa chừng vẫn chạy lại an toàn.
• Savings Plan/Reserved cho tải nền ổn định: cam kết phần baseline chắc chắn dùng, để on-demand/spot cho phần dao động.
• Tiering tự động: bật S3 Intelligent-Tiering / lifecycle rule đẩy dữ liệu >90 ngày xuống Glacier — chi tiết ở FinOps storage tiering.

Phân bổ chi phí: tag & showback

Không đo được thì không tối ưu được. Tagging (gắn nhãn team, env, project, cost-center lên mọi tài nguyên) cho phép showback — báo cho từng đội thấy họ tiêu bao nhiêu. Đây là bước "INFORM" trong vòng lặp FinOps: minh bạch chi phí thay đổi hành vi mạnh hơn mọi mệnh lệnh cắt giảm.

Giám sát chi phí & ngân sách

• Budget alert: đặt ngưỡng (AWS Budgets, Azure Cost Management, GCP Budgets) và cảnh báo khi chi tiêu vượt 80%/100% dự kiến — hoặc khi dự báo sẽ vượt.
• Phát hiện bất thường (anomaly detection): bắt cú tăng đột biến (một job quét nhầm toàn bộ lake) trước khi hoá đơn cuối tháng gây sốc.

Vận hành & giám sát: nền của Operational Excellence

Ba trụ trên chỉ đứng vững nếu ta nhìn thấy hệ thống. Mỗi cloud có dịch vụ giám sát trung tâm:

• AWS CloudWatch, Azure Monitor, GCP Cloud Monitoring — thu metric, log, đặt alarm.

Kết hợp cả ba trụ vào một vòng vận hành: metric độ trễ dữ liệu (reliability) + chi phí theo tag (cost) + trạng thái pipeline (operations) hiển thị trên cùng dashboard. Chi tiết cách dựng ba trụ observability (metrics–logs–traces) và SLO nằm ở phần vận hành production. Và toàn bộ hạ tầng — cả DR, cả tag chi phí — phải khai báo bằng IaC để tái lập được region DR chỉ bằng một lần apply.

Cân bằng các trụ: không cắt chi phí bằng cách hy sinh tin cậy

Điểm mấu chốt của Well-Architected là đánh đổi có kỷ luật. Một số va chạm điển hình và hướng xử lý cho ngân hàng:

• Cost vs Reliability: cám dỗ tắt Multi-AZ để "tiết kiệm x2" — sai với production ngân hàng. Cách đúng: tiết kiệm ở non-prod (single-AZ, tắt idle), giữ nguyên tin cậy ở prod.
• Cost vs Security: không tắt log audit hay VPC endpoint để bớt tiền — đây là yêu cầu tuân thủ, không phải tuỳ chọn.
• Performance vs Cost: thay vì mua cụm to hơn, thường tối ưu partition/định dạng cột (Parquet) rẻ và nhanh hơn.

Thứ tự ưu tiên trong ngân hàng gần như luôn là: Security ≈ Reliability & Compliance > Performance > Cost. Chi phí được tối ưu trong ràng buộc của tuân thủ và độ tin cậy, không bao giờ vượt lên trên. Đó là khác biệt lớn so với một startup có thể chấp nhận downtime để tiết kiệm.

Use case thực tế

Bối cảnh: NCB vận hành nền tảng dữ liệu trên AWS region ap-southeast-1 (Singapore). Nền tảng phục vụ báo cáo cuối ngày, chấm điểm rủi ro và trích xuất cho NHNN — yêu cầu chạy 24/7 với DR thật, nhưng vẫn phải kiểm soát chi phí.

Thiết kế theo Well-Architected:

1. Reliability — phân tầng theo giá trị:

   • Kho dữ liệu warehouse (Redshift): Multi-AZ, snapshot tự động mỗi 8 giờ, RPO 8 giờ (chấp nhận được vì tái tạo lại được từ core). Chiến lược DR = Pilot Light sang region ap-southeast-3 (Jakarta): giữ replica cấu hình + snapshot cross-region, compute tắt. RTO mục tiêu 4 giờ, RPO 8 giờ.
   • Metadata & catalog (dữ liệu không tái tạo được): Warm Standby, RPO 15 phút, RTO 30 phút.
   • SLO: "99.5% ngày làm việc, bảng báo cáo NHNN sẵn sàng trước 07:00".

2. Fault-tolerant pipeline: các job Glue ghi theo partition ngày, idempotent (ghi đè cả partition khi chạy lại); dùng SQS + DLQ giữa ingest và transform; retry backoff cho gọi API core banking.

3. Cost — tối ưu trong ràng buộc:

   • Cụm ETL chạy trên Spot (job có checkpoint, chấp nhận thu hồi) → giảm ~70% chi phí compute.
   • Baseline warehouse mua Reserved 1 năm → giảm ~40%.
   • Dữ liệu lake >90 ngày tự chuyển Glacier qua lifecycle → giảm ~75% chi phí lưu.
   • Môi trường dev tắt ngoài giờ (19h–7h + cuối tuần) bằng lịch → giảm ~65% chi phí non-prod.
   • Mọi tài nguyên gắn tag cost-center, env; showback hàng tháng cho từng đội; budget alert ở 80%.

Kết quả (minh hoạ): chi phí hạ tầng dữ liệu giảm ~35% so với thiết kế ban đầu, trong khi tăng độ tin cậy (thêm DR Pilot Light mà trước đó không có). Điều quan trọng: không đụng tới Multi-AZ ở prod và không tắt bất kỳ log audit nào — tiết kiệm đến từ non-prod, spot, tiering và cam kết, không từ việc hạ chuẩn tin cậy hay tuân thủ.

Một truy vấn minh hoạ kiểu "gắn nhãn chi phí theo đơn vị nghiệp vụ" (dữ liệu mô phỏng, không phải bảng chi phí thật):

-- ▶ Chạy được
SELECT c.city AS cost_center,
       COUNT(a.id)          AS so_tai_khoan,
       ROUND(SUM(a.balance),0) AS tong_so_du
FROM customers c
JOIN accounts a ON a.customer_id = c.id
GROUP BY c.city
ORDER BY tong_so_du DESC;

Ghi nhớ

• Well-Architected Framework (AWS 6 trụ / Azure 5 / GCP tương đương): Operational Excellence, Security, Reliability, Performance Efficiency, Cost Optimization, Sustainability — dùng để đánh đổi có kỷ luật, không phải checklist điểm tuyệt đối.
• Multi-AZ là mặc định cho production; multi-region dành cho hệ trọng yếu vì đắt và độ trễ cao.
• Backup ≠ replication: replication nhân bản cả lỗi con người/ransomware; cần snapshot + PITR + versioning + Object Lock. Backup chưa test restore = chưa có backup.
• DR định lượng bằng RTO (bao lâu phục hồi) và RPO (mất bao nhiêu dữ liệu); bốn chiến lược tăng dần chi phí/tốc độ: Backup & Restore → Pilot Light → Warm Standby → Active-Active. Chọn theo giá trị nghiệp vụ.
• Pipeline chịu lỗi: retry backoff + idempotent + queue/DLQ + checkpoint. Idempotent là điều kiện để retry và spot an toàn.
• SLI đo được → SLO tự đặt → SLA cam kết; đặt SLO theo giá trị nghiệp vụ để chỉ đầu tư tin cậy ở nơi cần.
• Đòn bẩy chi phí: right-size, serverless, spot (tải gián đoạn), commit/savings (baseline), storage tiering, tắt idle; đo bằng tag → showback → budget/anomaly alert.
• Ngân hàng ưu tiên Security ≈ Reliability & Compliance > Performance > Cost: tối ưu chi phí trong ràng buộc tuân thủ, không bao giờ hạ chuẩn tin cậy/bảo mật để cắt tiền.