利用 AWS Trusted Advisor 和 Well-Architected Review 達到成本最佳化

在 AWS Well-Architected 框架^[1]中, 成本最佳化是為框架的六大支柱之一。利用成本最佳化中定義的設計準則和最佳實踐，主要用來協助客戶建構工作負載；既要能夠達到服務的商業目標，同時又能以有效的成本支出，才是所謂成本最佳化。AWS 主控台中的 Well-Architected Tool，主要基於設計準則以及最佳實踐的選項，協助架構設計人員進行 AWS Well-Architected Framework Review；在持續改善的過程中，有系統的記載潛在的風險，並持續進行架構改善。在 AWS Well-Architected Framework Review 的過程中，利用觀測工具或是自動化收集，利用環境中的數據資料來進行決策，減少主觀性造成的偏差，更快地確定架構改善的方向。要有效的參照這些數據資料，您可以利用 AWS 中的 AWS Trusted Advisor。本文將探討如何利用 AWS Trusted Advisor 和 AWS 架構完善的工具運行數據驅動型方法，實作成本最佳化。

在 Well-Architected Framework Review 的過程中，每一條設計準則都有評核問題來涵蓋相對應的範疇，用於探索當下的架構狀態。經由這些問答討論確保客戶在每個領域都能採用雲計算架構的最佳實踐。一但在評核過程中找到任何架構設計中的潛在風險，都可記載在 Well-Architected Tool 當中。將這些評核結果與最佳實踐進行比較，便可以針對當下的架構進行改善，消除潛在的風險。

當然，對於改善成本結構來說也是一樣。在此我們舉一個評核問題作為例子∶

這個問題背後隱含的意義，是為了確保計算資源使用最佳的類型，正確的規模大小以及適當的數量。目的是找出可以支持商業目標所需的性能級別，同時又能讓成本花費精簡，不會過度浪費的平衡點。

從更高的維度來看，成本設計準則「採用消費模型」(Adopt a Consumption Model) 就是這個問題的理論基礎。在花費模型當中，明確的定義了使用者應該採用「具有經濟效益資源」-- 意即採用高效能與低成本更好的雲計算資源。當我們能夠遵從設計準則、找到正確定義，就能夠真正落實最佳實踐中描述的「正確地調整資源規模」(Right Sizing)。

在進行 Well-Architected Framework Review 時，涵蓋到架構設計中的某些區塊，需要在當下收集準確的資料及數據，用於未來改善的基準線 (Baseline)。例如在 AWS Lambda 函數計算資源下，若要達到正確地調整資源規模，可以選擇函數記憶體的成本花費作為最佳化的選項∶

• 因此需要監控 AWS Lambda 函數在一段時間內的利用率
• 並將其與分配的總記憶體進行比較。
• 預配置過多記憶體空間，意味著您正在為未使用的資源付費，造成支出浪費。
• 配置太少則會對函數性能產生負面影響。

這意味著，在沒有這些利用數據點來提供參照的情況下，Well-Architected Framework Review 討論一但開始偏差，偏向空泛的討論而沒有明確的佐証，會無法直接找到明確的改善方案。例如∶需要等到配置相對應的監控機制才能進行下一步，或是誤以為目前的配置是正確有效的。

在 AWS 的環境當中，如果我們想要對 AWS Lambda 函數的記憶體使用率進行觀測，Amazon CloudWatch 通常都是第一個我們想要參照的觀測服務。用人工的方式來解讀Ｉ這些觀測資料背後的意義通常需要很長的時間，同時也需要有足夠的經驗或是對於系統有足夠的理解。在這樣的情況下，有效的利用 AWS Trusted Advisor 提供的資訊去解讀數據背後的意義，能夠有效轉化成架構改善的解法方案。這些數據資訊將為您架構決策提供確切的指引，協助您更快地解決問題。以這個 AWS Lambda 函數的例子來說，依照 AWS Trusted Advisor 當中 AWS Compute Optimizer 提供的檢驗中，我們可以看到有以下兩個項目與函數的記憶體大小有關∶

- 預配置過多 (Over-provisioned) 的 Lambda 和函數記憶體大小
- 預配置不足 (Under-provisioned) 的 Lambda 和函數記憶體大小

很明顯的，在 AWS Lambda 函數的記憶體空間，在配置過多或是過少都有可能造成不必要的費用支出。記憶體配置過小，可能會造成函數在執行的時間變長，有時甚至會造成函數執行錯誤或失敗；但相對來說卻也比較容易被察覺。預配置過多的空間則變得不容易被察覺到，除非我們針對每一個函數的空間利用率進行細部的觀測與比較。下圖就是 AWS Compute Optimizer 自動監控 AWS Lambda 函數的利用率，根據觀測數據所提出的建議內容，同時也包括了不同面向的參照∶

• 這個函數的記憶體空間目前配置為 1 GB
• 過去的紀錄顯示最大的空間使用為 819MB
• 建議調整的記憶體空間大小為 900MB, 是基於紀錄的最大值外加了 10% 的空間
• 調整後的函數預估會增加 200ms 的執行時間
• 建議調整後的空間大小以及執行時間估計能減少 7.1%~15.7% 的花費支出 

基於以上這些訊息，針對 AWS Lambda 函數記憶體的討論就變得相對明確。在架構調整上面我們不需要再回到觀測建置或數據收集的階段。此時只需要考慮到縮小後的記憶體能正常運行，再考慮到達加的執行時間是否在可以接受的範圍，討論的主軸就會相對有效率。當然，建議訊息裡面也明確指出能節省的數字，這也會是一個推動架構改善的重要推力。

採用數據驅動的 Well-Architected Framework Review，您將能夠將架構改善更推近到您的預期結果。使用上述 lambda 函數記憶體大小的範例，可以有效的得到記憶體大小的配置建議，明確的指出有效的修正解決方案。

藉由 Well-Architected Framework Review 進行成本最佳化，主要預期每一次的評核及改善週期中逐漸修正成本結構，儘可能消除任何不必要的支出。在工作負載逐步進行改善的過程中，您希望確保所做的改進被修復的潛在風險可以被清楚的理解，以可視化的報告或是文字紀載作為參照。您可以利用 AWS Well-Architected Tool 中的里程碑 (Milestones) 機制紀錄每一次評核時的定點快照 (Snapshot)。通過里程碑，您將能夠記錄 Well-Architected Framework Review 在每一個週期之間的資訊，當下被偵測到的高度風險和中等風險問題（HRI / MRI）的總數。隨著改善週期的推進，您將能夠通過查看被修復 (Remediation) 的 HRI / MRI 數量來衡量您的進度。當您看到在成本最佳化支柱的 HRI / MRI 數量減少時，您的架構設計即逐漸往成本最佳化前進。

在過去的文章我們曾分享如何利用 AWS Well-Architected Framework 協助成本最佳化。如今您可以由此擴展，以數據驅動審核的方式、先延展到 AWS Trusted Advisor 所支援的 自動成本優化檢查項目。更可以延伸涵蓋工作負載中的不同領域，例如 AWS Trusted Advisor 同時也涵蓋了其他性能、安全性、容錯能力和資源服務配額等項目。AWS Well-Architected Framework 則是涵蓋六大支柱，即成本優化、卓越運營、安全性、可靠性、性能效率和可持續性。兩者之間的重疊性非常高，利用 AWS Trusted Advisor 提供的各項資訊用作 AWS Well-Architected Framework Review 的參照，能協助在您在雲計算架構設計上更快速有效的採用最佳實踐。AWS Trusted Advisor 持續監控您的資源，並隨著時間的推移對其進行分析且無需任何額外的配置。這降低複雜性並提供可擴充性，確保您始終以成本最佳化的方式運行資源。作為 AWS 業務支援計劃的一部分，這些功能不會產生額外費用。

AWS Well-Architected 協助雲端架構師建置安全、高效能、有彈性又有效率的各種應用程式和工作負載基礎設施。以五大架構支柱為基礎，即卓越營運、安全性、可靠性、效能達成效率、成本優化和永續發展，AWS Well-Architected 為客戶與合作夥伴提供一致的方法來評估架構及實作可擴展的設計。AWS Well-Architected Tool 能協助您持續審查應用及工作負載的狀態、改善架構設計並採用建議的最佳實踐。如果您需要我們的説明，可以聯繫 AWS 客戶團隊或 AWS 架構完善的合作夥伴。如需後續問題或意見，請加入我們不斷增長的 AWS re:Post 論壇 。