Hệ thống lưu trữ dữ liệu xây dựng trên nền tảng Apache Kafka của LinkedIn hằng ngày phải gửi tiếp nhận đến 800 triệu messages hằng ngày, tương đương với kích thước hơn 175 terabytes dữ liệu. Hơn 650 terabytes messages được tiêu thụ hằng ngày, đặt ra bài toán thiết kế một hệ thống có thể xử lý khối lượng dữ liệu khổng lồ 24/7. Như vậy, nhóm engineer ở LinkedIn đã giải quyết bài toán này như thế nào ?


Các engineers ở Linkedin định nghĩa 4 loại messages: queueing, metrics, logs, tracking data được đưa vào từng cluster khác nhau

Queueing - các messages được các producer đẩy vào topic, và các consumer sẽ lấy ra các message cần thiết, không quan tâm những message khác. Các dạng message này có thể được dùng để gửi email ra ngoài hoăc là các tập dữ liệu được tính toán bởi ứng dụng khá. Cũng có thể là dữ liệu kết hợp với các backend component

Metrics - các thông số đo đạc của hệ thống được các ứng dụng tạo ra trong quá trình vận hành. Những thông số đo đạc từ OS hoặc phần cứng, những kết quả đo đạc cụ thể của từng ứng dụng vận hành trong hệ thống. Bằng những thông số này, các engineers sẽ biết các vấn đề hoặc phát hiện các sự cố trong quá trình vận hành của hệ thống.

Logging - Ban đầu, logging và metrics được gộp chung trong một cluster. Nhưng hiện tại logging và metrics đã được tách ra vì kích thước dữ liệu ngày càng tăng. Logging data được đẩy vào Kafka từ các ứng dụng và được đọc bởi các hệ thống khác.

Tracking - đóng vai trò then chốt nhất trong kiến trúc của LinkedIn. Thông tin để theo dõi những phiên giao dịch thanh toán, đo đạc growth vectors trong thời gian thực.

Các engineer ở LinkedIn phân chia kiến trúc hệ thống thành những data center.

Đối với từng category message, sẽ có một Kafka cluster tên là "local" chứa những message được tạo ra bên trong datacenter đó. Đồng thời, có một "aggregate" Kafka cluster để kết hợp toàn bộ messages từ "local" cluster tương ứng với từng category. LinkedIn dùng ứng dụng Kafka mirror maker để copy toàn bộ messages từ "local" cluster sang "aggregate" cluster.

Luân chuyển dữ liệu bên trong kiến trúc Kafka giúp giảm chi phí về mạng và độ trễ bằng cách sao chép messages với số lần tối thiểu (một lần trong một datacenter). Các consumer truy xuất data nội bộ trong datacenter, đơn giản hóa các thiết lập, không cần phải quan tâm đến vấn đề liên kết với các datacenter khác.

Trong kiến trúc này, producer là lớp đầu tiên, kế đến là "local" cluster (trong từng datacenter), các "aggregate" cluster là một lớp được thêm vào. Lớp cuối cùng là consumer.

Kiến trúc này phát huy khá nhiều ưu điểm, tuy nhiên lại mang nhược điểm về sự phức tạp khi vận hành và đảm bảo sự ổn định của hệ thống. Với việc đưa thêm vào những lớp phụ, các component như mirror maker vô tình tạo ra những điểm có nguy cơ làm mất dữ liệu. Thêm vào đó, song song với việc monitor các Kafka clusters, các engineers cần phải tìm ra giải pháp để đảm bảo tất cả messages phải hiện diện trong tất các lớp.

Nhóm engineer ở LinkedIn sử dụng Kafka Audit như một tool để đảm bảo tất cả các message được tạo ra được sao chép vào tất cả các lớp. Có một dạng message với schema đặc tả từng đặc điểm của các message như thời điểm message được tạo ra, tạo ra bởi producer nào, ở host nào,...

Một producer sẽ gửi những message với thông tin là số lượng message đã gửi trong một khoảng thời gian nhất định nào đó (ví dụ 1000 message/s) vào một topic. Từ đó, ta có thể biết được mỗi producer sẽ đẩy bao nhiêu message vào trong mỗi topic.

Đội ngũ engineer đang ngày càng hoàn thiện hệ thống để đáp ứng cho mục tiêu có thể scale đến 1 trillion message trong một ngày và hơn nữa.

Reference: https://engineering.linkedin.com/kafka/running-kafka-scale