匯總的建議
適用于此 Azure Well-Architected Framework 成本優化檢查清單建議:
CO:14 | 合併資源和責任。 在工作負載中,決定合併資源和增加密度的方式。 在工作負載外部,使用現有的集中式資源和服務,以便合併工作負載責任。 |
---|
本指南說明合併資源和責任的建議,以將工作負載成本優化。 合併資源是一項細微的工作,與單純消除浪費不同。 合併牽涉到合併工作負載的元件,例如伺服器、資料庫、應用程式和責任。
匯總可減少備援資源和授權,並增加密度。 尋找合併工作負載責任的機會。 使用集中式資源或小組來優化成本。 如果您未使用共用資源並優化規模經濟來合併資源和責任,您可能會錯過節省成本的機會。
定義
詞彙 | 定義 |
---|---|
集中式資源 | 多個元件使用的共用資源,而不是每個元件都有自己的專用資源。 |
變更控制項 | 管理和實作變更的結構化方法。 |
合併 | 結合元件以達到最佳工作負載需求的動作。 |
資源密度 | 資源內的邏輯區隔量值。 增加的密度通常等於較高的使用率,因為不同元件、取用者或環境的組合。 |
主要設計策略
匯總的主要目標是優化,而不是縮減。 匯總牽涉到重新調整工作負載、資源和小組角色,以達到最高成本效益。 與 優化元件成本不同,匯總是需要仔細考慮的程式。
幾乎所有匯總工作都有取捨和潛在風險,但可以大幅降低成本。 請務必分析潛在優點和相關聯的取捨。 所有匯總策略都會遵循下列步驟:
評量:執行徹底評估,以找出匯總可能會有好處的區域。
識別和評估:找出並評估潛在的匯總目標,以判斷潛在的成本優勢和取捨是否證明合併工作。
通訊和實作:如果您判斷匯總很有説明,請宣告即將進行的變更並加以套用。
合併資源
合併資源牽涉到合併工作負載內的資源。 您可以共置功能或取用者。 例如,您可以將三部網頁伺服器合併成單一伺服器,或將三個資料庫合併成單一資料庫伺服器。 您可以將多個防火牆合併成提供多個環境的單一防火牆。
目標是要增加資源密度,因此您可以將每個資源的成本效益最大化。 擴充資源的使用,並將資源備援降到最低。
您可以合併的常見服務類型包括應用程式平臺、資料庫、網路設備、閘道,以及分散式阻斷服務 (DDoS) 保護。 若要合併工作負載內的資源,請考慮下列建議:
評估工作負載資源。 評估現有的工作負載及其資源使用率。 分析 CPU 使用量、記憶體使用量、儲存體容量和網路頻寬等因素。 識別匯總可能有説明的區域。 匯總可能涉及優化資源配置、消除備援或使用量過低的資源,或重新設定工作負載以更有效率地執行。 請考慮工作負載相依性、效能需求和延展性等因素。
識別匯總目標。 選擇要合併的資源。 它可以是現有的資源,或是在工作負載內建立的新資源。 識別您可能用於匯總的現有資源。 例如,您可能有伺服器可以容納部分工作負載元件。 如果沒有現有的資源符合匯總需求,或合併新資源比較有説明,請考慮建立新的資源。
評估匯總可行性。 確保功能和技術需求,例如 CPU、記憶體和成長,都支援匯總。 避免危害效能、可靠性和安全性等需求。 例如,請勿建立不想要的跨區域相依性,或跨生產環境合併資源。
估計成本。 判斷合併的工作和潛在複雜度。 您應該計算成本,包括資源、授權和營運費用。 請考慮影響,例如因合併而造成資源監視的潛在挑戰。
與您的小組溝通並協調。 請確定您通知所有專案關係人即將進行的變更,以及需要採取的必要動作。 與小組協調以避免衝突,並確保順暢的實作。
風險:請考慮資源密度的影響,例如雜訊鄰近、縮放單位效果,以及減少備援。 對於任務關鍵性和業務關鍵性工作負載流程而言,資源匯總通常太有風險。
取捨:
資源匯總可減少隔離,而且可以在工作負載中建立雜訊鄰近案例。 尋找其他方法來實作邏輯隔離並增加裝載環境的容量。 例如,如果防火牆支援多個工作負載,請增加防火牆容量。
合併可消除分割,並可增加安全性風險,讓攻擊者更容易水準移動。 這也會使某些合規性標準難以達成。 優先處理合規性,而非匯總。
資源匯總會導致較少的備援。 請仔細規劃,以確保您在工作負載中具有適當的可靠性。
合併責任
合併工作負載責任的目標是要減少工作負載小組的責任。 這是一項策略性成本優化工作,需要工作負載小組外部的組織意識和共同作業。
有兩種主要方式可合併工作負載小組的責任。 您可以使用外部共用或集中式資源,而不會在工作負載環境中執行該資源。 您也可以將工作負載責任卸載給組織中的其他小組,因此您的小組不會直接負責這些工作或人員。
使用外部集中式資源
外部集中式資源是指工作負載環境外部的共用資源。 例如,組織可能有提供多個工作負載的集中式閘道。 外部集中式資源的目標是將重複和額外負荷降到最低。 您可以使用共用資源來優化成本,而不是為您的工作負載提供專用資源。 請考量下列建議事項:
評估工作負載資源。 評估工作負載的目前狀態,並找出匯總可能有説明的區域。
尋找外部商機。 調查貴組織是否有預先存在的集中式資源。 這些資源可能是您工作負載的潛在解決方案。 例如,您可以使用共用的安全性資訊和事件管理 (SIEM) ,而不是設定獨立的 SIEM 工具。
請考慮變更控制項。 瞭解管理集中式資源變更的程式。 請考慮核准工作流程、測試通訊協定和部署方法。 如果您減少對資源修改的控制,請分析潛在的挑戰。
預估成本。 在實作集中式資源之前,請清楚量化預期的節省成本,以符合與轉換相關聯的成本。 根據風險來衡量節省成本的優點,以做出明智的決策。
與您的小組溝通並協調。 建立小組之間持續意見反應的機制,以解決疑慮、改善共同作業,以及精簡程式。
記錄並追蹤變更。 維護所有已核准變更的詳細檔,包括其範圍、實作步驟,以及相關聯的風險或問題。 使用集中式系統或變更管理工具來追蹤和監視整個生命週期中的變更狀態。
取捨:過度合併可能會導致資源爭用,這可能會導致效能問題。 合併可能會限制個別小組和工作負載的彈性和靈活度,因為它們必須遵守可禁止自訂的集中式標準。
將責任卸載給外部小組
將工作負載責任卸載給外部小組是指使用執行安全性作業小組等特殊服務的專家集中式小組。 您可以將責任卸載給現有的小組,以協助優化成本和委派特定功能的專業知識。
評估小組技能。 評估小組目前的技能集。 識別集中式小組優化成本的技能差距或區域。
尋找可用的機會。 探索您的組織以取得可用的服務,例如安全性作業小組的服務。 請確定集中式小組可以容納新增的責任,而不會危害品質。
請考慮變更控制項。 熟悉集中式小組如何處理變更,例如核准工作流程、測試通訊協定和部署策略。 如果您對這些函式沒有直接控制,請判斷可能發生的潛在挑戰。
與您的小組溝通並協調。 請確定小組熟悉彼此的流程、工具和期望。 請考慮階段式轉換或試驗期間,以簡化班次,並提早找出潛在的挑戰。
記錄並追蹤變更。 維護所有已核准變更的詳細檔,包括其範圍、實作步驟,以及相關聯的風險或問題。 使用集中式系統或變更管理工具來追蹤和監視整個生命週期中的變更狀態。
Azure 設施
密度支援:許多 Azure 服務都支援增加的資源密度。 下表顯示這些服務的取樣。
Azure 服務 | 分割控制項 |
---|---|
Azure Front Door | 客戶網域和 URL 路徑 |
Azure 防火牆 | 網路和應用程式規則 |
Azure 應用程式閘道 | 接聽程式、URL 路徑型路由 |
API 管理 | API 原則 |
Azure Kubernetes Service (AKS) | 命名空間、節點集區 |
Azure App Service | App Service方案上的多個 Web 應用程式和 API |
Azure SQL Database | 伺服器上的多個資料庫 |
資源可觀察性:Azure 監視器 提供集中式平臺,用於監視和管理 Azure 資源的效能和健康情況。 您可以收集和分析遙測資料、設定警示,以及深入瞭解資源使用率和合併的機會。
Log Analytics 提供集中式記錄管理和分析。 您可以從各種 Azure 資源收集、分析和視覺化記錄資料,這有助於識別問題、疑難排解問題,以及取得操作見解。
相關連結
成本優化檢查清單
請參閱一組完整的建議。
意見反應
https://aka.ms/ContentUserFeedback。
即將登場:在 2024 年,我們將逐步淘汰 GitHub 問題作為內容的意見反應機制,並將它取代為新的意見反應系統。 如需詳細資訊,請參閱:提交並檢視相關的意見反應