Cách triển khai Kafka Cluster production từ A-Z
Kafka Cluster giúp doanh nghiệp xử lý dữ liệu thời gian thực ổn định hơn nhờ mô hình nhiều broker, replication và khả năng mở rộng theo tải. Bài viết này Bizfly Cloud sẽ giải thích cách Kafka Cluster hoạt động, các cấu hình quan trọng khi triển khai production và khi nào nên tự dựng hoặc sử dụng Managed Kafka để giảm gánh nặng vận hành.
Kafka Cluster là gì?
Kafka Cluster là cụm gồm nhiều Kafka broker hoạt động cùng nhau để lưu trữ, phân phối và xử lý dữ liệu dạng event. Mỗi broker trong cluster chịu trách nhiệm lưu một phần dữ liệu của các topic. Khi một topic được chia thành nhiều partition, các partition này có thể nằm trên nhiều broker khác nhau để tăng khả năng ghi, đọc và xử lý song song.
Trong một Kafka Cluster, dữ liệu không chỉ được lưu trên một broker duy nhất. Với các topic quan trọng, mỗi partition thường có nhiều bản sao, gọi là replica. Một replica đóng vai trò leader để nhận request đọc/ghi, các replica còn lại đóng vai trò follower và sao chép dữ liệu từ leader. Nếu broker chứa leader gặp sự cố, Kafka có thể bầu một replica khác làm leader mới để tiếp tục phục vụ hệ thống.
>> Xem thêm: Kafka là gì? Tổng quan kiến trúc và cách Apache Kafka hoạt động
Có thể hiểu ngắn gọn:
| Thành phần | Vai trò |
|---|---|
| Broker | Máy chủ Kafka lưu trữ và phục vụ dữ liệu |
| Cluster | Cụm nhiều broker phối hợp với nhau |
| Topic | Luồng dữ liệu logic, ví dụ order_created, payment_success |
| Partition | Phần chia nhỏ của topic để xử lý song song |
| Replica | Bản sao của partition trên broker khác |
| Leader | Replica chính nhận request đọc/ghi |
| Follower | Replica sao chép dữ liệu từ leader |
| Consumer group | Nhóm consumer cùng đọc và xử lý dữ liệu song song |
Kafka Cluster thường được dùng trong các hệ thống event-driven architecture, log streaming, realtime analytics, đồng bộ dữ liệu giữa nhiều hệ thống, xử lý giao dịch thời gian thực hoặc xây dựng data pipeline.
Mô hình Kafka Cluster mẫu
Trong bài viết này, mô hình triển khai mẫu gồm 3 server Kafka. Đây là mô hình tối thiểu thường được dùng để minh họa cluster production vì có thể hỗ trợ replication và chịu lỗi tốt hơn broker đơn lẻ.
| Node | IP minh họa | Vai trò |
|---|---|---|
| kafka-01 | 192.168.1.121 | broker, controller |
| kafka-02 | 192.168.1.122 | broker, controller |
| kafka-03 | 192.168.1.123 | broker, controller |
Các port cần mở giữa các node:
| Port | Mục đích |
|---|---|
9092 | Client kết nối tới Kafka broker |
9093 | Controller quorum trong KRaft |
9000 | Kafdrop UI, nếu sử dụng |
Trong môi trường thực tế, địa chỉ IP, hostname, port, disk path và cấu hình bảo mật cần được điều chỉnh theo hạ tầng của doanh nghiệp. Không nên copy nguyên cấu hình mẫu vào production nếu chưa kiểm tra network, firewall, storage, quyền truy cập và mô hình bảo mật.
Vì sao nên dùng KRaft thay vì ZooKeeper?
Các bài hướng dẫn Kafka Cluster cũ thường dùng ZooKeeper để quản lý metadata và điều phối cluster. Tuy nhiên, với Kafka hiện đại, hướng triển khai mới nên ưu tiên KRaft.
KRaft là cơ chế quản lý metadata mới của Kafka, thay thế ZooKeeper. Trong KRaft mode, Kafka dùng controller quorum để quản lý metadata, trạng thái broker, partition leader và quá trình điều phối cluster. Apache Kafka 4.0 đã vận hành hoàn toàn không cần ZooKeeper và chạy KRaft mặc định, giúp giảm độ phức tạp khi triển khai và quản trị cluster Apache Kafka 4.0 Release.
Vì vậy, nếu bạn triển khai Kafka Cluster mới, đặc biệt trong giai đoạn 2026 trở đi, ZooKeeper chỉ nên được nhắc như mô hình legacy. Với hệ thống mới, nên dùng KRaft ngay từ đầu.
| Tiêu chí | ZooKeeper legacy | KRaft hiện đại |
|---|---|---|
| Quản lý metadata | Qua ZooKeeper ensemble | Bên trong Kafka |
| Thành phần vận hành | Kafka + ZooKeeper | Kafka controller quorum |
| Độ phức tạp | Cao hơn | Gọn hơn |
| Phù hợp | Hệ thống Kafka cũ | Cluster mới, production hiện đại |
| Kafka 4.x | Không còn là hướng chính | Mặc định |
Chuẩn bị môi trường trước khi cài Kafka Cluster
Trước khi cài đặt Kafka, cần chuẩn bị hạ tầng đủ ổn định. Với production, không nên chỉ quan tâm tới số lượng server, mà cần kiểm tra cả CPU, RAM, disk, network, firewall và đồng bộ thời gian giữa các node.
Yêu cầu tham khảo cho mỗi node:
| Hạng mục | Khuyến nghị |
|---|---|
| CPU | Tối thiểu 2 vCPU, production nên tính theo throughput |
| RAM | Tối thiểu 4GB, workload lớn cần cao hơn |
| Disk | SSD hoặc disk có IOPS ổn định |
| Network | Kết nối ổn định giữa các broker |
| OS | Linux server |
| Java | Kafka 4.x broker/tools yêu cầu Java 17 |
| Time sync | Nên bật NTP/chrony để đồng bộ thời gian |
Cần kiểm tra trước các điểm sau:
- Các node ping được nhau.
- Port
9092và9093không bị firewall chặn. - Hostname hoặc IP được khai báo nhất quán.
- Java đã được cài đặt đúng phiên bản.
- Thư mục lưu dữ liệu Kafka có đủ dung lượng.
- Disk dùng cho Kafka nên tách rõ với disk hệ điều hành nếu workload lớn.
- Người vận hành có quyền đọc log, restart service và kiểm tra tiến trình.
Kiểm tra Java:
java -version
Nếu dùng Kafka 4.x, broker, Kafka Connect và tools yêu cầu Java 17 theo thông tin từ Apache Kafka 4.0 release Apache Kafka 4.0 Release.
Bước 1: Tải và giải nén Apache Kafka
Trên cả 3 node, tải Apache Kafka từ trang chính thức, sau đó giải nén vào thư mục cài đặt. Ví dụ:
tar -xzf kafka_<scala-version>-<kafka-version>.tgz sudo mv kafka_<scala-version>-<kafka-version> /opt/kafka
Tạo thư mục lưu dữ liệu Kafka:
sudo mkdir -p /data/kafka sudo chown -R kafka:kafka /data/kafka
Trong production, thư mục /data/kafka nên đặt trên disk có dung lượng và hiệu năng phù hợp. Nếu retention dài, message lớn hoặc số topic nhiều, disk rất dễ trở thành điểm nghẽn.
Bước 2: Cấu hình Kafka Cluster bằng KRaft
Trong KRaft mode, mỗi node cần có node.id riêng. Đồng thời, tất cả node phải biết danh sách controller tham gia quorum thông qua cấu hình controller.quorum.voters.
Ví dụ cấu hình trên kafka-01:
process.roles=broker,controller node.id=1 controller.quorum.voters=1@192.168.1.121:9093,2@192.168.1.122:9093,3@192.168.1.123:9093 listeners=PLAINTEXT://192.168.1.121:9092,CONTROLLER://192.168.1.121:9093 advertised.listeners=PLAINTEXT://192.168.1.121:9092 controller.listener.names=CONTROLLER listener.security.protocol.map=CONTROLLER:PLAINTEXT,PLAINTEXT:PLAINTEXT log.dirs=/data/kafka num.partitions=3 default.replication.factor=3 min.insync.replicas=2
Trên kafka-02, đổi node.id và IP tương ứng:
process.roles=broker,controller node.id=2 controller.quorum.voters=1@192.168.1.121:9093,2@192.168.1.122:9093,3@192.168.1.123:9093 listeners=PLAINTEXT://192.168.1.122:9092,CONTROLLER://192.168.1.122:9093 advertised.listeners=PLAINTEXT://192.168.1.122:9092 controller.listener.names=CONTROLLER listener.security.protocol.map=CONTROLLER:PLAINTEXT,PLAINTEXT:PLAINTEXT log.dirs=/data/kafka num.partitions=3 default.replication.factor=3 min.insync.replicas=2
Trên kafka-03, đổi node.id và IP tương ứng:
process.roles=broker,controller node.id=3 controller.quorum.voters=1@192.168.1.121:9093,2@192.168.1.122:9093,3@192.168.1.123:9093 listeners=PLAINTEXT://192.168.1.123:9092,CONTROLLER://192.168.1.123:9093 advertised.listeners=PLAINTEXT://192.168.1.123:9092 controller.listener.names=CONTROLLER listener.security.protocol.map=CONTROLLER:PLAINTEXT,PLAINTEXT:PLAINTEXT log.dirs=/data/kafka num.partitions=3 default.replication.factor=3 min.insync.replicas=2
Các cấu hình quan trọng cần hiểu:
| Cấu hình | Ý nghĩa |
|---|---|
process.roles | Xác định node đóng vai trò broker, controller hoặc cả hai |
node.id | ID duy nhất của từng node trong cluster |
controller.quorum.voters | Danh sách controller tham gia quorum |
listeners | Địa chỉ Kafka lắng nghe kết nối |
advertised.listeners | Địa chỉ client dùng để kết nối tới broker |
controller.listener.names | Listener dùng cho controller |
log.dirs | Thư mục Kafka lưu dữ liệu |
num.partitions | Số partition mặc định khi tạo topic |
default.replication.factor | Số replica mặc định cho topic |
min.insync.replicas | Số replica tối thiểu phải đồng bộ khi ghi dữ liệu an toàn |
Trong môi trường production, không nên dùng PLAINTEXT cho kết nối qua mạng không tin cậy. Cần cấu hình TLS/SASL và ACL để bảo vệ dữ liệu, tài khoản và quyền truy cập topic.
Bước 3: Khởi tạo Cluster ID và format storage
Trước khi start Kafka ở KRaft mode, cần tạo Cluster ID. Chạy lệnh sau trên một node bất kỳ:
/opt/kafka/bin/kafka-storage.sh random-uuid
Kết quả trả về là một chuỗi UUID. Dùng cùng Cluster ID này để format storage trên cả 3 node:
/opt/kafka/bin/kafka-storage.sh format \ -t <cluster-id> \ -c /opt/kafka/config/kraft/server.properties
Lưu ý: Cluster ID phải giống nhau trên tất cả node trong cùng cluster. Nếu mỗi node format bằng một Cluster ID khác nhau, các broker sẽ không tham gia đúng vào cùng một cluster.
Bước 4: Start Kafka Broker
Sau khi format storage, start Kafka trên từng node:
/opt/kafka/bin/kafka-server-start.sh -daemon /opt/kafka/config/kraft/server.properties
Kiểm tra tiến trình:
ps aux | grep kafka
Kiểm tra log Kafka nếu broker không start được:
tail -f /opt/kafka/logs/server.log
Một số lỗi thường gặp ở bước này:
| Lỗi | Nguyên nhân thường gặp |
|---|---|
| Broker không join cluster | Sai node.id, sai controller.quorum.voters hoặc firewall chặn port 9093 |
| Client không kết nối được | Sai advertised.listeners hoặc port 9092 chưa mở |
| Broker start rồi dừng | Sai quyền thư mục log.dirs hoặc Cluster ID không khớp |
| Controller election lỗi | Các node controller không nhìn thấy nhau |
Bước 5: Tạo topic để kiểm tra cluster
Sau khi broker đã chạy, tạo một topic test với 3 partition và replication factor 3:
/opt/kafka/bin/kafka-topics.sh \ --create \ --bootstrap-server 192.168.1.121:9092 \ --topic order-created \ --partitions 3 \ --replication-factor 3
Kiểm tra topic:
/opt/kafka/bin/kafka-topics.sh \ --describe \ --bootstrap-server 192.168.1.121:9092 \ --topic order-created
Kết quả cần chú ý các thông tin:
| Trường | Ý nghĩa |
|---|---|
Partition | ID của partition |
Leader | Broker đang làm leader của partition |
Replicas | Danh sách broker đang giữ bản sao |
Isr | Các replica đang đồng bộ với leader |
Nếu topic có replication factor 3, phần Replicas nên có 3 broker. Nếu Isr thiếu broker, nghĩa là có replica chưa đồng bộ hoặc broker đang gặp vấn đề.
Bước 6: Test producer và consumer
Tạo producer để gửi message vào topic:
/opt/kafka/bin/kafka-console-producer.sh \ --bootstrap-server 192.168.1.121:9092 \ --topic order-created
Nhập thử một vài message:
order_id=1001,status=created order_id=1002,status=created order_id=1003,status=created
Mở terminal khác và chạy consumer:
/opt/kafka/bin/kafka-console-consumer.sh \ --bootstrap-server 192.168.1.122:9092 \ --topic order-created \ --from-beginning
Nếu consumer đọc được dữ liệu, nghĩa là luồng ghi và đọc cơ bản đã hoạt động. Tuy nhiên, test này mới xác nhận Kafka chạy được, chưa đủ để kết luận cluster đã sẵn sàng production.
Bước 7: Kiểm tra replication, leader và ISR
Replication là phần quan trọng nhất khi triển khai Kafka Cluster production. Nếu replication hoạt động không đúng, broker lỗi có thể làm gián đoạn dịch vụ hoặc tăng nguy cơ mất dữ liệu.
Chạy lệnh describe topic:
/opt/kafka/bin/kafka-topics.sh \ --describe \ --bootstrap-server 192.168.1.121:9092 \ --topic order-created
Ví dụ kết quả:
Topic: order-created Partition: 0 Leader: 1 Replicas: 1,2,3 Isr: 1,2,3 Topic: order-created Partition: 1 Leader: 2 Replicas: 2,3,1 Isr: 2,3,1 Topic: order-created Partition: 2 Leader: 3 Replicas: 3,1,2 Isr: 3,1,2
Kết quả này cho thấy:
- Topic có 3 partition
- Mỗi partition có 3 replica
- Leader được phân bổ trên các broker khác nhau
- ISR đầy đủ, nghĩa là các replica đang đồng bộ
Nếu Isr chỉ còn 1 broker trong khi replication factor là 3, cần kiểm tra ngay broker bị lỗi, network, disk hoặc replication lag. Trong production, under-replicated partition là tín hiệu rủi ro lớn.
Bước 8: Kiểm tra consumer group và consumer lag
Consumer lag cho biết consumer đang xử lý chậm hơn tốc độ dữ liệu được ghi vào Kafka bao nhiêu. Đây là một trong những chỉ số quan trọng nhất khi vận hành Kafka.
Tạo consumer group:
/opt/kafka/bin/kafka-console-consumer.sh \ --bootstrap-server 192.168.1.121:9092 \ --topic order-created \ --group inventory-service \ --from-beginning
Kiểm tra trạng thái consumer group:
/opt/kafka/bin/kafka-consumer-groups.sh \ --bootstrap-server 192.168.1.121:9092 \ --describe \ --group inventory-service
Các trường cần chú ý:
| Trường | Ý nghĩa |
|---|---|
CURRENT-OFFSET | Offset consumer đã đọc tới |
LOG-END-OFFSET | Offset mới nhất trong partition |
LAG | Số message consumer còn xử lý chậm |
CONSUMER-ID | Consumer đang xử lý partition |
HOST | Máy đang chạy consumer |
Nếu lag tăng liên tục, nguyên nhân không nhất thiết nằm ở Kafka broker. Vấn đề có thể đến từ consumer xử lý chậm, database phía sau bị nghẽn, logic xử lý chưa tối ưu, số partition quá ít hoặc consumer group chưa được scale đúng cách.
Bước 9: Cài Kafdrop UI để quan sát Kafka Cluster
Kafdrop là giao diện web giúp quan sát Kafka Cluster, topic, partition, consumer group và message. Công cụ này phù hợp để kiểm tra nhanh trong môi trường dev, staging hoặc nội bộ.
Ví dụ chạy Kafdrop bằng Docker:
docker run -d \ --name kafdrop \ -p 9000:9000 \ -e KAFKA_BROKERCONNECT=192.168.1.121:9092,192.168.1.122:9092,192.168.1.123:9092 \ obsidiandynamics/kafdrop
Sau đó truy cập:
http://<server-ip>:9000
Kafdrop giúp kiểm tra nhanh:
- Danh sách topic
- Số partition của từng topic
- Consumer group
- Offset và lag
- Message trong topic
- Broker trong cluster
Tuy nhiên, không nên coi Kafdrop là hệ thống monitoring production đầy đủ. Với production, cần thêm Prometheus, Grafana, Kafka Exporter, JMX Exporter hoặc công cụ giám sát tương đương để theo dõi metric, cảnh báo và xu hướng tải dài hạn.
Checklist cấu hình Kafka Cluster production
Một Kafka Cluster chạy được chưa chắc đã sẵn sàng production. Trước khi đưa vào vận hành, cần kiểm tra các nhóm cấu hình sau.
| Nhóm | Cần kiểm tra |
|---|---|
| Broker | Số broker, node.id, listener, advertised listener |
| Replication | default.replication.factor, topic replication factor |
| Durability | acks=all, min.insync.replicas, producer retry |
| Partition | Số partition theo throughput và số consumer |
| Storage | Disk usage, retention, segment size, I/O throughput |
| Network | Băng thông client traffic và replication traffic |
| Security | TLS/SASL, ACL, phân quyền topic |
| Monitoring | Consumer lag, under-replicated partitions, request latency |
| Alerting | Cảnh báo broker down, offline partition, disk gần đầy |
| Backup/DR | Chính sách phục hồi, multi-AZ, replication liên vùng nếu cần |
Với dữ liệu quan trọng, một cấu hình thường gặp là replication factor 3, min.insync.replicas=2 và producer dùng acks=all. Cách này giúp giảm rủi ro mất dữ liệu khi một broker lỗi. Đổi lại, độ trễ ghi có thể cao hơn so với cấu hình ưu tiên tốc độ.
Kafka luôn cần được thiết kế theo trade-off. Hệ thống thanh toán, đơn hàng hoặc giao dịch tài chính thường ưu tiên độ bền dữ liệu. Hệ thống tracking hành vi hoặc log có thể ưu tiên throughput và chấp nhận mất một phần nhỏ dữ liệu trong một số trường hợp.
Các lỗi thường gặp khi triển khai Kafka Cluster
Khi dựng Kafka Cluster, nhiều lỗi không nằm ở Kafka mà nằm ở cấu hình network, listener hoặc cách hiểu sai về replication.
| Vấn đề | Nguyên nhân thường gặp | Cách xử lý |
|---|---|---|
| Client không kết nối được broker | Sai advertised.listeners | Đặt IP/hostname mà client thật sự truy cập được |
| Broker không join cluster | Sai controller.quorum.voters hoặc firewall | Kiểm tra IP, port 9093, log controller |
| Topic tạo không đủ replica | Số broker ít hơn replication factor | Tăng broker hoặc giảm replication factor |
| ISR bị thiếu | Broker chậm, disk nghẽn, network lỗi | Kiểm tra broker log, disk I/O, network |
| Consumer lag tăng | Consumer xử lý chậm hoặc partition quá ít | Scale consumer, tối ưu xử lý, tăng partition nếu phù hợp |
| Disk đầy nhanh | Retention dài, message lớn, topic nhiều | Điều chỉnh retention, compression, dung lượng disk |
| Rebalance liên tục | Consumer restart, session timeout chưa hợp lý | Kiểm tra consumer config và độ ổn định ứng dụng |
Một điểm rất hay bị bỏ qua là advertised.listeners. Đây là địa chỉ broker “quảng bá” cho client. Nếu cấu hình sai, broker vẫn chạy nhưng client bên ngoài không kết nối được hoặc kết nối chập chờn.
Khi nào nên tự dựng Kafka Cluster?
Tự dựng Kafka Cluster phù hợp khi doanh nghiệp có đội ngũ kỹ thuật đủ năng lực vận hành hạ tầng phân tán. Cách này cho phép kiểm soát sâu version Kafka, broker config, storage, network, bảo mật, monitoring và mô hình triển khai.
Tự dựng phù hợp nếu:
- Doanh nghiệp có DevOps/SRE hoặc data platform team
- Cần tùy biến sâu cấu hình Kafka
- Có yêu cầu hạ tầng riêng, network riêng hoặc compliance đặc thù
- Đội ngũ có khả năng xử lý sự cố broker, replication, lag và upgrade
- Có thời gian xây dựng monitoring, alerting và runbook vận hành
Tuy nhiên, chi phí vận hành Kafka không nhỏ. Ngoài việc cài đặt, đội ngũ kỹ thuật còn phải theo dõi broker, disk, network, replication, consumer lag, bảo mật, backup, version upgrade và khả năng mở rộng cluster.
Khi nào nên dùng Managed Kafka?
Managed Kafka phù hợp khi doanh nghiệp muốn dùng Kafka cho dữ liệu realtime nhưng không muốn tự quản lý toàn bộ hạ tầng bên dưới. Thay vì tự dựng broker, cấu hình storage, thiết lập monitoring và xử lý lỗi hạ tầng, doanh nghiệp có thể tập trung nhiều hơn vào producer, consumer, topic design và luồng dữ liệu nghiệp vụ.
Managed Kafka phù hợp với các bài toán:
- Log streaming từ nhiều hệ thống
- Event-driven architecture giữa các microservice
- Realtime analytics cho website, app, thương mại điện tử
- Đồng bộ dữ liệu giữa application, database và data warehouse
- Xử lý giao dịch, notification hoặc event nghiệp vụ theo thời gian thực
- Doanh nghiệp cần triển khai nhanh nhưng chưa có đội ngũ vận hành Kafka chuyên sâu
Với Bizfly Cloud Kafka, doanh nghiệp có thể triển khai Kafka Cluster nhanh hơn trên hạ tầng cloud, giảm gánh nặng quản trị broker, storage, monitoring và mở rộng tài nguyên. Đây là hướng phù hợp với các hệ thống cần xử lý dữ liệu realtime nhưng vẫn muốn tối ưu thời gian triển khai và chi phí vận hành.
Kết luận
Kafka Cluster là nền tảng quan trọng cho các hệ thống cần xử lý dữ liệu thời gian thực ở quy mô lớn. Tuy nhiên, triển khai Kafka production không chỉ là cài Kafka trên nhiều server. Người vận hành cần hiểu rõ broker, controller, listener, topic, partition, replication, ISR, consumer group, storage, network và monitoring để cluster hoạt động ổn định.
Với hệ thống mới, nên ưu tiên triển khai Kafka theo KRaft thay vì ZooKeeper để phù hợp với kiến trúc Kafka hiện đại. Nếu doanh nghiệp có đội ngũ kỹ thuật mạnh, tự dựng Kafka Cluster giúp kiểm soát sâu hạ tầng. Ngược lại, nếu mục tiêu là triển khai nhanh, giảm gánh nặng vận hành và tập trung vào luồng dữ liệu nghiệp vụ, Managed Kafka như Bizfly Cloud Kafka sẽ là lựa chọn đáng cân nhắc.
FAQ về Kafka Cluster
Kafka Cluster cần tối thiểu mấy broker?
Môi trường test có thể dùng 1 broker. Production thường nên bắt đầu từ 3 broker để hỗ trợ replication và chịu lỗi tốt hơn.
Kafka Cluster có cần ZooKeeper không?
Với Kafka hiện đại, đặc biệt Kafka 4.0 trở lên, Kafka chạy bằng KRaft và không còn cần ZooKeeper. ZooKeeper chỉ còn liên quan đến các hệ thống Kafka cũ.
Replication factor trong Kafka là gì?
Replication factor là số bản sao của mỗi partition. Replication factor 3 nghĩa là mỗi partition có 3 replica nằm trên các broker khác nhau.
ISR trong Kafka là gì?
ISR là viết tắt của In-Sync Replicas, tức các replica đang đồng bộ với leader. Nếu ISR bị thiếu, cluster có thể đang gặp vấn đề về broker, disk, network hoặc replication.
Thêm broker có làm Kafka nhanh hơn không?
Có thể, nhưng không phải lúc nào cũng vậy. Nếu bottleneck nằm ở consumer, database phía sau, số partition, disk hoặc network, cần xử lý đúng điểm nghẽn thay vì chỉ thêm broker.
Có nên tự dựng Kafka Cluster không?
Nên tự dựng nếu doanh nghiệp có đội ngũ DevOps/SRE đủ năng lực vận hành. Nếu muốn triển khai nhanh, giảm gánh nặng quản trị và tập trung vào ứng dụng, Managed Kafka sẽ phù hợp hơn.
