3.C4 LinkedIn：Kafka 分層叢集治理
LinkedIn 的 Kafka 分層叢集案例呈現了 Kafka 在規模化之後，瓶頸從「broker 容量」轉移到「workload 互相干擾」。分層的核心判斷是按業務風險隔離，把叢集當成資源治理單位。
業務背景
LinkedIn 是 Kafka 的誕生地，內部 Kafka 叢集承載的工作負載涵蓋即時推薦、搜尋索引更新、analytics pipeline、audit log 跟 monitoring。早期所有 workload 共用少數幾個大叢集，隨流量成長，叢集內不同 workload 的資源競爭開始互相影響。
LinkedIn 的 Kafka 規模是全球最大的之一 — 數千個 broker、每秒數百萬筆訊息、PB 級資料保留。在這個規模下，單一叢集的容量限制是 broker 數量跟 ZooKeeper 的 metadata 管理上限，但更早觸及的限制是 workload 之間的干擾。
技術挑戰
Noisy neighbor
即時推薦系統需要低延遲的 consumer（P99 < 50ms），analytics pipeline 是大量 batch consumer（高吞吐但延遲容忍到秒級）。兩者共用同一組 broker 時，batch consumer 的大範圍 sequential read 佔滿 disk I/O，擠壓即時推薦的 random read latency。
一個 analytics job 的重跑（backfill 歷史資料）可以讓推薦系統的 consumer lag 從毫秒跳到秒級。在共享叢集中，這種干擾難以預防 — 只能在事後發現、人工協調。
Broker 故障的影響面
單一叢集中 broker 故障會觸發 partition reassignment，reassignment 的資料搬移佔用 disk I/O 跟網路頻寬。在混合 workload 的叢集中，reassignment 同時影響所有 workload 的效能 — 包括跟故障 broker 無直接關係的 topic。
叢集越大、topic 越多、reassignment 的影響面越廣。
容量規劃的模糊邊界
共享叢集的容量規劃沒有清楚的 owner — analytics 團隊說「我們需要更多 retention」、推薦團隊說「我們需要更低 latency」、audit 團隊說「我們的資料不能丟」。三種需求各自合理，但共享叢集無法同時最佳化。
解法：分層叢集
LinkedIn 按業務風險跟效能需求把 workload 分配到不同叢集：
Tier 1 — 即時關鍵路徑：即時推薦、搜尋索引更新、使用者通知。Broker 配置偏向低延遲（SSD、高 IOPS）、replication factor 3、retention 短（保留足夠的 consumer catchup 時間）。
Tier 2 — 可靠性要求高但延遲容忍：audit log、合規事件、支付事件。配置偏向持久性（replication factor 3、min.insync.replicas 2、acks=all）、retention 長。
Tier 3 — 高吞吐分析：analytics pipeline、ETL、batch processing。配置偏向吞吐（大 batch size、長 linger.ms、HDD）、retention 最長、容忍偶發 consumer lag。
分層的判準
分層的判準是「這個 workload 故障時，業務影響有多大、多快」：
- 即時影響使用者體驗 → Tier 1
- 影響合規或財務但可容忍分鐘級延遲 → Tier 2
- 影響分析準確性但可容忍小時級延遲 → Tier 3
取捨
| 面向 | 共享叢集 | 分層叢集 |
|---|---|---|
| 資源利用率 | 高（所有 workload 共用資源池） | 低到中（每層有獨立的保留容量） |
| 隔離性 | 低（noisy neighbor 互相干擾） | 高（故障跟效能退化限制在同層） |
| 運維複雜度 | 低（一組 broker 統一管理） | 高（多組 broker、各自的監控跟維護） |
| 容量規劃清晰度 | 模糊（多種需求混合、難以歸因） | 清楚（每層的需求跟 owner 明確） |
| 故障影響面 | 廣（reassignment 影響所有 topic） | 有限（reassignment 只影響同層） |
分層的成本是資源利用率下降 — 每層都需要保留一定的 headroom 應對高峰，加總起來比共享叢集多。LinkedIn 的判斷是隔離性的價值大於利用率的損失 — 推薦系統一次 P99 退化的業務損失遠大於多幾台 broker 的成本。
回寫教材的連結
- 3.1 broker basics：broker 配置怎麼影響延遲 vs 吞吐 vs 持久性的取捨。
- 6.14 dependency reliability budget：不同 tier 的 Kafka 叢集各自有不同的 reliability budget。
- 3.4 consumer design：batch consumer 跟 real-time consumer 的資源消耗差異。
判讀徵兆
讀者在自己的系統看到以下訊號時，應該回讀本案例：
- 即時消費者的 consumer lag 因為同叢集的 batch job 而上升
- Broker 故障後的 partition reassignment 影響到跟故障無關的 topic
- 容量規劃會議中不同團隊的需求互相矛盾、無法在同一組配置中滿足
- Kafka 叢集的 topic 數量超過 500 個、workload 類型超過三種