本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
優化 Amazon ECS 容量和可用性
應用程式可用性對於提供無錯誤的體驗，以及將應用程式延遲降至最低至關 可用性取決於具有足夠容量以滿足需求的可用資源。 AWS 提供數種機制來管理可用性。對於 Amazon 上託管的應用程式ECS，其中包括自動調度資源和可用區域 (AZs)。自動調度資源會根據您定義的指標來管理工作或執行個體的數量，而可用區域則可讓您將應用程式託管在隔離但靠近地理位置的位置。
與任務規模一樣，容量和可用性存在您必須考慮的某些權衡。理想情況下，容量將與需求完全一致。永遠有足夠的容量來處理要求和處理工作，以符合服務等級目標 (SLOs)，包括低延遲和錯誤率。容量永遠不會太高，導致成本過高；也不會太低，從而導致高延遲和錯誤率。
自動調度資源是一個潛在的過程。首先，必須將即時指標傳遞給 CloudWatch。然後，需要將它們彙總以進行分析，這可能需要長達幾分鐘的時間，具體取決於指標的粒度。 CloudWatch 將測量結果與警示臨界值進行比較，以識別資源短缺或過多。為了防止不穩定，請將警報配置為要求在警報關閉之前超過設定的閾值幾分鐘。佈建新任務和終止不再需要的任務也需要時間。
由於系統上所描述的這些可能延遲，因此請務必透過過度佈建來維持一些預留空間。這樣做可以幫助滿足短期的需求爆發。這也有助於您的應用程序在不飽和的情況下服務其他請求。最好的做法是，您可以將擴展目標設定在使用率的 60-80% 之間。這有助於您的應用程式更有效地處理突發的額外需求，而額外的容量仍在佈建的過程中。
我們建議您過度佈建的另一個原因是，您可以快速回應可用區域故障。我們建議從多個可用區域提供生產工作負載。這是因為，如果發生可用區域失敗，在剩餘可用區域中執行的工作仍然可以滿足需求。如果您的應用程式在兩個可用區域中執行，則需要將正常工作計數加倍。這樣您就可以在任何潛在的故障期間立即提供容量。如果您的應用程式在三個可用區域中執行，建議您執行正常工作計數的 1.5 倍。也就是說，為普通服務所需的每兩個運行三個任務。
最大化縮放速度
自動調度資源是一種反應過程，需要時間才能生效。但是，有一些方法可以幫助最大程度地減少擴展所需的時間。
最小化圖像大小。較大的影像需要較長的時間才能從映像儲存庫下載並解壓縮。因此，保持較小的影像大小可減少容器啟動所需的時間量。要減小圖像大小，您可以遵循以下具體建議：
-
如果您可以構建靜態二進製文件或使用 Golang，請構建映像
FROM暫存並在生成的映像中僅包含二進製應用程序。 -
使用來自上游發行版供應商（例如 Amazon Linux 或 Ubuntu）的最小化基本映像。
-
不要在最終映像中包含任何構建工件。使用多階段構建可以幫助解決此問題。
-
盡可能緊湊的
RUN階段。每個RUN階段都會創建一個新的圖像圖層，從而導致額外的往返下載圖層。結合多個指令的單一RUN階段，所&&擁有的圖層少於具有多個RUN階段的圖層。 -
如果您想要在最終映像中包含 ML 推論資料之類的資料，請僅包含啟動和開始提供流量所需的資料。如果您在不影響服務的情況下從 Amazon S3 或其他儲存視需求擷取資料，請改為將資料存放在這些位置。
保持您的圖像靠近。網路延遲時間越高，下載映像檔所需的時間越長。將映像託管在工作負載所在的相同區域中的儲存庫中。Amazon ECR 是一個高性能的圖像存儲庫，可在 Amazon 可用的每ECS個區域中使用。避免遍歷互聯網或下載容器映像的VPN鏈接。在同一區域託管圖像可提高整體可靠性。它減輕了不同區域中網絡連接問題和可用性問題的風險。或者，您也可以實作 Amazon ECR 跨區域複寫，以協助進行此操作。
降低負載平衡器健康狀態檢查閾值 負載平衡器會在傳送流量至應用程式之前執行健康狀態檢查。目標群組的預設健全狀況檢查組態可能需要 90 秒或更長時間。在此期間，負載平衡器會檢查健康狀態並接收要求。降低健全狀況檢查間隔和臨界值計數可讓您的應用程式更快接受流量，並減少其他工作的負載。
考慮冷啟動效能。一些應用程序使用運行時，如 Java 執行即時（）編譯。JIT編譯過程至少在啟動時可以顯示應用程序性能。解決方法是使用不會造成冷啟動效能損失的語言來重新撰寫工作負載的延遲關鍵部分。
使用步驟調整，而不是目標追蹤擴展政策。工作有數個「Application Auto Scaling」選項。目標追蹤是最容易使用的模式。有了它，您只需要設置指標的目標值，例如CPU平均使用率。然後，自動縮放器會自動管理獲得該值所需的任務數量。使用步驟擴展，您可以更快對需求變化做出反應，因為您定義了擴展指標的特定閾值，以及超越閾值時要新增或刪除的任務數量。而且，更重要的是，您可以透過最大限度減少閾值警報違反的時間來對需求變化做出非常快速的反應。如需詳細資訊，請參閱服務 Auto Scaling。
如果您使用 Amazon EC2 執行個體提供叢集容量，請考慮下列建議：
使用更大的 Amazon EC2 實例和更快的 Amazon EBS 卷。您可以使用更大的 Amazon EC2 執行個體和更快的 Amazon 磁EBS碟區來提高映像下載和準備速度。在指定的執行個體系列中，網路和 Amazon EBS 最大輸送量會隨著執行個體大小的增加而增加 (例如，從m5.xlarge到m5.2xlarge)。此外，您還可以自訂 Amazon EBS 磁碟區以增加其輸送量和IOPS. 例如，如果您使用gp2磁碟區，請使用可提供更多基準輸送量的較大磁碟區。如果您使用gp3磁碟區，請指定輸送量以及建立磁碟區的IOPS時間。
對 Amazon EC2 執行個體上執行的任務使用橋接網路模式。Amazon 上使用bridge網路模式的任務EC2開始速度比使用awsvpc網路模式的任務快。使用awsvpc網路模式時，Amazon 會在啟動任務之前將 elastic network interface (ENI) ECS 附加至執行個體。這會引入額外的延遲。儘管如此，使用橋接網絡有幾種權衡。這些工作不會取得自己的安全性群組，而且負載平衡會有一些含意。如需詳細資訊，請參閱《E lastic Load Balancing 使用者指南》中的負載平衡器目標群組。
處理需求衝擊
某些應用程序遇到突然的大衝擊需求。發生這種情況的原因有多種：新聞事件，大型銷售，媒體活動或其他一些事件，會傳播病毒並導致流量在很短的時間內快速顯著增加。如果未計劃，這可能會導致需求快速超出可用資源。
處理需求衝擊的最佳方法是預測它們並進行相應的計劃。由於自動調度資源可能需要一些時間，因此建議您在需求衝擊開始之前向外擴充應用程式。為了獲得最佳效果，我們建議制定一個商業計劃，該計劃涉及使用共享日曆的團隊之間的緊密協作。籌劃活動的團隊應提前與負責申請的團隊緊密合作。這為該團隊提供了足夠的時間來制定明確的計劃。他們可以排程容量以在活動開始前向外擴展，並在活動結束後擴展。如需詳細資訊，請參閱《Application Auto Scaling 使用者指南》中的排程擴展。
如果您有企業 Support 方案，請務必與您的技術客戶經理合作 (TAM)。您TAM可以驗證您的服務配額，並確保在活動開始之前提出任何必要的配額。如此一來，您就不會意外碰到任何服務配額。他們還可以通過預熱負載平衡器等服務來幫助您，以確保您的活動順利進行。
處理不定期的需求衝擊是一個更困難的問題。不定期的衝擊，如果振幅足夠大，可能會迅速導致需求超出容量。它也可能超過自動調度資源的反應能力。為非計劃衝擊做好準備的最佳方法是過度佈建資源。您必須擁有足夠的資源，以便隨時處理最大的預期流量需求。
在預期意外需求衝擊的情況下維持最大容量可能會非常昂貴。為了減輕成本影響，請找到一個領先的指標指標或預測大量需求衝擊的事件即將到來。如果量度或事件可靠地提供明顯的預先通知，請在事件發生或量度超過您設定的特定臨界值時立即開始向外延展程序。
如果您的應用程式容易遭受突然的非排程需求衝擊，請考慮在應用程式中加入高效能模式，以犧牲非關鍵功能，但為客戶保留重要功能。例如，假設您的應用程式可以從產生昂貴的自訂回應切換到提供靜態回應頁面。在這個案例中，您可以大幅增加輸送量，完全不需要擴展應用程式。
您可以考慮打破整體服務，以更好地應對需求衝擊。如果您的應用程式是執行成本昂貴且擴充速度緩慢的整合式服務，您可能可以擷取或重寫效能關鍵部分，並以個別服務的形式執行它們。然後，這些新服務可以獨立於不太重要的組件進行擴展。與應用程式的其他部分分開擴充關鍵效能功能的彈性，既能縮短增加容量所需的時間，也能協助節省成本。
