From Always-On to On-Demand: Scaling Kafka Sinks with KEDA

trivago · 2026 · 4. Điều chỉnh · Độ khó: Trung bình — bài gốc

Bối cảnh

trivago dùng Kafka làm lớp vận chuyển dữ liệu giữa các hệ. Nhiều dữ liệu vào Kafka từ database qua Debezium (CDC), topic dùng log compaction nên giữ giá trị mới nhất mỗi key, như một snapshot liên tục.
Sink: consumer đọc topic, áp business rule (lọc, chuẩn hoá, policy) rồi upsert idempotent vào database cục bộ của service dưới dạng materialized view. Đọc nhanh và không phụ thuộc hệ thượng nguồn; dựng lại được bằng cách đọc topic từ đầu.
50+ sink × 3 region (US, EU, ASIA) trên Kubernetes, mỗi sink khoảng 1 core + 1 GB. Dữ liệu tới theo đợt (import ban đêm, cronjob); phần lớn thời gian sink chỉ poll và chờ, nhưng vẫn tốn compute, tải control plane (probe, endpoint, metric), log/metric và tải poll lên broker.

Sink chủ yếu chờ I/O, nên CPU thấp trong khi lag tăng; RAM ổn định, không phản ánh backlog; tín hiệu tới quá muộn. Muốn chịu đợt cao điểm thì phải đặt min replica cao, chạy không 24/7.
Câu hỏi đúng là "có việc đang chờ không?", tức là consumer lag.

KEDA với Kafka scaler: scale theo lag của consumer group, scale về 0 (HPA thường không xuống 0 được). Cấu hình mẫu: minReplicaCount: 0, activationLagThreshold: 0 (có lag là dậy), lagThreshold: 100 (replica ≈ tổng lag / 100), cooldownPeriod: 300 (chống dao động), pollingInterval: 30.
maxReplicaCount ≤ số partition (mỗi partition chỉ một consumer trong group), thấp hơn nữa nếu sink bị database chặn.
Fallback: không lấy được metric 6 lần liên tiếp thì giữ 1 replica, để sink không kẹt ở 0 vì mất tín hiệu.
Ca biên: chính sách xoá consumer group không hoạt động quá 2 tuần, mà topic hiếm (một tháng một lần) thì sink ngủ lâu sẽ mất group. Thêm Cron scaler đánh thức 1 replica định kỳ; lệch giờ đánh thức mỗi sink để không cùng dậy một lúc.
Rollout: một sink không quan trọng → một region (ASIA) → chạy một tuần (qua ít nhất một chu kỳ import đêm) → mọi region → các sink còn lại theo lô nhỏ. Mỗi bước so lag Kafka báo, metric consumer sẵn có và metric KEDA đưa cho Kubernetes.

Mức dùng trung bình mỗi ngày từ khoảng 50 replica-giờ/region xuống 1–2 replica-giờ/region.
Đợt cao điểm tự scale lên rồi về 0, không chỉnh replica bằng tay.

Scale theo việc đang chờ, không theo tài nguyên đang dùng (Tự động hoá vận hành và auto-remediation).
Trần scale của consumer là số partition (Event-driven, message queue và Kafka).
Scale-to-zero cần đường lui khi mất tín hiệu và cần biết các chính sách dọn dẹp ngầm (xoá group) (Chi phí hạ tầng và build vs buy).
Kiểm chứng tín hiệu điều khiển trước khi giao cho nó cả fleet.