October 2024 queue retrospective
Bài tóm tắt Inngest 2024 2. Tăng trưởng Độ khó: Trung bình
Inngest · 2024 · 2. Tăng trưởng · Độ khó: Trung bình — bài gốc
Một bài gom bảy sự cố trong một tháng nâng cấp hệ queue. Không sự cố nào mất dữ liệu (theo Inngest). Hai năm sau Inngest chuyển queue sang FoundationDB: Inngest 2026.
Bối cảnh
Inngest chạy durable workflow cho khách; lõi là một queue đa tenant có flow control theo key do user đặt. Tháng 10/2024 họ nâng cấp liên tục; kết quả cuối tháng là P95 latency thực thi khoảng 50 ms với hàng chục nghìn step đồng thời mỗi user.
Các sự cố
| Ngày | Chuyện gì | Gốc | Xử lý |
|---|---|---|---|
| 4/10 | Throughput tụt sau release Key Queues (flow control cho key cardinality cao) | Mỗi key một queue con. Xử lý một queue tốn gấp 4 lần thao tác so với một item; cardinality cực cao sinh rất nhiều queue chỉ có một item, nên tổng năng lực giảm | Rollback một phần, dọn dẹp; lên kế hoạch load test tốt hơn trên staging, thiết kế mới cho cardinality cực cao |
| 9/10 | Cron trễ khoảng 52 phút | Refactor đổi kho lưu của dịch vụ cron | Cảnh báo riêng cho cron theo số lịch |
| 11/10 | Trạng thái function run cập nhật lỗi | Chia stream NATS và round-robin khi publish để giảm tải một stream; lỗi publish im lặng bên trong NATS, chỉ thấy qua metric | Revert, gán stream cố định; cảnh báo lệch pub/sub; chia nhỏ cụm NATS. Theo Inngest, NATS JetStream có vấn đề nền tảng khi publish; hướng dài hạn là quay về Kafka |
| 18/10 | Run bị trễ | CPU của shard queue chính tăng vọt, mọi thao tác chậm | Đã có sẵn việc shard queue; xây công cụ dời account giữa các shard, thử ở staging rồi với chính account của họ, rồi chuyển khách theo lô, theo dõi từng lần. Khách đã chuyển có P95 10–50 ms |
| 22/10 | Ghép event cho waitForEvent/cancelOn trễ lác đác |
Thiếu năng lực trong lúc migration shard còn dở | Tự hết khi migration xong |
| 24/10 | Ghép event trễ nặng | Ghép event về bản chất là bậc hai (mọi event so với mọi waitForEvent/cancelOn đã lưu); bộ tối ưu (gần 1 ms) không tối ưu được một biểu thức cụ thể |
Tối ưu biểu thức, chỉnh worker, scale theo tài nguyên, cảnh báo độ phức tạp biểu thức |
| 30/10 | UI và DB chậm | Lỗi đĩa của Postgres RDS (metadata): disk queue depth tăng dù query và IO bình thường | Chuyển đọc sang replica, tăng cache cục bộ, bảo trì primary; khoảng 1 giờ |
Bài học cho SWE
- Thiết kế đúng trên lý thuyết và qua test vẫn có thể sai ở tổng thể khi cardinality cực đoan: chi phí trên mỗi queue nhân với số queue (Event-driven, message queue và Kafka).
- Publish lên broker có thể lỗi im lặng; cần metric so sánh lượng publish và subscribe.
- Shard queue theo tenant và có công cụ dời tenant giữa shard là cách gỡ shard nóng; dời theo lô, bắt đầu bằng account của chính mình (Sharding và tách database).
- Pub-sub có bộ lọc theo biểu thức: chi phí là ghép, không phải giao; một biểu thức xấu đủ làm backlog (cùng ý với Atlassian 2026 Atlassian 2026).
- Một tháng nhiều thay đổi hạ tầng liên tiếp cho ra nhiều sự cố nhỏ (Sự cố và postmortem).
Liên quan
Sự cố và postmortemEvent-driven, message queue và KafkaSharding và tách databaseMulti-tenancy và cô lập tenant
Được nhắc tới trong
Chủ đề (4)
Công ty (1)
Bài tóm tắt (1)