優化調整成本的建議

  • 發行項

適用于此 Azure Well-Architected 架構成本優化檢查清單建議：

CO：12 將調整成本優化。 評估縮放單位內的替代縮放比例。 請考慮替代的調整設定，並配合成本模型。 考慮應包括針對每個實例、資源和縮放單位界限的繼承限制使用。 使用控制需求和供應的策略。

本指南提供優化調整成本的建議。 成本優化調整是移除工作負載調整效率不佳的程式。 目標是降低調整成本，同時仍符合所有非功能需求。 花費較少以取得相同的結果。 優化調整可讓您避免不必要的費用、過度布建和浪費。 它也可藉由控制需求和上限供應專案，協助防止非預期的成本尖峰。 沒有效率的調整做法可能會導致工作負載和營運成本增加，並對工作負載的整體財務健康情況造成負面影響。

定義

詞彙 定義
自動調整 調整方法，可在符合一組條件時自動新增或移除資源。
成本計量 與工作負載成本相關的數值資料。
相應減少 垂直調整策略，會轉移至較低的 SKU，以提供較少的資源給工作負載。
相應縮小 水準調整策略，可移除實例，以提供較少的資源給工作負載。
擴增 水準調整策略，可新增實例，以提供更多資源給工作負載。
縮放單位 可依比例調整的資源群組。
相應增加 垂直調整策略，會轉移至較高的 SKU，以提供更多資源給工作負載。
庫存單位 (SKU) Azure 服務的服務層級。
使用情況資料 使用方式資料是直接資訊 (實際) 或間接/代表性資訊， (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 產品層級的價值。

成本優化檢查清單

請參閱一組完整的建議。

成本優化檢查清單