Kafka KRaft và Kafka UI dưới góc nhìn kiến trúc

Vì sao hệ sinh thái Kafka đang rời xa ZooKeeper?

Trong nhiều năm, Kafka được triển khai song hành với ZooKeeper như một cách để quản lý metadata cluster, leader election và trạng thái của broker. Mô hình này từng hoạt động tốt ở giai đoạn Kafka còn chủ yếu đóng vai trò như một hệ thống log phân tán tốc độ cao. Tuy nhiên, khi Kafka dần trở thành nền tảng trung tâm cho event streaming, CDC, analytics pipeline và microservices, điểm nghẽn không còn nằm ở throughput đơn thuần mà nằm ở độ phức tạp vận hành.

Vấn đề của kiến trúc cũ không phải Kafka xử lý dữ liệu chậm, mà là hệ thống phải duy trì thêm một lớp điều phối riêng bên ngoài broker. Điều đó đồng nghĩa với thêm một mặt phẳng quản trị, thêm quy trình giám sát, thêm logic failover, và thêm rủi ro khi cluster mở rộng hoặc nâng cấp phiên bản. Với các đội hạ tầng, ZooKeeper không chỉ là một dependency; nó là một operational burden.

Chính vì vậy, KRaft xuất hiện không đơn thuần như một tính năng mới, mà là một bước tái thiết kế control plane của Kafka. Từ Kafka 4.0 trở lên, ZooKeeper đã bị loại bỏ hoàn toàn; các cụm Kafka mới bắt buộc chạy ở KRaft mode. Đồng thời, tài liệu nâng cấp chính thức của Apache Kafka cũng nêu rõ KRaft được xem là production-ready cho new clusters từ dòng 3.3.x trở đi.

Bản chất của KRaft không chỉ là “bỏ ZooKeeper”

Nhiều bài viết mô tả KRaft theo cách rất ngắn gọn: Kafka không còn cần ZooKeeper. Cách nói này đúng, nhưng chưa đủ. Điều quan trọng hơn là metadata quorum giờ đây được đưa vào ngay trong nội bộ Kafka, sử dụng cơ chế dựa trên Raft để duy trì tính nhất quán.

Trong KRaft mode, một số node sẽ giữ vai trò controller, tham gia vào metadata quorum và chịu trách nhiệm quản lý trạng thái cluster. Đây là khác biệt lớn so với mô hình cũ, nơi controller election phụ thuộc vào ZooKeeper. Apache Kafka mô tả rõ rằng trong KRaft, server có thể được cấu hình làm broker, controller hoặc đồng thời cả hai thông qua process.roles. Các controller được chọn sẽ tham gia metadata quorum với một active controller và các hot standby còn lại.

Điểm đáng chú ý là khi metadata path được nội bộ hóa, Kafka giảm được rất nhiều chi phí đồng bộ giữa hai hệ thống khác nhau. Thay vì phải theo dõi trạng thái broker ở một nơi và dữ liệu truyền tải ở nơi khác, toàn bộ mặt phẳng điều phối được gom về một nền tảng thống nhất. Đây là lý do KRaft thường được đánh giá cao hơn ở ba khía cạnh: đơn giản hóa deployment, giảm độ phức tạp của failure recovery và cải thiện khả năng scale control plane.

Tại sao ZooKeeper trở thành điểm yếu khi Kafka đi vào production lớn?

Ở quy mô nhỏ, việc vận hành thêm ZooKeeper chưa chắc đã gây ra cảm giác phức tạp. Nhưng khi cluster tăng số broker, số topic, số partition và tần suất thay đổi topology cao hơn, các vấn đề bắt đầu lộ rõ.

Trước hết là operational overhead. Đội ngũ vận hành phải quản lý hai hệ thống với vòng đời riêng: Kafka broker và ZooKeeper ensemble. Việc backup, monitoring, upgrade, tuning tài nguyên và xử lý sự cố đều tách thành hai lớp. Nếu một cụm Kafka chỉ phục vụ nội bộ thì chi phí này có thể chấp nhận được. Nhưng trong môi trường nhiều tenant, streaming liên tục và yêu cầu HA cao, mọi thành phần ngoài lõi đều là một nguồn rủi ro.

Tiếp theo là giới hạn trong thay đổi kiến trúc. Khi cần mở rộng cluster hoặc nâng cấp version, tính tương thích giữa Kafka và ZooKeeper luôn là biến số phải tính đến. Một cụm streaming hiện đại cần scale theo tải và giảm downtime ở mức tối thiểu, nhưng mô hình cũ khiến không ít thao tác trở nên cẩn trọng quá mức.

Cuối cùng là độ phức tạp trong xử lý lỗi. Khi control plane nằm ngoài Kafka, việc chẩn đoán sự cố không chỉ là xem broker log. Người vận hành phải xác định lỗi đến từ network partition, ZooKeeper session timeout, metadata inconsistency hay broker registration failure. Đó là kiểu phức tạp mà doanh nghiệp chấp nhận lúc đầu, nhưng về lâu dài luôn muốn loại bỏ.

KRaft thay đổi control plane của Kafka như thế nào?

Nếu xem Kafka như một hệ thống có hai mặt phẳng, thì data plane chịu trách nhiệm ghi và đọc message, còn control plane chịu trách nhiệm quản lý cluster metadata. Trước đây, control plane phụ thuộc ZooKeeper; giờ đây KRaft đưa phần đó quay trở lại Kafka.

Sự thay đổi này tạo ra ba tác động rất rõ.

Thứ nhất, deployment gọn hơn. Không còn cụm ZooKeeper riêng, không còn tập cấu hình tách biệt chỉ để duy trì metadata. Khi triển khai một cluster mới, quy trình provisioning dễ chuẩn hóa hơn, đặc biệt trong Docker, Kubernetes hoặc hạ tầng IaC.

Thứ hai, controller quorum rõ ràng hơn về vai trò. KRaft cho phép định nghĩa node nào là controller, node nào chỉ là broker, hoặc dùng combined mode trong môi trường lab/dev. Điều này mở đường cho mô hình production tách biệt controller node và broker node khi cần tối ưu tài nguyên hoặc giới hạn blast radius.

Thứ ba, đường nâng cấp về tương lai sáng hơn. Khi Kafka 4.x chỉ còn hỗ trợ KRaft, việc tiếp tục đầu tư vào ZooKeeper-based deployment gần như không còn ý nghĩa dài hạn. Với các hệ thống mới, KRaft không còn là lựa chọn thử nghiệm mà là hướng kiến trúc mặc định.

Kafka UI đóng vai trò gì trong một cluster hiện đại?

Sau khi control plane được đơn giản hóa, bài toán tiếp theo là khả năng quan sát và thao tác vận hành. Đây là nơi Kafka UI phát huy giá trị.

Về bản chất, Kafka UI là lớp quản trị trực quan cho cluster. Dự án mã nguồn mở này cho phép theo dõi broker, topic, partition, producer, consumer và nhiều tín hiệu vận hành quan trọng mà không phụ thuộc hoàn toàn vào CLI. Tài liệu dự án mô tả đây là web UI miễn phí, mã nguồn mở để monitor và manage Kafka cluster, đồng thời giúp data flows “observable” hơn và hỗ trợ troubleshooting nhanh hơn.

Với đội platform hoặc DevOps, giá trị lớn nhất của Kafka UI không nằm ở chỗ “dễ nhìn”, mà nằm ở việc rút ngắn vòng phản hồi khi vận hành. Thay vì phải liên tục gọi lệnh để xem topic config, replica state, consumer lag hoặc message flow, kỹ sư có thể rà soát cluster từ một dashboard tập trung. Điều này đặc biệt hữu ích trong các giai đoạn test tải, điều tra lag bất thường, hoặc kiểm tra nhanh trước và sau khi thay đổi cấu hình.

Tuy vậy, Kafka UI không phải là lớp thay thế hoàn toàn cho monitoring chuyên sâu. Nó nên được xem là operational console hơn là hệ thống observability đầy đủ. Với production, Kafka UI thường đi cùng metrics stack như Prometheus, Grafana và alerting riêng.

Kết hợp KRaft và Kafka UI tạo ra mô hình gì?

Khi đi cùng nhau, KRaft và Kafka UI giải quyết hai phần rất khác nhau nhưng bổ trợ chặt chẽ.

KRaft làm gọn control plane, giảm dependency và đưa cluster về mô hình hiện đại hơn. Kafka UI lại làm gọn experience của người vận hành, giúp cluster dễ quan sát hơn, dễ thao tác hơn và ít phụ thuộc hơn vào kiến thức CLI ở những công việc thường ngày.

Nói cách khác, KRaft tối ưu tầng kiến trúc, còn Kafka UI tối ưu tầng vận hành. Một bên giảm complexity bên trong hệ thống; bên còn lại giảm friction cho con người làm việc với hệ thống.

Đây là lý do nhiều đội ngũ kỹ thuật hiện nay không chỉ quan tâm “Kafka có chạy được không”, mà quan tâm nhiều hơn tới việc “Kafka có dễ vận hành, dễ mở rộng và dễ kiểm soát khi sự cố xảy ra hay không”. Ở góc nhìn đó, tổ hợp KRaft + Kafka UI phù hợp hơn nhiều với nhu cầu production hiện đại so với cách triển khai Kafka cũ.

Khi triển khai bằng Docker, cần hiểu đúng điều gì?

Docker giúp dựng môi trường Kafka nhanh, nhưng cũng là nơi rất nhiều cấu hình sai xuất hiện, đặc biệt liên quan đến listener và advertised listener. Bài toán ở đây không nằm ở việc container có start được hay không, mà ở việc client và các broker khác có nhìn thấy đúng endpoint để kết nối hay không.

Một cluster KRaft triển khai bằng Docker thường phải xử lý đồng thời ba lớp giao tiếp:

• Listener cho client bên ngoài container
• Listener nội bộ giữa các broker
• Listener dành cho controller quorum

Nếu ba luồng này không được tách bạch rõ, cluster có thể khởi động nhưng client sẽ timeout, hoặc broker giao tiếp được nội bộ nhưng UI không kết nối đúng bootstrap server.

Trong môi trường lab, nhiều người dùng combined mode với broker,controller trên cùng một node vì dễ dựng. Điều này phù hợp cho development, POC hoặc demo. Nhưng khi đi vào production, kiến trúc thường tách controller quorum ra khỏi broker để giảm rủi ro và tăng khả năng kiểm soát. Apache Kafka cũng mô tả rõ việc cấu hình vai trò server thông qua process.roles, phản ánh mô hình này là một phần chính thức của KRaft architecture.

Một lỗi khá phổ biến khác là dùng image/tag quá chung chung hoặc phụ thuộc vào latest, dẫn tới thay đổi hành vi khi version mới phát hành. Với Kafka, đây là điều nên tránh. KRaft gắn chặt với behavior của metadata version và quy trình upgrade, nên việc pin version cụ thể luôn an toàn hơn deployment mơ hồ.

Docker Compose cho KRaft nên được nhìn như môi trường mô phỏng kiến trúc

Nhiều người tiếp cận Docker Compose như một cách “chạy Kafka cho nhanh”, nhưng nếu muốn học đúng về KRaft thì compose file nên phản ánh rõ topology của cluster.

Một compose tốt cho KRaft không chỉ liệt kê container, mà phải thể hiện được các yếu tố:

• Node ID của từng broker/controller
• Quorum voters cho controller
• Listener map theo đúng vai trò
• Advertised listener phù hợp với hướng truy cập
• Volume tách biệt để giữ metadata và log
• Network nội bộ ổn định cho broker-to-broker communication

Khi thêm Kafka UI vào cùng stack, bootstrap server mà UI sử dụng nên là địa chỉ nội bộ trong Docker network, không nên lẫn với endpoint public map ra host nếu không thật sự cần. Đây là điểm nhỏ nhưng ảnh hưởng lớn đến tính ổn định của lab environment.

Nói cách khác, Docker Compose không chỉ là file chạy dịch vụ. Với Kafka KRaft, nó chính là bản mô hình hóa control plane và data plane ở quy mô nhỏ.

KRaft đã sẵn sàng cho production chưa?

Nếu xét theo tài liệu chính thức, câu trả lời là có, nhưng cần hiểu đúng phạm vi. Apache Kafka nêu rõ KRaft được xem là production-ready cho new clusters từ 3.3.x và Kafka 4.0 trở lên chỉ còn hỗ trợ KRaft mode. Điều này cho thấy về mặt định hướng nền tảng, KRaft không còn là tính năng bên lề nữa.

Tuy nhiên, production-ready không có nghĩa là mọi cụm hiện hữu nên chuyển đổi ngay lập tức mà không đánh giá. Với hệ thống đang chạy ZooKeeper lâu năm, thách thức nằm ở migration plan, kiểm thử compatibility, rollout strategy và quy trình rollback. Đặc biệt ở các cụm có nhiều ACL, connector, stream app hoặc phụ thuộc vào quy trình vận hành cũ, việc chuyển đổi phải được coi là một dự án kỹ thuật độc lập chứ không phải một thao tác đổi cấu hình đơn giản.

Vì thế, với cluster mới, KRaft là hướng triển khai nên ưu tiên. Còn với cluster cũ, trọng tâm không phải là “có nên chuyển không”, mà là “chuyển theo lộ trình nào để không làm gián đoạn hệ thống”.

Tham khảo thêm dịch vụ Kafka: https://bizflycloud.vn/kafka

Khi nào nên tự dựng, khi nào nên dùng managed Kafka?

Tự dựng Kafka KRaft bằng Docker hoặc Kubernetes rất phù hợp khi đội kỹ thuật cần kiểm thử use case, xây lab environment hoặc kiểm soát sâu hạ tầng. Đây cũng là cách tốt để hiểu bản chất hoạt động của metadata quorum, listener topology và consumer behavior.

Nhưng khi đi vào production thực tế, bài toán không dừng ở việc cluster chạy được. Doanh nghiệp còn phải xử lý:

• Capacity planning
• HA và failover
• Bảo mật kết nối
• Backup và recovery
• Quan sát lag, throughput, disk usage
• Nâng cấp version
• Xử lý sự cố liên quan đến partition imbalance hoặc retention

Đó là lý do mô hình managed Kafka ngày càng được chọn nhiều hơn: đội phát triển tập trung vào event pipeline và ứng dụng, thay vì dành quá nhiều nguồn lực cho việc giữ cluster khỏe.

Kết luận

KRaft không chỉ là bản nâng cấp kỹ thuật của Kafka, mà là sự thay đổi nền tảng ở lớp điều phối cluster. Nó loại bỏ một dependency lịch sử, tinh gọn control plane và đưa Kafka tiến gần hơn tới mô hình triển khai phù hợp với hạ tầng hiện đại. Kafka UI, ở chiều ngược lại, không thay đổi lõi hệ thống nhưng cải thiện mạnh trải nghiệm vận hành, giúp cluster dễ quan sát và dễ xử lý hơn trong thực tế.

Nếu nhìn Kafka như một nền tảng streaming dành cho giai đoạn tăng trưởng tiếp theo của doanh nghiệp, thì KRaft là phần làm cho kiến trúc bền hơn, còn Kafka UI là phần làm cho hệ thống dễ vận hành hơn. Ghép hai mảnh này lại, chúng ta có một stack Kafka vừa hiện đại hơn về thiết kế, vừa thực dụng hơn trong khai thác hằng ngày.

Nguồn tham khảo: https://bizflycloud.vn/tin-tuc/kafka-kraft-mode-va-kafkaui-20260323154706524.htm