設計可靠調整策略的建議

  • 發行項

適用于此 Azure Well-Architected Framework 可靠性檢查清單建議：

RE：06 在應用程式、資料和基礎結構層級實作及時且可靠的調整策略。

相關指南：資料分割

本指南說明設計可靠調整策略的建議。

定義

詞彙 定義
垂直規模調整 將計算容量新增至現有資源的調整方法。
水平調整規模 調整方法，可新增指定資源類型的實例。
自動調整 調整方法，可在符合一組條件時自動新增或移除資源。

注意

調整作業可以是靜態 (定期排程的每日調整，以配合一般負載模式) 、自動 (自動化程式以回應符合) 的條件，或手動 (運算子執行一次性調整作業，以回應未預期的負載變更) 。 垂直和水準縮放都可以透過上述任何方法執行。 不過，自動垂直調整需要額外的自訂自動化開發，而且可能會根據調整的資源造成停機時間。

主要設計策略

若要為工作負載設計可靠的調整策略，請專注于識別導致調整作業之每個工作負載的使用者和系統流程的負載模式。 以下是不同負載模式的範例：

  • 靜態：每天下午 11 點 EST 為止，作用中的使用者數目低於 100，而應用程式伺服器的 CPU 使用率在所有節點上都會下降 90%。

  • 動態、一般且可預測的：每個星期一上午，跨多個區域的 1000 名員工登入 ERP 系統。

  • 動態、異常且可預測的：產品啟動會在當月的第一天發生，而先前啟動的歷程記錄資料會說明這些情況中的流量增加方式。

  • 動態、不規則且無法預測：大規模事件會導致產品的需求突然增加。 例如，當受影響區域的人員需要在其家中幹室時，公司製造及銷售除法器可能會發生突然暴增的流量。

識別出這些類型的負載模式之後，您可以：

  • 識別與每個模式相關聯的負載變更如何影響您的基礎結構。

  • 建置自動化以可靠地解決調整。

針對先前的範例，您的調整策略可能是：

  • 靜態：您已將計算節點的排程規模調整為最小計數， (2) 下午 11 點到上午 6 點之間。

  • 動態、一般且可預測的：在第一個區域開始工作之前，您已將計算節點排程相應放大至一般每日容量。

  • 動態、異常且可預測的：您可以在產品啟動時定義計算和資料庫實例的一次性排程相應增加，並在一周後相應減少。

  • 動態、異常且無法預測：您已定義自動調整閾值，以考慮非計劃性流量尖峰。

設計調整自動化時，請務必考慮這些問題：

  • 工作負載的所有元件都應該是調整實作的候選項目。 在大部分情況下，Microsoft Entra識別碼等全域服務會自動且透明地調整給您和您的客戶。 請務必瞭解網路輸入和輸出控制器和負載平衡解決方案的調整功能。

  • 無法相應放大的元件。例如，未啟用分區化且無法重構的大型關係資料庫，而不會影響。 記錄雲端提供者所發佈的資源限制，並密切監視這些資源。 在未來規劃移轉至可調整的服務時，請包含這些特定資源。

  • 執行調整作業所需的時間，讓您在額外負載到達基礎結構之前，適當地排程作業發生。 例如，如果API 管理等元件需要 45 分鐘來調整規模，將縮放閾值調整為 65%，而不是 90% 可能會協助您稍早調整規模，並準備預期的負載增加。

  • 根據縮放作業的順序，流程元件的關聯性。 請先調整上游元件，以確保您不會不小心多載下游元件。

  • 任何可能會因調整作業而中斷的具狀態應用程式元素，以及實作的任何會話親和性 (或會話黏性) 。 黏性可以限制您的調整能力，並引進單一失敗點。

  • 潛在的瓶頸。 相應放大不會修正每個效能問題。 例如，如果您的後端資料庫是瓶頸，則無法協助新增更多網頁伺服器。 先識別並解決系統中的瓶頸，再新增更多實例。 系統具狀態組件最有可能是瓶頸的原因。

遵循 部署戳記 設計模式可協助您進行整體基礎結構管理。 根據戳記作為縮放單位的縮放設計也很有説明。 它可協助您嚴格控制跨多個工作負載和工作負載子集的調整作業。 您可以套用一組有限的調整定義至部署戳記，然後視需要跨戳記鏡像，而不是管理許多不同資源的調整排程和自動調整閾值。

取捨：相應增加具有成本影響，因此請優化您的策略，儘快相應減少，以協助控制成本。 請確定您用來相應增加的自動化也具有相應減少的觸發程式。

Azure 指導

許多 Azure 服務都提供自動調整功能。 它可讓您輕鬆地設定條件，以水準調整實例。 某些服務有限或沒有內建功能可自動相應縮小，因此請務必記錄這些案例，並定義處理相應縮小的程式。

許多 Azure 服務都提供 API，可讓您使用Azure 自動化來設計自訂自動調整作業，例如自動調整Azure IoT 中樞的程式碼範例。 您可以使用 KEDA 之類的工具來進行事件驅動自動調整，其可在Azure Kubernetes Service和Azure Container Apps中使用。

Azure 監視器自動調整為 Azure 虛擬機器擴展集、Azure App 服務、Azure Spring Apps 等提供一組常見的自動調整功能。 您可以依排程或執行時間計量來執行調整，例如 CPU 或記憶體使用量。 如需最佳做法，請參閱 Azure 監視器指南 。

取捨

自動調整考慮

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

系統必須設計為可以水平調整。 避免假設實例親和性。 請勿設計需要程式碼一律在特定進程實例中執行的解決方案。 水準調整雲端服務或網站時，請勿假設來自相同來源的一系列要求一律會路由傳送至相同的實例。 基於相同理由，請將服務設計成無狀態，以避免需將一連串來自應用程式的要求一律路由傳送至相同的服務執行個體。 在設計從佇列讀取訊息並處理它們的服務時，不要假設哪個服務的執行個體會處理特定訊息。 自動調整可能會在佇列長度成長時啟動更多服務的實例。 競爭取用者模式說明如何解決這種情況。

如果解決方案會實作長時間執行的工作，請將此工作設計為同時支援相應縮小和相應放大。 若不小心，這類工作可能會防止系統相應縮小時，完全關閉進程的實例。 或者，如果進程強制終止，它可能會遺失資料。 理想的情況是，重整長時間執行工作並分解處理，讓其以較小且不連續的區塊執行。 管道和篩選模式提供如何達成此解決方案的範例。

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

當背景工作在不同的計算實例上執行時，例如在雲端服務裝載應用程式的背景工作角色中，您可能需要使用不同的調整原則來調整應用程式的不同部分。 例如，您可能需要部署額外的使用者介面 (UI) 計算實例，而不增加背景計算實例的數目，反之亦然。 如果您提供不同的服務層級，例如基本和進階服務套件，您可能需要比基本服務套件更積極相應放大進階服務套件的計算資源，以符合服務等級協定 (SLA) 。

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

例如，佇列中可能有 50,000 則訊息。 但最舊訊息的重要時間是 500 毫秒，而端點會處理與傳送電子郵件的協力廠商 Web 服務整合。 商務專案關係人可能會認為是一段時間，這不會證明花費額外的費用來調整規模。

另一方面，佇列中可能有 500 則訊息，具有相同的 500 毫秒關鍵時間，但端點是某些即時線上遊戲中重要路徑的一部分，其中商務專案關係人定義了 100 毫秒或更少回應時間。 在此情況下，相應放大會很合理。

若要在自動調整決策中使用關鍵時間，程式庫會在傳送和處理訊息時自動將相關資訊新增至訊息的標頭。 其中一個提供這項功能的程式庫是 NServiceBus。

如果您以測量商務程式的計數器為基礎的自動調整策略，例如每小時的訂單數目或複雜交易的平均執行時間，請確定您完全瞭解這些計數器類型的結果與實際計算容量需求之間的關聯性。 可能需要調整多個元件或計算單位，以回應商務程式計數器中的變更。

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

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

相反地，如果您需要容量在磁片區快速變動時處理所有要求，而且成本不是主要因素，請考慮使用更快速啟動更多實例的主動自動調整策略。 您也可以使用排程原則，在最大負載來臨前預先啟動足量的執行個體。

自動調整機制應該監視自動調整程式，並記錄每個自動調整事件的詳細資料， (觸發事件、新增或移除哪些資源，以及何時) 。 如果您建立自訂自動調整機制，請確定它包含這項功能。 分析資訊，以協助測量自動調整策略的有效性，並視需要加以微調。 您可以在使用模式變得更明顯時短時間內進行調整，以及在業務量拓展或對應用程式的需求演變時長期進行調整。 如果應用程式達到自動調整所定義的上限，則機制可能也會針對可能在必要時手動啟動更多資源的操作員發出警示。 在這些情況下，操作員也可能負責在工作負載簡化之後手動移除這些資源。

範例

請參閱 AKS 基準參考架構 調整指引。

可靠性檢查清單

請參閱一組完整的建議。

可靠性檢查清單