Mở hóa đơn AWS của cluster Kafka lên và nhìn kỹ. Phần lớn tiền không nằm ở EC2. Nó nằm ở hai dòng ít ai để ý: cross-AZ data transfer và EBS. Một cluster ba broker trải trên ba availability zone, replication factor 3, nghĩa là mỗi byte producer ghi vào sẽ được chép qua ranh giới AZ ít nhất hai lần — và cloud provider tính tiền cả chiều đi lẫn chiều về. Với workload vài trăm MB/s, khoản này dễ dàng gấp nhiều lần tiền compute.
Đó là lý do KIP-1150 "Diskless Topics" — được cộng đồng Kafka chấp nhận tháng 3/2026 — là thay đổi kiến trúc lớn nhất của Kafka kể từ KRaft. Không phải vì nó thêm tính năng. Vì nó đổi chỗ đặt tiền.
Vì sao Kafka trên cloud đắt ở chỗ không ngờ
Kafka được thiết kế năm 2011 cho datacenter tự vận hành: đĩa rẻ, băng thông nội bộ miễn phí. Kiến trúc replication của nó — leader nhận write, follower kéo về, ISR xác nhận — hoàn toàn hợp lý trong bối cảnh đó.
Mang nguyên kiến trúc này lên cloud, ba giả định sụp đổ:
- Băng thông cross-AZ không miễn phí. Producer ở AZ-a ghi vào leader ở AZ-b: tính tiền. Leader replicate sang follower ở AZ-c: tính tiền tiếp. Consumer ở AZ khác đọc: lại tính tiền.
- Đĩa gắn với broker. Muốn thêm throughput phải thêm broker, thêm broker phải rebalance partition — với cluster lớn, một lần rebalance kéo dài nhiều giờ, trong lúc đó cluster chạy trong trạng thái nửa vời.
- Hot partition là drama thường trực. Một partition nóng ghim vào một broker cụ thể vì data nằm trên đĩa của broker đó. Không thể "san tải" mà không di chuyển dữ liệu.
Trong khi đó, S3 và các object storage tương đương đã có sẵn thứ Kafka tự xây bằng replication: durability 11 số 9, replicate xuyên AZ, và — điểm mấu chốt — không tính tiền cross-AZ khi ghi/đọc trong cùng region.
KIP-1150 làm gì
Ý tưởng thẳng thừng: với topic được đánh dấu diskless, broker không ghi log ra đĩa local nữa. Batch từ producer được gom lại và ghi thẳng vào object storage. Replication biến mất — object storage tự lo. Đĩa của broker chỉ còn hai việc: cache đọc và metadata KRaft.
graph LR
P[Producer] --> B1[Broker bất kỳ<br/>stateless với topic diskless]
B1 -->|batch + commit| S3[(Object Storage<br/>S3 / GCS / Azure Blob)]
S3 --> B2[Broker khác<br/>cache đọc]
B2 --> C[Consumer]
K[KRaft metadata<br/>+ batch coordinator] -.-> B1
K -.-> B2
Hệ quả kiến trúc quan trọng hơn con số tiết kiệm:
- Broker trở nên gần như stateless với topic diskless. Leader không còn "sở hữu" data — bất kỳ broker nào cũng nhận write cho bất kỳ partition nào. Producer ghi vào broker cùng AZ với mình: cross-AZ traffic về gần zero.
- Scale theo giây, không theo giờ. Thêm broker không kéo theo di chuyển dữ liệu. Autoscale cluster Kafka theo traffic — điều trước đây gần như bất khả — thành chuyện bình thường.
- Hot partition hết là vấn đề của một máy. Data ở object storage, cache có thể dựng ở nhiều broker.
Con số ~80% tiết kiệm chi phí cloud mà cộng đồng đưa ra đến từ đúng chỗ này: xóa cross-AZ replication và thay EBS đắt bằng S3 rẻ.
Cái giá phải trả rõ ràng: độ trễ. Ghi vào object storage nghĩa là chờ gom batch rồi chờ S3 PUT xác nhận. End-to-end latency từ vài ms nhảy lên vài trăm ms đến hàng giây, tùy cấu hình batch. Đây không phải bug, đây là trade-off được chọn có chủ đích. Và vì diskless là thuộc tính per-topic, cùng một cluster có thể vừa chạy topic classic độ trễ thấp vừa chạy topic diskless giá rẻ.
Vendor đã chạy trước ba năm
KIP-1150 không phát minh mô hình này — nó chuẩn hóa thứ thị trường đã kiểm chứng:
| WarpStream | AutoMQ | Aiven (Inkless) | |
|---|---|---|---|
| Cách tiếp cận | Viết lại từ đầu, protocol-compatible, agent stateless | Fork Kafka, thay tầng storage bằng S3 + WAL | Đóng góp chính cho KIP-1150, chạy trên Kafka upstream |
| Độ tương thích | Protocol Kafka, không phải codebase Kafka | Giữ codebase Kafka, đổi storage engine | Kafka thật, theo upstream |
| Latency p99 | Cao nhất (thuần object storage, tối ưu chi phí) | Thấp hơn nhờ WAL đệm trước khi đẩy S3 | Phụ thuộc cấu hình batch, chấp nhận độ trễ giây |
| Rủi ro chính | Lock-in vào Confluent (đã mua lại) | Fork — theo kịp upstream đến đâu? | Chậm nhất về tính năng, nhưng an toàn nhất dài hạn |
Bức tranh streaming 2026 mà Kai Waehner tổng kết cũng xoay quanh trục này: cuộc cạnh tranh không còn là "ai có Kafka" mà là "ai chạy Kafka trên object storage tốt nhất". Việc KIP-1150 được chấp nhận đổi thế cờ — lợi thế độc quyền của vendor co lại thành lợi thế thời gian.
Mảnh ghép còn lại: diskless topic gặp lakehouse
Khi data Kafka đã nằm sẵn trên object storage, câu hỏi tự nhiên: sao không đọc nó như một bảng?
Đây là chỗ Confluent Tableflow (đã GA cho Iceberg và Delta) và xu hướng streaming-first lakehouse gặp nhau. Tableflow materialize topic thành bảng Iceberg tự động — schema, CDC, publish vào catalog — không cần pipeline Spark tự viết để "đổ Kafka xuống lake". Cộng với Iceberg V3 vừa có deletion vectors và row lineage, chuỗi CDC-từ-Kafka-thành-bảng-queryable rút từ ba hệ thống tự vá về một đường thẳng.
Với team data platform, đây là phần đáng tiền hơn cả khoản tiết kiệm hạ tầng: cả một lớp pipeline ETL Kafka-to-lake — thứ vẫn hỏng vào 2 giờ sáng — trở thành cấu hình.
Khung quyết định: chờ upstream hay đi với vendor
Câu hỏi thực tế không phải "diskless có tốt không" mà là "workload nào, thời điểm nào".
Bước 1 — phân loại topic theo độ nhạy latency:
- Chịu được latency giây: log aggregation, CDC ingest xuống lakehouse, clickstream, analytics feed, ML feature pipeline. Thường chiếm phần lớn throughput (và phần lớn hóa đơn).
- Phải giữ Kafka classic: matching engine, thanh toán, fraud detection realtime, mọi thứ có SLA p99 dưới ~100ms.
Bước 2 — soi hóa đơn. Nếu cross-AZ transfer + EBS dưới 30% tổng chi phí Kafka, hoặc cluster của bạn nhỏ, đừng làm gì cả. Độ phức tạp không đáng.
Bước 3 — chọn đường:
- Đau ngay bây giờ, hóa đơn sáu chữ số: đi với vendor. AutoMQ nếu muốn giữ tối đa tương thích codebase Kafka; WarpStream nếu đã trong hệ sinh thái Confluent và chấp nhận latency cao nhất.
- Đau nhưng chịu được 12–18 tháng: chờ upstream. KIP-1150 mới accepted 3/2026; từ accepted đến bản release production-ready cho topic quan trọng là chặng đường dài. Trong lúc chờ, việc hữu ích nhất là gắn label phân loại latency cho từng topic ngay từ bây giờ — để ngày migrate chỉ là đổi config.
- Đã dùng managed Kafka (MSK, Confluent Cloud, Aiven): ngồi yên. Áp lực cạnh tranh sẽ ép giá diskless xuống tận tay bạn, không cần tự migrate.
Kafka không chết, cũng chẳng bị thay thế. Nó vừa làm điều các hệ thống hạ tầng sống lâu vẫn làm: thừa nhận giả định phần cứng của năm 2011 đã hết hạn, và hy sinh thứ mình từng tự hào nhất — cái đĩa cứng — để giữ thứ quan trọng hơn: vị trí mặc định trong mọi kiến trúc dữ liệu. Từ giờ, trả tiền cross-AZ replication cho topic log và CDC không còn là chi phí vận hành. Nó là lựa chọn — và sẽ sớm là lựa chọn khó giải trình.