云計算實例在計算能力、內存、存儲和對GPU的支持、機器學習和其他專門功能方面具有廣泛的應用范圍。管理人員應該讓應用程序需求決定云計算實例的類型和規模，尤其是因為錯誤的匹配會導致性能低下和成本高昂的情況。

 

某些應用程序可能需要更大的云計算實例，這意味著需要高水平計算、存儲和其他資源的虛擬機，而其他應用程序可以在資源較少的規模較小實例上運行良好。但并不是每個用戶一開始都會使用正確的云計算實例，云計算應用程序的動態特性意味著配對并不總是按計劃工作。

 

可以使用云優化工具和技術來選擇正確的云計算實例類型和規模，然后根據需要隨時重置和調整它們。

 

 

云托管應用程序需要與本地應用程序不同的思維模式。IT經理通常會過度配置本地應用程序，因為以后擴展其他資源是一項挑戰。云計算應用程序更容易按需擴展，而需要擴展的特定資源(如計算、內存和存儲)因工作負載而異。例如，數據庫應用程序需要比網絡服務器更多的內存和存儲IOPS，這對計算提出了更高的要求。

 

Enterprise Management Associates管理研究主管Torsten Volk表示，由于企業需要了解應用程序的資源使用模式(最好是一年)，因此很難確定云計算實例的規模。

 

檢查云計算供應商的CPU、內存、存儲等資源限制。盡管云計算提供商的工具可以幫助確定應用程序的最佳實例類型和設置，但這些供應商幾乎沒有動力向客戶提供復雜的云優化工具，因為過度配置可能是其收入來源。管理人員將需要實現其他技術，以及可能的第三方優化工具，以全面了解情況。

 

 

利用率指標(如CPU、存儲、內存和網絡容量)可以顯示實例的規模是否適合應用程序。例如，大量的請求延遲可能表示實例規模，無法處理當前負載。

 

云計算咨詢機構Candid Partners公司的高級云架構師Beau Bennett表示，“在確定正確的實例規模時，一定要理解峰值是如何影響指標的。”

 

應該有足夠的備用容量來處理使用的峰值，只需要足夠長的時間來進行水平擴展。如果單個指標遠遠高于其他指標(例如，如果內存被完全使用，但CPU和網絡容量很低)，那么可能是使用不同的實例規模的時候了。

 

 

為確保云計算應用程序有效擴展，需要在指標和操作之間創建反饋循環。監控指標顯示高利用率或低利用率時，請對實例規模或類型進行小幅調整。繼續監控這些指標，以了解更改如何影響應用程序性能和效率。

 

強大的持續集成/連續部署(CI/CD)管道，借助基于策略的控制和自動化進行更改，可以幫助云計算管理員調整設置，而不會產生意外后果或冗長的手動流程。Bennett說，基礎設施作為代碼，資源被模板化并用編程語言編寫，也有助于持續的云優化。

 

性能和利用率指標是云計算提供商的核心產品，或者組織可以轉向第三方產品，這些產品提供所使用實例的概述。

 

 

本地成本管理工具(包括Azure成本管理、AWS成本管理和Google權限推薦)可以幫助進行優化，但可能不足以準確估算所有工作負載的需求。例如，Google Rightsizing Recommendations可以根據運行的平均值建議實例規模調整。但是，這種平均利用率信息不足以滿足每月或每季度發生一次峰值的Spikey應用程序，或基于特定事件(如黑色星期五)。

 

Volk警告說，“需要分析重要的工作負載，以將平均使用量和峰值使用量都包括在其云實例規模決定中。”

 

此外，這些工具可能無法跟蹤對應用程序很重要的所有必需資源。例如，Google Rightsizing Recommendations只考慮CPU、內存和存儲大小。某些應用程序具有其他限制因素，例如網絡IOPS。此外，該工具不考慮某些部署類型，例如Kubernetes集群，這使管理人員可以做出自己的云優化決策。

 

 

Volk建議，對不同實例類型和規模的應用程序進行負載測試，以確定預期的平均和突發性能指標。模型負載測試盡可能接近真實的使用模式。例如，峰值負載可能發生在API函數調用期間，同時也可能發生在用戶與應用程序圖形前端的交互過程中。

 

集成的第三方系統可能在與云托管應用程序的通信速度方面有要求，這可能使事情變得更復雜。當應用程序共享通用微服務時，集成過程變得更加棘手。跨這些互連的分布式架構進行云優化需要警惕和復雜的建模。

 

 

AWS公司提供了可突發的性能實例，使管理人員可以根據需要動態添加和支付CPU性能。雖然這種服務可以提高云計算性能，但很難知道應用程序只有CPU改進才能擴展，并且不會升級到內存和存儲的速度或規模。Volk說，每當依賴實例爆發時，總是進行負載測試。

 

此外，如果企業在增加的CPU上花費很多，需要查看應用程序的需求，可能是轉換為更大實例規模的時候了。

 

 

容器群集可能具有導致比預期更高的網絡吞吐量或存儲負載的依賴性。關鍵的罪魁禍首通常是Kubernetes調度策略。“這是一個需要診斷的潛在問題。”Volk說。

 

如果企業計劃啟動容器，請考慮云優化評估，而不僅僅是CPU、存儲和內存。確定在一段時間內用戶可以啟動或刪除的Kubernetes pod數量是否存在限制，以及對實例上運行的各個容器是否存在規模限制。