設計可靠調整策略的建議

適用於此 Azure 架構完善的架構可靠性檢查清單建議：

相關指南：數據分割

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

定義

關鍵設計策略

根據負載模式設計

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

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

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

• 動態、不規則且可預測的：產品推出會在當月的第一天進行，而且先前的推出有關於這些情況量如何增加的歷史數據。

• 動態、不規則且無法預測：大規模事件會導致產品的需求激增。 例如，製造和銷售除濕器的公司，在颶風或其他洪水事件之後，當受災地區的人需要在家裡乾燥房間時，交通突然激增。

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

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

• 建置自動化以可靠地處理調整。

針對上述範例，您的調整策略可能是：

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

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

• 動態、不規則且可預測的：您在產品推出當天上午定義計算和資料庫實例的一次性相應增加，並在一周后相應減少。

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

自動化調整策略

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

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

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

• 執行調整作業所需的時間，讓您在額外負載達到基礎結構之前，適當地排程作業發生。 例如，如果類似 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 則訊息，其時間相同，但端點是一些即時在線遊戲中重要路徑的一部分，其中商務專案關係人定義了 100 毫秒或更少的回應時間。 在此情況下，相應放大會有意義。

若要在自動調整決策中使用關鍵時間，讓連結庫在傳送和處理訊息時，自動將相關信息新增至訊息標頭很有説明。 提供此功能的其中一個連結庫是 NServiceBus。

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

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

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

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

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

範例

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

相關連結

• 效能效率調整
• 自動調整的最佳做法

可靠性檢查清單

請參閱一組完整的建議。