Amazon ECS 容量和可用性 - Amazon Elastic Container Service
最大化擴展速度處理需求衝擊

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

Amazon ECS 容量和可用性

應用程式可用性對於提供無錯誤體驗和將應用程式延遲降至最低至關重要。可用性取決於擁有可存取的資源，以及足夠的容量以滿足需求。 AWS 提供數種機制來管理可用性。對於您在 Amazon ECS 上託管的應用程式，這些包括自動擴展和可用區域 (AZs)。Autoscaling 會根據您定義的指標來管理任務或執行個體的數量，而可用區域可讓您將應用程式託管在隔離但地理位置封閉的位置。

與任務大小一樣，容量和可用性存在您必須考慮的特定權衡。在理想情況下，容量將與需求完全一致。永遠只有足夠容量來為請求和程序任務提供服務，以滿足服務水準目標 (SLOs)，包括低延遲和錯誤率。容量永遠不會太高，導致成本過高；也不會太低，導致高延遲和錯誤率。

Autoscaling 是一種潛在程序。首先，CloudWatch 必須接收即時指標。然後，CloudWatch 需要彙總它們進行分析，這可能需要幾分鐘的時間，具體取決於指標的精細程度。CloudWatch 會將指標與警示閾值進行比較，以識別資源不足或過多的情況。為了防止不穩定，您應該設定警示，要求在警示關閉之前超過設定的閾值幾分鐘。佈建新任務和終止不再需要的任務也需要一些時間。

由於這些潛在的系統延遲，您應該透過過度佈建來維持一些空間。過度佈建有助於因應短期的需求暴增。這也有助於您的應用程式服務額外的請求，而不會達到飽和。作為最佳實務，您可以將擴展目標設定為使用率的 60-80%。這有助於您的應用程式更好地處理大量額外需求，同時額外容量仍在佈建中。

我們建議您過度佈建的另一個原因是，以便您可以快速回應可用區域故障。 AWS 建議從多個可用區域提供生產工作負載。這是因為如果發生可用區域故障，您在剩餘可用區域中執行的任務仍然可以滿足需求。如果您的應用程式在兩個可用區域中執行，您需要將正常任務計數加倍。如此一來，您就可以在任何潛在的故障期間提供立即的容量。如果您的應用程式在三個可用區域中執行，我們建議您執行正常任務計數的 1.5 倍。也就是說，為一般服務所需的每兩個執行三個任務。

最大化擴展速度

Autoscaling 是一種反應式程序，需要一些時間才能生效。不過，有一些方法可協助將擴展所需的時間降至最低。

將影像大小降至最低。較大的映像需要更長的時間才能從映像儲存庫下載並解壓縮。因此，保持較小的影像大小可減少容器啟動所需的時間量。若要減少影像大小，您可以遵循下列特定建議：

  • 如果您可以建置靜態二進位檔或使用 Golang，請建置映像FROM暫存區，並在產生的映像中僅包含二進位應用程式。

  • 使用上游分發廠商的最小化基礎映像，例如 Amazon Linux 或 Ubuntu。

  • 請勿在最終映像中包含任何建置成品。使用多階段建置有助於達成此目的。

  • 盡可能精簡RUN的階段。每個RUN階段都會建立新的映像層，進而產生額外的往返以下載層。具有由 聯結之多個命令的單一RUN階段&&，其層數少於具有多個RUN階段的層。

  • 如果您想要在最終映像中包含 ML 推論資料等資料，請僅包含啟動和開始服務流量所需的資料。如果您隨需從 Amazon S3 或其他儲存體擷取資料而不影響服務，請改為將您的資料存放在這些位置。

保持影像關閉。網路延遲越高，下載映像所需的時間就越長。將映像託管在工作負載所在的相同 AWS 區域中的儲存庫中。Amazon ECR 是高效能映像儲存庫，可在 Amazon ECS 提供的每個區域中使用。避免周遊網際網路或 VPN 連結以下載容器映像。在相同區域中託管映像可改善整體可靠性。它可降低不同區域中網路連線問題和可用性問題的風險。或者，您也可以實作 Amazon ECR 跨區域複寫來協助執行此操作。

降低負載平衡器運作狀態檢查閾值。負載平衡器會在傳送流量至應用程式之前執行運作狀態檢查。目標群組的預設運作狀態檢查組態可能需要 90 秒或更長的時間。在此期間，負載平衡器會檢查運作狀態並接收請求。降低運作狀態檢查間隔和閾值計數可讓應用程式更快地接受流量，並減少其他任務的負載。

考慮冷啟動效能。有些應用程式使用執行時間，例如 Java Just-In-Time(JIT) 編譯。編譯程序至少會在啟動時顯示應用程式效能。解決方法是以不會造成冷啟動效能懲罰的語言重寫工作負載的延遲關鍵部分。

使用步驟擴展，而不是目標追蹤擴展政策。您有多個適用於 Amazon ECS 任務的 Application Auto Scaling 選項。目標追蹤是最容易使用的模式。這樣一來，您僅需要為指標設定目標值，例如 CPU 平均使用率。然後，自動縮放器會自動管理獲得該值所需的任務數量。使用步驟擴展，您可以更快對需求變化做出反應，因為您定義了擴展指標的特定閾值，以及超越閾值時要新增或刪除的任務數量。而且，更重要的是，您可以透過最大限度減少閾值警報違反的時間來對需求變化做出非常快速的反應。如需詳細資訊，請參閱《Amazon Elastic Container Service 開發人員指南》中的服務自動擴展。

如果您使用 Amazon EC2 執行個體來提供叢集容量，請考慮下列建議：

使用較大的 Amazon EC2 執行個體和更快的 Amazon EBS 磁碟區。您可以使用較大的 Amazon EC2 執行個體和更快的 Amazon EBS 磁碟區來改善映像下載和準備速度。在指定的 Amazon EC2 執行個體系列中，網路和 Amazon EBS 最大輸送量會隨著執行個體大小的增加而增加 （例如，從 m5.xlarge到 m5.2xlarge)。此外，您也可以自訂 Amazon EBS 磁碟區，以提高其輸送量和 IOPS。例如，如果您使用的是 gp2磁碟區，請使用可提供更多基準輸送量的較大磁碟區。如果您使用的是磁碟gp3區，請在建立磁碟區時指定輸送量和 IOPS。

針對在 Amazon EC2 執行個體上執行的任務使用橋接網路模式。在 Amazon EC2 上使用bridge網路模式的任務啟動速度比使用awsvpc網路模式的任務快。使用awsvpc網路模式時，Amazon ECS 會先將彈性網路界面 (ENI) 連接至執行個體，再啟動任務。這會導致額外的延遲。不過，使用橋接聯網有幾個權衡。這些任務無法取得自己的安全群組，而且負載平衡有一些影響。如需詳細資訊，請參閱 Elastic Load Balancing 使用者指南中的負載平衡器目標群組。

處理需求衝擊

有些應用程式會突然發生需求大幅衝擊。發生這種情況的原因有很多：新聞事件、大型銷售、媒體事件或一些其他會傳播並導致流量在非常短的時間內快速大幅增加的事件。如果未計劃，這可能會導致需求快速超過可用資源。

處理需求衝擊的最佳方法是預測並相應地進行規劃。由於自動擴展可能需要一些時間，我們建議您在需求衝擊開始之前擴展應用程式。為了獲得最佳結果，我們建議制定業務計畫，該計畫涉及使用共用行事曆的團隊之間的緊密協作。規劃事件的團隊應事先與負責應用程式的團隊緊密合作。這可讓該團隊有足夠的時間制定明確的排程計畫。他們可以排定容量在事件之前向外擴展，並在事件之後向內擴展。如需詳細資訊，請參閱《Application Auto Scaling 使用者指南》中的排程擴展。

如果您有企業支援計劃，也請務必與您的技術客戶經理 (TAM) 合作。您的 TAM 可以驗證您的服務配額，並確保在事件開始之前提出任何必要的配額。如此一來，您就不會意外達到任何服務配額。它們也可以透過預熱負載平衡器等服務來協助您，以確保您的事件順利進行。

處理未排程的需求衝擊是較困難的問題。如果振幅夠大，未排程的震動可能會快速導致需求超過容量。它也可以超過自動擴展做出反應的能力。準備非排定衝擊的最佳方法是過度佈建資源。您必須有足夠的資源，以隨時處理最大預期流量需求。

在預期非排定需求衝擊時維持最大容量可能會很昂貴。若要降低成本影響，請尋找預測大量需求衝擊的領導指標或事件即將到來。如果指標或事件可靠地提供重大的預先通知，請在事件發生或指標超過您設定的特定閾值時立即開始橫向擴展程序。

如果您的應用程式容易突然發生未排程的需求衝擊，請考慮為應用程式新增高效能模式，以犧牲非關鍵功能，但保留重要的功能給客戶。例如，假設您的應用程式可以從產生昂貴的自訂回應切換為提供靜態回應頁面。在此案例中，您可以大幅提高輸送量，完全不需要擴展應用程式。

最後，您可以考慮分開單體服務，以更好地處理需求衝擊。如果您的應用程式是執行成本高昂且擴展速度緩慢的單體服務，您可能可以擷取或重寫效能關鍵片段，並以個別服務的形式執行它們。然後，這些新服務可以獨立於較不關鍵的元件進行擴展。靈活地將效能關鍵功能與應用程式的其他部分分開擴展，可以同時減少增加容量和節省成本所需的時間。