最佳實務：最佳化應用程式伺服器的數目

重要

該 AWS OpsWorks Stacks 服務於 2024 年 5 月 26 日終止使用壽命，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載移轉至其他解決方案。如果您對移轉有任何疑問，請透過 AWS Re: post 或透過進AWS 階 Support 與 AWS Support 團隊聯絡。

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

AWS OpsWorks 堆疊提供三種管理伺服器執行個體數目的方式。

• 全年無休執行個體為手動啟動，並會持續執行到手動停止為止。

• AWS OpsWorks Stacks 會按照使用者指定的排程自動啟動和停止以時間為基礎的執行個體。

• 當 AWS OpsWorks 堆疊超過使用者指定的負載指標 (例如 CPU 或記憶體使用率) 的臨界值時，以負載為基礎的執行個體會自動啟動和停止。

注意

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

建議：如果您管理的堆疊上有很多個應用程式伺服器執行個體，我們建議您混合使用這三種執行個體類型。下列範例說明如何管理堆疊的伺服器容量，以處理具備下列特點的不同每日請求數量。

• 平均請求數量會在一天中出現正弦曲線般的差異。

• 平均請求數量最少要 5 個應用程式伺服器執行個體。

• 平均請求數量最多要 16 個應用程式伺服器執行個體。

• 通常，一或兩個應用程式伺服器執行個體即可處理遽增的請求數量。

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

此範例具有下列特性：

• 堆疊具備 3 個全年無休執行個體，這些執行個體絕不中斷並會持續處理基本負載。

• 堆疊具備 12 個時間式執行個體，這些執行個體是設定為處理平均每日變動。

  其中一個從下午 10 點執行到上午 2 點，另外兩個從下午 8 點執行到下午 10 點和上午 2 點執行到上午 4 點，以此類推。為求簡化，此圖表會每兩小時修改一次時間式執行個體，但如果您需要更精確的控制，則可以每小時修改一次數目。

• 此堆疊具備的負載式執行個體足以處理超過全年無休和時間式執行個體可處理的流量高峰。

  AWS OpsWorks 只有當所有目前執行中伺服器的負載超過指定的指標時，堆疊才會啟動以載入為基礎的執行個體。非執行中執行個體的成本最低 (Amazon EBS 支援的執行個體) 或沒有 (執行個體存放區支援的執行個體)，因此建議的做法是建立足夠的執行個體，以便輕鬆處理預期的最大請求量。在這個範例中，堆疊應該至少有三個負載式執行個體。

注意

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