容器化 .NET 应用程序 - AWS 规范性指导

本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。

容器化 .NET 应用程序

概述

容器是一种轻量且高效的方案,能够以一致且可重复的方式对应用程序进行打包和部署。本部分说明如何使用无服务器容器服务 AWS Fargate来降低 .NET 应用程序的成本,同时提供可扩展且可靠的基础设施。

成本影响

影响使用容器节省成本的有效性的一些因素包括应用程序的规模和复杂程度、需要部署的应用程序数量,以及应用程序所承受的流量和需求水平。对于小型或简单的应用程序而言,与传统的基础设施方法相比,容器可能并不会带来显著的成本节省,因为管理容器及其相关服务所产生的开销实际上可能会增加成本。然而,对于规模较大或更为复杂的应用程序而言,使用容器能够通过提高资源利用率并减少所需实例的数量来实现成本节省。

我们建议您在使用容器节省成本时,务必牢记以下几点:

  • 应用程序规模和复杂性 – 规模更大、更复杂的应用程序更适合容器化,因为这类应用程序通常需要更多的资源,并且能从资源利用效率的提升中获得更大的益处。

  • 应用程序数量 – 您所在组织必须部署的应用程序越多,通过容器化实现的成本节省就可能越高。

  • 流量和需求 – 那些流量大、需求高的应用程序能够从容器所提供的可扩展性和弹性中获益。这样可以节省成本。

不同的架构和操作系统会影响容器的成本。如果您使用的是 Windows 容器,那么由于许可方面的因素,成本可能不会降低。使用 Linux 容器时,许可费用更低或者根本就没有费用。下图使用了美国东部(俄亥俄州)地区的基本配置,其设置如下: AWS Fargate 在分配了 4 v CPUs 和 8 GB 内存的情况下,每月运行 30 个任务,每项任务持续 12 小时。

您可以选择两个主要的计算平台来运行您的容器 AWS:基于 EC2 的容器主机和无服务器或AWS Fargate如果您使用 Amazon Elastic Container Service(Amazon ECS)而非 Fargate,则必须保持运行中的计算(实例),以便让放置引擎在需要时能够实例化容器。如果您改用 Fargate,则仅会预调配所需的计算容量。

下面的图表显示了等效容器使用 Fargate 与 Amazon EC2 产生的区别。由于 Fargate 具有灵活性,应用程序的任务每天可以运行 12 个小时,且在非工作时间不会占用资源。但是,对于 Amazon ECS,您必须使用 EC2 实例的自动扩缩组来控制计算容量。这可能会导致容量全天 24 小时运行,从而最终增加成本。

Fargate 每月成本与 EC2 每月成本对比

成本优化建议

使用 Linux 容器而非 Windows

如果您使用 Linux 容器而非 Windows 容器,就能实现显著的节省。例如,如果您在 EC2 Linux 上运行 .NET Core 而非在 EC2 Windows 系统上运行 .NET Framework,那么在计算成本方面就能节省约 45% 的费用。如果您使用ARM架构(AWS Graviton)而不是x86,则可以额外节省40%。

如果您计划为现有的 .NET Framework 应用程序运行基于 Linux 的容器,则您必须将这些应用程序移植到现代的、跨平台的 .NET 版本(例如 .NET 6.0)中,这样才能使用 Linux 容器。一个重要的考虑因素是:权衡重构的成本与通过降低 Linux 容器的成本所获得的节省成本之间的关系。有关将应用程序移植到现代 .NET 的更多信息,请参阅 AWS 文档中的 Porting Assistant for .NET

迁移到现代 .NET(即从 .NET Framework 中迁出)的另一个好处是,可以获得更多的现代化机会。例如,您可以考虑对您的应用程序进行重新架构,使其采用基于微服务的架构,这样会更具可扩展性、敏捷性和成本效益。

以下图表展示了探索现代化机遇的决策流程。

更换平台决策树

利用节省计划

容器可以帮助您利用计算类节省计划来降低 Fargate 成本。这种灵活的折扣模式所提供的折扣与可转换预留实例的折扣相同。Fargate 定价是根据从您开始下载容器映像之时起直至 Amazon ECS 任务终止期间所使用的 vCPU 和内存资源计算得出(向上取整到最接近的一秒)。Fargate 的节省计划可为用户节省最多 50% 的 Fargate 使用费用,条件是用户需承诺在一年或三年的时间内使用特定数量的计算资源(以每小时美元计价)。您可以使用 AWS Cost Explorer 来帮助您选择节省计划。

需要明白的是,计算类节省计划会优先应用于能为您带来最高节省的用量。例如,如果您在 us-east-2 中运行一个 t3.medium Linux 实例以及一个相同的 Windows t3.medium 实例,那么 Linux 实例会首先享受到节省计划的益处。这是因为 Linux 实例的节省潜力为 50%,而相同的 Windows 实例的节省潜力则为 35%。如果您有其他符合储蓄计划条件的资源 AWS 账户,例如亚马逊 EC2 或 Lambda,则无需先将您的储蓄计划应用于 Fargate。有关更多信息,请参阅本指南的储蓄计划文档中的了解储蓄计划如何适用于您的 AWS 使用量,以及本指南的 “优化 Windows 在 Amazon EC2 上的支出” 部分。

调整 Fargate 任务的大小

重要的是确保 Fargate 任务的大小正确,以实现最大程度的成本优化。通常情况下,在最初为应用程序中使用的 Fargate 任务确定配置时,开发人员并不具备所有必要的使用信息。这可能会导致任务过度预调配,进而造成不必要的开支。为避免这种情况,我们建议您对 Fargate 上运行的应用程序进行负载测试,以了解特定任务配置在不同使用场景下的表现情况。您可以利用负载测试结果、任务的 vCPU 和内存分配情况以及自动扩缩策略,来找到性能与成本之间的恰当平衡。

以下图表显示了 Compute Optimizer 如何为最佳任务和容器大小生成建议。

Compute Optimizer 针对任务和容器大小的建议

一种方法是使用负载测试工具(如上 AWS的 “分布式负载测试” 中所述的工具)来建立 vCPU 和内存利用率的基准。在您运行负载测试以模拟典型的应用程序负载之后,您就可以对任务的 vCPU 和内存配置进行微调,以满足基准利用率要求。

其他资源