Building a fault-tolerant metrics storage system at Airbnb

Airbnb · 2026 · 3. Quy mô lớn · Độ khó: Khó — bài gốc

Bài không nêu tên hệ storage mã nguồn mở bên dưới (chỉ nhắc rollout operator của Grafana và Promxy). Bối cảnh rời vendor: Airbnb 2026.

Bối cảnh

• Airbnb chuyển từ nhà cung cấp metrics hosted sang tự vận hành. Quy mô (2026): 1,3 tỷ time series active trung bình, 50 triệu sample/giây, 2,5 PB dữ liệu logic.
• Yêu cầu: hơn 50 triệu sample/giây, tới 10.000 dashboard và 500.000 alert, p99 thời gian query dưới 30 giây.

Thay đổi chính

• Tenant theo service (khoảng 1.000 service), không theo team vì quyền sở hữu team đổi thường xuyên; quy được tăng trưởng metric về từng ứng dụng, mở đường cho chargeback. Guardrail ghi/đọc theo tenant (lượng và tốc độ series, số rule, chu kỳ đánh giá).
• Shuffle sharding: mỗi tenant chỉ ghi vào một tập con node storage và query chỉ dùng một tập con query worker; một tenant bị tấn công hoặc lỗi chỉ hạ được vài shard, tenant khác vẫn còn.
• Control plane hợp nhất: tự onboard tenant khi phát hiện service mới; chỉ lộ ra vài giới hạn (ví dụ giới hạn series) và suy ra các giới hạn khác (tốc độ ingest, burst) từ đó, thay cho hàng loạt bước tay và tham số không ai biết chỉnh cái nào.
• Kiểm chứng bằng shadow cluster nhận traffic production lộ ra: thành phần ghi/đọc mất ổn định khi series active tăng đột biến và thiếu guardrail query; compaction trễ với tenant lớn làm query lịch sử chậm và tốn tài nguyên; query lớn (hơn 5.000 series hoặc hơn 500 MB dữ liệu) chậm; cụm có vấn đề thì mọi tenant "bay mù".
• Một cụm cho chắc trước: benchmark thành phần ghi để định cỡ và đặt giới hạn mỗi replica (tốc độ ingest, request đang bay); giới hạn series mỗi tenant với lookback một tháng. Đọc: query sharding để san tải worker, giới hạn series/chunk mỗi query theo tenant, tách đường đánh giá alert khỏi query ad hoc (dashboard, CI), autoscale thành phần đọc; compaction của tenant lớn chia shard, mỗi worker tối đa 8 triệu series. Thành phần stateful chạy zone-aware trên 3 zone.
• Rồi nhiều cụm: cụm chuyên cho workload đặc thù (compute, mesh) và nhiều cụm ứng dụng; rollout theo thứ tự quan trọng: test/nội bộ → cụm ứng dụng → cụm hạ tầng, để đạt hơn 99,9% availability. Công cụ ánh xạ tenant → cụm làm nguồn sự thật; rollout StatefulSet đa AZ bằng operator (thay quy trình tay mất nhiều ngày, bớt trôi cấu hình); Promxy (có thêm native histogram, tối ưu fan-out) cho query và alert xuyên cụm.

Vì sao

• Theo Airbnb: tin cậy thật cần nghĩ lại tenancy, failure domain và phụ thuộc từ đầu đến cuối; nguyên tắc là cô lập, tự động hoá, guardrail, và đường riêng cho tín hiệu quan trọng.

Bài học cho SWE

• Query liên cụm đắt gấp 5–10 lần query trong một cụm; vài query đắt đủ làm hỏng đọc trên nhiều cụm, nên Airbnb phải gom lại tenant theo mẫu đọc nóng. Chia cụm để giảm blast radius thì phải trả giá ở đường đọc chéo.
• Đặt khoá tenant theo thứ ổn định (service) thay cho thứ hay đổi (team).
• Lộ ít núm, suy ra phần còn lại; người vận hành không phải biết hàng chục tham số.
• Cụm tự điều chỉnh được thì thêm/thay cụm rẻ: "cattle, not pets".

Liên quan

• Multi-tenancy và cô lập tenant
• Observability và monitoring · Độ tin cậy và multi-region
• Cùng đợt chuyển observability: Airbnb 2026 · Airbnb 2026
• Cell và blast radius ở Slack: Slack 2023