Express 代理程式的最佳實務 - Amazon Managed Streaming for Apache Kafka
用戶端考量事項伺服器端考量事項

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

Express 代理程式的最佳實務

本主題概述使用 Express 代理程式時應遵循的一些最佳實務。快速代理程式已預先設定，可提供高可用性和耐用性。您的資料預設會分散到三個可用區域，複寫一律設為 3，而最小同步複本一律設為 2。不過，為了最佳化叢集的可靠性和效能，仍需考量幾個因素。

用戶端考量事項

您應用程式的可用性和效能不僅取決於伺服器端設定，也取決於用戶端設定。

  • 設定您的用戶端以獲得高可用性。在 Apache Kafka 等分散式系統中，確保高可用性對於維護可靠且容錯的訊息基礎設施至關重要。中介裝置將針對計劃和非計劃事件離線，例如升級、修補、硬體故障和網路問題。Kafka 叢集可容忍離線代理程式，因此 Kafka 用戶端也必須正常處理代理程式容錯移轉。請參閱 Apache Kafka 用戶端最佳實務建議中的完整詳細資訊。

  • 執行效能測試，確認您的用戶端組態可讓您在尖峰負載下重新啟動代理程式時滿足您的效能目標。您可以從 MSK 主控台或使用 MSK APIs 重新啟動叢集中的代理程式。

伺服器端考量事項

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

選擇 Express 型叢集的代理程式數量非常簡單。每個 Express 代理程式都有用於輸入和輸出的定義輸送量容量。您應該使用此輸送量容量做為調整叢集大小的主要方法 （然後考慮其他因素，例如分割區和連線計數，如下所述）。

例如，如果您的串流應用程式需要 45 MBps 的資料輸入 （寫入） 和 90 MBps 的資料輸出 （讀取） 容量，您可以直接使用 3 個 express.m7g.large 代理程式來滿足您的輸送量需求。每個 express.m7g.large 代理程式將處理 15 MBps 的輸入和 30 MBps 的輸出。如需每個 Express 代理程式大小的建議輸送量限制，請參閱下表。如果您的輸送量超過建議的限制，您可能會遇到效能降低，而且您應該減少流量或擴展叢集。如果您的輸送量超過建議的限制並達到每個代理程式配額，MSK 會調節您的用戶端流量，以防止進一步過載。

您也可以使用我們的 MSK 大小和定價試算表來評估多個案例，並考慮其他因素，例如分割區計數。

每個代理程式的建議最大輸送量
執行個體大小 輸入 (MBps) 輸出 (MBps)

express.m7g.large

 15.6 31.2

express.m7g.xlarge

 31.2 62.5

express.m7g.2xlarge

 62.5 125.0

express.m7g.4xlarge

 124.9 249.8

express.m7g.8xlarge

 250.0 500.0

express.m7g.12xlarge

 375.0 750.0

express.m7g.16xlarge

 500.0 1000.0

監控 CPU 用量

我們建議您將代理程式 （定義為 CPU 使用者 + CPU 系統） 的總 CPU 使用率維持在 60% 以下。如果至少有叢集總 CPU 的 40% 可用，Apache Kafka 就能在必要時於叢集中的代理程式之間重新分配 CPU 負載。這可能是由於計劃或非計劃事件而需要的。計劃事件的範例是叢集版本升級，在此期間 MSK 會透過一次重新啟動一個代理程式來更新叢集中的代理程式。意外事件的範例是代理程式中的硬體故障，或在最壞的情況下，AZ 故障，其中 AZ 中的所有代理程式都會受到影響。當具有分割區引線複本的代理程式離線時，Apache Kafka 會重新指派分割區領導，將工作重新分配給叢集中的其他代理程式。透過遵循此最佳實務，您可以確保叢集中有足夠的 CPU 標頭空間，以容忍這類的操作事件。

您可以在 Amazon CloudWatch 使用者指南中使用數學表達式搭配 CloudWatch 指標，建立 CPU 使用者 + CPU 系統的複合指標。 Amazon CloudWatch 設定當複合指標達到平均 60% 的 CPU 使用率時觸發警示。觸發此警示後，請使用下列選項之一擴展叢集：

  • 選項 1：將您的代理程式大小更新為下一個較大的大小。請記住，當您更新叢集中的代理程式大小時，Amazon MSK 會以滾動方式讓代理程式離線，並暫時將分割區領導權重新指派給其他代理程式。

  • 選項 2：透過新增代理程式來擴展叢集，然後使用名為 的分割區重新指派工具來重新指派現有分割區kafka-reassign-partitions.sh。

其他建議

  • 監控每個代理程式的總 CPU 使用率，將其作為負載分配的測算代替物。如果代理程式的 CPU 使用率持續不平均，這可能是負載在叢集內分佈不平均的跡象。建議使用 Cruise Control 透過分割區指派持續管理負載分佈。

  • 監控生產和取用延遲。生產和取用延遲會隨著 CPU 使用率線性增加。

  • JMX 湊集間隔：如果您使用 Prometheus 功能啟用開放監控，建議您針對 Prometheus 主機組態 (scrape_interval: 60s) 使用 60 秒或更高的湊集間隔 ()prometheus.yml。降低湊集間隔可能導致叢集上的 CPU 使用率過高。

正確調整叢集大小：每個 Express 代理程式的分割區數量

如果您有高分割區、低輸送量的使用案例，其中您的分割區計數較高，但您未跨所有分割區傳送流量，只要您已執行足夠的測試和效能測試，以驗證您的叢集在分割區計數較高時仍正常運作，就可以為每個代理程式封裝更多分割區。如果每個代理程式的分割區數量超過允許的最大值，且叢集超載，您將無法執行下列操作：

  • 更新叢集的組態

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

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

具有大量分割區的叢集也可能導致 CloudWatch 和 Prometheus 湊集缺少 Kafka 指標。

如需選擇分割區數目的指導，請參閱 Apache Kafka 支援每個叢集 200K 個分割區。我們也建議您執行自己的測試，以判斷適合代理程式的大小。如需不同代理程式大小的詳細資訊，請參閱 Amazon MSK 代理程式大小。

如需每個 Express 代理程式的建議分割區數量 （包括領導者和跟隨者複本） 的相關資訊，請參閱 快速代理程式分割區配額。不強制執行建議的分割區數量，這是您跨所有佈建主題分割區傳送流量的最佳實務。

監控連線計數

代理程式的用戶端連線會耗用記憶體和 CPU 等系統資源。根據您的身分驗證機制，您應該監控 以確保您在適用的限制內。若要處理失敗連線的重試，您可在用戶端設定 reconnect.backoff.ms 組態參數。例如，如果您希望用戶端在 1 秒後重試連線，請將 reconnect.backoff.ms設定為 1000。如需設定重試的詳細資訊，請參閱 Apache Kafka 文件。

維度 配額

每個代理程式的最大 TCP 連線數 (IAM 存取控制)

 3000

每個代理程式的最大 TCP 連線數 (IAM)

 每秒 100 次

每個代理程式的最大 TCP 連線數 （非 IAM)

 MSK 不會強制執行非 IAM 驗證的連線限制。不過，您應該監控其他指標，例如 CPU 和記憶體用量，以確保您不會因為連線過多而讓叢集超載。

重新指派分割區

若要將分割區移至相同 MSK 佈建叢集上的不同代理程式，您可以使用名為 的分割區重新指派工具kafka-reassign-partitions.sh。我們建議您在單一kafka-reassign-partitions呼叫中不要為安全操作重新指派超過 20 個分割區。例如，在您新增代理程式以展開叢集或移動分割區以移除代理程式之後，您可以透過將分割區重新指派給新的代理程式來重新平衡該叢集。如需如何將代理程式新增至 MSK 佈建叢集的詳細資訊，請參閱 展開 Amazon MSK 叢集中的代理程式數量。如需如何從 MSK 佈建叢集中移除代理程式的詳細資訊，請參閱 從 Amazon MSK 叢集移除代理程式。如需有關分割區重新指派工具的詳細資訊，請參閱 Apache Kafka 文件中的 擴充您的叢集。