什麼情境下必須用 Kafka？

Kafka 的核心價值是 「解耦」 —— 對來源數據與下游消費端的時間、空間解耦。這帶來兩種典型的使用場景：

1. 一源多用

   • 例如一個交易事件，可能同時需要被記錄到資料庫、推送到監控系統、再送往實時推薦模型。
   • 若沒有 Kafka，每個下游都要直接與來源綁定，系統會變得僵硬且難以演進。

2. 高併發流量

   • 當事件量成長到秒級、甚至毫秒級吞吐時，傳統的 ETL 或簡單消息隊列（如 Redis Stream）很快會遇到瓶頸。
   • Kafka 提供 Partition 水平擴展，讓我們能透過 benchmark 驗證瓶頸與吞吐能力（可參考 OpenMessaging Benchmark）。

若你的需求只涉及單一來源與單一目的地，甚至對「順序性」與「持久化」沒有強烈要求，那麼 ETL 工具、Flink 實時串流、或 RabbitMQ、Redis Stream 都是更輕量的替代方案。

而在決定採用 Kafka 之後，接下來的挑戰就是「如何讓它穩定存在於基礎設施中」。
現今最常見、也最方便的方式，是直接在 Kubernetes 叢集上部署 Kafka，而這裡有兩個常見方案：

1. Strimzi Operator

   • Strimzi 提供了 Kafka 的原生 Operator，能透過 CRD（Custom Resource Definition）來管理整個 Kafka 集群。
   • 優點是與 Kubernetes 的生態整合度高，適合需要多環境、自動化、大規模管理的團隊。
   • 你可以把它理解為：Kafka 成為 Kubernetes 的一種「一等公民資源」。

2. Bitnami Kafka Chart

   • Bitnami 則以 Helm Chart 提供開箱即用的 Kafka 部署方案，安裝快速，學習曲線低。
   • 它特別適合小型團隊、PoC 或測試環境，能在短時間內啟動 Kafka，方便上手。
   • 若遇到進階需求，則需要自行撰寫額外的設定與維運流程。

簡單來說，Strimzi 強調全面自動化與一致性，Bitnami 則追求快速啟動與輕量靈活。
選擇哪一個方案，取決於團隊的規模、基礎設施成熟度，以及對維運效率的需求。

--

而無論選擇哪種部署方式，真正的挑戰往往不在「如何部屬」，而在於長期維運：如何追蹤 offset、如何監控消費延遲、如何確保 broker 在災難時能快速恢復。
接下來，我們就來談談 Kafka 在維運面向上的幾個關鍵考量。

維運考量：資源與網路

Kafka 雖然是分散式系統，但真正決定效能的，往往不是 Kafka 本身的程式碼，而是基礎資源的規劃。這一層看似直觀，卻是最常被忽略的，也是 SRE 或 Infra 團隊最需要優先關注的基石。

• 資源配置

  • Kafka 高度依賴 磁碟 I/O，效能瓶頸常常出現在儲存層，而不是 CPU 或記憶體。

  • 在雲端環境中，實際效能取決於 VM 晶片類型（e.g. N2, C2, M 系列） 搭配的 儲存方案。同樣是 SSD，不同規格在 IOPS、吞吐量與延遲差異極大。

  • 最佳實務：

    • 選擇 低延遲、高 IOPS 的 SSD（如 GCP 的 Local SSD，或 EBS io2 系列），而非單純追求容量。
    • 為 broker 分配足夠的 page cache（記憶體），以減少磁碟直接讀取的壓力。
    • 避免與高 I/O 負載的服務混用同一磁碟，防止資源爭奪。

• 網路規劃

  • Kafka 的本質是事件流，因此網路延遲與頻寬會直接影響 consumer lag 與 replication 效率。

  • 跨區部署的隱憂：

    • 當 broker 分布在不同 zone，跨區網路延遲（通常 2–10ms）會成倍放大 ISR 同步的時間。
    • Replication throughput 在跨區時會受到頻寬上限與封包丟失率影響，造成「集群看似健康，但實際吞吐顯著下降」。

  • 雲端環境的注意事項：

    • 在 GCP/GKE，要特別留意 VPC 頻寬上限（常與 VM 規格綁定），以及跨 zone 的流量收費與限制。
    • 在 AWS 上則需注意 AZ 間流量雖免費，但跨 region 的傳輸費用極高，不適合直接做 replication。

  • 最佳實務：

    • 儘可能將 Kafka broker 部署在同一個區域，並透過 replication 確保 zone-level 容錯。
    • 若必須跨區，務必壓測網路延遲，並在設計上允許更高的 consumer lag。

維運考量：Broker 與儲存

當基礎設施穩定後，維運的焦點會轉向 Kafka Broker 的狀態管理。
Broker 基於磁碟持久化，「儲存層」幾乎就是 Kafka 的生命線。無論是單一 broker 宕機、資料遺失，還是 Pod 重新排程，背後都依賴正確的儲存策略與狀態維護。

持久化存儲

• 在 Strimzi 中，Kafka 集群的儲存透過 Kafka CR（Custom Resource）定義，例如：

storage:
  type: persistent-claim
  size: 100Gi
  class: premium-ssd

• Operator 會自動為每個 broker 建立 PVC 並與 Pod 綁定，負責 PVC 的生命週期管理，降低「PVC 被意外刪除 → broker 狀態遺失」的風險。

最佳實務：

• 使用高 IOPS SSD（例如 GCP 的 premium-rwo）。
• 避免在 production 環境使用 ephemeral（暫存）存儲。
• 明確規劃 broker 的資料目錄大小，避免磁碟飽和導致 broker 無法寫入。

副本與容錯

• 建議至少部署 3 個 broker，並將 topic replication factor ≥ 3，確保單一 broker 宕機時，ISR（in-sync replica）仍能維持服務。
• Strimzi 會自動處理 broker Pod 的重新調度與資料同步，但 replication 的速度仍依賴磁碟與網路效能。

最佳實務：

• 嚴格規劃 min.insync.replicas，避免「只剩一個副本仍允許寫入」的錯誤設計。
• 在多 zone 環境中，將 broker 分布於不同 zone，可提升容錯能力，但需考慮跨區延遲。

好的，我幫你把 災難演練 + 多叢集（跨區 Geo-redundancy） 的內容整合到前面 Broker 與儲存章節的最後部分，並將重點明確放在 如何保持 Broker 狀態、如何利用狀態確保資料完整性與服務可用性。以下是優化後版本：

維運示例：Broker 災難演練與跨區多叢集

Kafka 的可靠性不僅取決於副本數量或 Operator 的自動化能力，更關鍵的是Broker 狀態的維護與復原策略。狀態包括 broker 本地 log、ISR、offset 與 replication 狀態，這些是保證資料完整性與服務持續性的核心。

單區 Broker 故障演練（狀態維護核心）

• 模擬單個 broker 當機或 Pod 被重新排程。

• 核心檢查點：

  • ISR 是否正確補償，Leader 是否重新選舉。
  • Broker 重啟後能否從持久化存儲正確恢復 log 與 offset。
  • 消費端 offset 與 topic 資料一致性是否維持。

最佳實務：

• 使用高 IOPS SSD 保證 log 重播與副本同步速度。
• 每次演練後紀錄 broker 狀態復原時間，形成性能指標。

跨區多叢集部署（Geo-redundancy）

跨區多叢集部署是為了異地容錯，確保單一區域或整個 Region 失效時，仍能保持 Kafka 的狀態與資料完整性。

• 架構示意

Region A                 Region B
┌─────────────┐         ┌─────────────┐
│ Kafka Cluster│         │ Kafka Cluster│
│ Broker 1     │         │ Broker 1     │
│ Broker 2     │         │ Broker 2     │
│ Broker 3     │         │ Broker 3     │
└─────────────┘         └─────────────┘
        │                       │
        └── MirrorMaker 2.0 ───┘

• 運作與演練策略

  1. 跨區同步狀態

     • 使用 MirrorMaker 2.0 將 Region A 的 log 與 offset 同步到 Region B。
     • 演練時可調整 offset，模擬異地重播消息，檢查資料一致性與 ISR 狀態。

  2. A/B 災難切換

     • 當 Region A 全面不可用時，消費端切換到 Region B。

     • 核心檢查點：

       • Broker 狀態（log、ISR、offset）是否完整。
       • 消費端是否能從 Region B 正確接續消息消費。

  3. Runbook 建立

     • 包含 broker 重建、PVC 重綁定、offset 對齊、topic replication 檢查流程。
     • 強調狀態恢復順序：持久化存儲 → broker log → offset → 消費端。

最佳實務：

• 每次演練監控 replication lag、ISR 狀態與消費端 offset。
• 先從單 broker、單 zone 演練，再逐步擴展到跨區整個叢集。
• 文件化演練結果與流程，確保團隊熟悉 broker 與跨區狀態維護。

維運示例：Offset 與監控

在 Kafka 的維運中，除了關注 broker 的健康狀態，生產端（Producer）與消費端（Consumer）的管理同樣重要。核心挑戰通常不是訊息能否進入系統，而是如何精準追蹤與控制消費進度。以下提供實務做法與範例。

Offset 操作

在日常維運中，我們經常需要對 offset 進行操作，例如：

• 資料重播：重新消費歷史訊息。
• 跳過壞訊息：避免單一訊息阻塞消費流程。
• 災難復原：在 consumer group 遇到異常時回復至特定位置。

以下是實務範例：

# 查看 consumer group 狀態
kafka-consumer-groups.sh --bootstrap-server <BROKER>:9092 \
    --describe --group <CONSUMER_GROUP>

上述指令可查看每個 partition 的 offset 與 lag，方便判斷是否需要調整。

接著，如果想從最早的訊息重新消費：

# 從 earliest 開始重置 offset
kafka-consumer-groups.sh --bootstrap-server <BROKER>:9092 \
    --group <CONSUMER_GROUP> --reset-offsets \
    --to-earliest --execute --topic <TOPIC>

或者，想依特定時間戳重新消費：

# 指定 timestamp 位置開始消費
kafka-consumer-groups.sh --bootstrap-server <BROKER>:9092 \
    --group <CONSUMER_GROUP> --reset-offsets \
    --to-datetime 2025-10-02T00:00:00 \
    --execute --topic <TOPIC>

⚠️ 注意：執行 --execute 前建議先用 --dry-run 模擬，確認操作結果，避免意外跳過重要訊息。

消費延遲（Consumer Lag）監控

Offset 操作只是手段，更重要的是持續監控消費進度。這裡建議從 Partition 級別著手：

• Lag 定義：Producer 已寫入但 Consumer 尚未消費的訊息數量。

• 常用指標：

  • consumer_lag：分區 lag 數量
  • consumer_lag_seconds：Lag 對應時間

• 監控工具範例：

  使用 Prometheus Kafka Exporter：

  kafka_consumergroup_lag{consumergroup="order-service", topic="orders", partition="0"}
  

  配合 Grafana Dashboard 可視化各 topic 與 partition 的 lag 變化。

透過監控 lag，我們能快速判斷異常：

• Lag 持續上升 → 消費端可能卡住或無法處理資料。
• Lag 突然降為 0 → Consumer 可能重置 offset 或跳過訊息，需要檢查。

雙端追蹤：Producer + Consumer

單看 Consumer Lag 有時不足以判斷問題源頭，我們還需要結合 Producer 速率 進行雙端監控：

• Producer 速率：確保上游訊息產生速度與消費能力匹配。

  • Kafka Broker 指標：BytesInPerSec / MessagesInPerSec
  • Prometheus metric：kafka_server_brokertopicmetrics_messagesin_total

• 結合 Consumer Lag 分析：

  • Lag 上升但 Producer 流量正常 → 下游消費端瓶頸。
  • Lag 上升且 Producer 流量暴增 → 上游壓力導致積壓。

建議實作方式：

1. 建立 Grafana Dashboard：

   • Producer throughput（topic 級別）
   • Consumer Lag（Partition 級別）

2. 設定告警規則：

   • Lag > N 且持續 T 分鐘 → 發送告警

透過這種雙端追蹤，維運團隊可以快速定位問題源頭，是上游流量過大還是下游消費能力不足，並採取相應措施。

小結

今天我們介紹了 Kafka 的使用與維運經驗，整理如下：

1. Kafka 適用場景

   • 適合「一源多用」與「高併發流量」的系統，能有效解耦資料來源與下游消費端。
   • 若需求單一，且對順序性與持久化要求不高，輕量 ETL 工具或消息隊列（如 RabbitMQ、Redis Stream）即可滿足。

2. 部署方案選擇

   • Strimzi Operator：適合大規模、多環境管理，強調自動化與一致性。
   • Bitnami Helm Chart：快速啟動、簡單上手，適合 PoC 或測試環境，但進階維運需自行補充流程。

3. 資源與網路規劃

   • Kafka 高度依賴 磁碟 I/O，低延遲、高 IOPS SSD 與足夠的 page cache 是效能保障。
   • 網路延遲與頻寬會直接影響 replication 與 consumer lag，跨區部署需特別留意延遲、頻寬與費用。

4. Broker 與儲存維運

   • Broker 狀態（log、ISR、offset）是 Kafka 的核心生命線。
   • 建議至少 3 個 broker，topic replication factor ≥ 3。
   • 高 IOPS SSD 與持久化 PVC 是維護資料完整性的重要保障。

5. 災難演練與跨區多叢集

   • 演練單 broker 宕機、Pod 重建，確認 ISR 與 offset 能正確恢復。
   • 跨區部署（Geo-redundancy）可透過 MirrorMaker 2.0 同步 log 與 offset，確保異地容錯。
   • 建立完整 Runbook，包含 broker 重建、PVC 綁定、offset 對齊流程。

6. Offset 操作與消費監控

   • Offset 調整可用於資料重播、跳過壞訊息或災難復原。
   • 持續監控 consumer lag 與 producer throughput，可快速定位瓶頸。
   • 雙端追蹤（Producer + Consumer）能精準判斷問題來源，保障訊息流穩定性。

以上內容是我在 Kafka 維運上的經驗分享，供讀者參考。
其實 Kafka 的服務細節很多，可設定的參數也不少，但它的核心概念很簡單——提供一個訊息主題，讓多個服務能共享與消費資料。

今天的分享希望能對讀者在理解與使用 Kafka 上提供一些幫助，也讓大家對維運 Kafka 的思路有初步概念。

感謝各位的閱讀，我們明天見！