優化調整成本的建議
適用於此 Azure 架構完善的架構成本優化檢查清單建議：
| CO：12 | 將調整成本優化。 評估縮放單位內的替代縮放比例。 請考慮替代調整組態，並配合成本模型。 考慮應包含針對每個實例、資源和縮放單位界限之繼承限制的使用率。 使用控制需求和供應的策略。 |
|---|
本指南提供優化調整成本的建議。 成本優化調整是移除工作負載調整效率不佳的程式。 目標是要降低調整成本，同時仍符合所有非功能需求。 花更少的錢來得到相同的結果。 優化調整可讓您避免不必要的費用、過度布建和浪費。 它也有助於控制需求和限制供應，以防止非預期的成本暴增。 沒有效率的調整做法可能會導致工作負載和營運成本增加，並對工作負載的整體財務健康情況造成負面影響。
定義
| 詞彙 | 定義 |
|---|---|
| 自動調整 | 調整方法，可在符合一組條件時自動新增或移除資源。 |
| 成本計量 | 與工作負載成本相關的數值數據。 |
| 相應減少 | 垂直調整策略，會轉移到較低的 SKU，以提供較少的資源給工作負載。 |
| 縮減 | 水平調整策略，可移除實例，以提供較少的資源給工作負載。 |
| 橫向擴增 | 水平調整策略，可新增實例，以提供更多資源給工作負載。 |
| 縮放單位 | 按比例調整的資源群組。 |
| 相應增加 | 垂直調整策略，會轉移到較高的 SKU，以提供更多資源給工作負載。 |
| 庫存單位（SKU） | Azure 服務的服務層級。 |
| 使用方式資料 | 使用方式數據是使用工作、服務或應用程式之直接資訊（real）或間接/代表性資訊（Proxy）。 |
關鍵設計策略
成本最佳化調整的目標是在最後責任時刻擴增與擴大，並在可行時縮小和縮減。 若要最佳化工作負載的調整作業，您可以評估縮放單位內的替代調整選項，並使其與成本模型保持一致。 縮放單位代表可以獨立或一起調整的特定資源群組。 您應該設計縮放單位來處理特定數量的負載，而且它們可以組成多個實例、伺服器或其他資源。 您必須評估工作負載縮放單位和模型替代專案的成本效益。
如果您未使用調整，請參閱調整工作負載的指引。 您必須瞭解您的應用程式是否可以調整。 無狀態應用程式更容易調整，因為它們可以同時處理多個要求。 此外，評估應用程式是否使用分散式系統原則來建置。 分散式系統可以藉由將工作負載分散到多個節點，以處理增加的負載。 不過，單一應用程式的設計目的是在任何指定時間只執行一個實例。 因此，調整可能不適用於所有工作負載。
評估相應放大與相應增加
評估橫向擴增與縱向擴大涉及到根據定價、工作負載需求和可接受的停機時間等各種因素，確定增加現有系統中的資源 (縱向擴大) 或新增該系統的更多實例 (橫向擴增) 之間最具成本效益的方法。 選擇正確的擴縮調整方法可大幅節省成本，確保您只需支付所需的費用，同時仍符合效能和可靠性標準。
目標是根據服務層級定價、工作負載特性、可接受的停機時間和成本模型來判斷最具成本效益的選擇。 對於某些人來說，選擇較少數目的昂貴實例可能比較經濟。 相反地，對於其他人來說，具有更多實例的較便宜層可能會更好。 若要做出明智的決策，您需要分析設定的實際或代表性數據，並評估每個策略的相對成本優點。 若要評估最符合成本效益的方法，請考慮這些建議：
收集使用量數據：收集代表工作負載使用模式和資源使用率的實際生產數據或 Proxy 數據。 此數據應包含計量，例如CPU使用量、記憶體使用量、網路流量，以及影響調整成本的任何其他相關計量。
定義成本計量：識別與您的工作負載相關的成本計量，例如每小時成本、每筆交易的成本，或資源使用量單位的成本。 這些計量可協助您比較不同調整選項的成本效益。
收集使用量數據：收集代表工作負載使用模式和資源使用率的實際生產數據或 Proxy 數據。 此數據應包含計量，例如CPU使用量、記憶體使用量、網路流量，以及影響調整成本的任何其他相關計量
定義成本計量：識別與您的工作負載相關的成本計量，例如每小時成本、每筆交易的成本，或資源使用量單位的成本。 這些計量可協助您比較不同調整選項的成本效益。
請參閱需求：在相應放大和相應增加策略之間決定時，請考慮工作負載的可靠性、效能和調整需求。 相應放大可透過備援來改善可靠性。 相應增加會增加資源的容量，但可能會限制您可以相應增加多少。
考慮資源限制：評估調整選項時，請務必考慮每個實例、資源和縮放單位界限的固有限制。 請注意每個資源的上限，並據以規劃。 此外，請記住訂用帳戶和其他資源的限制。
測試調整：針對不同的調整案例建立測試，包括相應放大和相應增加選項。 套用使用量數據，在不同的調整組態下模擬工作負載行為。 使用模型化調整案例進行真實世界測試。
計算成本：使用收集的數據和成本計量來計算與每個調整設定相關聯的成本。 請考慮實例定價、資源使用率，以及任何與調整相關的額外成本等因素。
優化自動調整
優化自動調整原則牽涉到精簡自動調整，以根據工作負載的非功能需求來回應負載變更。 您可以藉由調整臨界值並使用正確的冷卻期間來限制過度調整活動。 若要優化自動調整，請考慮下列建議：
分析目前的自動調整原則：瞭解現有的原則及其行為，以回應不同的負載層級。
請參閱非功能需求：識別您需要考慮的特定非功能需求，例如回應時間、資源使用率或成本。
調整調整臨界值：根據工作負載特性和非功能需求調整調整臨界值。 根據一段時間的CPU使用率、網路流量或佇列長度等因素，設定相應增加或減少的閾值。
調整冷卻期間：調整冷卻期間，以防止暫時性負載尖峰觸發的過度調整活動。 冷卻期間會在調整事件之間造成延遲，讓系統在進一步調整動作之前穩定下來。
監視和微調：持續監視系統的行為和效能。 分析調整活動，並視需要調整原則，以將成本優化並符合所需的非功能需求。
取捨：減少調整事件數目，會增加遇到與調整相關的問題的機會。 這表示您要消除額外的緩衝或緩衝區，以協助管理調整的潛在問題或延遲。
使用事件型調整
事件驅動自動調整可讓應用程式根據特定事件或觸發程式動態調整資源，而不是 CPU 或記憶體使用率等傳統計量。 例如，Kubernetes 事件驅動自動調整 （KEDA） 可以根據縮放程式來調整應用程式，例如 Kafka 主題的長度。 精確度有助於防止不必要的調整波動和資源浪費。 高階精確度最終將成本優化。 若要使用事件型調整，請遵循下列步驟：
選擇事件來源：判斷觸發縮放單位縮放比例的事件來源。 來源可以是消息佇列、串流平臺或任何其他事件驅動系統。
設定事件擷取：設定您的應用程式取用所選事件來源的事件。 它通常涉及建立連線、訂閱相關的主題或佇列，以及處理傳入事件。
實作調整邏輯：撰寫邏輯，以決定縮放單位根據傳入事件調整的時機和方式。 此邏輯應考慮的因素，例如事件數目、傳入事件的速率，或任何其他相關計量。
與調整機制整合：視應用程式的運行時間環境而定，您可以使用不同的調整機制來調整配置給應用程式的資源。
設定調整規則：定義調整規則，以指定縮放單位應如何調整以回應事件。 這些規則可以根據閾值、模式或任何其他符合您應用程式需求的準則。 調整閾值應該與商務計量相關。 例如，如果您再新增兩個實例，則可以在購物車處理中再支援50位使用者。
測試和監視：使用不同事件案例測試事件型調整實作的行為。 監視調整動作，並確保動作符合您的期望。
優化需求和供應
根據您的供應量控制需求。 在使用量決定調整的工作負載上，成本會與調整相互關聯。 若要將調整成本優化，您可以將調整費用降至最低。 您可以將需求分散到其他資源，也可以藉由實作優先順序佇列、閘道卸除、緩衝和速率限制來減少需求。 由於調整和資源耗用量，這兩種策略都可防止不想要的成本。 您也可以限制調整限制來控制供應。 若要優化工作負載需求和供應，請考慮下列建議。
卸除需求
卸載需求是指將資源需求分散或轉移給其他資源或服務的做法。 您可以使用各種技術或策略：
快取：使用快取來儲存經常存取的數據或內容，以減少後端基礎結構上的負載。 例如，使用內容傳遞網路 （CDN） 來快取及提供靜態內容，減少調整後端的需求。 不過，並非所有工作負載都可以快取數據。 需要最新和實時數據的工作負載，例如交易或遊戲工作負載，不應該使用快取。 快取的數據會是舊數據，與用戶無關。
取捨。 快取可能會在快取失效、一致性和管理快取到期方面帶來挑戰。 請務必仔細設計和實作快取策略，以避免潛在的取捨。內容卸除：將內容卸除至外部服務或平臺，以減少基礎結構上的工作負載。 例如，您可以在與主伺服器無關的個別記憶體服務中裝載這些檔案，而不是將視訊檔案儲存在主伺服器上。 您可以直接從記憶體服務載入這些大型檔案。 此方法可釋出伺服器上的資源，讓您能夠使用較小的伺服器。 將大型檔案儲存在不同的數據存放區可以更便宜。 您可以使用 CDN 來改善效能。
負載平衡：使用負載平衡將連入要求分散到多部伺服器。 負載平衡會平均分散工作負載，並防止任何單一伺服器變得不堪重負。 負載平衡器可將資源使用率優化，並提升基礎結構的效率。
資料庫卸除：將資料庫作業卸除至個別資料庫伺服器或特製化服務，以減少主應用程式伺服器上的負載。 例如，使用CDN進行靜態內容快取，並使用 Redis 快取進行動態內容（資料庫的數據）快取。 資料庫分區化、讀取複本或使用受控資料庫服務等技術也可以減少負載。
取捨： 將特定工作卸除給替代資源有助於減少或避免與調整相關的額外調整和成本。 不過，請務必考慮卸除可能造成的作業和維護挑戰。 針對工作負載選取最適當的卸除技術時，進行全面的成本效益分析非常重要。 此分析可確保所選方法對於預期的節省和操作複雜度而言既有效又可行。
減少需求
減少資源需求表示實作策略，以協助將工作負載中的資源使用率降到最低。 卸除需求會將需求轉移至其他資源。 減少需求會減少對工作負載的需求。 減少需求可讓您避免超額佈建資源，並支付未使用或使用量過低的容量費用。 您應該使用程式碼層級設計模式來減少工作負載資源的需求。 若要透過設計模式減少需求，請遵循下列步驟：
了解設計模式：熟悉促進資源優化的各種設計模式。
分析工作負載需求：評估工作負載的特定需求，包括其預期的需求模式、尖峰負載和資源需求。
選取適當的設計模式：選擇符合您工作負載需求和目標的設計模式。 例如，如果您的工作負載遇到變動的需求，事件驅動調整和節流模式可透過動態配置資源來協助管理工作負載。 將選取的設計模式套用至您的工作負載架構。 您可能需要分隔工作負載元件、將應用程式容器化、優化記憶體使用率等等。
持續監視和優化：定期評估實作設計模式的有效性，並視需要進行調整。 監視資源使用量、效能計量和成本優化機會。
遵循這些步驟並使用適當的設計模式，您可以降低資源需求、將成本優化，並確保其工作負載的有效作業。
使用這些設計模式來減少需求：
另行快取：模式會檢查快取，以查看數據是否已儲存在記憶體中。 如果在快取中找到數據，應用程式就可以快速擷取並傳回數據，減少查詢永續性數據存放區的需求。
宣告檢查：藉由分隔數據與傳訊流程，此模式會減少訊息的大小，並支援更具成本效益的傳訊解決方案。
競爭取用者：此模式藉由套用分散式和並行處理，有效率地處理佇列中的專案。 此設計模式會根據佇列深度進行調整，並設定並行取用者實例上限的限制，藉此將成本優化。
計算資源匯總：此模式會藉由合併共用基礎結構上的多個應用程式或元件來增加密度，並合併計算資源。 其可最大化資源使用率，避免未使用的布建容量並降低成本。
部署戳記：使用部署戳記可提供數個優點，例如裝置的異地散發群組、將新功能部署到特定戳記，以及觀察每個裝置的成本。 部署戳記可提供更好的延展性、容錯和有效率的資源使用率。
網關卸除：此模式會卸除閘道裝置中的要求處理，並將每個節點資源的成本重新導向至閘道實作。 使用此設計模式可能會導致集中式處理模型中的擁有成本較低。
發行者/訂閱者：此模式會將架構中的元件分離，以中繼訊息代理程式或事件總線取代直接通訊。 它可啟用事件驅動方法和以耗用量為基礎的計費，以避免過度布建。
佇列型負載撫平：模式會緩衝佇列中的傳入要求或工作。 緩衝處理可順暢處理工作負載，並減少過度布建資源以處理尖峰負載的需求。 傳入要求會以異步方式處理，以降低成本。
分區化：此模式會將特定要求導向至邏輯目的地，允許使用數據共置進行優化。 分區化可能會使用多個低規格計算或記憶體資源的實例來節省成本。
靜態內容裝載：此模式會使用專為此目的設計的裝載平臺，有效率地提供靜態內容。 它可避免使用更昂貴的動態應用程式主機，將資源使用率優化。
節流：此模式會限制資源或元件的傳入要求速率（速率限制）或輸送量。 它有助於通知成本模型化，並可直接系結至應用程式的商務模型。
代客密鑰：此模式會授與安全且獨佔的資源存取權，而不需要更多元件、減少對中繼資源的需求並提高效率。
控制供應器
定義您願意在特定資源或服務上花費的金額上限，是控制供應的一種方式。 這是控制成本並確保費用不超過特定層級的重要策略。 建立預算並監視支出，以確保其保持在已定義的金額內。 您可以使用成本管理平臺、預算警示，或追蹤使用量和支出模式。 某些服務可讓您節流供應和限制速率，而且您應該在有幫助的情況下使用這些功能。
控制供應是指定義您願意在特定資源或服務上花費的金額上限。 這是一個重要策略，因為可以協助控制成本，並確保費用不會超過特定層級。 建立預算並監視支出，以確保費用在定義的閾值內。 您可以使用成本管理平臺、預算警示，或追蹤使用量和支出模式。 某些服務可讓您節流供應和限制速率，而且您應該在有幫助的情況下使用這些功能。
Azure 便利化
評估向外延展與相應增加：Azure 提供測試環境，您可以在其中部署及測試不同的調整組態。 藉由使用實際的工作負載數據或 Proxy 數據，您可以模擬真實世界的案例，並測量對成本的影響。 Azure 提供效能測試、負載測試和監視的工具和服務，可協助您評估相應放大與相應增加選項的成本效益。
Azure 透過各種工具和服務提供成本管理建議，例如 Azure Advisor。 這些建議會分析您的使用模式、資源使用率和調整組態，以提供優化成本的深入解析和建議。
Azure 負載測試 是完全受控的負載測試服務，可產生大規模的負載。 無論應用程式的裝載位置為何，這項服務都會針對應用程式模擬流量。 開發人員、測試人員和質量保證 （QA） 工程師可以使用負載測試，將應用程式效能、延展性或容量優化。
優化自動調整：許多 Azure 計算服務都支援部署多個相同的實例，並快速調整調整臨界值和原則。 Azure 提供自動調整功能，可讓您根據工作負載需求自動調整實例或資源數目。 您可以定義調整規則和閾值，以觸發向外延展或相應縮小動作。 藉由使用自動調整，您可以根據實際需求動態調整資源，將資源配置和成本效益優化。
Azure 會維護訂用 帳戶和服務限制的清單。 您可以在每個資源群組中部署的資源實例數目有一般限制，但有一些例外狀況。 如需詳細資訊，請參閱 每個資源群組的資源實例限制。
優化需求和供應：Azure 監視器可讓您深入瞭解應用程式和基礎結構的效能和健康情況。 您可以使用 Azure 監視器來監視資源的負載，並分析一段時間的趨勢。 藉由使用 Azure 監視器所收集的計量和記錄，您可以識別可能需要調整調整的區域。 此資訊可引導自動調整原則的精簡，以確保其符合非功能需求和成本優化目標。
卸除供應專案：Azure 具有稱為 Azure Front Door 的新式雲端 內容傳遞網路（CDN）和快取服務（Azure Cache for Redis 和 Azure HPC Cache）。 CDN 會快取更接近使用者的內容，減少網路等待時間並改善回應時間。 快取會將數據復本儲存在主要數據存放區前，以減少對後端重複要求的需求。 藉由使用CDN和快取服務，您可以優化效能並降低伺服器上的負載，以節省潛在的成本。
控制供應：Azure 也可讓您設定雲端工作負載的資源限制。 藉由定義資源限制，您可以確定工作負載會保留在已配置的資源內，並避免不必要的成本。 Azure 提供各種機制來設定資源限制，例如配額、原則和預算警示。 這些機制可協助您監視和控制資源使用量。
API 管理 可以對限制和節流要求進行速率。 能夠節流傳入要求是 Azure API 管理的重要角色。 藉由控制要求的速率或傳輸的要求/資料總量，API 管理讓 API 提供者能夠保護其 API 不被濫用，並建立不同 API 產品層級的價值。
相關連結
- 調整工作負載
- Azure Advisor 成本建議
- 什麼是 Azure 負載測試？
- Azure 訂用帳戶和服務限制、配額與限制 (機器翻譯)
- 每個資源群組的資源不限於800個實例
- Azure Front Door 是什麼？
- 什麼是 Azure Cache for Redis？
- 什麼是 Azure HPC Cache？
- 以 Azure API 管理進行進階要求節流
成本優化檢查清單
請參閱一組完整的建議。