费率优化设计

在不更改设计、返工交易或放弃任何必备功能的情况下提高效率。

你并不总是需要重新设计或重新谈判来节省资金。 有时，可以更好地利用已有的内容。 如果不优化现有资源和作，则无需看到任何实际利益即可浪费资金。

示例方案

Contoso 的商业智能（BI）团队托管了一套 GraphQL API，以便不同的部门无需直接接触数据库即可访问数据。 随着时间的推移，他们添加了版本控制，现在通过消耗层上的单个 Azure API 管理网关运行所有内容。

三个 Azure Kubernetes 服务 （AKS） 群集位于 API 管理实例后面：

• 一个运行 Windows 节点池，用于以 .NET 4.5 编写的 API。

• 一个 Linux 群集，用于用 Java Spring 编写的 API。

• 其中一个运行在 Linux 上的 .NET Core 中编写的 API 的 Windows 节点池。 他们从以前的团队继承了此群集。

这些群集仅用于 API，现在都由 BI 团队管理。 这不是最干净的设置，但它是可行的，所以它们已经单独离开了。

BI 团队是业务中的一个成本中心，因此他们正在寻找优化其费率以降低运营成本的方法。

将基础结构组合在一起，使其有意义

尝试在同一位置运行内容，无论是资源、工作负荷还是团队。 使用有助于将更多内容打包到更少空间的服务。 考虑任何权衡，尤其是围绕安全性。

将更多实用工具打包到更少的系统中时，使用的硬件更少，在管理所有硬件上花费更少。 这意味着成本更低，复杂性更低。

Contoso 的挑战

• Contoso 的团队遵循 Microsoft AKS 基线体系结构。 它们运行三个群集，每个群集都有三个系统节点，因此总共有 9 个节点。

• 它们每月向所有群集应用三次修补程序和更新。

应用方法和结果

• 在团队进行测试后，他们决定将所有 API 合并到单个群集中，同时实现其原始群集的相同性能和 OS 特征。

• 它们还会将其系统节点池合并到四个节点，从而节省五个虚拟机的成本。

• 现在，他们只有一个群集可以修补和更新，从而节省更多时间。

• 接下来，他们正在考虑将两个 Linux 节点池合并为一个池，使事情更加简单。

利用预留和其他基础结构折扣

通过提交和预购来充分利用预期不会随时间变化的资源类型提供的折扣，以及哪些成本和利用率是可预测的， 进行优化。 此外，请与许可团队合作，影响未来的购买协议计划和续订。

对于特定资源和资源类别的可预测和长期承诺使用量，Microsoft 提供更低的费率。 资源在使用期间的成本更低，并且可以在使用期间进行摊销。

通过让许可团队了解当前和预测的资源投资，你可以在组织签署协议时帮助他们对承诺进行权利化。 在某些情况下，这些预测和承诺使用量可能会影响组织的价目表，这有利于工作负载的成本，也有利于使用相同技术的其他团队。

Contoso 的挑战

• 现在，团队已整合到一个群集上，消除了他们以前承担的一些多余的计算和操作负担，因此他们有兴趣寻找其他措施来降低群集的成本。

• 由于 BI 团队对 AKS 平台感到满意，因此他们计划在可预见的将来继续使用它，甚至可能会增加对它的使用。

应用方法和结果

• 由于 AKS 是基于 Azure 虚拟机规模集构建的，因此团队将调查 Azure 预留项。 他们知道用户节点所需的预期 SKU 和缩放单元。

• 他们购买了为期三年的预留，涵盖系统节点池和每个用户节点池的最小节点实例计数。

• 通过此购买，团队知道他们在计算需求方面得到了最好的处理，同时容许工作负载随时间增长。

在可行的情况下使用固定价格计费

当资源利用率高且可预测且可用的可比较 SKU 或计费选项时，请切换到固定价格计费，而不是基于消耗的计费。

当使用量很高且可预测时，固定价格模型通常成本更低，并且通常支持更多功能。 使用该模型可提高你的投资回报率 (ROI)。

Contoso 的挑战

• API 管理实例当前都部署为消耗层 SKU。 在评估 API 的使用模式后，他们了解到这些 API 在全局使用，有时使用得相当频繁。 团队决定分析当前计费模型与固定价格模型之间的成本差异。

应用方法和结果

• 进行成本分析后，团队发现，鉴于当前的使用模式，从消耗层迁移到标准层后成本将略低一些。 随着下一年服务的增长，成本差异可能会变得更加明显。 尽管固定定价模型没有反映出请求的弹性特征，但有时预先购买的计费模型是正确之选。

• 作为额外的奖金，使用标准层允许使用专用终结点进行入站连接，团队一直渴望为工作负荷实现该终结点。

• 在这种情况下，切换 SKU 对于利用率目的和专用终结点实现可能的额外网络分段的附加优势都有意义。