Original URL：https://amazonaws-china.com/cn/blogs/big-data/best-practices-for-running-apache-kafka-on-aws/
注意: 本文的撰寫時間早於Amazon MSK的上線日期。Amazon MSK是一項面向Apache Kafka的全託管、高可用性、高安全性服務。我們建議您直接使用Amazon MSK，而非在EC2實例中運行您自主管理的Apache Kafka集羣。當然，如果您需要在EC2上運行Apache Kafka，那麼本文提供的最佳實踐與指導方針仍然適用。
本文是與Intuit公司合作撰寫的特約文章，旨在分享在AWS上運行Apache Kafka集羣的經驗、最佳實踐與建議。感謝Vaishak Suresh以及Intuit公司各位同事們的貢獻與支持。
援引Intuit公司的自我評價：Intuit是一家領先的AWS企業客戶，爲市場提供各類業務與財務管理解決方案。關於Intuit公司與AWS合作的更多詳細信息，請參閱我們之前發佈的《在AWS上使用Apache Spark Streaming與Apache Kafka實現實時流處理》博文。Apache Kafka是一套開源分佈式流平臺，可幫助用戶構建各類實時流式應用程序。
本文中提到的各項最佳實踐，基於我們兩年多以來在AWS上運行及操作大規模Kafka集羣所積累到的經驗心得。本文的目標在於幫助各位正在AWS上運行Kafka集羣、以及正在考慮將本地Kafka部署遷移至AWS的客戶找到更理想的實現途徑。
AWS也提供Amazon Kinesis Data Streams，一項Kafka替代性全託管服務。
在Amazon EC2上運行Kafka部署能夠帶來一種高性能且可擴展性強的解決方案，高效實現流數據提取。AWS爲Kafka部署提供多種不同的實例類型與存儲選項組合，因此帶來的部署拓撲也會非常的複雜與豐富，用戶要找到最符合自身需求的配置也非常困難。
在本文中，我們將從以下幾個方面探索在AWS上搭建與維護Kafka集羣的訣竅：
- 部署注意事項與模式選擇
- 存儲選項
- 實例類型
- 網絡
- 升級
- 性能調優
- 監控
- 安全性
- 備份與恢復
注意：在生產環境中部署Kafka集羣時，大家還需要考慮一系列重要因素，例如消息數量、消息大小、監控、故障處理以及其他運維問題。
部署注意事項與模式選擇
在本節中，我們將探討適用於AWS平臺的各種Kafka部署選項，以及各個選項的優缺點。一套成功的部署方案必須考慮到這些具體選項，並在實際選擇時充分考慮到可用性、一致性以及運維成本等因素。
單AWS區域、三可用區、全主動模式
一種典型的部署模式（全主動模式）是在單一AWS區域之內使用三個可用區。每個可用區內部署一套Kafka集羣，同時附帶Apache ZooKeeper與Kafka生產/消費實例，具體如下圖所示。
在這種模式下，Kafka集羣部署具有以下特徵：
- Kafka生產實例與Kafka集羣部署在同一可用區內。
- 使用Elastic Load Balancer將數據均勻分發至三個Kafka集羣當中。
- Kafka消費實例將來自三個Kafka集羣的數據聚合起來。
Kafka集羣的故障轉移則通過以下方式實現：
- 標記所有Kafka生產實例。
- 停止消費實例。
- 調度並重新堆疊Kafka。
- 重啓消費實例。
- 重啓Kafka生產實例。
下面來看這種模式的優勢與缺點。
優勢
- 高可用性
- 可承受兩個可用區發生故障。
- 故障轉移期間不存在消息丟失。
- 部署難度低。
缺點
- 運維較高：
- 所有變更都需要部署三次，每個Kafka集羣部署一次。
- 需要對三個Kafka集羣進行維護與監控。
- 需要對三個消費集羣進行維護與監控。
必須重新啓動才能修復並升級Kafka集羣中的代理。在這種模式下，我們需要對各個集羣分別進行滾動升級。
單一區域、三個可用區、主-備模式
另一種典型的部署模式（主-備）是在單一AWS區域內部署單一Kafka集羣，而各Kafka broker及ZooKeeper則分佈在三個可用區之間。另外建立一個類似的Kafka集羣充當備用集羣，詳見下圖。我們可以通過MirrorMaker使用Kafka鏡像功能，藉此在任意兩個集羣之間複製消息內容。
在這種模式下，Kafka集羣部署將具有以下特徵：
- Kafka生產實例將被部署在全部三個可用區內。
- 只有一個Kafka集羣跨三個可用區進行部署（主動）。
- ZooKeeper實例將被部署在所有可用區內。
- 代理均勻分佈在全部三個可用區內。
- Kafka消費實例可跨全部三個可用區進行部署。
- 部署體系內還包含備用Kafka生產實例以及一個多可用區Kafka集羣。
Kafka集羣的故障轉移通過以下方式實現：
- 將流量切換至備用Kafka生產集羣與Kafka集羣。
- 重新啓動消費實例以對接備用Kafka集羣。
- 下面來看這種模式的優勢與缺點。對於0.10或更低的Kafka版本，我們需要額外分配主題副本，以便將各副本分配給不同可用區上的代理（機架感知）。
優勢
- 與第一種模式相比，運維成本更低。
- 只需要一套Kafka集羣即可實現數據的管理與消費。
- 可以在不激活備用Kafka集羣的前提下處理單可用區故障。
缺點
- 由於需要在各Kafka broker之間進行跨可用區數據傳輸，因此延遲將相應增加。
- 對於0.10或更低的Kafka版本，我們需要額外分配主題副本，以便將各副本分配給不同可用區上的broker（機架感知）。
- 一旦出現網絡故障（ZooKeeper無法識別Kafka代理），則集羣可用性可能受到影響。
- 故障轉移期間，傳輸中的消息可能丟失。
Intuit公司建議在單一AWS區域內使用單一Kafka集羣，並將broker分佈在三個可用區（即單區域、三可用區模式）當中。這種模式擁有遠超其他模式的容錯能力，可用區故障亦不會導致Kafka停機。
存儲選項
我們可以通過以下兩種存儲選項，在Amazon EC2中實現文件存儲：
臨時存儲位於Amazon EC2實例之內。這種方式可以根據實例類型提供較高的IOPS。另一方面，Amazon EBS存儲卷則擁有更高的彈性水平，用戶可以根據存儲需求對IOPS進行單獨配置。EBS存儲卷在恢復時間方面也擁有明顯的優勢。大家選擇的存儲方案在很大程度上由Kafka集羣所支持的工作負載類型決定。
Kafka提供內置容錯機制，可跨越多個實例（可配置具體數量）複製數據分區。一旦某個代理髮生故障，用戶可以從集羣當中託管有其他副本的各代理處提取數據並實現恢復。取決於數據傳輸的實際大小，恢復過程與相關網絡流量也有可能存在很大差別。這些反過來，又會最終影響到集羣的整體性能。
下表對比了使用實例存儲與使用EBS存儲的具體優勢。
實例存儲
- 對於中大型Kafka集羣，建議大家使用實例存儲。這是因爲在規模較大的集羣當中，讀取/寫入流量將分佈在大量代理當中，因此單一代理丟失所產生的影響較小。但對於規模較小的集羣，故障節點的快速恢復則變得非常重要。因此如果使用實例存儲，則小型Kafka集羣中恢復故障代理的時間週期將更長，且會造成更多的網絡傳輸流量。
- 對於h1、i3以及d2這樣的存儲優化型實例，特別適合充當Kafka這類分佈式應用程序的存儲方案。
EBS
- 在Kafka部署中使用EBS的主要優勢在於，一旦代理髮生故障或者因其他原因而需要更換，EBS能夠顯著減少數據傳輸流量。替換用代理可以更快加入集羣。
- 當實例發生故障或終止時，存儲在EBS上的數據將得到保留。存儲在EBS存儲捲上的代理數據將保持不變，用戶能夠將該EBS存儲卷掛載至新的EC2實例之上。被替代的代理中的大部分複製數據已經被保存在EBS存儲卷內，無需通過網絡從其他代理處複製。只有初始代理髮生故障時，後續變更才需要在網絡上傳輸。這將顯著加快代理的恢復速度。
Intuit公司之所以選擇EBS，是因爲其業務經常需要對實例進行重新調整部署，而且EBS還能夠提供其他一些額外助益。
Kafka部署中通常使用的複製因子爲3。考慮到EBS在其自身存儲層也有多副本機制，因此Intuit選擇的Kafka的複製因子爲2（而非3）。
實例類型
實例類型的選擇，通常由Kafka集羣上流式應用程序所需要的存儲類型決定。如果您的應用程序需要臨時存儲，那麼h1、i3以及d2實例往往是大家的最佳選項。
Intuit公司使用r3.xlarge實例對應代理，r3.large對應ZooKeeper，並使用ST1（吞吐量優化型磁盤驅動器）EBS匹配Kafka集羣。
下面來看Intuit測試中的基準示例配置：
配置
- r3.xlarge
- ST1 EBS
- 12 brokers
代理字節 (MB/s)
- 12分區
- 總計346.9
如果需要使用EBS存儲，不妨考慮AWS提供的新型r4實例。相較於原有R3實例，此r4實例在以下方面有所提升：
- 處理器速度更快（Boradwell架構）。
- 默認對EBS進行優化。
- 具有基於彈性網絡適配器（ENA）的網絡功能，能夠在較低配置條件下實現10 Gbps傳輸速率。
- 使用成本比R3實例低20%。
注意：最佳實踐建議大家始終檢查實例類型的最新變更。
網絡
對於Kafka這類分佈式系統，網絡無疑扮演着非常重要的角色。快速可靠的網絡將保證各節點之間能夠輕鬆通信，而可用的網絡吞吐量上限則控制着Kafka能夠處理的最大流量。網絡吞吐量與磁盤存儲通常是決定集羣大小的主要因素。
如果大家希望集羣能夠接收高讀取/寫入流量，請選擇提供10 Gb/s傳輸性能的實例類型。
此外，請通過選項保證代理間的網絡流量保持在專用子網之內，這意味着客戶端將能夠接入各代理。代理與客戶端之間的通信將使用相同的網絡接口與端口。關於更多詳細信息，請參閱EC2實例IP尋址說明文檔。
如果大家需要在一個以上的AWS區域內部署集羣，則可使用跨區域VPC對等網絡連接位於兩個AWS區域內的兩個VPC。但請注意，跨可用區部署場景會帶來網絡傳輸成本。
升級
Kafka在發展早期對向下兼容不夠重視，但隨着項目發展，其向下兼容性也做得越來越好。在Kafka升級期間，大家應該確保生產者與消費者客戶端的版本等於或低於當前待升級版本。升級完成之後，大家即可開始使用新的協議版本及其支持的一切新功能。目前我們可以通過三種方式進行升級，下面具體展開討論。
滾動升級或就地升級
在滾動或就地升級場景下，我們每次只對一個Kafka broker進行升級。這裏推薦大家選擇滾動重啓方案以避免給最終用戶帶來停機影響。
停機升級
如果您可以接受停機，則可暫時關閉整個集羣，升級各個Kafka broker而後重新啓動集羣。
藍/綠升級
Intuit公司選擇藍/綠部署模式處理其工作負載，下面來看更多詳細情況。
如果您能夠構建起另一個獨立的Kafka集羣並對其進行升級，我們強烈建議您使用藍/綠升級方案。在這種情況下，推薦大家使用最新Kafka版本以使集羣保持最新。關於Kafka版本升級的更多詳細信息，請參閱Kafka升級說明文檔。
下圖所示，爲藍/綠升級模式的基本架構。
在這種情況下，升級的具體流程爲：
- 在AWS上創建一個新的Kafka集羣。
- 創建一個新的Kafka生產棧並指向新的Kafka集羣。
- 在新的Kafka集羣上創建主題。
- 端到端測試綠部署（合理性檢查）。
- 使用Amazon Route 53將AWS上的新Kafka生產棧指向之前創建的新綠Kafka環境。
回滾的具體流程爲：
- 使用Amazon Route 53將AWS上的舊Kafka生產線指向舊有Kafka環境。
關於使用Kafka藍/綠部署架構的更多詳細信息，請參閱re: Invent大會演示文稿《通過藍/綠部署架構運用雲資源》。
性能調優
大家可以在多個維度上實現Kafka的性能調優。下面來看部分性能優化最佳實踐。
以下是部分常規性能調優方法：
-
如果吞吐量低於網絡容量，則嘗試以下方法：
- 添加更多線程
- 添加批次大小
- 添加更多生產實例
- 添加更多分區
-
要提高acks = -1時的延遲，請上調num.replica.fetches的值。
-
對於跨可用區數據傳輸用例，請調整sockets與OS TCP的緩衝區設置。
-
保證num.replica.fetches值大於Kafka專用磁盤的數量。
-
根據生產者實例數量，消費者實例數量以及複製因子調整num.network.threads 的值。
-
您的消息大小也會影響到網絡傳輸帶寬。要從Kafka集羣中獲得更高性能，請選擇可提供10 Gb/s性能的實例類型。
要對Java及JVM進行性能調優，請嘗試以下方法：
- 使用Oracle JDK（使用新的G1垃圾優先收集器）最大程度減少GC暫停。
- 嘗試將Kafka堆大小保持在4 GB以下。
監控
我們需要隨時瞭解Kafka集羣在生產環境中是否保持正常運行。有時候我們只需要確保集羣已經啓動，但有時候還需要對Kafka應用程序中的諸多活動部分進行監控。接觸過運維工作的朋友可能也有同感，我們往往很難準確分辨需要留意的重要內容與可以暫時擱置起來的內容。對項目的監控範圍從總體流量到簡單指標、再到生產者、消費者、代理、控制器、ZooKeeper、主題、分區乃至消息等等，可謂無所不包。
爲了進行監控，Intuit公司使用到多種工具，包括Newrelec、Wavefront、Amazon CloudWatch以及AWS CloudTrail。我們建議大家使用以下監控方案。
在系統指標方面，我們建議監控以下幾項：
- CPU 負載
- 網絡指標
- 文件句柄使用量
- 磁盤空間
- 磁盤I/O性能
- 垃圾收集
- ZooKeeper
在生產者方面，我們建議監控以下幾項：
- Batch-size-avg
- Compression-rate-avg
- Waiting-threads
- Buffer-available-bytes
- Record-queue-time-max
- Record-send-rate
- Records-per-request-avg
在消費者方面，我們建議監控以下幾項：
- Batch-size-avg
- Compression-rate-avg
- Waiting-threads
- Buffer-available-bytes
- Record-queue-time-max
- Record-send-rate
- Records-per-request-avg
安全性
與大多數分佈式系統一樣，Kafka也在各相關組件之間提供較爲安全的數據傳輸機制。根據您的具體設置，安全性要素可能涵蓋不同的服務，例如加密、Kerberos、傳輸層安全（TLS）證書以及高級訪問控制列表（ACL）設置等。下文將詳細介紹Intuit公司採取的方法。關於本節未提及的更多Kafka安全詳細信息，請參閱Kafka說明文檔。
靜態加密
對於採用EBS的EC2實例，大家可以使用啓用加密功能的Amazon EBS存儲卷實現靜態數據加密。Amazon EBS使用AWS Key Management Service (AWS KMS) 實現加密功能。關於更多詳細信息，請參閱EBS說明文檔中的Amazon EBS加密。對於採用實例存儲的EC2實例，大家可以使用Amazon EC2實例存儲加密實現靜態數據加密。
傳輸加密
Kafka使用TLS對各客戶端與節點間通信進行加密。
身份驗證
由客戶端（生產實例與消費實例）指向各代理以及各代理間的連接使用安全套接字層（SSL）或簡單身份驗證與安全層（SASL）實現身份驗證。
Kafka支持Kerberos身份驗證。如果您已經擁有Kerberos服務器，則可將Kafka添加至現有配置當中。
授權
在Kafka中，我們可以進行插入式授權，並與外部授權服務進行集成。
備份與恢復
我們在部署中使用的具體存儲類型，決定了備份與恢復的實際策略。
在使用實例存儲時，備份Kafka集羣的最佳方法是設置另一個集羣並使用MirrorMaker進行消息複製。Kafka的鏡像功能可幫助用戶輕鬆爲現有Kafka集羣維護一套副本。根據具體設置及要求，您的備份集羣可以與主集羣位於同一AWS區域之內，也可以位於其他集羣當中。
對基於EBS的部署，大家可以啓用EBS存儲卷的自動快照功能以實現存儲卷備份。我們可以利用這些快照輕鬆創建新的EBS存儲卷以進行恢復。我們建議將備份文件存儲在Amazon S3當中。
關於如何在Kafka中實現備份的更多詳細信息，請參閱Kafka說明文檔。
總結
在本文中，我們將討論了在AWS雲中運行Kafka的幾種常見模式。AWS還提供另一種託管解決方案，即 Amazon Kinesis Data Streams。該方案無需爲服務器的管理或擴展而分神，大家可以在幾秒鐘之內擴展流式管道規模且無任何停機，跨可用區數據複製將自動執行，以開箱即用的方式享受良好的安全保障，Kinesis Data Stream與Lambda、Redshift、Elasticsearch等多種AWS服務以及Storm、Spark、Flink等開源框架緊密集成。大家還可以參考kafka-kinesis連接器的相關信息。
如果大家有任何問題或建議，請在評論區中與我們交流。
擴展閱讀
如果本文對您有所幫助，也建議大家參閱使用Amazon Kinesis Analytics實現無服務器日誌分析以及使用Amazon Kinesis Analytics進行實時點擊流異常檢測。
核子可樂譯
作者介紹：
Prasad Alle 是 AWS 專業服務部的高級大數據顧問。他在領導和構建適合於 AWS 企業和戰略客戶的可擴展且可靠的大數據、機器學習、人工智能和物聯網解決方案上投入了大量時間。他還對各種不同技術非常感興趣，例如高級邊緣計算、在邊緣站點的機器學習等。在他的空餘時間，他喜歡閱讀和與家人在一起。
原文鏈接：
https://amazonaws-china.com/cn/blogs/china/best-practices-for-running-apache-kafka-on-aws/