Running Kafka At Scale

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

Bối cảnh

Năm 2015 Kafka chạm gần như mọi server LinkedIn: hơn 800 tỷ message/ngày (175 TB vào, 650 TB đọc ra), đỉnh 13 triệu message/giây (2,75 GB/s), hơn 1.100 broker trong hơn 60 cụm.

Tách cụm theo loại message: queuing (trong một ứng dụng, như gửi email), metrics, logging (tách khỏi metrics chỉ vì quá nhiều), tracking (mọi hành động người dùng; nuôi Samza, Hadoop, search index, tính tiền; dữ liệu lãnh đạo nhìn thấy).
Hai tầng cụm cho multi-DC: mỗi loại có cụm local trong từng data center và cụm aggregate gom từ mọi local bằng MirrorMaker (chỉ chép local → aggregate nên không có vòng lặp). Message đi qua mạng giữa DC đúng một lần; consumer luôn đọc local.
Kafka Audit kiểm độ đầy đủ: header message mang timestamp, service và host gốc. Producer đếm số message gửi mỗi khoảng thời gian và gửi con số vào một topic audit; mỗi cụm có console auditor đọc mọi topic và cũng gửi số đếm. So số giữa các tầng phát hiện mất hoặc trùng message và lần ngược về host hỏng. Consumer quan trọng (Hadoop) cũng ghi audit như một tầng riêng, nên kiểm được đầu-cuối.
Thư viện nội bộ bọc client mã nguồn mở: TrackerProducer tự chèn header, đăng ký schema, gửi audit; consumer tự lấy schema và giải Avro. Một team Kafka (gồm committer) hỗ trợ mọi team dùng Kafka thống nhất.
Hướng tới: security, quota, mức 1.000 tỷ message/ngày; SRE tự động hoá việc như dời partition.

Một cụm Kafka chạy đúng thì không mất message, nhưng thêm tầng và MirrorMaker tạo nhiều điểm mất mà monitoring sức khoẻ cụm không thấy; phải đếm theo dòng dữ liệu.

Đo độ đầy đủ bằng số đếm do chính producer báo so với số mỗi tầng nhận, thay vì tin vào trạng thái của từng thành phần.
Thư viện client chung là nơi đặt quy ước (header, schema, audit) để cả công ty theo mà không phải kiểm từng team.