How WarpStream Powers Grafana Labs' Redesigned Architecture

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

Bài do Grafana Labs viết (giọng "chúng tôi" là Grafana), đăng lại trên blog WarpStream. Kiến trúc mới đang được rollout lúc viết, chưa có kết quả vận hành; mọi nhận định ghi "theo Grafana Labs".

Bối cảnh

• Grafana Mimir (2025): TSDB mã nguồn mở, scale ngang, multi-tenant, tương thích Prometheus; đã chạy tới 1 tỷ active series. Là nền của Grafana Cloud Metrics.
• Kiến trúc cũ: node ingester có trạng thái, giữ TSDB trong bộ nhớ cộng WAL cục bộ trên persistent volume; mỗi điểm dữ liệu replicate ra 3 volume, crash thì nạp snapshot rồi replay WAL.
• Hai đánh đổi của thiết kế đó:
  1. Ingester tham gia cả đường ghi lẫn đường đọc, nên query nặng làm nhiễu ghi.
  2. Ingester rất stateful (volume WAL cục bộ), vận hành phải cẩn thận.

Thay đổi chính

• Mục tiêu chính: tách đường đọc khỏi đường ghi, sự cố ở bên này không ảnh hưởng bên kia, và ingester đơn giản hơn. Chọn Kafka làm nền cho Mimir (chuẩn mở, hệ sinh thái lớn).
• Riêng Grafana Cloud: muốn chạy nhiều phần hơn trên nhiều AZ cho khách cần SLA cao. Kiến trúc cũ làm được nhưng phí truyền dữ liệu giữa AZ khiến chạy diện rộng quá đắt. Kafka tự nó không giải quyết chuyện này.
• Chọn WarpStream (Kafka trên object storage) cho Grafana Cloud: không phí mạng giữa AZ, không đĩa phải quản, stateless, tự scale.
• Load test cùng WarpStream: ghi 1,5 GiB/s (đã nén) vào một cụm, đọc với fan-out 4 lần, tổng 7,5 GiB/s, không gặp nút thắt.
• Rollout dần cho Grafana Cloud Metrics; khi đủ tin cậy mới đưa lên bản ổn định của Mimir OSS.

Vì sao

• Theo Grafana Labs: hệ mới chịu spike query và spike ingest tốt hơn nhiều, vì đường ghi chỉ cần ghi vào log bền, không phải phục vụ query.

Bài học cho SWE

• Khi một thành phần vừa nhận ghi vừa phục vụ đọc, query nặng sẽ làm hỏng ghi. Đặt một log bền (Kafka) ở giữa để hai đường scale và hỏng độc lập (Tách compute khỏi storage).
• WAL cục bộ trên volume làm node thành "thú cưng"; chuyển độ bền ra ngoài (log, object storage) thì node đơn giản lại.
• Multi-AZ không chỉ là câu hỏi kỹ thuật mà là câu hỏi chi phí mạng: replicate giữa AZ có thể đắt tới mức không làm diện rộng được (Chi phí hạ tầng và build vs buy, Độ tin cậy và multi-region).
• Hạ tầng observability ở quy mô lớn gặp đúng các bài toán của hệ dữ liệu sản phẩm (Observability và monitoring).

Liên quan

• WarpStream 2025 · WarpStream 2026 · Miro 2020 · Prometheus 2026
• Observability và monitoring · Tách compute khỏi storage · Event-driven, message queue và Kafka