優化 Amazon ECS 服務 auto 擴展

Amazon ECS 服務是受管的任務集合。每個服務都有關聯的任務定義、所需的任務計數以及可選的放置策略。Amazon ECS 服務 auto 擴展是透過 Application Auto Scaling 服務實作的。「Application Auto Scaling」會使用 CloudWatch 指標做為擴展指標的來源。它還使用 CloudWatch 警報來設置閾值，以確定何時擴展服務擴展或縮小。您可以設定測量結果目標 (稱為目標追蹤調整)，或指定臨界值 (稱為步驟調整)，來提供調整的臨界值。設定「Application Auto Scaling」之後，它會持續計算服務的適當所需工作計數。它還會在所需的任務計數發生變化ECS時通知 Amazon，無論是向外擴展或擴展。

若要有效地使用服務 auto 調整規模，您必須選擇適當的擴展指標。

如果預測需求大於目前的容量，應該向外擴充應用程式。相反地，當資源超出需求時，應用程式也可以進行擴充，以節省成本。

識別度量

為了有效擴展，識別指示使用率或飽和度的指標至關重要。此量度必須顯示下列屬性，才能用於縮放比例。

• 量度必須與需求相關。當資源保持穩定但需求變更時，量度值也必須變更。當需求增加或減少時，量度應增加或減少。

• 度量值必須按照容量成比例調整。當需求保持不變時，新增更多資源必須導致標準值的比例變更。因此，將任務數量加倍應導致指標減少 50％。

識別使用率指標的最佳方法是在生產前環境 (例如測試環境) 中進行負載測試。商業和開源負載測試解決方案已廣泛使用。這些解決方案通常可以產生合成負載或模擬真實的使用者流量。

若要開始負載測試程序，請為應用程式的使用率指標建立儀表板。這些指標包括CPU使用率、記憶體使用率、I/O 作業、I/O 佇列深度和網路輸送量。您可以透過服務 (例如容器深入解析) 收集這些指標。如需詳細資訊，請參閱使用ECS容器洞察來監控 Amazon 容器。在此過程中，請確定您收集並繪製應用程式回應時間或工作完成率的指標。

從一個小的請求或工作插入率開始。將此速率保持穩定數分鐘，以便您的應用程序進行預熱。然後，慢慢增加速度並保持穩定幾分鐘。重複此週期，每次都會增加速率，直到應用程式的回應或完成時間太慢，無法達到您的服務層級目標為止 (SLOs)。

在負載測試時，檢查每個使用率指標。隨負載而增加的指標是作為最佳使用率指標的主要候選人。

接下來，確定達到飽和度的資源。同時，還要檢查使用率指標，以查看哪一個先在高級別扁平化，或者達到峰值，然後首先崩潰您的應用程序。例如，如果在添加負載時CPU使用率從 0％ 增加到 70-80％，那麼在添加更多負載後保持在該級別，那麼可以肯定地說CPU是飽和的。根據CPU架構的不同，它可能永遠不會達到 100％。例如，假設記憶體使用率隨著您增加負載而增加，當應用程式達到任務或 Amazon EC2 執行個體記憶體限制時突然當機。在這種情況下，很可能是內存已完全消耗的情況。您的應用程式可能會耗用多個資源。因此，請選擇代表首先耗盡資源的指標。

最後，在任務或 Amazon EC2 執行個體數量加倍後，再次嘗試負載測試。假設關鍵量度以前一半的速率增加或減少。如果是這種情況，則度量與容量成正比。這是 auto 調整規模的良好使用率指標。

現在考慮這種假設的情況。假設您負載測試應用程式，並發現每秒 100 個要求時，CPU使用率最終達到 80%。當添加更多負載時，它不會再使CPU利用率提高。但是，它確實使您的應用程序響應速度更慢。然後，您再次運行負載測試，將任務數量加倍，但將速率保持在其先前的峰值。如果您發現平均CPU使用率降至大約 40%，則平均CPU使用率是擴展指標的理想選擇。另一方面，如果CPU使用率在增加任務數量後仍保持在 80％，則平均CPU使用率不是一個很好的擴展指標。在這種情況下，需要更多的研究來找到合適的指標。

一般應用程式模型和縮放屬性

各種軟件都在上運行 AWS。許多工作負載都是本土開發的，而其他工作負載則以熱門的開放原始碼 無論它們的起源如何，我們都觀察到了一些常見的服務設計模式。如何有效縮放在很大程度上取決於陣列。

高效率的CPU伺服器

高效的CPU綁定服務器除CPU了網絡吞吐量之外幾乎不使用其他資源。每個請求都可以由應用程序單獨處理。請求不依賴於其他服務，例如數據庫。該應用程序可以處理數十萬個並發請求，並且可以有效地利用多個請求CPUs來執行此操作。每個請求都是由具有低內存開銷的專用線程提供服務，或者有一個異步事件循環在每CPU個服務請求上運行。應用程式的每個複本同樣能夠處理要求。之前可能耗盡的唯一資源CPU是網絡帶寬。在CPU邊界服務中，即使在尖峰輸送量的情況下，記憶體使用率也只是可用資源的一小部分。

這種類型的應用程序適用於CPU基於 auto 縮放。該應用程序在擴展方面享有最大的靈活性。它可以通過提供更大的 Amazon EC2 實例或 Fargate vCPUs 來垂直擴展。而且，它也可以通過添加更多複本水平縮放。新增更多複本或將執行個體大小增加一倍，相對於容量的平均CPU使用率減少一半。

如果您將 Amazon EC2 容量用於此應用程式，請考慮將其放置在運算優化執行個體上，例如c5或c6g系列。

高效率的記憶體繫結伺服器

高效率的記憶體繫結伺服器會為每個要求配置大量記憶體。在最大並行 (但不一定是輸送量) 下，記憶體會在CPU資源耗盡之前耗盡。要求結束時，會釋放與要求相關聯的記憶體。只要有可用的記憶體，就可以接受其他要求。

這種類型的應用程序適用於基於內存的 auto 縮放。該應用程序在擴展方面享有最大的靈活性。它可以通過向其提供更大的 Amazon EC2 或 Fargate 內存資源來垂直擴展。而且，它也可以通過添加更多複本水平縮放。新增更多複本或將執行個體大小增加一倍，可以將相對於容量的平均記憶體使用率減少一半。

如果您將 Amazon EC2 容量用於此應用程式，請考慮將其放在記憶體最佳化的執行個體上，例如r5或r6g系列。

有些記憶體繫結應用程式在結束時不會釋放與要求相關聯的記憶體，因此減少並行運算不會導致使用的記憶體減少。為此，我們不建議您使用以記憶體為基礎的縮放。

以工作者為基礎的伺服器

以 Worker 為基礎的伺服器會依次處理每個個別 Worker 執行緒的一個要求。工作線程可以是輕量級線程，例如POSIX線程。它們也可以是重量較重的線程，例如過程。UNIX無論它們是哪個線程，應用程序總是可以支持的最大並發性。通常，並行限制會按比例設定為可用的記憶體資源。如果達到並行限制，則會將其他要求放入待處理佇列中。如果積壓佇列溢位，則會立即拒絕其他內送要求。適合這種模式的常見應用程序包括 Apache 的 Web 服務器和 Gunicorn。

請求並行通常是擴展此應用程序的最佳指標。因為每個複本都有並行限制，因此在達到平均限制之前向外擴充是很重要的。

取得要求並行量度的最佳方式是讓您的應用程式將其報告給 CloudWatch。應用程式的每個複本都可以高頻發佈並行要求數量，做為自訂量度。我們建議將頻率設定為每分鐘至少一次。收集數個報告之後，您可以使用平均並行作為縮放量度量。此量度的計算方式是將並行總數除以複本數目。例如，如果並行總數為 1000，而複本數為 10，則平均並行為 100。

如果您的應用程式位於應用程式負載平衡器之後，您也可以使用負載平衡器的ActiveConnectionCount指標作為擴展指標中的一個因素。ActiveConnectionCount測量結果必須除以複本數目，才能取得平均值。平均值必須用於縮放，而不是原始計數值。

為了使此設計發揮最佳效果，在低請求率下，響應延遲的標準差應該很小。我們建議在需求不足的期間，大部分的要求都會在短時間內得到回應，而且沒有太多要求的時間比平均回應時間長得多。平均回應時間應接近第 95 個百分位數的回應時間。否則，可能會導致佇列溢位。這會導致錯誤。我們建議您在必要時提供其他複本，以減輕溢位的風險。

等待伺服器

等待伺服器會針對每個要求執行一些處理，但高度依賴於一個或多個下游服務才能運作。容器應用程式通常會大量使用下游服務，例如資料庫和其他API服務。這些服務可能需要一些時間才能回應，特別是在高容量或高並行情況下。這是因為這些應用程序傾向於使用很少的CPU資源，並在可用內存方面利用其最大並發性。

等待服務適用於記憶體繫結伺服器模式或以工作者為基礎的伺服器模式，視應用程式的設計方式而定。如果應用程式的並行僅受記憶體限制，則應使用平均記憶體使用率作為擴展指標。如果應用程式的並行是以 Worker 限制為基礎，則應使用平均並行作為縮放量度量。

基於 Java 的服務器

如果您的基於 Java 的服務器是CPU綁定的，並且按比例擴展到CPU資源，那麼它可能適合高效CPU的綁定服務器模式。在這種情況下，平均CPU使用率可能適合作為擴展指標。但是，許多 Java 應用程序沒有CPU綁定，這使得它們難以擴展。

為了獲得最佳效能，建議您將盡可能多的記憶體配置給 Java 虛擬機器 (JVM) 堆積。的最新版本 (包括 Java 8 更新 191 或更新版本) 會自動設定盡可能大的堆集大小以符合容器。JVM這表示在 Java 中，記憶體使用率很少與應用程式使用率成正比。隨著請求率和並發性的增加，內存使用率保持不變。因此，我們不建議根據記憶體使用率來擴展 Java 型伺服器。相反，我們通常建議根據CPU使用率進行擴展。

在某些情況下，基於 Java 的服務器在耗盡之前會遇到堆耗盡。CPU如果您的應用程式容易在高並行時出現堆積耗盡，則平均連線是最佳的擴展指標。如果您的應用程式容易在高輸送量下出現堆積耗盡，則平均要求率是最佳的擴展指標。

使用其他垃圾收集執行階段的伺服器

許多伺服器應用程式都以執行記憶體回收的執行階段為基礎，例如. NET和紅寶石。這些伺服器應用程式可能適合先前描述的其中一種模式。但是，與 Java 一樣，我們不建議根據記憶體擴展這些應用程式，因為它們觀察到的平均記憶體使用率通常與輸送量或並行無關。

對於這些應用程式，如果應用程式已繫結，建議您根據CPU使用率進CPU行調整。否則，建議您根據負載測試結果，根據平均輸送量或平均並行擴展。

Job 處理器

許多工作負載涉及非同步工作處理 它們包括不會即時接收要求，而是訂閱工作佇列以接收工作的應用程式。對於這些類型的應用程式，適當的擴展指標幾乎總是佇列深度。佇列成長表示待處理工作超過處理能力，而空白佇列則表示有比工作更多的容量。

AWS 簡訊服務 (例如 Amazon SQS 和 Amazon Kinesis Data Streams) 提供可用於擴展的 CloudWatch指標。對於 Amazon 來說SQS，ApproximateNumberOfMessagesVisible是最好的指標。對於 Kinesis Data Streams，請考慮使用 Kinesis 用戶端程式庫 () KCL 所發佈的MillisBehindLatest量度。在使用此指標進行擴展之前，應先對所有消費者進行平均。