Robinhood Swaps Kafka for WarpStream to Tame Logging Workloads and Costs

WarpStream · 2025 · 3. Quy mô lớn · Độ khó: Trung bình — bài gốc

Nhà cung cấp viết lại talk của hai engineer Robinhood (Ethan Chen, Renan Rueda) ở Current New Orleans 2025. Là case study quảng bá; số liệu là theo Robinhood qua lời kể của WarpStream.

Bối cảnh

• Robinhood (2025): hơn 14 triệu người dùng hoạt động mỗi tháng, hơn 10 TB dữ liệu mỗi ngày. Log gồm log ứng dụng và pipeline observability chạy bằng Vector, trước đó đi qua Kafka.
• Tải theo giờ giao dịch của thị trường Mỹ: cao trong giờ mở cửa, có spike bất ngờ, thấp vào đêm và cuối tuần. Kafka trên EBS không tự co giãn: máy EC2 phải giữ để gắn EBS, đĩa phải cấp dư, nên lãng phí cả compute lẫn storage.
• Log không nhạy latency, nên hợp với Kafka "diskless" trên object storage (latency cao hơn).

Thay đổi chính

• Tách cụm Kafka nguyên khối thành hai cụm WarpStream: một cho dịch vụ logging, một cho Vector daemonset. Migration hai pha:
  • Dịch vụ logging kiểu "tất cả hoặc không": tạm tắt ingest của Vector, log đệm lại trong Kafka, chờ ứng dụng xử lý hết hàng đợi, rồi chuyển nhanh sang WarpStream (gián đoạn tối đa vài phút).
  • Vector: chạy song song hai nhóm consumer (một ship về Kafka, một về WarpStream), rồi chuyển dần producer sang WarpStream và tắt Kafka.
• Agent Groups để cách ly: client nào vào nhóm nào, tránh noisy neighbor; cấu hình khác nhau theo nhóm (TLS hay không). Nhiều tài khoản AWS dùng chung một bucket S3 trung tâm, Agent Group nằm ở VPC khác nhau: bên ghi và bên đọc gặp nhau qua S3, không cần VPC peering hay PrivateLink.
• HPA scale lên nhanh (lúc thị trường mở cửa) và scale xuống chậm (để client kịp rời Agent sắp tắt). Ba deployment, mỗi AZ một cái với HPA riêng, client đi theo AZ để mỗi vùng tự co giãn theo tải của nó.
• Batch lớn hơn để giảm số request S3; latency tăng từ 0,2 lên 0,45 giây, chấp nhận được với log.

Kết quả (theo Robinhood)

• Tiết kiệm 45% so với Kafka: bỏ hẳn phí mạng giữa AZ, compute giảm 36%, storage giảm 13%.
• Vận hành nhẹ hơn: S3 tự replicate (hết chuyện under-replicated partition, hết tăng EBS), control plane do nhà cung cấp quản, ít việc on-call hơn, dựng cụm mới trong vài giờ.

Bài học cho SWE

• Workload log có tải theo chu kỳ rõ và chịu được latency là ứng viên tốt nhất để tách compute khỏi storage: compute stateless co giãn theo giờ, dữ liệu nằm ở object storage (Tách compute khỏi storage).
• Phí mạng giữa AZ có thể là khoản lớn nhất trong hoá đơn Kafka; kiến trúc ghi qua object storage xoá khoản đó (Chi phí hạ tầng và build vs buy).
• Migration hệ log tuỳ thành phần: phần "tất cả hoặc không" thì xả hàng đợi rồi chuyển một lần; phần chạy song song được thì nhân đôi consumer rồi chuyển dần (Migration không downtime).
• Scale lên nhanh, scale xuống chậm: scale xuống quá nhanh gây spike latency vì client chưa kịp rời node.

Liên quan

• Batching và khấu hao round-trip
• WarpStream 2025 · WarpStream 2026 · WarpStream 2026 · Redpanda 2023
• Event-driven, message queue và Kafka · Chi phí hạ tầng và build vs buy · Tách compute khỏi storage · Observability và monitoring