如何疑難排解 Amazon MSK 叢集中一個或多個代理程式的 CPU 使用量？

解決方案

Amazon MSK 叢集的 CPU 總使用率計算方式為下列項目的總和：

• 由指標 CpuUser 所定義使用者空間中的 CPU 百分比
• 由 CpuSystem 所定義核心空間中的 CPU 百分比

最佳實務是將 CPU 總使用率保持小於 60%，如此叢集的 CPU 即有 40% 可供使用。Apache Kafka 可以視需要在叢集中的代理程式之間重新分配 CPU 負載。舉例來說，當 Amazon MSK 從代理程式故障復原時，可用的 CPU 可用來執行自動維護，例如修補。

以下是造成 Amazon MSK 叢集中高 CPU 使用率的一些最常見原因：

• 傳入或傳出的流量偏高。
• 每個代理程式的分區數量過多，導致叢集超載。
• 您正在使用 T 類型執行個體。

傳入或傳出的流量偏高

您可以使用 Amazon CloudWatch 指標 BytesInPerSec 和 BytesOutPerSec 指標來監控叢集的傳入和傳出流量。如果代理程式的這些指標偏高或有偏差，則表示代理程式可能遇到高 CPU 使用量。以下是導致傳入和傳出高流量的某些原因：

• 高流量主題的分區計數沒有平均分佈在代理程式上。或者，生產者沒有將資料均勻傳送到所有分區。請記得檢查您的生產者分區金鑰，並據以更新叢集組態。請務必設定分區金鑰，如此能使得某個分區取得的資料不超過其他分區。
• 取用者群組經常提交偏移量。來自偏移量提交的流量影響代理程式。在這種情況下，您會看到代理程式有明顯偏高的 MessagesInPerSec 值，這就是 _consumer_offset 主題分區的前置值。這是提交取用者群組偏移量的分區。若要解決此問題，請減少取用者群組的數量或升級執行個體的大小。

每個代理程式的分區數量過多

如果每個代理程式的分區數量超過建議值，您的叢集即會超載。在此情況下，您可能無法執行下列動作：

• 更新叢集組態。
• 更新叢集的 Apache Kafka 版本。
• 將叢集更新為較小的代理程式類型。
• 將 AWS Secret Manager 密碼與具有 SASL/SCRAM 身分驗證的叢集建立關聯。

因為高 CPU 使用率，分區太多會導致效能降級。這表示即使流量很少，每個分區都會使用一定程度的代理程式資源。若要解決此問題，請嘗試下列方法：

• 刪除過時或未使用的主題，使分區計數落在建議的限值內。
• 將代理程式執行個體類型擴充為可容納您所需分區數量的類型。另外，可試著新增更多代理程式並重新指派分區。

請注意，當您新增代理程式時，不會自動重新指派分區。您必須執行 kafka-reassign-partitions 命令。如需詳細資訊，請參閱變更叢集大小後重新指派分區。

您正在使用 T 類型執行個體

請注意，T 類型執行個體具有基準效能，其中包含某些爆量特性。這些執行個體可讓您有 20% CPU 使用率的基準效能。如果超過此值，則執行個體類型會開始使用 CPU 積分。使用率小於 20% 時，即會累積 CPU 積分。

請務必監控 Amazon CloudWatch 中的 CPU 積分餘額指標。積分在獲得後會在積分餘額中累積，並在消耗時從積分餘額中扣除。積分餘額有上限值，由執行個體大小決定。達到此限值後，所有獲得的新積分都會遭捨棄。對於 T2 標準執行個體類型，啟動積分不會計入限值。

CPUCreditBalance 指標所指出的 CPU 積分可供執行個體爆量消耗其基準 CPU 使用率。執行個體正在執行時，CPUCreditBalance 中的積分不會逾期。當 T4g、T3a 或 T3 執行個體停止時，CPUCreditBalance 值會持續七天。七天後，您會失去所有累積的積分。當 T2 執行個體停止時，CPUCreditBalance 值不會持續存在，而您會失去所有累積的積分。以五分鐘的頻率提供 CPU 積分指標。

請務必監控在 T 類型執行個體上執行的任何叢集的基準 CPU 使用量和積分餘額。如果 CPU 使用量超過基準，且沒有剩餘的積分可用，則叢集會發生效能問題。

其他原因

• 與用戶端的連線數量偏高： 下列任何 CloudWatch 指標的激增可能會導致 CPU 使用量中斷增加。若要疑難排解此問題，請對 CloudWatch 監控這些指標。然後，視需要減少連線計數或擴充代理程式類型。
  • ConnectionCount
  • ConnectionCreationRate
  • ConnectionCloseRate
• 取用者群組的數量偏高： 如果取用者群組數量偏高 (例如，超過 1000 個)，代理程式的 CPU 使用量可能會增加。當某個取用者群組經常提交偏移量時，也可能導致高 CPU 使用量。若要解決此問題，請減少取用者群組的數量或升級執行個體的大小。
• Amazon MSK 會偵測並從代理程式故障中復原： 在此情況下，Amazon MSK 會執行自動維護作業 (例如修補)，進而增加 CPU 使用量。
• 使用者請求代理程式類型變更或版本升級： 在此情況下，Amazon MSK 會部署滾動式工作流程，讓代理程式逐一依次離線。當具有前置分區的代理程式離線時，Apache Kafka 會重新指派分區前置值，以將工作重新分配給叢集中的其他代理程式。監控這些代理程式的 CPU 使用量，並確保叢集中有足夠的 CPU 預留空間以容許作業事件。
• 一或多個代理程式的 CPU 使用量因為資料分配有偏差而偏高： 舉例來說，如果六個代理程式中有兩個遭寫入並耗用最多，則該代理程式有較高的 CPU 使用量。若要解決此問題，請確保使用循環方法，讓叢集中的分區能夠妥善分配。執行 topic describe 命令，以便查看分區在叢集中的分配情形。輸出可能類似於以下內容：

bin/kafka-topics.sh -bootstrap-server $MYBROKERS --describe --topic my-topic
    Topic:my-topic    PartitionCount:7 ReplicationFactor:3 Configs:
    Topic: my-topic    Partition: 0 Leader: 1 Replicas: 1,3,2 Isr: 1,3,2
    Topic: my-topic    Partition: 1 Leader: 2 Replicas: 2,1,3 Isr: 2,1,3
    Topic: my-topic    Partition: 2 Leader: 3 Replicas: 3,2,1 Isr: 3,2,1
    Topic: my-topic    Partition: 3 Leader: 1 Replicas: 1,2,3 Isr: 1,2,3
    Topic: my-topic    Partition: 4 Leader: 2 Replicas: 2,3,1 Isr: 2,3,1
    Topic: my-topic    Partition: 5 Leader: 3 Replicas: 3,1,2 Isr: 3,1,2

• 已開啟開放式監控： 如果您使用 Prometheus 開啟開放式監控，而抓取間隔很低，則其可能會導致發出的指標數量偏高。這會導致 CPU 使用量增加。若要解決此問題，請增加抓取間隔。