今年公司的架構開始轉為 microservice + event driven，我們選擇 AWS MSK 託管 Kafka broker 以提供系統各 service 之間的溝通橋樑。
在一次 MSK upgrade 時，Kafka broker 重啓居然造成系統的 producer 無法 publish event，導致 streaming pipeline 短暫失常。
這篇文章記錄問題的發生原因和解決方法。
Kafka Replica
在設定 Kafka broker 時，有一個參數通常會打開來，那就是 kafka topic replication。
它會複製 topic 到不同的 broker，降低一台 broker 發生問題時，event 消失的情況。
其中，replication factor 便是指定 event 會複製幾份在 broker。
假如設為 1， 表示 event 只有一份，並沒有 replication 的效果。要設幾份 replica 取決於 broker 數量及資料特性。
In-Sync Replicas Fails
假如今天 Kafka cluster 有三台 broker，replication factor 設為 2。
在 producer publish event 時，會確保2份 replica 都寫入 broker 才回報成功。
而這次的情況是 MSK upgrade 時，重啓一台 broker，但我們的 producer 採用所有的 replica 都要寫入才算數。
這造成了不斷有 event 出現 In-Sync Replicas fails 問題，且這是無法 retry 成功的，直到 broker upgrade 完成。
如何解決
了解問題原因後，回到我們使用的 Kafka client library 官網。
找到 [produce message}(https://kafka.js.org/docs/producing#producing-messages) 時有一個 acks 的選項，預設為 -1 表示所有 replica
都要完成寫入才會告知 producer publish 成功。
於是將這個參數改為 1，只要 leader broker 寫入成功便回報，這樣就能避免其中一台 broker 失效便無法完成 publish。
MSK 不定期會 upgrade，雖然都會通知用戶，但少了這個參數對系統穩定性會有很大的影響。