Building Self-driving Kafka clusters using open source components

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

Bối cảnh

• Kafka ở Slack là xương sống của Job Queue (Slack 2017), pipeline log, trace, billing, analytics. Năm 2018 mỗi team tự chạy cụm Kafka riêng: nhiều phiên bản, lặp công sức.
• Dự án chuẩn hoá về một phiên bản (Kafka 2.0.1), một team nhỏ quản lý, nên phải tự động hoá tối đa. Quy mô (2022): khoảng 0,7 PB trên 10 cụm, hàng trăm node, hàng triệu message/giây, 6,5 Gbps lúc cao điểm; chi phí chủ yếu là phần cứng và mạng.

Thay đổi chính

• Provision tái lập được: Chef cấu hình host, Terraform tạo ASG; bỏ gói Debian, tự build binary từ bản fork nội bộ lên S3. Zookeeper từng phải dựng tay (dễ dựng nhầm nhiều node cùng AZ); nâng lên ZK 3.6 (thay node không cần restart cả cụm) và cấp ID duy nhất qua Consul KV trước khi node vào cụm, nên ZK cũng chạy bằng ASG.
• Hot spot là gốc của mất ổn định:
  • Đặt số partition là bội số của số broker và số consumer đều trên các node; khi thêm broker/consumer thì chỉnh lại để vẫn là bội số.
  • Giới hạn băng thông replication khi rebalance (trước đó nó ăn hết tài nguyên của producer/consumer lúc cao điểm), và chỉ chuyển ít partition mỗi lần, thay đổi nhỏ liên tục.
  • Cruise Control (của LinkedIn) tự rebalance khi cụm lệch dần do lỗi cục bộ.
• Chaos với dark traffic trước khi cutover: làm bão hoà tài nguyên, tắt broker có kiểm soát. Phát hiện phục hồi bị giới hạn bởi packet per second → bật jumbo frames; lộ bug trong consumer dùng Sarama (Go) → chuyển một số sang client Confluent; ZK lỗi lan nhanh thành lỗi Kafka → mỗi cụm Kafka một cụm ZK riêng.
• Tự phục vụ: Kafka Manager cho mọi người xem metadata và tự tạo topic, tăng partition; offset exporter ra Prometheus và dashboard lag theo topic/consumer; gộp runbook thành một trang, dashboard thành một. Ít phải SSH vào broker hơn, cũng tốt cho bảo mật.
• Nâng cấp bằng cutover, không nâng tại chỗ: dựng cụm mới, kiểm bằng dark traffic, dừng ghi vào cụm cũ, ghi sang cụm mới, tắt cụm cũ khi hết retention. Cùng quy trình dùng để chuyển topic giữa cụm và thử loại EC2 mới.
• Tách cụm chính (đầu 2021): cụm 90 broker chạm trần mạng khoảng 40.000 pps, pipeline log trễ hằng ngày. Tách ba topic lớn nhất sang cụm nhỏ trên d3en: 20 broker đạt hiệu năng tương đương, khoảng 2,5 lần hiệu quả hơn. Độ trễ log xấu nhất từ khoảng 1,5 giờ xuống 3–4 phút; alert on-call của pipeline log từ 71 xuống 9 một tháng.

Vì sao

• Team nhỏ chỉ trụ được nếu thao tác thường ngày (rebalance, thay broker, tạo topic, trả lời "consumer có theo kịp không") không cần người.

Bài học cho SWE

• Phân bố đều là điều kiện của tự động hoá: số partition không chia hết cho số broker thì broker nóng, và mọi thao tác quản trị khuếch đại điểm nóng đó.
• Thao tác bảo trì phải có giới hạn tốc độ (replication throttle, ít partition mỗi lần) để không cạnh tranh với tải thật.
• Cụm lớn dùng chung đến một lúc thành nguồn noisy neighbor; cụm nhỏ chuyên dụng làm thao tác nhanh hơn và cô lập lỗi.
• Nâng cấp bằng dựng mới rồi chuyển đổi lấy lại được khả năng kiểm chứng trước khi chịu tải thật, đổi lại phải phối hợp consumer.

Liên quan

• Event-driven, message queue và Kafka · Tự động hoá vận hành và auto-remediation · Hot partition và thundering herd
• Job Queue dùng Kafka làm lớp đệm: Slack 2017