Chi phí AWS của nền tảng e-commerce nhiều cửa hàng: góc nhìn từ ShopBase

ShopBase là nền tảng thương mại điện tử cho các nhà bán hàng xuyên biên giới, và là đối tác giới thiệu của CostKernel. Mỗi merchant trên một nền tảng như vậy có cửa hàng riêng, với giao diện, sản phẩm, đơn hàng và các tích hợp riêng, nhưng tất cả chạy chung trên một hạ tầng. Cách một hệ thống như thế tiêu tiền trên AWS khác khá nhiều so với một ứng dụng thông thường: chi phí không chỉ tăng theo số người dùng, mà tăng theo số cửa hàng, số sản phẩm, số ảnh, và mức độ hoạt động của merchant trong những mùa bán hàng lớn.

Bài viết này đi qua những dòng chi phí đặc thù của nền tảng e-commerce nhiều cửa hàng, vì sao chúng lớn, những thay đổi thường có tác dụng nhất, và các đánh đổi đi kèm. Đây là những điểm chúng tôi luôn xem xét đầu tiên khi làm việc với các merchant và đối tác trong hệ sinh thái này.

Một nền tảng nhiều cửa hàng tiêu tiền ở đâu

Khi chia hóa đơn theo service và usage type, chi phí của một nền tảng e-commerce thường tập trung vào năm nhóm:

• Compute cho storefront và API: các service phục vụ trang cửa hàng, giỏ hàng, checkout và trang quản trị của merchant.
• Data transfer: ảnh sản phẩm, file tĩnh và trang cửa hàng được tải bởi người mua ở nhiều quốc gia.
• Lưu trữ ảnh và file trên S3: hàng triệu ảnh sản phẩm, mỗi ảnh thường có nhiều kích thước.
• Database: dữ liệu sản phẩm, đơn hàng và khách hàng của tất cả merchant.
• Log và observability: lượng log tăng theo số request, và số request tăng rất mạnh vào mùa sale.

Điểm đáng chú ý là compute không phải lúc nào cũng chiếm phần lớn nhất. Với một nền tảng phục vụ nhiều ảnh cho người mua ở nhiều nơi, data transfer, NAT Gateway và lưu trữ có thể chiếm tỷ trọng lớn hơn nhiều so với những gì đội kỹ thuật cảm nhận khi chỉ nhìn vào số lượng server.

Mùa sale quyết định cách tính toán

Với merchant bán hàng xuyên biên giới, những đợt như Black Friday và Cyber Monday tạo ra lượng traffic gấp nhiều lần ngày thường. Hệ thống phải được thiết kế cho những ngày đó, nhưng hóa đơn được trả cho cả năm.

Vì vậy cần trả lời rõ hai câu hỏi: phần năng lực nào cần có sẵn quanh năm, và phần nào chỉ cần trong vài tuần cao điểm. Câu trả lời ảnh hưởng trực tiếp tới việc mua Savings Plans bao nhiêu, dùng Spot cho phần nào, và giữ bao nhiêu năng lực dự phòng.

Ảnh sản phẩm và data transfer

Ảnh là thứ người mua tải nhiều nhất trên một trang cửa hàng. Những điểm nên xem lại:

• Đưa toàn bộ ảnh và file tĩnh qua CloudFront, đặt cache policy chỉ giữ những tham số thực sự làm thay đổi ảnh như kích thước và định dạng, để cache hit ratio đủ cao. Dữ liệu từ origin trên AWS tới CloudFront không bị tính phí data transfer.
• Phục vụ định dạng nhẹ hơn như WebP hoặc AVIF cho trình duyệt hỗ trợ, và chỉ tạo những kích thước ảnh thực sự được dùng trên giao diện.
• Đặt tên file có version để có thể đặt TTL dài, thay vì phải invalidate mỗi khi merchant cập nhật ảnh.

Chúng tôi đã viết chi tiết về cách CloudFront giảm chi phí egress trong một bài riêng.

Traffic ra ngoài qua NAT Gateway

Merchant xuyên biên giới dùng rất nhiều tích hợp bên ngoài: cổng thanh toán, đơn vị vận chuyển, nền tảng quảng cáo, công cụ email marketing. Mỗi tích hợp là một luồng request từ các service trong private subnet ra internet, và toàn bộ đi qua NAT Gateway với phí tính theo từng GB.

Bên cạnh đó, các service còn đọc ghi S3 và kéo image từ ECR. Nếu chưa có VPC Endpoint, phần traffic này cũng đi qua NAT Gateway dù đích đến nằm ngay trong AWS. Thứ tự xử lý nên là:

1. Thêm Gateway Endpoint cho S3 và Interface Endpoint cho ECR, để traffic tới dịch vụ AWS không còn đi qua NAT.
2. Đo lượng traffic còn lại qua NAT theo từng service bằng VPC Flow Logs, để biết tích hợp nào tạo ra nhiều traffic nhất.
3. Với các tích hợp gửi dữ liệu lớn, gom request theo batch và nén payload khi phía bên kia hỗ trợ.

Cách đo và các phương án chi tiết cho NAT Gateway nằm trong bài viết này.

S3 với hàng triệu object nhỏ

Mỗi ảnh sản phẩm thường được lưu thành nhiều phiên bản kích thước, và mỗi merchant có thể có hàng nghìn sản phẩm. Kết quả là số object trên S3 rất lớn, trong khi phần lớn object có kích thước nhỏ.

Với kiểu dữ liệu này, các gợi ý quen thuộc như chuyển dữ liệu cũ sang Standard-IA hay Intelligent-Tiering cần được tính kỹ. Object nhỏ hơn 128 KB bị tính như 128 KB ở Standard-IA, và không bao giờ được Intelligent-Tiering chuyển xuống tầng rẻ hơn. Những thay đổi thường có tác dụng hơn:

• Xóa ảnh của sản phẩm và cửa hàng đã bị xóa, bằng lifecycle rule theo prefix hoặc job dọn dẹp định kỳ.
• Không tạo trước mọi kích thước ảnh, mà tạo theo yêu cầu và để CloudFront cache lại.
• Chỉ áp dụng lifecycle sang class rẻ hơn cho những prefix chứa file lớn và ít được đọc, như file export hoặc backup.

Phần phân tích hóa đơn S3 theo bucket và các bẫy của lifecycle được viết kỹ trong bài về S3.

Log trong mùa cao điểm

Lượng log tăng theo số request, nên vào mùa sale, chi phí ingestion log có thể tăng nhanh hơn cả chi phí compute. Những thay đổi ít rủi ro nhất là chạy production ở log level INFO, bỏ log cho health check, sampling log của request thành công, và đặt retention cho mọi log group. Log lỗi vẫn nên được giữ đầy đủ để debug.

Đánh đổi

Không phải thay đổi nào cũng miễn phí về mặt vận hành:

Kết quả

Với ShopBase, việc rà soát và điều chỉnh theo các hướng trên giúp tổng hóa đơn AWS giảm khoảng 15%, trong khi nền tảng vẫn phục vụ cùng lượng merchant và traffic. Phần tiết kiệm đến từ nhiều thay đổi nhỏ cộng lại, không phải từ việc giảm cấu hình server hay cắt bớt độ sẵn sàng.

Con số 15% nghe không lớn, nhưng với một nền tảng có hóa đơn AWS đáng kể, đó là khoản tiết kiệm lặp lại mỗi tháng. Nó cũng không làm hệ thống yếu đi trong mùa sale, vì phần năng lực cho cao điểm vẫn được giữ nguyên.

20% × 1/2 + 12% × 1/4 + 8% × 1/2  =  10% + 3% + 4%  ≈  17%

Tóm lại

• Chia hóa đơn theo usage type trước khi tối ưu. Với nền tảng nhiều ảnh và nhiều tích hợp, data transfer và NAT thường lớn hơn bạn nghĩ.
• Tách phần năng lực nền và phần cao điểm trước khi mua Savings Plans.
• Kiểm tra kích thước object trước khi áp dụng lifecycle hay Intelligent-Tiering.
• Đo trước và sau mỗi thay đổi bằng chính dữ liệu billing, để biết khoản tiết kiệm đến từ đâu.

Nếu bạn đang vận hành một nền tảng hoặc cửa hàng có những đặc điểm tương tự, chúng tôi có thể bắt đầu bằng một buổi Assessment dựa trên dữ liệu billing của 3 tháng gần nhất.