設計可靠調整策略的建議

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

相關指南：數據分割

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

定義

關鍵設計策略

根據負載模式設計

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

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

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

• 動態、不規則且可預測的：產品推出在每個月的第一天進行，而且有先前推出活動中流量增加的歷史數據。

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

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

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

• 建置自動化以可靠地解決擴展問題。

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

• 靜態：您已將計算節點的排程調整至最小數量（2），時間範圍為美東時間晚上 11 點到早上 6 點。

• 動態、一般和可預測的：在第一個區域開始工作之前，您已經按照計劃將計算節點擴展到正常的每日容量。

• 動態、不規則且可預測的：您在產品推出當天上午設定計算和資料庫實例的一次性擴展，並在一週後縮減。

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

自動化擴展策略

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

• 工作負載的所有元件應該都是進行可擴展實作的候選者。 在大部分情況下，等全域服務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 Service、Azure Spring Apps 等提供一組常見的自動調整功能。 您可以依排程或根據運行時間計量來執行調整，例如 CPU 或記憶體使用量。 如需最佳做法，請參閱 Azure 監視器指南。

權衡

自動擴展考量

自動調整不是立即解決方案。 只要將資源新增至系統或執行更多進程實例，就不保證系統的效能會改善。 設計自動調整策略時，請考慮下列幾點：

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

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

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

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

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

例如，佇列中可能有 50,000 則訊息。 但最舊訊息的關鍵時間是500毫秒，端點正在處理與第三方Web服務整合以傳送電子郵件。 相關利害關係人可能會認為，這段時間不值得額外花費資金來擴展。

另一方面，佇列中可能有 500 則訊息，且同樣有 500 毫秒的關鍵時間，但端點屬於某些即時線上遊戲的關鍵路徑之一，而商業利益相關者將回應時間定義為 100 毫秒或更短。 在此情況下，擴充會有意義。

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

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

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

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

相反地，如果您需要在流量快速波動時具有處理所有請求的能力，且成本不是主要考量，建議考慮採用積極的自動調整策略，以更快速地啟動更多的實例。 您也可以使用排程策略，在預期負載達到最大值之前啟動足夠多的實例，來應對這個負載。

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

例

請參閱 AKS 基準參考架構 擴充指引。

相關連結

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

可靠性檢查清單

請參閱一組完整的建議。