Tối ưu Kafka với 10 Triệu Message và 1500 Topic

Bài Toán Kafka

Mình có khoảng 1500 topic (mỗi topic tương ứng với một event từ client), do đặc thù các hệ thống khác nhau quan tâm đến các event khác nhau (có thể thay đổi) nên không thể nhóm các event vào một hoặc nhiều topic được. Mỗi ngày có tổng khoảng 10 triệu message, tập trung trong 4 tiếng (không đồng đều), với event nhiều nhất có khoảng 1 triệu message, 10 topic đầu chiếm 8 triệu message, các topic còn lại chỉ dưới 100k message.

Mình có 2 loại consumer:

1. Consumer loại 1: Cần nhận đủ trên tất cả các topic và có thể chạy batch vào buổi tối.
2. Consumer loại 2: Chỉ quan tâm đến một vài topic (có thể thay đổi theo thời gian) và cần ưu tiên nhận được message nhanh nhất.

Câu Hỏi

Nên chia Partition cho các topic này như thế nào, nên dùng bao nhiêu consumer cho mỗi loại, và phân chia theo consumer group thế nào để tối ưu?

Giới Thiệu Chung về Kafka

Một bài tập về System Design khá thú vị, trước khi bắt đầu giải quyết bài toán thì để hiểu bài viết này bạn cần một chút kiến thức về Kafka, bạn có thể tham khảo trên trang chủ của Kafka tại đây.

Nếu bạn chưa biết Kafka thì Kafka là một nền tảng stream-processing phân tán, có khả năng xử lý và truyền tải lượng lớn dữ liệu real-time với độ tin cậy cao. Kafka được sử dụng rộng rãi trong các hệ thống xử lý dữ liệu lớn, cung cấp cơ chế lưu trữ và truyền tải dữ liệu giữa các hệ thống với hiệu suất cao và độ trễ thấp.

Còn giờ thì chúng ta bắt đầu thôi.

Phân Chia Partition cho Các Topic

Phân Tích Tải Trọng của Từng Topic

• Top 10 topic: Chiếm 8 triệu message/ngày, mỗi topic trung bình khoảng 800,000 message.
• Các topic còn lại: Chiếm 2 triệu message/ngày, mỗi topic trung bình dưới 100,000 message.

Số Lượng Partition cho Các Topic

• Top 10 topic:
  • Chia thành nhiều partition để tăng khả năng song song xử lý. Giả sử mỗi partition có thể xử lý tối đa 100,000 message/giờ, bạn cần ít nhất 10 partition cho mỗi topic này.
• Các topic còn lại:
  • Với các topic có dưới 100,000 message/ngày, có thể bắt đầu với 1-2 partition.

Cấu Hình Consumer Groups

Consumer Loại 1 (Batch Consumer)

• Do cần nhận đủ trên tất cả các topic và có thể chạy batch buổi tối, bạn có thể tạo một consumer group duy nhất cho loại này. Mỗi consumer trong group này có thể xử lý nhiều partition từ nhiều topic.
• Số lượng consumer trong group này phụ thuộc vào số lượng partition và khả năng xử lý của mỗi consumer. Ví dụ: nếu bạn có 1500 topic với trung bình 2 partition/topic, bạn có tổng 3000 partition. Với khả năng xử lý của consumer, bạn có thể cần khoảng 100-150 consumer (giả sử mỗi consumer xử lý 20-30 partition).

Consumer Loại 2 (Real-time Consumer)

• Với loại consumer này chỉ quan tâm một vài topic và cần nhận message nhanh nhất, mỗi consumer nên được gán trực tiếp với các partition của các topic quan tâm.
• Số lượng consumer trong group này nên bằng hoặc nhiều hơn số partition của các topic quan tâm để đảm bảo khả năng xử lý thời gian thực.

Phân Chia Consumer Groups

Consumer Group cho Loại 1

• Tạo một consumer group duy nhất cho tất cả các partition từ tất cả các topic.
• Cân nhắc sử dụng nhiều consumer để phân chia tải đều và tăng khả năng song song xử lý.

Consumer Group cho Loại 2

• Tạo nhiều consumer group tương ứng với các nhóm topic khác nhau mà loại 2 quan tâm.
• Đảm bảo mỗi group có đủ consumer để xử lý partition của các topic này một cách nhanh chóng.

Ví Dụ Cụ Thể

Giả sử bạn có 1500 topic, mỗi topic trung bình 2 partition:

• Tổng partition: 1500 * 2 = 3000.
• Consumer group cho loại 1 (batch processing): Có thể cần khoảng 100-150 consumer.
• Consumer groups cho loại 2 (real-time processing): Mỗi group nên có số lượng consumer tương ứng với số partition của các topic mà nó quan tâm.

Ví Dụ Tối Ưu Partition

• Với top 10 topic:
  • Với mỗi topic có 1 triệu message/4 giờ, trung bình 70 message/giây, giả sử mỗi consumer của bạn xử lý được khoảng 10 message/giây -> cần 7-8 partition.
  • Tuy nhiên, do yêu cầu xử lý của bạn bị giới hạn bởi latency, nếu peak x2 bình thường -> bạn cần 16 partition.
• Với các topic còn lại: 1 partition mỗi topic là đủ.

Tối Ưu Consumer Groups

• Với real-time consumer, số consumer bằng hoặc lớn hơn số partition.
• Với batch consumer, nếu các consumer của các topic khác nhau có logic xử lý khác nhau hoàn toàn thì phải 1 consumer/1 topic. Nếu code có thể handle được nhiều topic cùng lúc thì tạo số consumer đủ để handle toàn bộ data trong khoảng thời gian mong muốn.

Kafka có thể handle được multiple topic trên một consumer, tuy nhiên nếu cảm thấy việc manage quá nhiều topic trên một consumer quá phức tạp thì có thể tạo 1 topic khác để gom tất cả các message về (vd dùng Kafka stream) sau đó batch consumer sẽ chỉ cần consume lại từ aggregated topic đó.

Cấu Hình Kafka Cluster

• Đảm bảo đủ số lượng broker: Với số lượng partition lớn như vậy, bạn cần đảm bảo cluster của bạn có đủ broker để phân phối các partition một cách đều đặn. Mỗi broker nên quản lý khoảng 200-300 partition.
• Cân nhắc về replication factor: Để đảm bảo độ tin cậy, replication factor nên được đặt ở mức 2 hoặc 3 tùy vào yêu cầu về dữ liệu của bạn.

Tổng Kết

1. Top 10 topic: Ít nhất 10 partition/topic.
2. Các topic còn lại: 1-2 partition/topic.
3. Consumer loại 1: 100-150 consumer trong một group.
4. Consumer loại 2: Số lượng consumer bằng hoặc nhiều hơn số partition của các topic quan tâm.