费率优化设计
 在不重新设计、不重新协调或不牺牲功能/非功能需求的情况下提高效率。 |
|---|
利用机会优化现有资源和操作的效用和成本。 如果没有，你就不必要在没有任何额外投资回报率 (ROI) 的情况下花钱。
示例方案
Contoso 的商业智能 (BI) 团队为各种业务部门提供一套 GraphQL API，无需授予直接数据库访问权限即可让其访问整个组织的数据存储。 他们多年来一直在构建这些功能，并发现版本控制很重要，因此他们现在单个消耗层 API 管理网关上通过经版本控制的终结点公开其 API。
在 API 管理实例背后有三个 AKS 群集，这些群集托管已公开的 API。 一个群集运行 Windows 节点池，用于以 .NET 4.5 编写的 API；一个 Linux 群集，用于以 Java Spring 编写的 API；一个 Linux 群集，它们从先前正在运行 .net core API 的团队继承而来。 这些群集现在都归 BI 团队所有，仅用于这些 API。 虽然管理 3 个群集不是理想之选，但它们一直在按预期工作，因此没有受到影响。
作为业务中的成本中心，BI 团队正在寻找优化其费率以降低运营成本的方法。
在可行的情况下整合基础结构
与其他资源、工作负载甚至团队共同查找使用情况。 首选更容易实现更高密度的服务。 考虑潜在权衡，尤其是在安全边界上。
整合基础结构有助于优化云成本。 随着密度的增加，运行工作负载所需的资源量更少。 这降低了每单位成本和管理成本。
Contoso 的挑战
- 工作负载团队根据 Microsoft 基线体系结构指南设计了其 AKS 基础结构，该指南建议为每个群集运行至少 3 个节点。 此配置使得团队跨 3 个群集支持 9 个系统节点。
- 团队每月向群集应用 3 次补丁和更新。
应用方法和结果
- 经过测试，团队确定他们可以将所有 API 合并到具有 3 个用户节点池的单个群集中，同时实现与原始群集相同的性能和 OS 特征。
- 将 API 整合到一个群集后，它们会将其系统节点池整合到 4 个节点，从而节省 5 个虚拟机的成本。
- 团队现在可以简化群集上的修补和升级过程，因为他们只有一个群集需要管理。
- 他们的下一个成本节省目标是评估将两个 Linux 节点池整合为一个池的情况，以进一步降低操作开销。
利用预留和其他基础结构折扣
通过承诺使用量和预购买来优化，以利用对资源类型提供的折扣，其中这些资源类型预计不会随时间变化，且其成本和使用量是可预测的。 此外，请与许可团队合作，影响未来的购买协议计划和续订。
对于特定资源和资源类别的可预测和长期承诺使用量，Microsoft 提供更低的费率。 资源在使用期间的成本更低，并且可以在使用期间进行摊销。
通过让许可团队了解当前和预测的资源投资，可以在组织签署协议时帮助他们承诺适当的使用量。 在某些情况下，这些预测和承诺使用量可能会影响组织的价目表，这有利于工作负载的成本，也有利于使用相同技术的其他团队。
Contoso 的挑战
- 现在，团队已整合到一个群集上，消除了他们以前承担的一些多余的计算和操作负担，因此他们有兴趣寻找其他措施来降低群集的成本。
- 由于 BI 团队对 AKS 平台感到满意，因此他们计划在可预见的将来继续使用它，甚至可能会增加对它的使用。
应用方法和结果
- AKS 是基于虚拟机规模集构建的，因此团队研究了 Azure 预留。 他们知道用户节点所需的预期 SKU 和缩放单元。
- 他们购买了为期三年的预留，涵盖系统节点池和每个用户节点池的最小节点实例计数。
- 通过此购买，团队知道他们在计算需求方面得到了最好的处理，同时容许工作负载随时间增长。
在可行的情况下使用固定价格计费
当资源使用量很高且可预测，并且有可比的 SKU 或计费选项可用时，请切换到固定价格计费，而不是基于消耗的计费。
当使用量很高且可预测时，固定价格模型通常成本更低，并且通常支持更多功能。 使用该模型可提高你的投资回报率 (ROI)。
Contoso 的挑战
- API 管理实例当前都部署为消耗层 SKU。 在评估 API 的使用模式后，他们了解到这些 API 在全局使用，有时使用得相当频繁。 团队决定分析当前计费模型与固定价格模型之间的成本差异。
应用方法和结果
- 进行成本分析后，团队发现，鉴于当前的使用模式，从消耗层迁移到标准层后成本将略低一些。 随着下一年服务的增长，成本差异可能会变得更加明显。 尽管固定定价模型没有反映出请求的弹性特征，但有时预先购买的计费模型是正确之选。
- 还有个好处是，使用标准层允许对入站连接使用专用终结点，这是团队一直渴望为工作负载实现的。
- 在这种情况下，对于使用量目的，还有专用终结点实现可能带来的额外网络分段这一额外好处，切换 SKU 都是有意义的。