本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# Amazon ECS 自動擴展與容量管理最佳實務
您可以在 Amazon ECS 上執行規模各異的容器化應用程式工作負載。這涵蓋了從最小化的測試環境到在全球範圍內運作的大規模生產環境。
如同所有 AWS 服務，使用 Amazon ECS 時，您只需支付使用量的費用。當您妥當規劃應用程式架構時，便能透過僅在需要時使用所需資源來節省成本。
下列建議說明如何在滿足服務等級目標的同時，以具成本效益的方式執行 Amazon ECS 工作負載。
**Topics**
+ [決定 Amazon ECS 的任務大小](capacity-tasksize-best-practice.md)
+ [最佳化 Amazon ECS 服務自動擴展](capacity-autoscaling-best-practice.md)
+ [Amazon ECS 容量與可用性](capacity-availability-best-practice.md)
+ [Amazon ECS 叢集容量](capacity-cluster-best-practice.md)
+ [為 Amazon ECS 選擇 Fargate 任務大小](fargate-task-size-best-practice.md)
+ [使用 Amazon EC2 容量提供者加速 Amazon ECS 叢集容量佈建](capacity-cluster-speed-up-ec2-best-practice.md)
# 決定 Amazon ECS 的任務大小
在 Amazon ECS 上部署容器時，容器與任務的大小設定是最關鍵的決策之一。容器與任務大小對於擴展和容量規劃至關重要。
Amazon ECS 使用兩種容量資源指標：CPU 與記憶體。Amazon ECS 以完整 vCPU 的 1/1024 為單位計量 CPU (其中 1024 個單位等於 1 個完整 vCPU)。Amazon ECS 以 MB 為單位計量記憶體。
在任務定義中，您可以宣告資源保留量與限制。
宣告保留量時，您要宣告任務所需的資源數量下限。任務至少會收到請求的資源量。應用程式實際使用的 CPU 或記憶體，可能會超出設定的保留量。但這受您同時宣告的所有限制的約束。
使用超過保留數量稱為爆量。爆量表示應用程式使用的資源超過保留的資源量，但會保持在您宣告的限制內。Amazon ECS 會保證保留量。例如，若使用 Amazon EC2 執行個體提供容量，當無法滿足保留量需求時，Amazon ECS 不會將該任務置放於該執行個體上。
限制是容器或任務所能使用的 CPU 單位或記憶體的最大數量。如果容器嘗試使用的 CPU 單位超過此限制，Amazon ECS 會對其進行限流。如果容器嘗試使用的記憶體超過此限制，Amazon ECS 會停止容器。
精準選擇這些值可能具有挑戰性。最適合應用程式的值，在很大程度上取決於應用程式的資源需求。
對應用程式進行負載測試，是成功規劃資源需求的關鍵。負載測試有助進一步了解應用程式的需求。
## 無狀態應用程式
對於可水平擴展的無狀態應用程式 (如負載平衡器後端的應用程式)，建議先判斷應用程式在處理請求時所耗用的記憶體量。
為此，您可以使用 `ps` 或 `top` 等傳統工具。您也可以使用 CloudWatch Container Insights 等監控解決方案。
在決定 CPU 保留量時，需考量如何擴展應用程式來滿足業務需求。
您可以使用較小的 CPU 保留量，例如 256 個 CPU 單位 (或 1/4 vCPU)，以將成本降至最低的精細方式橫向擴充。但此方式可能無法快速應對需求的大幅激增。
您可以使用較大的 CPU 保留量來更快地進行縮減與橫向擴充。這可協助您更快地應對需求激增情況。但較大的 CPU 保留量會帶來更高的成本。
## 其他應用程式
對於無法水平擴展的應用程式 (例如單例工作線程或資料庫伺服器)，可用容量與成本是最重要的考量因素。
根據負載測試的結果選擇記憶體與 CPU 的配置量，確保能應對流量並達成服務水準目標。Amazon ECS 可確保應用程式置放在具有足夠容量的主機上。
# 最佳化 Amazon ECS 服務自動擴展
Amazon ECS 服務是受管任務集合。每個服務都有相關聯的任務定義、所需任務計數以及選用的置放策略。
Amazon ECS 服務自動擴展功能透過應用程式自動擴展服務實現。應用程式自動擴展服務使用 CloudWatch 指標作為擴展指標的來源。該服務也會使用 CloudWatch 警示來設定關於何時縮減或橫向擴充服務的閾值。
您需提供擴展閾值。您可以設定稱為*目標追蹤擴展*的指標目標。您也可以指定稱為*步進擴展*的閾值。
設定應用程式自動擴展之後，該服務會持續為應用程式計算最適的任務數量目標值。當需要透過橫向擴充或縮減來調整任務數量時，該服務也會即時通知 Amazon ECS 進行相應變更。
若要有效使用服務自動擴展功能，您必須選擇適當的擴展指標。我們將在以下章節中探討如何選擇指標。
## 描述應用程式特性
若要適當地擴展應用程式，您必須了解縮減與橫向擴充應用程式的相關條件。
本質上，如果預測需求會超出容量，則應橫向擴充應用程式。相反地，如果資源超過需求，則應縮減應用程式以節省成本。
### 識別使用率指標
若要有效進行擴展，您必須識別能表示使用率或飽和度的指標。此指標需具備以下特性，才能有效用於擴展操作。
+ 該指標必須與需求相關聯。當資源保持穩定但需求變更時，指標值也必須隨之變化。需求增加或減少時，指標應隨之上升或下降。
+ 指標數值必須與容量成比例縮減。當需求保持不變時，增加更多資源必須使指標數值產生相應比例的變化。例如，將任務數量加倍，應使指標降低 50%。
識別使用率指標的最佳方法是透過生產前環境 (例如預備環境) 中的負載測試進行識別。市面上有許多商業與開源的負載測試解決方案可供使用。這類解決方案通常既能產生模擬負載，也能模擬真實使用者流量。
開始進行負載測試時，您應先為應用程式的使用率指標建置儀表板。這些指標包括 CPU 使用率、記憶體使用率、I/O 操作、I/O 佇列深度與網路輸送量。您可以透過 CloudWatch Container Insights 等服務收集這些指標。您也可以搭配使用 Amazon Managed Service for Prometheus 與 Amazon Managed Grafana 來收集這些指標。在此過程中，請務必收集並繪製應用程式的回應時間或工作完成率等指標。
進行負載測試時，請從較低的請求量或任務插入率開始。維持此速率數分鐘，讓應用程式完成暖機。接著，緩慢提高速率並穩定維持幾分鐘。重複此循環，逐步提高速率，直至應用程式的回應時間或完成時間過慢，無法達到服務水準目標 (SLO) 為止。
進行負載測試時，請檢查每個使用率指標。隨負載增加而上升的指標，是作為最佳使用率指標的首要候選對象。
然後，識別達到飽和的資源。同時，也請檢查使用率指標，觀察哪一項會率先在高位趨於平緩。或者，觀察哪項指標會最先達到峰值，而後導致應用程式當機。例如，若 CPU 使用率在您新增負載時從 0% 增加至 70-80%，而在您新增更多負載之後，會保持在該層級，則表示 CPU 已飽和。根據 CPU 架構，該使用率可能永遠不會達到 100%。例如，假設記憶體使用率隨著新增負載而增加，然後應用程式在達到任務或 Amazon EC2 執行個體記憶體限制時突然當機。這種情況通常意味著記憶體資源已完全耗盡。應用程式可能會消耗多種資源。因此，請選擇代表先耗盡之資源的指標。
最後，將任務數量或 Amazon EC2 執行個體數量加倍後，再次進行負載測試。此時假設關鍵指標的增長率或下降率為先前的一半。若情況確實如此，則表示該指標與容量成比例。這正是適用於自動擴展的良好使用率指標。
現在請考量下列假設案例。假設對應用程式進行負載測試，發現 CPU 使用率最終在每秒 100 個請求的負載下達到 80%。當您新增更多負載時，CPU 使用率不會再增加。不過，這樣確實會讓應用程式回應速度變慢。然後，再次執行負載測試，將任務數量加倍，但將速率保持在先前的峰值。如果發現平均 CPU 使用率降至約 40%，則平均 CPU 使用率是適合作為擴展指標的良好候選對象。另一方面，如果增加任務數量後，CPU 使用率仍維持在 80%，則平均 CPU 使用率並不適合作為擴展指標。此時便需進一步探尋合適的監控指標。
### 常見應用模型與擴展屬性
您可以在 AWS上執行各種軟體。許多工作負載是企業自行開發的，而其他工作負載則是以熱門的開放原始碼軟體為基礎。無論其來源為何。我們觀察到服務存在一些常見的設計模式。如何有效擴展，很大程度上取決於所採用的模式。
#### 高效的 CPU 密集型伺服器
高效的 CPU 密集型伺服器幾乎不使用 CPU 與網路輸送量以外的資源。每個請求均可由應用程式單獨處理。請求不依賴其他服務，例如資料庫。應用程式可以處理數十萬個並行請求，並可高效利用多顆 CPU 來達成此目標。每個請求要麼由記憶體負荷低的專用執行緒處理，要麼由每個 CPU 上執行的非同步事件迴圈處理。應用程式的每個副本都具備同等的請求處理能力。在 CPU 耗盡前，唯一可能耗盡的資源是網路頻寬。在 CPU 密集型服務中，即使處於峰值輸送量，記憶體使用率也僅佔可用資源的一小部分。
對此類應用程式，您可以使用 CPU 型自動擴展。這類應用程式在擴展面向享有最大的彈性。您可以透過提供更大的 Amazon EC2 執行個體或 Fargate vCPU 來進行垂直擴展，也可以透過新增副本來進行水平擴展。無論是新增副本數量，還是將執行個體大小加倍，都會將相對於容量的平均 CPU 使用率減半。
如果為此應用程式使用 Amazon EC2 容量，建議將其置放於運算最佳化執行個體上，例如 `c5` 或 `c6g` 系列。
#### 高效率的記憶體密集型伺服器
高效率的記憶體密集型伺服器會為每個請求配置大量記憶體。在最大並行數下，但未必是最大輸送量時，記憶體會先於 CPU 資源耗盡。與請求相關聯的記憶體會在請求結束時釋放。只要有可用記憶體，就能接受更多請求。
對此類應用程式，您可以使用記憶體型自動擴展。這類應用程式在擴展面向享有最大的彈性。您可以透過提供更大的 Amazon EC2 或 Fargate 記憶體資源來進行垂直擴展，也可以透過新增副本來進行水平擴展。無論是新增副本數量，還是將執行個體大小加倍，都會將相對於容量的平均記憶體使用率減半。
如果為此應用程式使用 Amazon EC2 容量，建議將其置放於記憶體最佳化的執行個體上，例如 `r5` 或 `r6g` 系列。
有些記憶體密集型應用程式不會在請求結束時釋放與之相關聯的記憶體，因此並行量減少時，已使用的記憶體也不會相應減少。對此，我們不建議使用記憶體型擴展方式。
#### 工作線程型伺服器
工作線程型伺服器會透過個別的工作執行緒逐一處理請求。工作執行緒可以是輕量型執行緒 (例如 POSIX 執行緒)，也可以是重量型執行緒 (例如 UNIX 程序)。無論是哪種類型的執行緒，應用程式所能支援的最大並行數都存在上限。通常，並行上限會依據可用的記憶體資源按比例設定。若達到並行上限，應用程式會將額外請求放入待處理佇列。若待處理佇列溢滿，應用程式會立即拒絕後續傳入的請求。符合此模式的常見應用程式包括 Apache 網頁伺服器與 Gunicorn。
請求並行數通常是此類應用程式最適合的擴展指標。由於每個副本都有並行上限，因此在達到平均上限前進行橫向擴充至關重要。
取得請求並行數指標的最佳方式，是讓應用程式將資料回傳至 CloudWatch。應用程式的每個副本都可以高頻率發布並行請求數作為自訂指標。建議頻率至少設定為每分鐘一次。收集多次回傳資料之後，即可將平均並行數作為擴展指標。此指標的計算方式是將總並行數量除以副本數量。例如，若並行總數為 1000，而副本數量為 10，則平均並行數為 100。
如果應用程式位於 Application Load Balancer 後端，您也可以使用負載平衡器的 `ActiveConnectionCount` 指標作為擴展指標的因素。必須將 `ActiveConnectionCount` 指標除以副本數量取得平均值。再使用該平均值進行擴展，而非直接採用原始計數值。
若要使此設計達到最佳效果，回應延遲的標準偏差應該在低請求速率時保持較小。建議在低需求期間，大多數請求能在短時間內得到回應，且不會有大量請求的回應時間顯著超過平均值。平均回應時間應接近第 95 百分位數回應時間。若未達此標準，可能引發佇列溢滿，進而觸發錯誤。建議在必要時提供額外副本，降低溢滿風險。
#### 等候型伺服器
等候型伺服器會為每個請求執行部分處理，但高度依賴一或多個下游服務才能運作。容器應用程式通常會大量使用資料庫與其他 API 服務等下游服務。這些服務可能需要一段時間才能回應，尤其在高容量或高並行場景中更為明顯。這是因為這類應用程式往往使用較少的 CPU 資源，其並行上限主要取決於可用記憶體容量。
等候型服務可能適用於記憶體密集型伺服器模式或工作線程型伺服器模式，具體取決於應用程式的設計方式。如果應用程式的並行數僅受記憶體限制，則應使用平均記憶體使用率作為擴展指標。如果應用程式的並行數基於工作線程限制，則應使用平均並行數作為擴展指標。
#### Java 型伺服器
如果 Java 型伺服器是 CPU 密集型伺服器，且能隨 CPU 資源成比例擴展，則可能適用於高效 CPU 密集型伺服器模式。在此情況下，平均 CPU 使用率可能適合作為擴展指標。然而，許多 Java 應用程式並非 CPU 密集型，這使得擴展難以進行。
為取得最佳效能，建議將盡可能多的記憶體配置給 Java 虛擬機器 (JVM) 堆積。JVM 的最新版本 (包括 Java 8 Update 191 或更新版本)，皆會自動將堆積大小設定為容器內可容納的最大值。這表示在 Java 中，記憶體使用率鮮少與應用程式使用率成正比。隨著請求速率和並行數量增加，記憶體使用率仍保持不變。因此，我們不建議根據記憶體使用率擴展 Java 型伺服器。反之，我們通常會建議基於 CPU 使用率進行擴展。
在某些情況下，Java 型伺服器會在 CPU 耗盡前先遭遇堆積記憶體耗盡的問題。如果應用程式在高並行時容易發生堆記憶體耗盡，則平均連接數是最佳擴展指標。如果應用程式在高輸送量時容易發生堆積記憶體耗盡，則平均請求速率是最佳擴展指標。
#### 使用其他具垃圾回收執行時期的伺服器
許多伺服器應用程式基於具備垃圾回收功能的執行時期 (例如 .NET 和 Ruby) 開發。這些伺服器應用程式可能符合前文描述的某種模式。然而，與 Java 類似，我們不建議依據記憶體來擴展這些應用程式，因為觀測到的平均記憶體使用率通常與輸送量或並行量不相關。
對這些應用程式而言，若屬於 CPU 密集型，建議基於 CPU 使用率進行擴展。否則，建議根據負載測試結果，基於平均輸送量或平均並行數進行擴展。
#### 任務處理器
許多工作負載涉及非同步任務處理。其中包括並非即時接收請求，而是透過訂閱工作佇列接收任務的應用程式。對此類應用程式而言，合適的擴展指標幾乎都是佇列深度。佇列成長表明待處理工作超過了處理能力，而空佇列表示處理能力多於實際工作需求。
AWS 訊息服務，例如 Amazon SQS 和 Amazon Kinesis Data Streams，提供可用於擴展的 CloudWatch 指標。對於 Amazon SQS，最佳指標為 `ApproximateNumberOfMessagesVisible`。對於 Kinesis Data Streams，建議使用 Kinesis Client Library (KCL) 發布的 `MillisBehindLatest` 指標。使用此指標進行擴展前，應先計算所有消費者的平均值。
# Amazon ECS 容量與可用性
應用程式的可用性至關重要，不僅能提供無錯誤的使用體驗，還有助於減少應用程式的延遲。可用性取決於擁有可存取的資源，以及足夠的容量以滿足需求。 AWS 提供數種機制來管理可用性。對於在 Amazon ECS 上託管的應用程式，這些機制包括自動擴展與可用區域 (AZ)。自動擴展會根據您定義的指標來管理任務或執行個體的數量，而可用區域可讓您將應用程式託管在相互隔離但地理位置相近的位置。
與任務大小一樣，容量與可用性之間也存在必須權衡的取捨。在理想情況下，容量應與需求完全一致。系統將一律保有足夠的容量來處理請求與任務，以達成服務水準目標 (SLO) 目標，包括低延遲與錯誤率。容量不會過高而導致成本過高，也不會過低而造成高延遲與高錯誤率。
自動擴展是一個存在延遲的過程。首先，CloudWatch 必須接收即時指標。接著，CloudWatch 需要彙總這些指標進行分析，根據指標的粒度不同，這個過程可能需要長達幾分鐘。隨後，CloudWatch 會將指標與警示閾值進行比對，判斷資源是否短缺或過剩。為避免系統不穩定，您應將警示設定為：需持續超過設定閾值幾分鐘後，警示才會觸發。此外，佈建新任務與終止不再需要的任務也需要時間。
由於系統中存在這些潛在延遲，您應採用過度佈建方式來保留一些緩衝空間。過度佈建有助於因應短期的需求突增。這也有助於應用程式在不達到飽和狀態的前提下處理更多請求。建議將擴展目標設定在使用率的 60-80% 之間。此舉能幫助應用程式在額外容量仍在佈建過程中時，更好地應對突增的額外需求。
我們建議您過度佈建的另一個原因是，以便您可以快速回應可用區域故障。 AWS 建議從多個可用區域提供生產工作負載。這是因為，如果某個可用區域發生失敗，在剩餘可用區域中執行的任務仍能持續處理需求。如果應用程式在兩個可用區域中執行，則需要將常規任務數量加倍。如此一來，您就可以在任何潛在的故障期間立即提供足夠容量。如果應用程式在三個可用區域中執行，建議將任務數量設定為常規需求的 1.5 倍。也就是說，每需要 2 個任務來處理日常請求，就應部署 3 個任務。
## 最大限度提高擴展速度
自動擴展是一種反應式程序，需要一些時間才能生效。不過，有一些方法可協助將橫向擴充所需的時間降至最低。
**最小化映像大小。**較大的映像需要更長的時間，才能從映像儲存庫下載並解壓縮。因此，保持較小的映像大小可減少容器啟動所需的時間量。若要減小映像大小，您可以遵循下列特定建議：
+ 如果您可以建置靜態二進位檔案或使用 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 平均使用率。然後，自動縮放器會自動管理獲得該值所需的任務數量。使用步驟擴展，您可以更快對需求變化做出反應，因為您定義了擴展指標的特定閾值，以及超越閾值時要新增或刪除的任務數量。而且，更重要的是，您可以透過最大限度減少閾值警報違反的時間來對需求變化做出非常快速的反應。如需詳細資訊，請參閱《Amazon Elastic Container Service 開發人員指南》**中的[服務自動擴展](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-auto-scaling.html)。
如果使用 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 User Guide* 中的 [Load balancer target groups](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-target-groups.html)。
## 因應需求衝擊
部分應用程式可能遭遇突發性的大量需求衝擊。發生這種情況的原因有很多：新聞事件、大型促銷活動、媒體事件，或者一些其他會迅速傳播並導致流量在非常短的時間內快速大幅增加的事件。如果未加以規劃，這可能會導致需求快速超過可用資源。
因應需求衝擊的最佳方法是預測需求衝擊並相應地進行規劃。由於自動擴展可能需要一些時間，建議您在需求衝擊開始之前橫向擴充應用程式。為達到最佳效果，建議制定一套結合跨團隊協作的業務計畫，其中應包含採用共用行事曆的緊密協作機制。活動規劃團隊應提前與負責應用程式的團隊緊密合作。這能讓負責應用程式的團隊有足夠時間制定明確的排程計畫。他們可以排定容量，在事件之前進行橫向擴充，並在事件之後進行縮減。如需詳細資訊，請參閱《Application Auto Scaling 使用者指南》中的[排程擴展](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-scheduled-scaling.html)。
如果有企業支援方案，也請務必與您的技術客戶經理 (TAM) 合作。技術客戶經理可以核實您的服務配額，並確保在事件開始之前提高任何必要的配額。如此一來，您就不會意外達到任何服務配額上限。此外，技術客戶經理亦可透過預先啟動負載平衡器等服務的暖機程序，確保活動順利進行。
因應未經排程的需求衝擊是一個更棘手的問題。若幅度夠大，未經排程的衝擊可能會迅速導致需求超過容量，甚至使自動擴展來不及反應。應對未經排程衝擊的最佳方式是過度佈建資源。您必須隨時擁有足夠的資源來因應預期的最大流量需求。
為因應未經排程的需求衝擊而維持最大容量可能耗費頗鉅。若要降低成本影響，可尋找能預測大規模需求衝擊即將發生的領先指標或事件。如果指標或事件能穩定提供足夠的預警時間，則在事件發生時，或指標超過您設定的特定閾值時，立即啟動水平擴展程序。
如果應用程式容易遭遇突發且未經排程的需求衝擊，可考慮為應用程式新增高效能模式。該模式會犧牲非關鍵功能，但保留對客戶而言至關重要的功能。例如，假設應用程式可從產生耗費資源的客製化回應，切換為提供靜態回應頁面。在此案例中，您無需對應用程式進行任何擴展，就能顯著提升輸送量。
最後，您可考慮拆分單體式服務，更高效地因應需求衝擊。如果應用程式是執行成本高昂且擴展速度緩慢的單體式服務，您也許可以擷取或重寫效能關鍵部分，並將其作為個別服務執行。如此，這些新服務便能獨立於非關鍵元件進行擴展。具備單獨橫向擴充應用程式中效能關鍵功能的彈性，不僅可縮短新增容量的時間，也有助於節省成本。
# Amazon ECS 叢集容量
您可以透過多種方式為 Amazon ECS 叢集提供容量。例如，您可以啟動 Amazon EC2 執行個體，並在啟動時使用 Amazon ECS 容器代理程式將其註冊至叢集。不過，這種方法可能較具挑戰性，因為您需要自行管理擴展。因此，建議採用 Amazon ECS 容量提供者。容量提供者會自動管理資源擴展。容量提供者有三種：Amazon EC2、Fargate 與 Fargate Spot。如需有關 Fargate 容量提供者的詳細資訊，請參閱 [Fargate 工作負載的 Amazon ECS 叢集](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/fargate-capacity-providers.html)；如需有關 EC2 工作負載的詳細資訊，請參閱 [EC2 工作負載的 Amazon ECS 叢集](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/asg-capacity-providers.html)。
Fargate 與 Fargate Spot 容量提供者會為您處理 Fargate 任務的生命週期。Fargate 提供隨需容量，而 Fargate Spot 則提供 Spot 容量。當您啟動任務時，Amazon ECS 會自動佈建 Fargate 資源。此 Fargate 資源隨附的記憶體與 CPU 單位，直接對應您於任務定義中宣告的任務層級限制。每個任務都會收到專用 Fargate 資源，從而在任務與運算資源之間建立 1:1 的關係。
執行於 Fargate Spot 上的任務可能會中斷。中斷會在發出兩分鐘的警告後發生。此類情況通常發生於需求高峰期間。Fargate Spot 最適合能夠容忍中斷的工作負載，例如批次任務、開發或預備環境。其也適用於其他不要求高可用性與低延遲的情況。
您可以將 Fargate Spot 任務與 Fargate 隨需任務一同執行。透過同時使用兩者，您能以較低的成本取得「高載」容量供應。
Amazon ECS 也能為您管理任務的 Amazon EC2 執行個體容量。每個 Amazon EC2 容量提供者都會與您指定的 Amazon EC2 Auto Scaling 群組建立關聯。當您使用 Amazon EC2 容量提供者時，叢集自動擴展會維持 Amazon EC2 Auto Scaling 群組的大小，確保可以置放所有排程任務。
# 為 Amazon ECS 選擇 Fargate 任務大小
對於 AWS Fargate 任務定義，您必須在任務層級指定 CPU 和記憶體，而且不需要考慮任何額外負荷。您也可以指定 Fargate 任務之容器層級的 CPU 和記憶體。不過，不需要這麼做。資源限制必須大於或等於您宣告的任何保留量。在大多數情況下，您可以將其設定為任務定義中宣告的每個容器的保留量總和。然後將數值向上取整至最接近的 Fargate 大小。如需有關可用大小的詳細資訊，請參閱[任務 CPU 與記憶體](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/fargate-tasks-services.html#fargate-tasks-size)。
# 使用 Amazon EC2 容量提供者加速 Amazon ECS 叢集容量佈建
在 Amazon EC2 上執行 Amazon ECS 的客戶，可以利用 [Amazon ECS 叢集自動擴展 (CAS)](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/cluster-auto-scaling.html) 來管理 Amazon EC2 Auto Scaling 群組 (ASG) 的擴展。透過 CAS，您可以設定 Amazon ECS 自動擴展 ASG，從而專注於執行任務。Amazon ECS 將確保 ASG 視需求進行擴展與縮減，無需額外人工介入。Amazon ECS 容量提供者可用來管理叢集中的基礎結構，確保有足夠的容器執行個體可滿足應用程式需求。如需了解 Amazon ECS CAS 的運作方式，請參閱 [Deep Dive on Amazon ECS Cluster Auto Scaling](https://aws.amazon.com/blogs/containers/deep-dive-on-amazon-ecs-cluster-auto-scaling/)。
由於 CAS 依賴與 ASG 的 CloudWatch 型整合來調整叢集容量，其本身存在固有延遲，包括：發布 CloudWatch 指標所需的時間、指標 `CapacityProviderReservation` 觸發 CloudWatch 高/低閾值警報的處理時間，以及新啟動 Amazon EC2 執行個體完成暖機所需的週期。您可以採取下列動作提高 CAS 的回應速度，加速實現部署：
## 容量提供者步進擴展大小
Amazon ECS 容量提供者最終將擴增/縮小容器執行個體，以滿足應用程式的需求。將 Amazon ECS 會啟動的執行個體數量下限預設為 1。如果需要多個執行個體來放置待處理任務，可能會增加部署所需的時間。您可以透過 Amazon ECS API 增加 [https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ManagedScaling.html](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ManagedScaling.html)，提高 Amazon ECS 每次可縮減或擴展的執行個體數量下限。太低的 [https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ManagedScaling.html](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ManagedScaling.html) 會限制每次可縮減或擴展的容器執行個體數量，進而拖慢部署速度。
**注意**
此組態目前只能透過 [https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateCapacityProvider.html](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateCapacityProvider.html) 或 [https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateCapacityProvider.html](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateCapacityProvider.html) API 使用。
## 執行個體暖機期間
執行個體暖機期間是指新啟動的 Amazon EC2 執行個體納入 Auto Scaling 群組 CloudWatch 指標統計前的一段時間。在指定的暖機期間到期後，執行個體才會納入 ASG 的彙總指標計算；而 CAS 會接著進行其下一輪計算，以估算所需的執行個體數量。
[https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ManagedScaling.html#ECS-Type-ManagedScaling-instanceWarmupPeriod](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ManagedScaling.html#ECS-Type-ManagedScaling-instanceWarmupPeriod) 的預設值為 300 秒，您可透過 [https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateCapacityProvider.html](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateCapacityProvider.html) 或 [https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateCapacityProvider.html](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateCapacityProvider.html) API 將其設定為較低的值，從而實現更即時的擴展。
## 備用容量
如果容量提供者沒有可用於置放任務的容器執行個體，就必須透過即時啟動 Amazon EC2 執行個體來增加 (橫向擴充) 叢集容量，並等待這些執行個體啟動完成後才能在其上部署容器。這會大幅降低任務啟動速率。對此，您有兩種選擇。
在這種情況下，若事先啟動並準備好可用於執行任務的 Amazon EC2 備用容量，即能提高有效的任務啟動速率。您可以透過 `Target Capacity` 組態來指定希望叢集維持的備用容量。例如，將 `Target Capacity` 設定為 80%，即指定叢集需隨時保留 20% 的備用容量。這些備用容量可讓任何獨立任務立即啟動，確保任務啟動不會受到限流。但此方法的權衡在於，維持叢集備用容量可能會增加成本。
另一種替代方法是為服務增加緩衝空間，而非為容量提供者設定。這意味著，您不必透過降低 `Target Capacity` 組態來啟動備用容量，而是可以藉由修改服務自動擴展的目標追蹤擴展指標或步進擴展閾值，直接增加服務中的副本數量。請注意，此方法僅對突發性工作負載有效；在部署新服務並首次從 0 擴展至 N 個任務時，則無法發揮作用。如需有關相關擴展政策的詳細資訊，請參閱[目標追蹤擴展政策](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-autoscaling-targettracking.html)或[步進擴展政策](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-autoscaling-stepscaling.html)