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

# 最佳實務：最佳化應用程式伺服器的數目
<a name="best-practices-autoscale"></a>

**重要**  
 AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援 團隊。

生產堆疊通常包含分散於多個可用區域的多部應用程式伺服器。不過，依據日期時間或週中的日，傳入的請求數目可能會有大幅差異。您可以執行足以處理最大預期負載數量的伺服器，但大多數情況下，您最後支付的伺服器容量都比實際需要的多。為了有效地執行您的站點，建議的實務就是讓伺服器數目與目前的請求數量相符。

OpsWorks Stacks 提供三種方法來管理伺服器執行個體的數量。
+ [全年無休執行個體](workinginstances-starting.md)為手動啟動，並會持續執行到手動停止為止。
+ Stacks OpsWorks 會根據使用者指定的排程自動啟動和停止[時間型執行個體](workinginstances-autoscaling.md)。
+ [當 Stacks 超過 CPU 或記憶體使用率等使用者指定負載指標的閾值時，負載型執行個體](workinginstances-autoscaling.md)會自動啟動和停止。 OpsWorks 

**注意**  
在建立和設定堆疊的時間式和負載式執行個體之後， OpsWorks Stacks 即會根據指定的組態自動啟動和停止這些執行個體。除非您決定變更組態或執行個體數目，否則您都不需要更動它們。

**建議：**如果您管理的堆疊上有很多個應用程式伺服器執行個體，我們建議您混合使用這三種執行個體類型。下列範例說明如何管理堆疊的伺服器容量，以處理具備下列特點的不同每日請求數量。
+ 平均請求數量會在一天中出現正弦曲線般的差異。
+ 平均請求數量最少要 5 個應用程式伺服器執行個體。
+ 平均請求數量最多要 16 個應用程式伺服器執行個體。
+ 通常，一或兩個應用程式伺服器執行個體即可處理遽增的請求數量。

這種便利的模型主要是基於討論用途而設，但您可以輕鬆地順應請求數量的變動來調整，也可以擴展這個模型以處理每週的變動。下圖說明如何使用這三種執行個體類型來管理此請求數量。

![\[Graph showing instance types over 24 hours: time-based, load-based, and 24/7, with average load curve.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/autoscaling.png)


此範例具有下列特性：
+ 堆疊具備 3 個全年無休執行個體，這些執行個體絕不中斷並會持續處理基本負載。
+ 堆疊具備 12 個時間式執行個體，這些執行個體是設定為處理平均每日變動。

  其中一個從下午 10 點執行到上午 2 點，另外兩個從下午 8 點執行到下午 10 點和上午 2 點執行到上午 4 點，以此類推。為求簡化，此圖表會每兩小時修改一次時間式執行個體，但如果您需要更精確的控制，則可以每小時修改一次數目。
+ 此堆疊具備的負載式執行個體足以處理超過全年無休和時間式執行個體可處理的流量高峰。

  OpsWorks Stacks 只有在所有目前執行中伺服器的負載超過指定的指標時，才會啟動負載型執行個體。非執行中執行個體的成本極低 (Amazon EBS 後端執行個體） 或沒有任何成本 （執行個體存放區後端執行個體），因此建議的做法是建立足夠的執行個體，以輕鬆處理您預期的最大請求磁碟區。在這個範例中，堆疊應該至少有三個負載式執行個體。

**注意**  
請務必將這所有三種執行個體類型分散於多個可用區域，以降低任何服務中斷的影響。