容量與可用

應用程式可用性對於提供無錯誤的體驗和最小化應用程式延遲至關重要。可用性取決於具有可存取且具有足夠容量來滿足需求的資源。AWS提供數種機制來管理可用性。對於 Amazon ECS 託管的應用程式，這些應用程式包括自動擴展和可用區域 (AZ)。自動調整會根據您定義的度量來管理工作或執行個體的數目，而可用區域則可讓您將應用程式託管在隔離但地理位置相當近的位置。

與任務規模一樣，容量和可用性存在某些權衡，您必須考慮。理想情況下，容量將完全符合需求。總是有足夠的容量來服務要求和處理工作，以滿足服務層級目標 (SLO)，包括低延遲和錯誤率。容量永遠不會太高，導致成本過高；也不會太低，導致高延遲和錯誤率。

自動調整是一個潛在的過程。首先，必須將即時指標傳遞至 CloudWatch。然後，它們需要進行彙總以進行分析，這可能需要長達數分鐘的時間，視量度的粒度而定。CloudWatch 會將指標與警示臨界值進行比較，以識別資源短缺或過量。若要防止不穩定，請設定警報，以便在鬧鐘響起前超過設定的臨界值數分鐘。它也需要一些時間來佈建新的任務和終止不再需要的任務。

由於系統中所描述的這些潛在延遲，因此您必須透過過過度佈建來維持一些預留空間。這樣做可以幫助容納短期突發的需求。這也有助於您的應用程式在不達到飽和度的情況下服務額外的請求。最好的做法是，您可以將縮放目標設定在使用率的 60-80% 之間。這有助於您的應用程式更好地處理額外需求的高載，而額外的容量仍在佈建過程中。

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

擴展速度最大化

自動調整是一個反應過程，需要時間才能生效。不過，有一些方法可協助將擴充所需的時間降至最低。

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

• 如果您可以構建靜態二進製文件或使用 Golang，請構建您的圖像FROM從頭開始，並在結果圖像中僅包含您的二進制應用程序。

• 使用來自上游發行版廠商 (例如 Amazon Linux 或 Ubuntu) 的最小化基礎映像檔。

• 不要在最終圖像中包含任何構建工件。使用多階段構建可以幫助解決這個問題。

• 精簡RUN階段，盡可能。每個RUN階段會建立新的影像圖層，導致下載圖層的額外往返。單一RUN階段，該階段具有多個由&&的圖層少於具有多個RUN階段。

• 如果您想要在最終影像中包含資料 (例如 ML 推論資料)，請僅包含啟動和開始服務流量所需的資料。如果您在不影響服務的情況下從 Amazon S3 或其他儲存中隨選取資料，請將資料存放在這些地方。

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

降低負載平衡器運作狀態檢查臨界值。 負載平衡器會先執行健全狀況檢查，再將流量傳送至應用程式。目標群組的預設健全狀況檢查組態可能需要 90 秒或更長的時間。在此期間，它會檢查健康狀態和接收要求。降低運作狀態檢查間隔和臨界值計數可讓您的應用程式更快接受流量，並減少其他工作的負載。

考慮冷啟動效能。 某些應用程序使用運行時，例如 Java 執行剛剛在時間（JIT）編譯。編譯過程至少在啟動時可以顯示應用程序性能。解決方法是以不會造成冷啟動效能損失的語言重寫工作負載的延遲關鍵部分。

使用步驟擴展政策，而不是目標追蹤擴展政策。 Amazon ECS 任務有數個 Application Auto Scaling 選項。目標追蹤是最容易使用的模式。有了它，您只需要設定測量結果的目標值，例如 CPU 平均使用率。然後，自動縮放器會自動管理達到該值所需的任務數量。不過，我們建議您改用步驟縮放比例，以便您可以更快速地回應需求的變更。使用步驟縮放，您可以定義縮放測量結果的特定臨界值，以及超過臨界值時要新增或移除的工作數目。此外，更重要的是，您可以將臨界值警報違反的時間減至最少，以便快速對需求變化做出反應。如需詳細資訊，請參閱「」Service Auto Scaling中的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 執行個體上執行的任務，使用橋接網路模式。 使用的任務bridge網路模式 Amazon EC2 啟動速度比使用awsvpc網路模式。時機awsvpc網路模式時，Amazon ECS 會在啟動任務之前將 elastic network interface (ENI) 附加至執行個體。這會引入額外的延遲。儘管如此，使用橋接網絡有幾個權衡。這些工作不會取得自己的安全性群組，而且負載平衡有一些含義。如需詳細資訊，請參閱「」負載平衡器目標群組中的Elastic Load Balancing 使用者。

處理需求衝擊

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

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

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

處理未定期的需求衝擊是一個更困難的問題。如果振幅足夠大的非排程衝擊，可能會迅速導致需求超出容量。它也可以超越自動調整反應的能力。準備意外衝擊的最佳方式是過度佈建資源。您必須擁有足夠的資源，才能隨時處理最大預期的流量需求。

預期未排定的需求衝擊時，維持最大容量可能會成本很高。若要減輕成本影響，請找出可預測即將發生大量需求衝擊的領先指標指標或事件。如果度量或事件可靠地提供重要的預先通知，當事件發生或度量超過您設定的特定臨界值時，立即開始向外延展程序。

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

最後，您可以考慮打破整體服務，以更好地處理需求衝擊。如果您的應用程序是執行昂貴且擴展速度緩慢的單一服務，您可能可以提取或重寫性能關鍵部分，並將其作為單獨的服務運行。然後，這些新服務可以獨立於較不重要的元件進行擴充。彈性地將效能關鍵功能與應用程式的其他部分分開擴充，既可減少增加容量所需的時間，也有助於節省成本。