Scaling StreamHub: Transitioning from Kinesis to Kafka for 145 Billion Daily Events

Atlassian · 2026 · 3. Quy mô lớn · Độ khó: Nâng cao — bài gốc

Bối cảnh

StreamHub là event bus của Atlassian (click, impression, API call, CDC, telemetry). Đã có trong wiki ở vai trò nền tảng cho Jira realtime năm 2019 (Atlassian 2019).
Từ khoảng 22 tỷ event/ngày lên 150 tỷ event nhận và hơn 225 tỷ event giao mỗi ngày (2026), trung bình khoảng 1,68 triệu event/giây, đỉnh hơn 3,2 triệu.
Kinesis ("zero ops") phục vụ tốt tới khoảng 20–30 tỷ event/ngày. Khi phải tăng 5 lần, nó lộ giới hạn:
- throttling lúc spike, khó vượt 99,99% (mục tiêu 99,999%);
- giá theo số shard (mỗi shard 1 MB/s vào, 2 MB/s ra) nên hoá đơn tăng tuyến tính theo traffic; on-demand quá đắt ở quy mô này;
- giữ dữ liệu quá 24 giờ phải trả thêm (muốn giữ 7 ngày để replay);
- nhiều consumer group chia chung băng thông ra của shard; Enhanced Fan-Out thì đắt.

Chuyển sang Kafka qua AWS MSK (managed) để một team platform nhỏ tập trung vào kiến trúc, client library, độ tin cậy.
Tiered Storage: tầng local (EBS) chỉ giữ 5 phút dữ liệu nóng; segment đã đóng đẩy bất đồng bộ lên S3, giữ 7 ngày. Consumer đã trễ quá 5 phút thì chịu thêm vài trăm ms là chấp nhận được. Giảm mạnh chi phí và backfill không còn tranh IOPS với consumer realtime.

Giới hạn mạng của broker quan trọng hơn CPU: replication, fan-out, relay xuyên region, retry, copy lên S3 đều cộng vào. Broker nhỏ nhận dữ liệu nhanh hơn tốc độ nó replicate và offload được, nên đĩa local đầy dần.
Tiered storage vẫn cần headroom local: copy lên S3 chậm lại thì đĩa local tăng tuyến tính.
Giới hạn request rate của S3: tăng retention từ 7 lên 21 ngày để điều tra rồi giảm lại tạo một cơn bão delete, làm chậm ghi lên S3, đĩa local tăng nhanh.
Cooldown khi mở rộng storage: thêm đĩa lần đầu quá ít thì phải chờ hết cooldown mới thêm tiếp, kéo dài sự cố.
Control plane của dịch vụ managed: khi một AZ suy giảm, control plane báo trạng thái sai và chặn mọi thay đổi (reboot broker, scale, thêm đĩa) đúng lúc cần nhất.
Scale chậm và không đối xứng: đĩa chỉ tăng được không giảm được; nâng instance là rolling restart khoảng 15 phút/broker; broker mới không đỡ được topic nóng cho tới khi rebalance (mà rebalance lại thêm tải).

Lập kế hoạch năng lực theo broker nóng nhất, không theo trung bình cụm; giữ CPU dưới ngưỡng thận trọng; coi headroom là tính năng độ tin cậy, không phải lãng phí.
Scale theo bội số AZ; cân lại partition và leader liên tục.
Đổi retention như một thao tác production rủi ro: segment lớn hơn, ít hơn; giãn thay đổi; đủ buffer đĩa.
Rate limit và quarantine ở API ingest: giới hạn động theo tenant, topic, producer, loại traffic; traffic lỗi lặp lại thì đưa sang đường giữ an toàn thay vì retry mãi trên đường nóng.
Client quota của Kafka (producer_byte_rate, consumer_byte_rate) để một pipeline cấu hình sai không chiếm hết băng thông broker. Theo Atlassian, quota là kiểm soát blast radius, không chỉ là kiểm soát chi phí.
Shard nhiều cụm + runbook failover cluster: chuyển shard (khoảng 15 phút), song song dựng cụm sạch từ IaC (khoảng 2 giờ), quá ngưỡng thì chuyển hẳn producer và consumer sang. Lối thoát không phụ thuộc control plane đang hỏng.
Companion region: cặp region được duyệt trước trong cùng ranh giới data residency để failover mà không vi phạm cam kết.

Dịch vụ managed bỏ được việc vận hành hằng ngày nhưng không bỏ được giới hạn; giá theo shard có thể thành lý do rời đi (Chi phí hạ tầng và build vs buy).
Tách lưu trữ nóng/lạnh để giảm chi phí, nhưng phần nóng vẫn phải có chỗ đệm.
Kế hoạch phục hồi phải tính trường hợp control plane của nhà cung cấp không dùng được (Độ tin cậy và multi-region).
Rate limit, quota và quarantine là công cụ độ tin cậy, đặt càng gần producer càng tốt (Load shedding, rate limit và backpressure).