Đã đăng vào khoảng 8 giờ trước 15 phút đọc

Tối ưu chi phí MongoDB Atlas: 9 lỗi kỹ thuật khiến chi phí tăng nhanh

Khi hóa đơn MongoDB Atlas tăng, phản xạ phổ biến là nhìn vào giá cluster tier. Nhưng trong thực tế, tối ưu chi phí MongoDB không bắt đầu từ việc chọn tier rẻ hơn. Nhiều hệ thống trả tiền cho tài nguyên mà ứng dụng không thực sự cần, hoặc phải dùng cluster lớn hơn để bù cho query, index và cách tổ chức dữ liệu chưa tối ưu. Muốn giảm chi phí MongoDB Atlas, cần nhìn vào toàn bộ workload: compute, storage, data transfer, backup, query pattern và cách vận hành các môi trường dev/test. MongoDB cũng xem cost optimization là một phần của Atlas Well-Architected Framework, với các khuyến nghị như tránh over-provisioning, tối ưu query và index, kiểm soát dữ liệu trả về, quản lý storage và theo dõi billing data.

Bài này tập trung vào 9 lỗi kỹ thuật thường khiến chi phí MongoDB tăng nhanh, cách kiểm tra từng lỗi trước khi nâng cluster, và ở phần cuối là những cách doanh nghiệp có thể rà soát thêm chi phí qua MongoDB Partner tại Việt Nam.

Tối ưu chi phí MongoDB Atlas: chi phí thực sự tăng ở đâu?

Có thể hình dung chi phí MongoDB Atlas bị kéo lên bởi bốn nhóm chính:

Compute - CPU và RAM cao khiến cluster phải chạy ở tier lớn hơn.
Storage - dữ liệu, index và backup tăng liên tục.
Data transfer - dữ liệu di chuyển giữa region, cloud hoặc ra Internet.
Cách vận hành - dev/test, analytics, backup policy và auto-scaling không được kiểm soát.

Nếu chưa biết bắt đầu từ đâu, hãy nhìn billing breakdown cùng cluster metrics trước. Đừng tối ưu theo cảm giác.

1. Cluster lớn hơn workload thực tế

Đây là lỗi dễ hiểu nhất nhưng cũng rất phổ biến. Team bắt đầu bằng một cluster tương đối lớn để "an toàn", sau đó workload ổn định nhưng cluster không bao giờ được right-size lại.

MongoDB khuyến nghị dùng Performance Advisor và cluster metrics để tìm cluster sử dụng thấp. Tài liệu Cost-Saving Configurations thậm chí gợi ý nhìn CPU utilization và lượng RAM dư để xác định cơ hội scale down.

Cách kiểm tra:

CPU thấp ổn định trong phần lớn thời gian nhưng tier vẫn cao.
RAM được cấp lớn nhưng working set thực tế nhỏ.
Peak load hiếm khi xuất hiện nhưng cluster được giữ ở cấu hình phục vụ peak 24/7.
Cluster dev/test chạy liên tục dù không có traffic đáng kể.

Cách xử lý: scale down có kiểm soát, dùng auto-scaling với min/max hợp lý và theo dõi vài chu kỳ workload trước khi chốt cấu hình mới.

2. Query chậm khiến bạn phải mua thêm compute

Một query tốn 500 ms thay vì 20 ms không chỉ ảnh hưởng latency. Nếu nó chạy hàng nghìn hoặc hàng triệu lần, CPU và I/O tăng lên đủ để đẩy workload sang cluster tier cao hơn.

MongoDB khuyến nghị dùng Query Profiler, Performance Advisor và explain() để tìm các operation đắt.

db.orders.explain("executionStats").find({ customerId: "C123" })

Khi đọc explain, đừng chỉ nhìn thời gian. Hãy chú ý số document được scan so với số document trả về. Nếu hệ thống quét hàng trăm nghìn document để lấy vài chục kết quả thì chi phí compute tăng là điều dễ hiểu.

3. Thiếu index cho query quan trọng

Không có index phù hợp, MongoDB có thể phải scan phần lớn collection. Với collection lớn, đây là cách rất nhanh để đẩy CPU lên cao.

Ví dụ, nếu ứng dụng thường xuyên lọc theo customerId và createdAt, index phải phản ánh pattern query thực tế thay vì chỉ thêm index theo từng field một cách ngẫu nhiên.

db.orders.createIndex({ customerId: 1, createdAt: -1 })

Index không phải mục tiêu tự thân. Mục tiêu là giảm lượng dữ liệu MongoDB phải đọc để trả đúng kết quả.

4. Quá nhiều index cũng làm hóa đơn tăng

Lỗi ngược lại cũng phổ biến: cứ thấy query chậm là thêm index. Index chiếm storage và làm write operation tốn thêm công việc vì MongoDB phải cập nhật index cùng với dữ liệu.

Vì vậy cần audit cả hai phía:

Index nào đang thực sự hỗ trợ query quan trọng?
Index nào gần như không được dùng?
Có index trùng hoặc một index rộng có thể bao phủ nhiều pattern không?
Index footprint có đang chiếm tỷ lệ quá lớn so với dữ liệu chính không?

Performance Advisor có thể hỗ trợ việc xác định index cần tạo hoặc bỏ trên dedicated clusters, nhưng quyết định cuối cùng vẫn nên dựa trên workload thực tế.

Query và index ảnh hưởng đến tài nguyên MongoDB Atlas

Hình 2 - Query và index có thể làm chênh lệch đáng kể lượng tài nguyên cần dùng.

Nguồn / tham chiếu: https://www.mongodb.com/docs/atlas/performance-advisor/

5. Query trả về quá nhiều dữ liệu

Một query có thể chạy rất nhanh nhưng vẫn tốn tiền nếu luôn trả về document đầy đủ trong khi ứng dụng chỉ cần vài field. Lúc đó compute có thể không phải vấn đề lớn nhất, nhưng egress và băng thông lại tăng.

Projection là một tối ưu nhỏ nhưng có tác động rất rõ khi document lớn hoặc API có traffic cao.

db.orders.find(
  { status: "PAID" },
  { _id: 1, customerId: 1, total: 1, createdAt: 1 }
).limit(100)

Nguyên tắc đơn giản: chỉ lấy những gì client thực sự cần.

6. Data model khiến mọi query đều phải làm việc nặng

MongoDB không ép bạn dùng một schema cố định, nhưng schema linh hoạt không có nghĩa là thiết kế thế nào cũng được. Oversized document, unbounded array hoặc data model buộc ứng dụng phải aggregate và lookup nặng có thể tạo chi phí compute rất âm thầm.

Tài liệu Atlas Architecture Center khuyến nghị rà soát những pattern làm tăng chi phí và thiết kế collection theo cách giảm operation phức tạp khi có thể.

Một câu hỏi hữu ích là: dữ liệu nào thường được đọc cùng nhau? Nếu hai nhóm dữ liệu luôn đi cùng nhau nhưng mỗi request lại cần nhiều bước join-like để ghép lại, có thể data model chưa phản ánh access pattern.

7. Hot storage tăng mãi vì không có vòng đời dữ liệu

Dữ liệu cũ thường có một vấn đề: ít được truy cập nhưng vẫn nằm ở tầng storage phục vụ workload nóng. Khi collection tăng theo thời gian, cluster vừa phải giữ nhiều storage hơn vừa phải duy trì index lớn hơn.

MongoDB gợi ý TTL index hoặc Online Archive cho dữ liệu phù hợp. Nhưng archive cũng có chi phí riêng khi lưu trữ và query, nên đây không phải nút bấm "giảm giá". Cần dựa vào access pattern và tần suất truy vấn dữ liệu cũ.

Rule of thumb: dữ liệu ít được đọc không đồng nghĩa với dữ liệu nên xóa; nhưng nó cũng không mặc định phải ở hot storage mãi mãi.

8. Data transfer bị bỏ quên trong thiết kế

Data transfer là phần dễ bị bỏ qua vì team thường chỉ nhìn giá cluster. Theo MongoDB, transfer trong cùng region thường rẻ nhất; cross-region cao hơn và Internet transfer thường đắt hơn.

Một vài câu hỏi nên kiểm tra:

Application và MongoDB Atlas có cùng cloud provider và cùng region không?
Có service nào gọi database xuyên region chỉ vì cấu hình mặc định không?
Có ETL hoặc analytics job kéo lượng dữ liệu lớn ra ngoài Atlas không?
API có đang trả payload lớn hơn nhu cầu thực tế không?

Nhiều hệ thống tối ưu được query nhưng vẫn để kiến trúc mạng tạo egress không cần thiết.

9. Dev/test, analytics và backup dùng policy giống production

Không phải workload nào cũng cần cùng một mức tài nguyên, availability và backup policy. Nếu dev/test chạy cluster lớn 24/7, analytics dùng chung primary workload hoặc non-critical cluster giữ continuous backup như production, chi phí sẽ phình lên theo thời gian.

MongoDB khuyến nghị cân nhắc giảm backup frequency cho non-critical clusters và tách workload aggregation khi phù hợp để tránh làm primary workload phải scale cao hơn chỉ vì analytics.

Điểm quan trọng là phân loại workload trước khi chọn cấu hình. Production critical, development, batch analytics và sandbox không nên mặc định dùng chung một policy.

Checklist 15 phút trước khi tăng cluster tier

Kiểm tra	Câu hỏi	Nếu có vấn đề
Cluster metrics	CPU/RAM có thực sự chạm giới hạn thường xuyên?	Right-size trước khi scale up.
Slow queries	Query nào đang dùng nhiều CPU/I/O nhất?	Dùng profiler, explain và tối ưu query.
Indexes	Có missing index hoặc index ít dùng?	Audit index footprint.
Payload	API có lấy toàn bộ document không?	Projection + limit.
Storage	Dữ liệu cũ có cần ở hot storage?	TTL/Archive khi phù hợp.
Network	Có cross-region/Internet transfer không?	Đưa app/data gần nhau hơn.
Environment	Dev/test có cấu hình giống production?	Tách policy theo workload.
Backup	Non-critical cluster có backup quá mạnh?	Rà soát tần suất/policy.

10. Cách nhanh và trực tiếp hơn: rà soát qua MongoDB Partner

Sau khi đã xử lý các vấn đề kỹ thuật, chi phí MongoDB vẫn còn một lớp thứ hai: cách doanh nghiệp mua dịch vụ và xử lý thanh toán tại Việt Nam. Đây là lúc làm việc qua MongoDB Partner có thể giúp rà soát nhanh hơn các chương trình giá, credit, thuế nhà thầu, hóa đơn VAT và đường billing phù hợp.

Điểm quan trọng: Partner không thay thế việc tối ưu query, index hay cluster. Partner giúp xử lý phần mà engineering team thường không tự nhìn thấy trong dashboard kỹ thuật: chương trình thương mại theo từng sản phẩm, điều kiện hỗ trợ, chứng từ và cấu trúc thanh toán.

Hình 3 - So sánh billing path MongoDB Atlas hiện tại với phương án MongoDB Direct Billing qua TitanBases.

Nguồn: TitanBases - MongoDB Direct Billing tại Việt Nam.

10.1 Thuế nhà thầu (FCT) và hóa đơn VAT

FCT là thuế nhà thầu phát sinh trong một số giao dịch xuyên biên giới. Vì vậy khi so chi phí MongoDB, không nên chỉ nhìn con số trên invoice hoặc giá niêm yết mà bỏ qua cách thuế được xử lý trong cấu trúc thanh toán.

Với phương án MongoDB Atlas Direct Billing qua TitanBases, landing chính thức của TitanBases mô tả MongoDB chịu thuế hộ theo cấu trúc áp dụng và TitanBases phát hành hóa đơn VAT Việt Nam. Đây là lợi ích cần nhìn ở góc tổng chi phí và quy trình mua hàng, không nên diễn đạt thành 'miễn FCT'.

10.2 Discount - kiểm tra chương trình giá qua MongoDB Partner

Một MongoDB Partner chính thức tại Việt Nam có thể giúp doanh nghiệp kiểm tra các chương trình discount đang áp dụng theo sản phẩm, quy mô workload và điều kiện từng deal. Discount không phải một mức giảm mặc định cho mọi khách hàng.

Ví dụ, với MongoDB Enterprise Advanced, TitanBases đang sử dụng guardrail công khai "ưu đãi lên tới 10% so với MongoDB list price". Đây là ví dụ cho việc mua qua Partner có thể mở ra chương trình giá khác với mua trực tiếp, nhưng không được suy rộng mức 10% này sang MongoDB Atlas Direct Billing.

10.3 Credit / hỗ trợ PoC - nên kiểm tra trước khi tự bỏ ngân sách

Với workload mới hoặc PoC, MongoDB Partner có thể giúp kiểm tra khả năng đủ điều kiện cho credit hoặc chương trình hỗ trợ hiện hành. Nếu có chương trình phù hợp, phần credit này có thể làm giảm chi phí thử nghiệm ban đầu. Tuy nhiên, việc có credit hay không, mức credit và thời điểm áp dụng phải được xác nhận theo từng trường hợp.

10.4 MongoDB Atlas Direct Billing tại Việt Nam

Nếu doanh nghiệp đang dùng MongoDB Atlas, một bước rất thực tế là gửi khoảng hai tháng statement để Partner rà soát billing path hiện tại. Việc chuyển sang Direct Billing là thay đổi ở đường thanh toán và mua hàng, không phải migration database.

Xem chi tiết: MongoDB Direct Billing tại Việt Nam.

10.5 Khi nào nên đi đường kỹ thuật, khi nào nên qua Partner?

CPU / RAM cao, query chậm, scan quá nhiều document: ưu tiên tối ưu kỹ thuật.
Index phình to, storage tăng, data transfer cao: ưu tiên tối ưu kỹ thuật.
Hệ thống đã tương đối tối ưu nhưng tổng chi phí vẫn cao: rà soát Partner, billing, FCT/VAT và chương trình giá.
Chuẩn bị PoC / workload mới: làm song song: thiết kế đúng từ đầu và kiểm tra credit nếu đủ điều kiện.

Muốn xem toàn bộ checklist từ kỹ thuật đến phần Partner, đọc thêm bài Tối ưu chi phí MongoDB: 10 cách giảm chi phí từ kỹ thuật đến phương án qua Partner trên TitanBases.

Điều quan trọng là không bắt đầu bằng câu hỏi "mua cluster nào rẻ nhất". Hãy xác định workload đang tiêu tài nguyên ở đâu trước, sau đó mới kiểm tra phần mua hàng và billing. Khi hai lớp này được rà soát cùng nhau, việc tối ưu chi phí mới bền vững.

Nguồn tham khảo

TitanBases - MongoDB Direct Billing tại Việt Nam

https://titanbases.com/landing/mongodb-direct-billing

Ghi chú tác giả

Tác giả hiện làm việc tại TitanBases, MongoDB Advanced Partner tại Việt Nam.