Anatomy of a serverless usage-based billing system

WarpStream · 2024 · 2. Tăng trưởng · Độ khó: Trung bình — bài gốc

Bài của nhà cung cấp; mọi nhận định là theo WarpStream. Phần định giá, tính hoá đơn giao cho Orb; bài nói về phần đo (metering) phía WarpStream.

Bối cảnh

• WarpStream (Kafka trên object storage) tính tiền theo ba chiều: cluster minutes (cụm có xử lý request, tính theo khối 15 phút), throughput ghi (GiB/s), lưu trữ (GiB-giờ). Theo họ, hệ billing theo usage tốt phải tách "event" khỏi "metric": giữ event thô để đổi logic tính tiền về sau mà không đổi cách sinh dữ liệu.

Thay đổi chính

• BYOC (data plane ở tài khoản khách): metadata store của control plane vốn đã theo dõi throughput ghi và có sẵn engine time series (cũng dùng cho console và index timestamp của giao thức Kafka). Một tiến trình định kỳ query, gom theo khoảng 15 phút, gửi event time series cho Orb. Mỗi event có idempotency key, Orb tự khử trùng lặp, nên tiến trình có thể chết hoặc khởi động lại bất cứ lúc nào và luôn nghiêng về gửi lại. Checkpoint (khoảng thời gian đã gửi xong, lưu trong metadata store) chỉ là tối ưu để khỏi gửi lại từ đầu, không cần cho tính đúng.
• Một event chứa nhiều chiều (hiện chỉ bytes_written_uncompressed) để thêm chiều tính tiền sau này mà không tăng số event. Cụm "đang hoạt động" không suy từ throughput (cụm có thể hoạt động mà không ghi) mà từ event cluster_heartbeat do metadata store phát định kỳ.
• Serverless (data plane chạy ở tài khoản WarpStream): đơn giá cao hơn, cộng phí mạng vào/ra, vì nhà cloud tính tiền load balancer và mạng giữa AZ, và phí egress phụ thuộc client có cùng region hay không. Phải đo ở Proxy (proxy hiểu giao thức Kafka đứng sau NLB, xác thực và định tuyến tới Agent của cụm), vì đó là lớp duy nhất client nói chuyện trực tiếp.
  • Một event mỗi message Kafka: hàng triệu event/giây với vài workload. Một event mỗi kết nối theo chu kỳ: vẫn quá nhiều, vì client Kafka viết kém có thể mở hàng chục, hàng trăm nghìn kết nối.
  • Chọn gom hai tầng trong bộ nhớ: mỗi kết nối tự đếm byte vào/ra, định kỳ gửi cho một aggregator trong cùng node Proxy (shard theo tenant); aggregator xả sang Orb khi đủ thời gian hoặc đủ số event, cái nào tới trước. Số event là O(số tenant × số node Proxy), overhead không đáng kể. Cái giá: dữ liệu đang gom trong bộ nhớ không bền; mất node thì tệ nhất là tính thiếu tiền khách, họ chấp nhận.
  • Nhận biết cùng region: bật client IP preservation của NLB để Proxy thấy IP thật của client, đối chiếu với dải CIDR theo region AWS công bố.
• Theo WarpStream, dùng Orb giúp làm xong trong vài ngày thay vì vài tuần hay vài tháng tự viết metering, rating, invoicing.

Vì sao

• Đo ở đường nóng phải gom trước khi gửi, nếu không chính việc đo thành tải lớn nhất; gom theo khoá ổn định (tenant) thì số event tỉ lệ với số khách, không với lưu lượng (Batching và khấu hao round-trip).
• Thiết kế cho phép gửi lại (idempotency key) làm tiến trình đo không cần chính xác tuyệt đối về trạng thái; chọn hướng sai số an toàn (tính thiếu) cho phần không bền (Chi phí hạ tầng và build vs buy).

Bài học cho SWE

• Đẩy tính đúng sang khử trùng lặp ở phía nhận; checkpoint chỉ còn là tối ưu.
• Khi phải bỏ độ bền để giảm overhead, chọn rõ hướng sai số và ghi lại.
• Phí mạng của cloud phụ thuộc topology; muốn tính tiền theo đó thì cần nhìn thấy IP thật của client.

Liên quan

• Multi-tenancy và cô lập tenant
• Stripe 2026 · Grammarly 2023 · Stripe 2025 · WarpStream 2025
• Batching và khấu hao round-trip · Chi phí hạ tầng và build vs buy