title: "Cost Optimization: Kiến trúc sư cũng là người quản trị tài chính – Tối ưu chi phí Cloud"
series: "Software Architecture Masterclass"
part: "Phần 4 — Bảo mật & Chất lượng"
order: 35
audience: "Solutions Architect & Technical Lead"
reading_time: "13 phút"
tags:

cost-optimization
finops
cloud-architecture
trade-off
capacity-planning

Cost Optimization: Kiến trúc sư cũng là người quản trị tài chính – Tối ưu chi phí Cloud

Hóa đơn AWS/GCP tháng này cao hơn tháng trước 18%. Không ai trong team biết chính xác vì sao. CFO hỏi, VP Engineering trả lời "traffic tăng thôi", rồi cả hai cùng nhìn vào một dashboard billing tổng hợp không tách được theo service, theo môi trường, theo feature. Câu trả lời cuối cùng luôn giống nhau: xin thêm ngân sách quý sau.

Đây không phải vấn đề kế toán. Đây là vấn đề kiến trúc. Mỗi đồng chi phí cloud là hệ quả trực tiếp của một quyết định kiến trúc đã được đưa ra — chọn RDS Multi-AZ hay single instance, chọn Lambda hay ECS long-running, chọn lưu log 90 ngày hay 7 ngày, chọn cross-region replication hay không. Vấn đề là các quyết định đó được đưa ra tại thời điểm thiết kế, còn hóa đơn thì xuất hiện 30-60 ngày sau, ở một bộ phận khác, trên một dashboard khác. Không ai nối được hai đầu dây. Kết quả: chi phí trôi tự do, không neo vào bất kỳ quyết định kỹ thuật cụ thể nào, và "tăng ngân sách" trở thành phản xạ mặc định thay vì "sửa kiến trúc".

Bài này nói về việc đưa chi phí trở lại làm một thuộc tính kiến trúc hạng nhất — ngang hàng với hiệu năng, độ tin cậy, bảo mật — thay vì một dòng excel mà finance quản lý riêng.

The Problem

Hầu hết tổ chức vận hành cloud theo mô hình: kiến trúc sư và kỹ sư thiết kế hệ thống, DevOps/SRE vận hành, Finance nhận hóa đơn và báo cáo lên ban điều hành. Ba nhóm này gần như không nói chuyện với nhau bằng cùng một ngôn ngữ. Kiến trúc sư nói về throughput, latency, RTO/RPO. Finance nói về OpEx, unit economics, burn rate. Không có tầng phiên dịch ở giữa.

Hệ quả cụ thể:

Chi phí tăng vô hạn, tuyến tính hoặc siêu tuyến tính theo traffic, trong khi doanh thu không tăng cùng tốc độ — biên lợi nhuận bị bào mòn âm thầm mà không ai phát hiện cho đến khi CFO hỏi.
Không truy vết được "tại sao": hóa đơn tổng hợp theo service (EC2, RDS, S3...) chứ không theo domain nghiệp vụ (feature X tốn bao nhiêu, tenant Y tốn bao nhiêu). Kiến trúc sư không thể trả lời câu hỏi "nếu bỏ tính năng A thì tiết kiệm bao nhiêu?".
Quyết định kiến trúc quá khứ không bao giờ được review lại dưới góc độ chi phí. Một quyết định "chọn Multi-AZ cho mọi database vì an toàn" được đưa ra 2 năm trước, khi hệ thống có 3 database. Nay có 40 database, không ai đặt lại câu hỏi liệu tất cả 40 cái đều cần Multi-AZ.
Phản xạ mặc định là mua thêm, không phải tối ưu: khi hệ thống chậm hoặc gần chạm giới hạn, phản ứng nhanh nhất luôn là scale up/scale out (tốn tiền ngay) thay vì phân tích lại kiến trúc (tốn thời gian kỹ sư nhưng rẻ hơn về dài hạn). Áp lực deadline khiến lựa chọn dễ luôn thắng.

Vấn đề gốc rễ: chi phí không có chủ sở hữu kỹ thuật. Nó là ngoại tác (externality) của kiến trúc — ai đó khác trả giá cho quyết định của kiến trúc sư, và kiến trúc sư không nhận phản hồi (feedback loop) đủ nhanh và đủ cụ thể để điều chỉnh.

The Theory

FinOps (Financial Operations) là khung vận hành nhằm đưa trách nhiệm và khả năng nhìn thấy chi phí cloud vào tay những người ra quyết định kỹ thuật, thay vì để hoàn toàn cho tài chính xử lý sau khi hóa đơn phát sinh. Nguyên lý cốt lõi không nằm ở công cụ hay dashboard, mà ở ba dịch chuyển tư duy:

1. Chi phí là một thuộc tính kiến trúc (architectural quality attribute), không phải hệ quả phụ. Cũng như ta đánh giá một thiết kế theo khả năng chịu tải, độ trễ, khả năng phục hồi, ta phải đánh giá nó theo cost-per-unit-of-value — chi phí trên mỗi request, mỗi user hoạt động, mỗi giao dịch. Một kiến trúc xử lý 10.000 request/giây với chi phí gấp đôi kiến trúc khác xử lý cùng tải không phải là "kiến trúc tốt hơn" nếu phần dư thừa đó không đổi lấy được -ility nào có giá trị tương xứng.

2. Variable cost phải ánh xạ được về unit economics của nghiệp vụ. Cloud bán theo mô hình biến phí (pay-as-you-go) — khác hẳn với hạ tầng on-premise là chi phí cố định (CapEx) khấu hao dần. Điều này có nghĩa mọi request, mọi byte lưu trữ, mọi lần gọi API đều có một cái giá tức thời. Kiến trúc sư giỏi phải biết trả lời: "tính năng recommendation engine này tốn bao nhiêu USD cho mỗi 1.000 active user?" Nếu không trả lời được, nghĩa là kiến trúc chưa được đo đúng tầng.

3. Trách nhiệm chi phí phải phân tán về đúng nơi ra quyết định (showback/chargeback), càng gần thời điểm quyết định càng tốt. Tagging tài nguyên theo team/feature/môi trường không phải bài tập hành chính — nó là cơ chế feedback loop. Nếu team A thấy hóa đơn riêng của mình tăng do một thiết kế cụ thể, họ sẽ tự sửa nhanh hơn nhiều so với việc chờ một báo cáo tổng công ty ba tháng sau.

FinOps vòng lặp chuẩn có ba pha lặp lại liên tục: Inform (làm cho chi phí nhìn thấy được, gắn đúng ngữ cảnh kỹ thuật) → Optimize (right-sizing, reserved capacity, kiến trúc lại phần đắt) → Operate (đưa cost review vào quy trình thường trực, không phải sự kiện một lần). Kiến trúc sư đóng vai trò trung tâm ở cả ba pha — vì chỉ họ mới hiểu vì sao một thiết kế lại tốn tiền ở tầng hạ tầng.

Điểm mấu chốt: tối ưu chi phí không phải là "cắt giảm". Nó là việc đảm bảo mỗi đồng chi tiêu đang mua đúng thứ hệ thống cần — không thừa, không thiếu — và mọi khoản chi vượt mức baseline đều có một quyết định kiến trúc tường minh đứng sau, được ai đó phê duyệt có ý thức, chứ không phải trôi vào hóa đơn một cách vô thức.

The Trade-off

Đây là phần không được phép mơ hồ: tối ưu chi phí luôn lấy đi thứ gì đó. Không có bữa trưa miễn phí.

Giảm dự phòng (redundancy) để tiết kiệm chi phí → mất độ tin cậy (reliability).
Chuyển từ Multi-AZ RDS sang Single-AZ tiết kiệm ~50% chi phí database. Cái giá: khi AZ đó gặp sự cố, downtime kéo dài đến khi failover thủ công hoàn tất — có thể là hàng giờ thay vì vài chục giây tự động. Với hệ thống core transaction, đây là đánh đổi không được phép làm một mình; phải là quyết định kinh doanh, có SLA đứng đằng sau con số RTO/RPO cụ thể.

Dùng Spot/Preemptible instance để tiết kiệm 60-90% compute → mất tính khả dự đoán (predictability) và tăng độ phức tạp kỹ thuật.
Được: chi phí compute giảm mạnh cho workload chịu được gián đoạn (batch job, CI/CD runner, training job). Mất: instance có thể bị thu hồi bất kỳ lúc nào với cảnh báo ngắn, buộc kiến trúc phải là stateless, checkpoint thường xuyên, và có cơ chế graceful shutdown — nghĩa là tốn công sức kỹ sư để xây dựng khả năng chịu lỗi đó. Nếu workload không sẵn sàng cho gián đoạn, tiết kiệm chi phí biến thành mất dữ liệu hoặc job treo.

Serverless (pay-per-invocation) thay vì server thường trực → tiết kiệm chi phí ở tải thấp/không đều, nhưng mất hiệu năng đuôi (tail latency) và trần chi phí không rõ ràng ở tải cao.
Được: không trả tiền cho compute nhàn rỗi, scale-to-zero khi không có traffic. Mất: cold start làm tăng p99 latency; và ở lưu lượng cao ổn định, chi phí per-invocation có thể vượt hẳn chi phí một server chạy liên tục có reserved capacity — điểm hòa vốn (break-even point) này bắt buộc phải tính bằng số, không phải cảm tính.

Nén/giảm retention log & metrics để tiết kiệm chi phí lưu trữ và ingestion → mất khả năng quan sát (observability) khi điều tra sự cố về sau.
Được: chi phí Datadog/CloudWatch/S3 giảm đáng kể — đây thường là một trong các dòng chi phí tăng nhanh nhất không tương xứng với giá trị. Mất: khi incident xảy ra 45 ngày sau và log retention chỉ 30 ngày, đội ngũ điều tra sự cố mất hoàn toàn dữ liệu gốc — chi phí thật sự trả bằng thời gian MTTR (mean time to resolve) tăng vọt hoặc không bao giờ tìm ra root cause.

Reserved Instance / Savings Plan cam kết dài hạn để giảm đơn giá → mất linh hoạt kiến trúc (architectural flexibility).
Được: giảm 30-60% so với on-demand nếu dự đoán tải chính xác. Mất: cam kết 1-3 năm cho một loại instance/region cụ thể triệt tiêu khả năng đổi kiến trúc (migrate sang instance type khác, đổi cloud provider, refactor sang serverless) mà không lãng phí phần cam kết chưa dùng hết — đây là dạng technical debt tài chính, y hệt technical debt code.

Nguyên tắc chung xuyên suốt: mọi đô la tiết kiệm được đều lấy từ một thuộc tính chất lượng khác — reliability, observability, predictability, hoặc flexibility. Việc của kiến trúc sư không phải là tối đa hóa tiết kiệm, mà là làm cho đánh đổi này tường minh và được người có thẩm quyền kinh doanh phê duyệt có ý thức, thay vì để một kỹ sư âm thầm bật flag tiết kiệm chi phí mà không ai biết cái giá kèm theo.

The Architecture Diagram

Breakdown chi phí theo thành phần kiến trúc của một hệ thống CRM điển hình — nhìn vào đây, chi phí không còn là một con số tổng bí ẩn mà là tổng của các quyết định kiến trúc cụ thể, mỗi quyết định có thể review và tối ưu độc lập.

flowchart TD
    Bill["Hóa đơn Cloud hàng tháng<br/>(một con số tổng, khó hành động)"]

    Bill --> Compute["Compute<br/>ECS/EC2/Lambda"]
    Bill --> Data["Data Layer<br/>RDS + Redis + DynamoDB"]
    Bill --> Network["Network & CDN<br/>Egress + Load Balancer"]
    Bill --> Storage["Storage<br/>S3 + EBS + Backup"]
    Bill --> ObsCost["Observability<br/>Logs/Metrics/Traces"]
    Bill --> ThirdParty["Third-party & AI<br/>LLM API, SaaS add-on"]

    Compute --> C1["Quyết định: bao nhiêu task chạy 24/7<br/>vs auto-scale theo tải?"]
    Data --> D1["Quyết định: Multi-AZ mọi DB<br/>hay chỉ DB core?"]
    Network --> N1["Quyết định: CDN cache-hit ratio<br/>bao nhiêu % traffic ra internet?"]
    Storage --> S1["Quyết định: retention policy<br/>bao nhiêu ngày/năm?"]
    ObsCost --> O1["Quyết định: log level prod<br/>là INFO hay DEBUG?"]
    ThirdParty --> T1["Quyết định: gọi LLM trực tiếp<br/>hay qua cache/batch?"]

    C1 -.->|"ánh xạ ngược"| Decision["Mỗi dòng chi phí<br/>= một quyết định kiến trúc<br/>có chủ sở hữu, có ngày phê duyệt"]
    D1 -.-> Decision
    N1 -.-> Decision
    S1 -.-> Decision
    O1 -.-> Decision
    T1 -.-> Decision

    Decision --> Review["Cost Review hàng tháng<br/>gắn số liệu với quyết định cụ thể"]
    Review --> Feedback["Feedback về đội kiến trúc:<br/>giữ nguyên / tối ưu / đánh đổi có phê duyệt"]
    Feedback -.->|"vòng lặp FinOps"| Bill

    style Bill fill:#333,color:#fff
    style Decision fill:#5b21b6,color:#fff
    style Review fill:#065f46,color:#fff

Điểm mấu chốt của sơ đồ: mũi tên phản hồi (feedback loop) đi từ Review ngược về Bill — đây chính là vòng lặp FinOps Inform → Optimize → Operate. Không có vòng lặp này, breakdown chi phí chỉ là một bài tập kế toán một lần, không tạo ra thay đổi hành vi kiến trúc lâu dài.

Implementation Guardrails

Không hạ tầng nào được provision mà không có ước tính chi phí đính kèm bản thiết kế (design doc/ADR). Trước khi PR hạ tầng (Terraform module mới, RDS instance mới, thêm CDN...) được duyệt, phải có một dòng ước tính: chi phí/tháng dự kiến ở tải hiện tại và ở tải x3 sau 6 tháng. Không có con số, không merge.
Mọi resource phải được tag bắt buộc theo Environment, Project, và thêm Owner/Feature để cost allocation report có thể tách theo domain nghiệp vụ, không chỉ theo loại service. Đây là điều kiện tiên quyết để trả lời được câu hỏi "feature X tốn bao nhiêu" — không tag được thì không tối ưu được, chỉ có thể đoán.
Cost review hàng tháng là một cuộc họp bắt buộc có kiến trúc sư tham dự, không chỉ finance. Buổi review phải nối được từng khoản tăng/giảm bất thường (>10% so với baseline) với một thay đổi kiến trúc hoặc traffic cụ thể — không được kết thúc bằng câu "traffic tăng thôi" nếu không có số liệu traffic đi kèm để chứng minh tỷ lệ tăng tương ứng.
Mọi đánh đổi chi phí đổi lấy -ility khác (giảm redundancy, giảm retention, dùng Spot instance cho workload production...) phải được ghi thành quyết định tường minh (ADR) và có chữ ký phê duyệt từ phía kinh doanh/product, không phải quyết định âm thầm của một kỹ sư cá nhân. Nếu SLA bị ảnh hưởng, khách hàng/nội bộ liên quan phải biết trước, không phải biết sau khi sự cố xảy ra.

Architect's Verdict

Chi phí không phải là việc của phòng tài chính xử lý sau khi kiến trúc sư đã "xong việc" — nó là hệ quả trực tiếp, đo lường được, và có thể dự đoán trước của từng quyết định thiết kế. Một kiến trúc sư đề xuất Multi-AZ cho mọi database, retention log vô thời hạn, hay auto-scale không giới hạn trần mà không kèm theo con số USD dự kiến và không giải trình được đánh đổi, là một kiến trúc sư chưa làm tròn phần việc của mình — dù thiết kế kỹ thuật có đẹp đến đâu. Hiểu tác động P&L (profit & loss) của quyết định kiến trúc không phải là kỹ năng "nice to have" của cấp Staff/Principal — nó là một phần định nghĩa công việc, ngang hàng với hiểu về CAP theorem hay khả năng vẽ sequence diagram.

🔗 Bài viết liên quan

Bài trước: Performance Engineering · Bài tiếp theo: Testing Strategies for Architects