為費率最佳化而設計
 在無需重新設計、重新談判或犧牲功能或非功能需求的情況下提高效率。 |
|---|
利用機會，將現有資源和作業的公用程式和成本最佳化。 如果沒有抓住這個機會，您會花費不必要的金錢，而未提升投資報酬率。
範例案例
Contoso 的商業智慧 (BI) 小組為各種業務單位裝載一套 GraphQL API，以存取整個組織的資料存放區，而不授與直接的資料庫存取權。 他們多年來一直在建置這些，發現到版本設定很重要，因此他們現在已在單一使用量層 API 管理閘道上，透過已建立版本的端點公開其 API。
APIM 執行個體背後有三個 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 或計費選項時，針對一項資源切換至固定價格計費，而非以使用量為基礎的計費。
當使用率很高且可預測時，固定價格模型通常成本較低，而且可支援更多功能。 使用固定價格模式可以提高您的投資報酬率。
Contoso 的挑戰
- APIM 執行個體會全都部署為目前的使用量階層 SKU。 在評估 API 的使用模式之後，他們了解 API 會全域使用，有時會大量使用。 小組決定分析目前計費模型與固定價格模式之間的成本差異。
套用方法和結果
- 執行成本分析之後，小組發現，在目前的使用模式下，從使用量階層移轉至標準層的整體成本會稍微低一點。 隨著服務在未來一年的增長，成本差異可能會變得更加明顯。 雖然固定定價模式並未反映要求的彈性特性，但有時預先購買的計費模式是正確的選擇。
- 此外，使用標準層可讓私人端點用於輸入連線，小組一直想要針對工作負載實作私人端點。
- 在此情況下，交換 SKU 對於使用率來說是合理的，以及具有私人端點實作額外網路分割的額外優點。