最佳實務

本主題概述使用 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.8xlargekafka.m7g.12xlarge、或 kafka.m7g.16xlarge	4000

如果每個代理程式的分區數量超過建議值，且叢集超載，您可能無法執行下列操作：

• 更新叢集的組態

• 將叢集更新為較小的代理程式大小

• 將 AWS Secrets Manager 密碼與具有SASL/SCRAM驗證的叢集建立關聯

大量的分區也可能導致在 Prometheus 刮擦上 CloudWatch 和丟失卡夫卡指標。

如需選擇分割區數目的指導，請參閱 Apache Kafka 支援每個叢集 200K 個分割區。我們還建議您執行自己的測試，以確定適合您的經紀人的規模。有關不同經紀人大小的更多信息，請參閱經紀人規模。

適當調整叢集大小：每個叢集的代理程式數量

若要判斷MSK叢集的正確代理程式數量並瞭解成本，請參閱MSK調整大小和定價試算表。與類似的自我管理EC2型 Apache Kafka MSK 叢集MSK相比，此試算表提供了調整叢集大小和 Amazon 相關成本的估算值。若要取得有關試算表中輸入參數的更多資訊，請將游標停留在參數描述上。此表提供的估計值較保守，僅為新叢集提供起點。叢集效能、大小和成本取決於您的使用案例，建議您透過實際測試進行驗證。

若要瞭解基礎結構如何影響 Apache Kafka 效能，請參閱大數據部落格中最佳化 Apache Kafka 叢集大小以最佳化效能和成本的最佳做法。 AWS 部落格文章提供如何調整叢集大小以符合輸送量、可用性和延遲需求的相關資訊。它也提供對一些問題的解答，例如應該何時縱向擴展或橫向擴展，以及如何持續驗證生產叢集大小。

最佳化 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 文件中的 擴充您的叢集。