速率優化的設計
 在不重新設計、重新談判或犧牲功能或非功能需求的情況下提高效率。 |
|---|
利用機會，將現有資源和作業的公用程式和成本優化。 如果沒有，您不需要花錢，而不需要任何額外的 ROI。
範例案例
Contoso 的商業智慧 （BI） 小組會為各種業務單位裝載一套 GraphQL API，以存取整個組織的資料存放區，而不授與直接資料庫存取權。 他們多年來一直在建置這些版本，併發現版本控制很重要，因此他們現在已透過單一取用層API 管理閘道上的版本端點公開其 API。
API 管理實例背後有三個 AKS 叢集，裝載公開的 API。 一個執行以 .NET 4.5 撰寫之 API 的 Windows 節點集區、一個以 JAVA Spring 撰寫之 API 的 Linux 叢集，以及他們繼承自先前執行 dotnet 核心 API 的小組所繼承的一個 Linux 叢集。 叢集現在全都由 BI 小組擁有，而且只用于這些 API。 雖然管理三個叢集並不理想，但它們已如預期般運作，因此已單獨運作。
作為企業成本中心，BI 小組正在尋找將費率優化以降低營運成本的方法。
合併實際運作的基礎結構
與其他資源、工作負載，甚至是小組共置使用量。 偏好讓服務更容易達到更高的密度。 請考慮潛在的取捨，特別是在安全性界限上。
合併您的基礎結構可協助您將雲端成本優化。 隨著密度增加，您需要執行工作負載的資源量會減少。 這可降低每個單位的成本和管理成本。
Contoso 的挑戰
- 工作負載小組根據 Microsoft 基準架構指引設計了其 AKS 基礎結構，建議每個叢集至少執行三個節點。 此設定導致小組跨三個叢集支援九個系統節點。
- 小組會每月將修補程式和更新套用至叢集三次。
套用方法和結果
- 測試之後，小組決定可以將所有 API 合併成單一叢集與三個使用者節點集區，同時達到其原始叢集的相同效能和 OS 特性。
- 將 API 合併到一個叢集之後，它們會將其系統節點集區合併到四個節點，以節省五部虛擬機器的成本。
- 小組現在可以簡化其叢集上的修補和升級程式，因為它們只有一個叢集可管理。
- 其下一個節省成本的目標是評估將兩個 Linux 節點集區合併成一個，以進一步降低作業額外負荷。
利用保留和其他基礎結構折扣
藉由認可和預先購買來優化，以利用資源類型上提供的折扣，這些類型不會隨著時間變化，以及可預測成本和使用率。 此外，請與您的授權小組合作，以影響未來的購買合約方案和續約。
Microsoft 針對特定資源和資源類別提供可預測的長期承諾率降低。 資源在使用量期間的成本較低，而且可在期間內攤銷。
藉由讓您的授權小組知道目前和預測的資源投資，您可以在組織簽署合約時協助他們正確大小的承諾。 在某些情況下，這些預測和承諾可能會影響貴組織的價位表，這有利於工作負載的成本，以及使用相同技術的其他小組。
Contoso 的挑戰
- 既然小組已合併到一個叢集，並移除先前吸收的一些多餘的計算和作業負擔，他們有興趣尋找額外的量值來降低叢集的成本。
- 由於 BI 小組對 AKS 平臺感到滿意，因此他們計畫在未來持續使用它，甚至可能會增加其使用量。
套用方法和結果
- 由於 AKS 是以虛擬機器擴展集為基礎所建置，因此小組會查看 Azure 保留。 他們知道使用者節點所需的預期 SKU 和縮放單位。
- 他們會購買為期三年的保留，其中包含系統節點集區，以及每個使用者節點集區節點的最小實例計數。
- 透過此購買，小組知道他們正在取得其計算需求的最佳交易，同時允許工作負載隨著時間成長。
實際時使用固定價格計費
當資源的使用率很高且可預測且可使用可比較的 SKU 或計費選項時，切換至固定價格計費，而不是以耗用量為基礎的資源計費。
當使用率很高且可預測時，固定價格模型通常成本較低，而且通常支援更多功能。 使用它可能會增加您的 ROI。
Contoso 的挑戰
- API 管理實例全都部署為目前耗用量層 SKU。 在評估 API 的使用模式之後，他們瞭解 API 會全域使用，有時相當嚴重。 小組決定分析目前計費模型與固定價格模型之間的成本差異。
套用方法和結果
- 執行成本分析之後，小組發現，在目前的使用模式下，從取用層移轉至標準層的成本會稍微低一點。 隨著服務在未來一年的增長，成本差異可能會變得更加明顯。 雖然固定定價模式並未反映要求的彈性特性，但有時預先購買的計費模型是正確的選擇。
- 此外，使用標準層可讓私人端點用於輸入連線，小組一直渴望針對工作負載實作此端點。
- 在此情況下，交換 SKU 對於使用率用途以及私人端點實作可能的額外網路分割的新增優點而言都是合理的。