本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。
最佳實務
本主題概述使用 Amazon 時應遵循的一些最佳實務MSK。
適當調整叢集大小:每個代理程式的分區數量
下表顯示每個代理程式建議的分區數量上限 (包括領導者和追隨複本)。
經紀人規模 | 每個代理程式的建議分區數量 (包括領導者和追隨複本) |
---|---|
kafka.t3.small |
300 |
kafka.m5.large 或 kafka.m5.xlarge |
1000 |
kafka.m5.2xlarge |
2000 |
kafka.m5.4xlarge 、kafka.m5.8xlarge 、kafka.m5.12xlarge 、kafka.m5.16xlarge 或 kafka.m5.24xlarge |
4000 |
kafka.m7g.large 或 kafka.m7g.xlarge |
1000 |
kafka.m7g.2xlarge |
2000 |
kafka.m7g.4xlarge 、kafka.m7g.8xlarge kafka.m7g.12xlarge 、或 kafka.m7g.16xlarge |
4000 |
如果每個代理程式的分區數量超過建議值,且叢集超載,您可能無法執行下列操作:
-
更新叢集的組態
-
將叢集更新為較小的代理程式大小
-
將 AWS Secrets Manager 密碼與具有SASL/SCRAM驗證的叢集建立關聯
大量的分區也可能導致在 Prometheus 刮擦上 CloudWatch 和丟失卡夫卡指標。
如需選擇分割區數目的指導,請參閱 Apache Kafka 支援每個叢集 200K 個分割區
適當調整叢集大小:每個叢集的代理程式數量
若要判斷MSK叢集的正確代理程式數量並瞭解成本,請參閱MSK調整大小和定價
若要瞭解基礎結構如何影響 Apache Kafka 效能,請參閱大數據部落格中最佳化 Apache Kafka 叢集大小以最佳化效能和成本
最佳化 m5.4xl、m7g.4xl 或更大型執行個體的叢集輸送量
使用 m5.4xl、m7g.4xl 或更大的執行個體時,您可以透過調整 num.io.thread 和 num.network.thread 組態來最佳化叢集輸送量。
Num.io.Threads 是代理程式用於處理請求的執行緒數量。新增更多執行緒 (達到執行個體大小支援的CPU核心數目) 可協助改善叢集輸送量。
Num.network.Threads 是代理程式用於接收所有傳入請求和傳回回應的執行緒數量。網路執行緒將傳入請求放置在請求隊列中,以便由 io.threads 處理。將 num.network.threads 設定為執行個體大小支援的CPU核心數量的一半,可讓您完全使用新的執行個體大小。
重要
在沒有先增加 num.io.threads 的情況下,請勿增加 num.network.threads,因為這可能會導致與佇列飽和度相關的堵塞。
建議設定 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
執行個體大小 | num.io.threads 的建議值 | num.network.threads 的建議值 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
m5.4xl |
16 |
8 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
m5.8xl |
32 |
16 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
m5.12xl |
48 |
24 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
m5.16xl |
64 |
32 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
m5.24xl |
96 |
48 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
m7g.4xlarge |
16 |
8 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
m7g.8xlarge |
32 |
16 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
m7g.12xlarge |
48 |
24 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
m7g.16xlarge |
64 |
32 |
使用最新的卡夫卡 AdminClient 以避免主題 ID 不匹配問題
當您使用帶有旗標--zookeeper
的 Kafka AdminClient 版本低於 2.8.0,以增加或重新指派使用 Kafka 2.8.0 版或更新版本的叢集主題分割區時,會遺失主題識別碼 (錯誤:不符合分割區的主題識別碼)。請注意,--zookeeper
旗標已在 Kafka 2.5 棄用,並從 Kafka 3.0 開始被刪除。請參閱 Upgrading to 2.5.0 from any version 0.8.x through 2.4.x
為了防止主題 ID 不相符,請使用 Kafka 用戶端 2.8.0 或更高版本進行 Kafka 管理員操作。2.5 及更高版本的用戶端可以使用 --bootstrap-servers
旗標而不是 --zookeeper
旗標。
建置高可用性叢集
請使用下列建議,讓MSK叢集在更新期間 (例如更新代理程式大小或 Apache Kafka 版本時) 或 Amazon 取代代理程式時具MSK有高可用性。
-
設定一個三可用區域叢集。
-
確保複寫係數 (RF) 至少為 3。請注意,RF 為 1 可能會導致滾動式更新期間分區離線;而 RF 2 可能會導致資料遺失。
-
將最小同步複本 (分鐘ISR) 設定為最多 RF-1。等於 RF ISR 的最小值可能會阻止在滾動式更新期間對叢集產生。最小ISR值 2 允許在一個複本離線時使用三向複製主題。
-
確定用戶端連線字串至少包含每個可用區域中一個代理程式。如果用戶端連接字串中有多個代理程式,則允許在特定代理程式離線進行更新時進行容錯移轉。如需有關如何取得具有多個代理程式的連接字串的詳細資訊,請參閱獲取 Amazon MSK 集群的引導程序代理。
監控CPU使用
Amazon MSK 強烈建議您將經紀商的總CPU使用率 (定義為CPU User + CPU System
) 維持在 60% 以下。當您至少有叢集總數的 40% 可CPU用時,必要時,Apache Kafka 可以在叢集中的代理程式之間重新分配CPU負載。Amazon MSK 偵測到代理程式故障並從中復原時的一個必要範例;在此情況下,Amazon MSK 會執行自動維護,例如修補。另一個範例是使用者請求代理程式大小變更或版本升級時;在這兩種情況下,Amazon 會MSK部署滾動式工作流程,讓一個代理程式一次離線。當具有領導者分區的代理程式離線時,Apache Kafka 會重新分配分區領導者,以將工作重新分配給叢集中的其他代理程式。透過遵循這個最佳做法,您可以確保叢集中有足夠的CPU預留空間來容忍這類作業事件。
您可以使用 Amazon CloudWatch 指標數學來建立複合指標CPU User + CPU System
。設定當複合度量達到 60% 的平均CPU使用率時觸發的警示。觸發此警示後,請使用下列選項之一擴展叢集:
-
選項 1(建議):將代理程式大小更新為下一個較大的大小。例如,如果目前的大小為
kafka.m5.large
,請更新要使用的叢集kafka.m5.xlarge
。請記住,當您更新叢集中的代理程式大小時,Amazon 會以滾動的方式MSK將代理程式離線,並暫時將分區領導地位重新指派給其他經紀人。更新每個代理程式的大小通常需要 10-15 分鐘。 -
選項 2:如果有主題包含從使用循環配置寫入的生產者擷取的所有訊息 (換句話說,訊息不用鍵入且排序對取用者不重要),請新增代理程式以擴充叢集。同時新增分區至有具有最高輸送量的現有主題。接下來,使用
kafka-topics.sh --describe
以確保新增的分區被指派給新的代理程式。與前一個選項相比,此選項主要的好處是您可以更精細地管理資源和成本。此外,如果CPU負載明顯超過 60%,您可以使用此選項,因為這種形式的擴展通常不會增加現有代理程式的負載。 -
選項 3:新增代理程式以擴充叢集,然後使用名為
kafka-reassign-partitions.sh
的分區重新指派工具來重新指派現有的分區。但是,如果您使用此選項,則重新指派分區之後,叢集將需要花費資源將資料從一個代理程式複製到另一個。與之前的兩個選項相比,這個選項在最初會顯著增加叢集的負載。因此,Amazon MSK 不建議在使用CPU率超過 70% 時使用此選項,因為複寫會造成額外的CPU負載和網路流量。Amazon MSK 僅建議在以前的兩個選項不可行時使用此選項。
其他建議:
-
監視每個代理程式的總CPU使用率,做為負載分配的 Proxy。如果代理程序始終不均勻的CPU利用率,則可能表明負載不均勻分佈在集群中。Amazon MSK 建議使用巡航控制,透過分區指派持續管理負載分配。
-
監控生產和取用延遲。產生和消耗延遲會隨著CPU使用率線性增加。
-
JMX抓取間隔:如果使用 Prometheus 功能啟用了開放式監控,建議您對普羅米修斯主機配置(prometheus.yml)使用 60 秒或更高的抓取間隔(抓取間隔:60s)。降低抓取間隔可能會導致叢集的高CPU使用率。
監控磁碟空間
若要避免訊息的磁碟空間不足,請建立監視KafkaDataLogsDiskUsed
指標的 CloudWatch 警示。當此指標的值達到或超過 85% 時,請執行下列一或多個動作:
如需如何設定和使用警示的詳細資訊,請參閱使用 Amazon CloudWatch 警示。如需 Amazon MSK 指標的完整清單,請參閱監控 Amazon MSK 群集。
調整資料保留參數
取用訊息不會從日誌中刪除它們。若要定期釋放磁碟空間,您可以明確指定保留期間,也就是訊息在記錄中保留的時間長度。您也可以指定保留記錄大小。當無論是保留時間週期或保留記錄大小達到,Apache Kafka 會開始從記錄中刪除非作用中區段。
若要在叢集層級指定保留政策,請設定下列一或多個參數:log.retention.hours
、log.retention.minutes
、log.retention.ms
或 log.retention.bytes
。如需詳細資訊,請參閱自訂 MSK 組態。
您也可以在主題層級指定保留參數:
-
若要指定每個主題保留時間期間,請使用下列命令。
kafka-configs.sh --bootstrap-server $bs --alter --entity-type topics --entity-name
TopicName
--add-config retention.ms=DesiredRetentionTimePeriod
-
若要指定每個主題的保留記錄大小,請使用下列命令。
kafka-configs.sh --bootstrap-server $bs --alter --entity-type topics --entity-name
TopicName
--add-config retention.bytes=DesiredRetentionLogSize
您在主題層級指定的保留參數會優先於叢集層級參數。
不正常關機後加快復原日誌速度
不正常關機後,代理程式可能需要一段時間才能重新啟動,因為它會試圖復原日誌。根據預設,Kafka 對每個日誌目錄僅使用單執行緒進行復原。例如,如果您有數千個分區,日誌復原可能需要數小時才能完成。若要加速日誌復原,建議使用組態屬性 num.recovery.threads.per.data.dir
增加執行緒數量。您可以將其設定為CPU核心數。
監控 Apache Kafka 記憶體
我們建議您監控 Apache Kafka 的記憶體用量。否則,叢集可能無法使用。
若要判斷 Apache Kafka 使用了多少記憶體,您可以監控 HeapMemoryAfterGC
指標。HeapMemoryAfterGC
則是垃圾回收之後使用中的總堆積記憶體百分比。我們建議您建立 CloudWatch 警報,在HeapMemoryAfterGC
增加到 60% 以上時採取行動。
您可以採取以減少記憶體用量的步驟各有不同。它們取決於您設定 Apache Kafka 的方式。例如,如果您使用交易性訊息傳輸,則可以將 Apache Kafka 組態中的 transactional.id.expiration.ms
值從 604800000
毫秒降至 86400000
毫秒 (從 7 天減少為 1 天)。這會減少每個交易的記憶體用量。
不要添加非MSK經紀人
對於 ZooKeeper基於叢集,如果您使用 Apache ZooKeeper 命令來新增代理程式,這些代理程式不會新增至您的MSK叢集,而您的 Apache ZooKeeper 將包含有關叢集的錯誤資訊。這可能會導致資料遺失。如需支援的叢集操作,請參閱 AmazonMSK:它是如何工作的。
啟用傳輸中加密
如需傳輸中加密及如何啟用的相關資訊,請參閱 傳輸中加密。
重新指派分割區
若要將分割區移至相同叢集上的不同代理程式,您可以使用名為 kafka-reassign-partitions.sh
的分割區重新指派工具。例如,在新增代理程式以擴充叢集或移動分割區以移除代理程式之後,您可以透過將分割區重新指派給新的代理程式來重新平衡該叢集。如需如何新增代理程式至叢集的詳細資訊,請參閱 擴展 Amazon MSK 群集。如需如何從叢集中移除代理程式的相關資訊,請參閱從 Amazon MSK 叢集中移除代理程式。如需有關分割區重新指派工具的詳細資訊,請參閱 Apache Kafka 文件中的 擴充您的叢集