自動調整規模

  • 發行項

自動調整是以動態方式配置資源以符合效能需求的程序。 隨著工作量的成長，應用程式可能需要額外的資源來保有所需的效能層級及滿足服務等級協定 (SLA)。 當需要降低而不再需要其他資源，可以將它們解除配置以將成本降至最低。

自動調整會充分利用雲端裝載環境的彈性，以降低管理額外負荷。 其可減少操作員持續監視系統效能的需求，並做出有關新增或移除資源的決策。

應用程式有兩種主要方式可調整：

  • 垂直調整也稱為相應增加和減少，表示變更資源的容量。 例如，您可以將應用程式移至較大的 VM 大小。 垂直調整通常需要讓系統在重新部署時暫時無法使用。 因此，自動化垂直調整比較不常見。

  • 水平調整也稱為相應放大和縮小，表示新增或移除資源的實例。 在佈建這些新資源時，應用程式會繼續執行而不中斷。 布建程式完成時，解決方案會部署在這些額外的資源上。 如果需求下降，可以完全關閉其他資源並解除分配。

許多雲端式系統，包括 Microsoft Azure，都支援自動水平調整。 本文的其餘部分著重於水平調整。

注意

自動調整主要適用於計算資源。 雖然可以水平調整資料庫或消息佇列，但這通常牽涉到 數據分割，這通常不會自動化。

自動調整元件

自動調整策略通常涉及下列部分：

  • 應用程式、服務和基礎結構層級的檢測和監視系統。 這些系統會擷取關鍵計量，例如響應時間、佇列長度、CPU 使用率和記憶體使用量。
  • 針對預先定義的臨界值或排程評估這些計量的決策邏輯，並決定是否要調整。
  • 調整系統的元件。
  • 測試、監視和調整自動調整策略，以確保其如預期般運作。

Azure 提供解決常見案例的內建自動調整機制。 如果特定服務或技術沒有內建的自動調整功能，或具有超出其功能的特定自動調整需求，您可能會考慮自定義實作。 自定義實作會收集作業和系統計量、分析計量，然後據以調整資源。

設定 Azure 解決方案的自動調整

Azure 提供適用於大部分計算選項的內建自動調整。

  • Azure 虛擬機器 透過虛擬機擴展集自動調整，以群組方式管理一組虛擬機。 請參閱 如何使用自動調整和虛擬機擴展集。

  • Service Fabric 也支援透過虛擬機擴展集進行自動調整。 Service Fabric 叢集中的每個節點類型都會設定為個別的虛擬機擴展集。 如此一來，每個節點類型都可以獨立相應縮小或相應放大。 請參閱 使用自動調整規則相應縮小或相應放大 Service Fabric 叢集。

  • Azure App 服務 具有內建的自動調整。 自動調整設定會套用至 App Service 內的所有應用程式。 請參閱手動或自動調整實例計數，並在 Azure App 服務 相應增加應用程式。

這些計算選項全都使用 Azure 監視器自動調整 來提供一組常見的自動調整功能。

  • Azure Functions 與先前的計算選項不同，因為您不需要設定任何自動調整規則。 相反地，Azure Functions 會在程式代碼執行時自動配置計算能力，視需要相應放大來處理負載。 如需詳細資訊，請參閱 選擇正確的 Azure Functions 主控方案。

最後，自定義自動調整解決方案有時可能很有用。 例如，您可以使用 Azure 診斷 和應用程式型計量，以及自定義程式代碼來監視和導出應用程式計量。 然後，您可以根據這些計量定義自定義規則，並使用 Resource Manager REST API 來觸發自動調整。 不過，自定義解決方案並不容易實作，而且只有在上述任何方法都無法滿足您的需求時，才應考慮使用。

如果您的需求符合您的需求，請使用平臺的內建自動調整功能。 如果沒有，請仔細考慮您是否真的需要更複雜的調整功能。 其他需求的範例可能包括更細微的控制、偵測觸發事件的觸發事件調整方式、跨訂用帳戶調整，以及調整其他類型的資源。

使用 Azure 監視器自動調整

Azure 監視器自動調整為虛擬機擴展集、Azure App 服務 和 Azure 雲端服務提供一組常見的自動調整功能。 調整可以依排程執行，或根據運行時間計量執行，例如 CPU 或記憶體使用量。

範例：

  • 相應放大為工作日的 10 個實例，並在星期六和星期日相應縮小為 4 個實例。
  • 如果平均 CPU 使用量超過 70%，則相應放大一個實例，如果 CPU 使用量低於 50%，則相應縮小一個實例。
  • 如果佇列中的訊息數目超過特定閾值，請相應放大一個實例。

當負載增加時相應增加資源，以確保可用性。 同樣地，在使用量低時相應減少，因此您可以將成本優化。 一律使用向外延展和相應縮小規則組合。 否則，自動調整只會以一個方向進行，直到達到配置檔中設定的臨界值（最大值或最小實例計數）。

選取適用於您工作負載的預設實例計數。 如果未設定最大或最小實例計數，則會根據該值進行調整。

如需內建計量的清單，請參閱 Azure 監視器自動調整一般計量。 您也可以使用 Application Insights 來實作自定義計量。

您可以使用 PowerShell、Azure CLI、Azure Resource Manager 樣本或 Azure 入口網站 來設定自動調整。 如需更詳細的控制，請使用 Azure Resource Manager REST API。 Azure 監視服務管理連結庫和 Microsoft Insights 連結庫（預覽版）是 SDK，可讓您從不同的資源收集計量，並使用 REST API 來執行自動調整。 對於無法使用 Azure Resource Manager 支援的資源，或如果您使用 Azure 雲端服務，服務管理 REST API 可用於自動調整。 在其他所有情況下，請使用 Azure Resource Manager。

使用 Azure 自動調整時，請考慮下列幾點：

  • 請考慮您是否可以準確地預測應用程式上的負載，以使用排程的自動調整、新增和移除實例，以符合預期的需求尖峰。 如果無法這樣做，請使用以運行時間計量為基礎的響應式自動調整，以處理無法預期的需求變更。 一般而言，您可以結合這些方法。 例如，建立策略，根據您知道應用程式最忙碌的時間排程來新增資源。 這有助於確保在需要時可以使用容量，而不需要啟動新實例的任何延遲。 針對每個排程規則，定義計量，以在該期間允許響應式自動調整，以確保應用程式可以處理持續但無法預測的需求尖峰。

  • 通常很難瞭解計量與容量需求之間的關聯性，特別是一開始部署應用程式時。 一開始布建一點額外的容量，然後監視和調整自動調整規則，讓容量更接近實際負載。

  • 設定自動調整規則，然後監視應用程式一段時間的效能。 使用此監視的結果，視需要調整系統調整的方式。 不過，請記住，自動調整不是瞬間的程式。 需要時間來回應計量，例如超過指定閾值的平均 CPU 使用率（或低於）。

  • 根據測量觸發程式屬性使用偵測機制的自動調整規則（例如 CPU 使用量或佇列長度）會隨著時間使用匯總值，而不是即時值來觸發自動調整動作。 根據預設，匯總是值的平均值。 這可防止系統反應太快，或造成快速振蕩。 它也允許自動啟動的新實例開始進入執行模式的時間，防止新實例啟動時發生額外的自動調整動作。 針對 Azure 雲端服務 和 Azure 虛擬機器，匯總的預設期間為 45 分鐘，因此計量最多可能需要這段時間，才能觸發自動調整，以回應需求尖峰。 您可以使用 SDK 來變更匯總期間，但少於 25 分鐘的期間可能會導致無法預期的結果。 對於 Web Apps，平均期間要短得多，允許在變更平均觸發程式量值后大約五分鐘內提供新的實例。

  • 避免 在 相應縮小和向外延展動作持續回溯的地方進行擷取。 假設有兩個實例，上限為 80% CPU，下限為 60%。 當負載為 85%，則會新增另一個實例。 經過一段時間之後，負載會減少到 60%。 在相應縮小之前，自動調整服務會在移除實例時計算總負載（三個實例）的分佈，並將它帶到 90%。 這表示它必須立即相應放大。 因此，它會略過相應縮小，而且您可能永遠不會看到預期的縮放結果。

    在相應放大和相應縮小閾值之間選擇適當的邊界，即可控制調整情況。

  • 手動調整會重設用於自動調整的實例數目上限和最小數目。 如果您手動將實例計數更新為高於或低於最大值的值，自動調整引擎會自動縮減為最小值（如果較低）或最大值（如果更高）。 例如，您設定的範圍是 3 到 6。 如果您有一個執行執行個體正在執行，自動調整引擎會在它下次執行時調整為三個執行個體。 同樣地，如果您以手動方式將規模設定為八個執行個體，在下次執行時，自動調整規模會在它下次執行時將它調整回六個執行個體。 除非您也重設自動調整規則，否則手動調整是暫時性的。

  • 自動調整引擎一次只會處理一個配置檔。 如果不符合條件，則會檢查下一個配置檔。 讓金鑰計量遠離預設配置檔，因為上次檢查該配置檔。 在設定檔中，您可以有多個規則。 擴增時，如果符合任何規則，便會執行自動調整。 縮減時，自動調整會要求必須符合所有規則。

如需 Azure 監視器調整方式的詳細資訊，請參閱 自動調整的最佳做法。

  • 如果您使用 SDK 而非入口網站來設定自動調整，您可以指定更詳細的排程，讓規則處於作用中狀態。 您也可以建立自己的計量，並在自動調整規則中搭配或不使用任何現有計量來使用這些計量。 例如，您可能想要使用替代計數器，例如每秒要求數目或平均記憶體可用性，或使用自定義計數器來測量特定的商務程式。

  • 自動調整 Service Fabric 時，叢集中的節點類型是由後端的虛擬機擴展集所組成，因此您必須為每個節點類型設定自動調整規則。 在設定自動調整之前，請先考慮您必須擁有的節點數目。 主要節點類型一定要有的節點數目下限是由您已選擇的可靠性層級決定。 如需詳細資訊，請參閱 使用自動調整規則相應縮小或相應放大 Service Fabric 叢集。

  • 您可以使用入口網站將資源，例如 SQL 資料庫 實例和佇列連結至雲端服務實例。 這可讓您更輕鬆地存取每個鏈接資源的個別手動和自動調整組態選項。 如需詳細資訊，請參閱 如何：將資源連結至雲端服務。

  • 當您設定多個原則和規則時，它們可能會彼此衝突。 自動調整會使用下列衝突解決規則，以確保一律有足夠的實例執行：

    • 向外延展作業一律優先於相應縮小作業。
    • 相應放大作業衝突時，起始實例數目最大增加的規則優先。
    • 當相應縮小作業衝突時，起始實例數目最小減少的規則優先。

  • 在 App Service 環境 中，任何背景工作集區或前端計量都可以用來定義自動調整規則。 如需詳細資訊，請參閱自動調整和 App Service 環境。

應用程式設計考量

自動調整不是即時解決方案。 簡單地將資源新增至系統或執行更多的流程執行個體並無法保證系統的效能得到改善。 設計自動調整策略時，請考量以下幾點:

  • 系統必須設計為可水平調整。 避免對實例親和性進行假設;請勿設計需要程式碼一律在特定進程實例中執行的解決方案。 水平調整雲端服務或網站時，請勿假設來自相同來源的一系列要求一律會路由傳送至相同的實例。 基於同樣的原因，設計服務是無狀態的，以避免要求一系列來自應用程式的要求一律路由傳送至相同的服務實例。 設計從佇列讀取訊息並處理訊息的服務時，請勿對服務處理特定訊息的實例進行任何假設。 隨著佇列長度的成長，自動調整可能會啟動服務的其他實例。 競爭取用者模式描述如何處理此案例。

  • 如果解決方案實作長時間執行的工作，請設計此工作以支持相應放大和相應縮小。 如果沒有適當小心，這類工作可能會防止系統相應縮小時，進程實例無法完全關閉，或者如果進程強制終止，可能會遺失數據。 在理想情況下，重構長時間執行的工作，並將其執行的處理分成較小的離散區塊。 管道和篩選模式提供如何達成此目的的範例。

  • 或者，您可以實作檢查點機制，以定期記錄工作的狀態資訊，並將此狀態儲存在執行工作的任何進程實例可以存取的持久記憶體中。 如此一來，如果進程已關閉，則會使用另一個實例，從最後一個檢查點繼續執行的工作。 有連結庫提供這項功能，例如 NServiceBus 和 MassTransit。 它們會透明地保存狀態，其中間隔會與 Azure 服務匯流排 中佇列中的訊息處理一致。

  • 當背景工作在個別的計算實例上執行時，例如在雲端服務裝載應用程式的背景工作角色中，您可能需要使用不同的調整原則來調整應用程式的不同部分。 例如，您可能需要部署額外的使用者介面 （UI） 計算實例，而不需要增加背景計算實例的數目，或與此相反。 如果您提供不同的服務層級（例如基本和進階服務套件），您可能需要更積極地向外延展進階服務套件的計算資源，而不是基本服務套件的計算資源，以符合 SLA。

  • 請考慮UI和背景計算實例通訊的佇列長度。 使用它作為自動調整策略的準則。 這是目前負載與背景工作處理容量之間不平衡或差異的一個可能指標。 有一個稍微複雜，但更好的屬性，以基底調整決策。 使用訊息傳送的時間，以及訊息處理完成的時間，稱為 「關鍵時間」。 如果這個關鍵時間值低於有意義的商務閾值，則即使佇列長度很長，也不需要調整。

    • 例如，佇列中可能有 50,000 則訊息，但最舊訊息的關鍵時間是 500 毫秒，而該端點會處理與第三方 Web 服務整合以傳送電子郵件。 業務項目關係人可能會認為，這是一段時間，不會證明花額外的錢進行調整是正當的。
    • 另一方面，佇列中可能會有 500 則訊息，具有相同的 500 毫秒關鍵時間，但端點是一些即時在線遊戲中關鍵路徑的一部分，其中商務項目關係人定義了 100 毫秒或更少的回應時間。 在此情況下，相應放大會有意義。
    • 為了在自動調整決策中使用關鍵時間，讓連結庫在傳送和處理訊息的標頭中自動新增相關信息會很有説明。 提供此功能的其中一個這類連結庫是 NServiceBus。

  • 如果您的自動調整策略是根據測量商務程序 (例如每小時訂單數或複雜交易的平均執行時間) 的計數器，請確定您完全了解這些計數器類型的結果與實際計算容量需求之間的關係。 您可能需要調整多個元件或計算單位，以響應商務程式計數器的變更。

  • 若要防止系統嘗試過度相應放大，並避免與執行數千個實例相關聯的成本，請考慮限制可自動新增的實例數目上限。 大部分的自動調整機制都可讓您指定規則的實例數目下限和上限。 此外，請考慮在部署實例數目上限時，讓系統所提供的功能正常降級，而且系統仍會超載。

  • 請記住，自動調整可能不是處理工作負載突然暴增的最適當機制。 布建和啟動服務的新實例或將資源新增至系統需要時間，而尖峰需求可能會在這些額外的資源可供使用時經過。 在此案例中，最好對服務進行節流。 如需詳細資訊，請參閱 節流模式。

  • 相反地，如果您需要容量在磁碟區快速波動時處理所有要求，而且成本不是主要因素，請考慮使用主動式自動調整策略，以更快速地啟動其他實例。 您也可以使用排程的原則，啟動足夠的實例數目，以符合預期負載之前的最大負載。

  • 自動調整機制應該監視自動調整程式，並記錄每個自動調整事件的詳細數據（觸發專案、新增或移除哪些資源，以及何時）。 如果您建立自定義自動調整機制，請確定它包含這項功能。 分析資訊以協助測量自動調整策略的有效性，並視需要調整。 您可以在短期內調整這兩者，因為使用模式變得更明顯，而且隨著業務擴展或應用程式需求的發展，長期而言。 如果應用程式達到自動調整所定義的上限，機制可能也會警示操作員，他們可能在必要時手動啟動其他資源。 請注意，在這些情況下，操作員也可能會負責在工作負載簡化之後手動移除這些資源。

實作自動調整時，下列模式和指引也可能與您的案例相關：

  • 節流模式。 此模式描述當需求增加時，當應用程式如何繼續運作並符合 SLA 時，會對資源產生極端負載。 節流可以與自動調整搭配使用，以防止系統在系統相應放大時不堪重負。

  • 競爭取用者模式。 此模式描述如何實作服務實例集區，以處理來自任何應用程式實例的訊息。 自動調整可用來啟動和停止服務實例，以符合預期的工作負載。 此方法可讓系統同時處理多個訊息，以優化輸送量、改善延展性和可用性，以及平衡工作負載。

  • 監視和診斷。 檢測和遙測對於收集可驅動自動調整程式的信息至關重要。