本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 標準代理程式的最佳實務
本主題概述一些使用 Amazon MSK 時應遵循的最佳實務。如需 Amazon MSK Replicator 最佳實務的相關資訊，請參閱 [使用 MSK Replicator 的最佳實務](msk-replicator-best-practices.md)。
## 用戶端考量事項
應用程式的可用性和效能不僅取決於伺服器端設定，還取決於用戶端設定。
+ 設定您的用戶端以獲得高可用性。在 Apache Kafka 等分散式系統中，確保高可用性對於維護可靠且容錯的訊息基礎設施至關重要。中介裝置將針對計劃和非計劃事件離線，例如升級、修補、硬體故障和網路問題。Kafka 叢集可容忍離線代理程式，因此 Kafka 用戶端也必須正常地處理代理程式容錯移轉。請參閱 的完整詳細資訊[Apache Kafka 用戶端的最佳實務](bestpractices-kafka-client.md)。
+ 確定用戶端連線字串至少包含每個可用區域中一個代理程式。如果用戶端連接字串中有多個代理程式，則允許在特定代理程式離線進行更新時進行容錯移轉。如需有關如何取得具有多個代理程式的連接字串的詳細資訊，請參閱[取得 Amazon MSK 叢集的引導代理程式](msk-get-bootstrap-brokers.md)。
+ 執行效能測試，以確認您的用戶端組態可讓您達成效能目標。
## 伺服器端考量事項
### 正確調整叢集大小：每個標準代理程式的分割區數量
下表顯示每個標準代理程式建議的分割區數量 （包括領導者和跟隨者複本）。不強制執行建議的分割區數量，這是您跨所有佈建主題分割區傳送流量的最佳實務。
| 代理程式大小 | 每個代理程式的建議分區數量 (包括領導者和追隨複本) | 支援更新操作的分割區數量上限 |
| --- | --- | --- |
| kafka.t3.small | 300 | 300 |
| kafka.m5.large 或 kafka.m5.xlarge | 1000 | 1500 |
| kafka.m5.2xlarge | 2000 | 3000 |
| kafka.m5.4xlarge、kafka.m5.8xlarge、kafka.m5.12xlarge、kafka.m5.16xlarge 或 kafka.m5.24xlarge | 4000 | 6000 |
| kafka.m7g.large 或 kafka.m7g.xlarge | 1000 | 1500 |
| kafka.m7g.2xlarge | 2000 | 3000 |
| kafka.m7g.4xlarge、kafka.m7g.12xlarge、 kafka.m7g.8xlarge或 kafka.m7g.16xlarge | 4000 | 6000 |
如果您有高分割區、低輸送量的使用案例，其中您的分割區計數較高，但您未跨所有分割區傳送流量，則您可以為每個代理程式封裝更多分割區，只要您已執行足夠的測試和效能測試，以驗證您的叢集在分割區計數較高的情況下保持正常運作。如果每個代理程式的分割區數量超過允許的最大值，且您的叢集超載，您將無法執行下列操作：
+ 更新叢集的組態
+ 將叢集更新為較小的代理程式大小
+ 將 AWS Secrets Manager 秘密與具有 SASL/SCRAM 身分驗證的叢集建立關聯
大量分割區也可能導致 CloudWatch 和 Prometheus 抓取缺少 Kafka 指標。
如需選擇分割區數目的指導，請參閱 [Apache Kafka 支援每個叢集 200K 個分割區](https://blogs.apache.org/kafka/entry/apache-kafka-supports-more-partitions)。我們也建議您執行自己的測試，以判斷適合代理程式的大小。如需不同代理程式大小的詳細資訊，請參閱 [Amazon MSK 代理程式類型](broker-instance-types.md)。
### 正確調整叢集大小：每個叢集的標準代理程式數量
若要判斷 MSK 佈建叢集的適當標準代理程式數量並了解成本，請參閱 [MSK 大小和定價](https://view.officeapps.live.com/op/view.aspx?src=https%3A%2F%2Fdy7oqpxkwhskb.cloudfront.net%2FMSK_Sizing_Pricing.xlsx&wdOrigin=BROWSELINK)試算表。相較於類似的自我管理 EC2-based Apache Kafka 叢集，此試算表提供 MSK 佈建叢集大小和 Amazon MSK 相關成本的預估值。若要取得有關試算表中輸入參數的更多資訊，請將游標停留在參數描述上。此工作表提供的估算是保守的，並為新的 MSK 佈建叢集提供起點。叢集效能、大小和成本取決於您的使用案例，建議您透過實際測試進行驗證。
若要了解基礎基礎設施如何影響 Apache Kafka 效能，請參閱 AWS 大數據部落格中的[正確調整 Apache Kafka 叢集大小以最佳化效能和成本的最佳實務](https://aws.amazon.com/blogs/big-data/best-practices-for-right-sizing-your-apache-kafka-clusters-to-optimize-performance-and-cost/)。部落格文章提供如何調整叢集大小以符合輸送量、可用性和延遲需求的相關資訊。它還提供問題的答案，例如何時應該*向上*擴展或*向外*擴展，以及如何持續驗證生產叢集大小的指導。如需分層儲存型叢集的相關資訊，請參閱[使用 Amazon MSK 分層儲存執行生產工作負載的最佳實務](https://aws.amazon.com/blogs/big-data/best-practices-for-running-production-workloads-using-amazon-msk-tiered-storage/)。
### 最佳化 m5.4xl、m7g.4xl 或更大執行個體的叢集輸送量
使用 m5.4xl、m7g.4xl 或更大的執行個體時，您可以透過調校 num.io.threads 和 num.network.threads 組態來最佳化 MSK 佈建叢集輸送量。
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 |
### 使用最新的 Kafka AdminClient，以避免主題 ID 不相符問題
當您使用低於 2.8.0 的 Kafka AdminClient 版本搭配 旗標`--zookeeper`來增加或重新指派使用 Kafka 2.8.0 版或更高版本的 MSK 佈建叢集的主題分割區時，主題的 ID 會遺失 （錯誤： 不符合分割區的主題 ID)。請注意，`--zookeeper` 旗標已在 Kafka 2.5 棄用，並從 Kafka 3.0 開始被刪除。請參閱 [Upgrading to 2.5.0 from any version 0.8.x through 2.4.x](https://kafka.apache.org/documentation.html#upgrade_2_5_0)。
為了防止主題 ID 不相符，請使用 Kafka 用戶端 2.8.0 或更高版本進行 Kafka 管理員操作。2.5 及更高版本的用戶端可以使用 `--bootstrap-servers` 旗標而不是 `--zookeeper` 旗標。
### 建置高可用性叢集
使用下列建議，以便在更新期間 （例如，當您更新代理程式大小或 Apache Kafka 版本時） 或 Amazon MSK 取代代理程式時，您的 MSK 佈建叢集可以高度使用。
+ 設定一個三可用區域叢集。
+ 確保複寫係數 (RF) 至少為 3。請注意，RF 為 1 可能會導致滾動式更新期間分區離線；而 RF 2 可能會導致資料遺失。
+ 請將最小同步複本 (minISR) 設定為不超過 RF-1。等於 RF 的 minISR 可避免在滾動更新期間產生至叢集。minISR 2 允許當一個複本離線時，可以使用三向複寫的主題。
### 監控 CPU 用量
Amazon MSK 強烈建議您將代理程式 （定義為 `CPU User + CPU System`) 的 CPU 使用率維持在 60% 以下。這可確保您的叢集保留足夠的 CPU 空間來處理操作事件，例如代理程式故障、修補和滾動升級。
Apache Kafka 可以視需要在叢集中的代理程式之間重新分配 CPU 負載。例如，當 Amazon MSK 偵測到代理程式錯誤並從中復原時，它會執行自動維護，例如修補。同樣地，當使用者請求代理程式大小變更或版本升級時，Amazon MSK 會啟動滾動工作流程，使一個代理程式一次離線。當具有領導者分區的代理程式離線時，Apache Kafka 會重新分配分區領導者，以將工作重新分配給叢集中的其他代理程式。透過遵循此最佳實務，您可以確保有足夠的 CPU 前端空間來容忍這些操作事件。
**注意**
監控 CPU 使用率時，請注意 CPU 使用率總計包含超過 `CPU User`和 `CPU System`。其他類別，例如 `iowait`、`softirq`、 `irq`和 `steal`，也有助於整體 CPU 活動。因此，CPU 閒置*不一定等於* `100% - CPU User - CPU System`。
您可以使用 [Amazon CloudWatch 指標數學](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html)來建立複合指標 (`CPU User + CPU System`)，並將警示設定為在平均用量超過 60% 時觸發。觸發時，請考慮使用下列其中一個選項擴展叢集：
+ 選項 1 （建議）：[將您的代理程式大小更新](https://docs.aws.amazon.com//msk/latest/developerguide/msk-update-broker-type.html)為下一個較大的大小。例如，如果目前大小為 `kafka.m5.large`，請更新叢集以使用 `kafka.m5.xlarge`。請記住，當您更新叢集中的代理程式大小時，Amazon MSK 會以滾動方式讓代理程式離線，並暫時將分割區領導權重新指派給其他代理程式。更新每個代理程式的大小通常需要 10-15 分鐘。
+ 選項 2：如果有主題包含從使用循環配置寫入的生產者擷取的所有訊息 (換句話說，訊息不用鍵入且排序對取用者不重要)，請新增代理程式以[擴充叢集](https://docs.aws.amazon.com//msk/latest/developerguide/msk-update-broker-count.html)。同時新增分區至有具有最高輸送量的現有主題。接下來，使用 `kafka-topics.sh --describe` 以確保新增的分區被指派給新的代理程式。與前一個選項相比，此選項主要的好處是您可以更精細地管理資源和成本。此外，如果 CPU 負載大幅超過 60%，也適合使用此選項，因為這種形式的擴展通常不會增加現有代理程式的負載。
+ 選項 3：新增代理程式以擴展 MSK 佈建叢集，然後使用名為 的分割區重新指派工具來重新指派現有分割區`kafka-reassign-partitions.sh`。但是，如果您使用此選項，則重新指派分區之後，叢集將需要花費資源將資料從一個代理程式複製到另一個。與之前的兩個選項相比，這個選項在最初會顯著增加叢集的負載。因此，當 CPU 使用率超過 70% 時，Amazon MSK 不建議使用此選項，因為複製會造成額外的 CPU 負載和網路流量。只有在先前兩個選項都不可行時，Amazon MSK 才建議使用此選項。
其他建議：
+ 監控每個代理程式的總 CPU 使用率，將其作為負載分配的測算代替物。如果代理程式的 CPU 使用率持續不均，則可能代表負載未均勻分佈在叢集中。建議使用 [Cruise Control](https://docs.aws.amazon.com//msk/latest/developerguide/cruise-control.html) 透過分割區指派持續管理負載分佈。
+ 監控生產和取用延遲。生產和取用延遲會隨著 CPU 使用率線性增加。
+ **JMX 湊集間隔**：如果您使用 [Prometheus 功能](https://docs.aws.amazon.com/msk/latest/developerguide/open-monitoring.html)啟用了開放式監控，建議您對 Prometheus 主機組態 (prometheus.yml) 使用 60 秒或更高的湊集間隔 (scrape\$1interval：60s)。降低湊集間隔可能導致叢集上的 CPU 使用率過高。
### 監控磁碟空間
若要避免訊息的磁碟空間不足，請建立 CloudWatch 警示以監視 `KafkaDataLogsDiskUsed` 指標。當此指標的值達到或超過 85% 時，請執行下列一或多個動作：
+ 請使用 [Amazon MSK 叢集的自動擴展](msk-autoexpand.md)。您也可以手動增加代理程式儲存空間，如 [標準代理程式的手動擴展](manually-expand-storage.md) 中所述。
+ 縮短郵件保留期間或記錄大小。如需如何執行此作業的資訊，請參閱 [調整資料保留參數](#bestpractices-retention-period)。
+ 刪除未使用的主題。
有關如何設定和使用警示的詳細資訊，請參閱 [使用 Amazon CloudWatch 警示](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)。如需 Amazon MQ 指標的完整清單，請參閱[監控 Amazon MSK 佈建叢集](monitoring.md)。
### 調整資料保留參數
取用訊息不會從日誌中刪除它們。若要定期釋放磁碟空間，您可以明確指定保留期間，也就是訊息在記錄中保留的時間長度。您也可以指定保留記錄大小。當無論是保留時間週期或保留記錄大小達到，Apache Kafka 會開始從記錄中刪除非作用中區段。
若要在叢集層級指定保留政策，請設定下列一或多個參數：`log.retention.hours`、`log.retention.minutes`、`log.retention.ms` 或 `log.retention.bytes`。如需詳細資訊，請參閱[自訂 Amazon MSK 組態](msk-configuration-properties.md)。
您也可以在主題層級指定保留參數：
+ 若要指定每個主題保留時間期間，請使用下列命令。
```
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 對每個日誌目錄僅使用單執行緒進行復原。例如，如果您有數千個分區，日誌復原可能需要數小時才能完成。若要加速日誌復原，建議使用組態屬性 [https://docs.aws.amazon.com/msk/latest/developerguide/msk-configuration-properties.html](https://docs.aws.amazon.com/msk/latest/developerguide/msk-configuration-properties.html) 增加執行緒數量。您可以將其設定為 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 為基礎的 MSK 佈建叢集，如果您使用 Apache ZooKeeper 命令來新增代理程式，這些代理程式不會新增至 MSK 佈建叢集，而且您的 Apache ZooKeeper 將包含有關叢集的不正確資訊。這可能會導致資料遺失。如需支援的 MSK 佈建叢集操作，請參閱 [Amazon MSK 主要功能和概念](operations.md)。
### 啟用傳輸中加密
如需傳輸中加密及如何啟用的相關資訊，請參閱 [傳輸中的 Amazon MSK 加密](msk-encryption.md#msk-encryption-in-transit)。
### 重新指派分割區
若要將分割區移至相同 MSK 佈建叢集上的不同代理程式，您可以使用名為 的分割區重新指派工具`kafka-reassign-partitions.sh`。我們建議您在單一`kafka-reassign-partitions`呼叫中不要為安全操作重新指派超過 10 個分割區。例如，在您新增代理程式以展開叢集或移動分割區以移除代理程式之後，您可以透過將分割區重新指派給新的代理程式來重新平衡該叢集。如需如何將代理程式新增至 MSK 佈建叢集的詳細資訊，請參閱 [擴展 Amazon MSK 叢集中的代理程式數量](msk-update-broker-count.md)。如需如何從 MSK 佈建叢集中移除代理程式的詳細資訊，請參閱 [從 Amazon MSK 叢集中移除代理系統](msk-remove-broker.md)。如需有關分割區重新指派工具的詳細資訊，請參閱 Apache Kafka 文件中的 [擴充您的叢集](https://kafka.apache.org/documentation/#basic_ops_cluster_expansion)。