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