大规模效率:AWS 成本优化的故事
已发表: 2022-07-22我最近推出了一个加密货币分析平台,预计每日用户数量很少。 然而,当一些受欢迎的 YouTube 用户发现该网站有帮助并发表评论时,流量增长如此之快以至于服务器超载,平台 (Scalper.AI) 变得无法访问。 我原来的 AWS EC2 环境需要额外的支持。 在考虑了多种解决方案后,我决定使用 AWS Elastic Beanstalk 来扩展我的应用程序。 事情看起来不错并且运行顺利,但我对计费仪表板中的成本感到吃惊。
这不是一个不常见的问题。 2021 年的一项调查发现,82% 的 IT 和云决策者遇到了不必要的云成本,86% 的人认为他们无法全面了解所有云支出。 尽管亚马逊在其文档中提供了额外费用的详细概述,但定价模型对于一个成长中的项目来说是复杂的。 为了让事情更容易理解,我将分解一些相关的优化来降低您的云成本。
为什么我选择 AWS
Scalper.AI 的目标是收集有关加密货币对(在交易所交易时交换的资产)的信息,运行统计分析,并为加密交易者提供有关市场状况的见解。 平台的技术架构由三部分组成:
- 数据摄取脚本
- 网络服务器
- 一个数据库
摄取脚本从不同来源收集数据并将其加载到数据库中。 我有使用 AWS 服务的经验,因此我决定通过设置 EC2 实例来部署这些脚本。 EC2 提供了许多实例类型,让您可以选择实例的处理器、存储、网络和操作系统。
我选择 Elastic Beanstalk 来实现其余功能,因为它保证了流畅的应用程序管理。 负载均衡器在我的服务器实例之间正确分配负载,而自动缩放功能处理添加新实例以增加负载。 部署更新变得非常容易,只需几分钟。
Scalper.AI 运行稳定,我的用户不再面临停机。 当然,由于我增加了额外的服务,我预计支出会增加,但数字比我预期的要大得多。
我如何能够降低云成本
回顾过去,我的项目使用 AWS 服务有很多复杂的地方。 我们将检查我在使用常见 AWS EC2 功能时发现的预算优化:突发性能实例、出站数据传输、弹性 IP 地址以及终止和停止状态。
突发性能实例
我的第一个挑战是支持我不断增长的项目的 CPU 功耗。 Scalper.AI 的数据摄取脚本为用户提供实时信息分析; 这些脚本每隔几秒钟运行一次,并为平台提供来自加密货币交易所的最新更新。 此过程的每次迭代都会生成数百个异步作业,因此站点增加的流量需要更多的 CPU 能力来减少处理时间。
AWS 提供的具有四个 vCPU 的最便宜的实例 a1.xlarge 当时每月花费我大约 75 美元。 相反,我决定在两个 t3.micro 实例之间分散负载,每个实例有两个 vCPU 和 1GB RAM。 t3.micro 实例为我需要的工作提供了足够的速度和内存,而成本仅为 a1.xlarge 的五分之一。 尽管如此,我的账单仍然比我在月底的预期要大。
为了理解原因,我搜索了亚马逊的文档并找到了答案:当实例的 CPU 使用率低于定义的基线时,它会收集积分,但当实例突然超过基线使用率时,它会消耗之前获得的积分。 如果没有可用的积分,该实例将使用 Amazon 提供的“剩余积分”。 这种赚取和花费积分的能力导致 Amazon EC2 平均 24 小时内实例的 CPU 使用率。 如果平均使用量高于基线,则实例按每个 vCPU 小时的统一费率额外计费。
我对数据摄取实例进行了多天的监控,发现我的 CPU 设置(旨在降低成本)却适得其反。 大多数时候,我的平均 CPU 使用率高于基线。
我最初分析了几个加密货币对的 CPU 使用情况; 负载很小,所以我认为我有足够的成长空间。 (我只使用了一个微实例进行数据摄取,因为更少的加密货币对不需要那么多的 CPU 能力。)然而,一旦我决定让我的见解更全面并支持数据的摄取,我就意识到我最初分析的局限性对于数百个加密货币对——除非以正确的规模执行,否则云服务分析毫无意义。
出站数据传输
我的网站扩展的另一个结果是由于一个小错误而增加了从我的应用程序传输的数据。 随着流量稳步增长并且没有更多的停机时间,我需要添加功能以尽快吸引并吸引用户的注意力。 我的最新更新是当加密货币对的市场条件与用户的预定义参数匹配时触发的音频警报。 不幸的是,我在代码中犯了一个错误,音频文件每隔几秒就会加载到用户的浏览器中数百次。
影响是巨大的。 我的错误从我的网络服务器生成了音频下载,导致额外的出站数据传输。 我的代码中的一个小错误导致账单几乎是以前的五倍。 (这不是唯一的后果:该错误可能导致用户计算机中的内存泄漏,因此许多用户不再回来。)
数据传输成本可占 AWS 价格飙升的 30% 以上。 EC2 入站传输是免费的,但出站传输费用按每 GB 计费(我构建 Scalper.AI 时每 GB 0.09 美元)。 正如我在艰难中学到的那样,对影响出站数据的代码保持谨慎是很重要的。 尽可能减少下载或文件加载(或仔细监控这些区域)将保护您免受更高的费用。 由于将数据从 EC2 传输到 Internet 的费用取决于工作负载和特定于 AWS 区域的费率,因此这些便士加起来很快。 许多新 AWS 客户不知道的最后一个警告:不同位置之间的数据传输变得更加昂贵。 但是,使用私有 IP 地址可以避免在同一区域的不同可用区之间产生额外的数据传输成本。
弹性 IP 地址
即使使用弹性 IP 地址 (EIP) 等公共地址,也可以降低您的 EC2 成本。 EIP 是用于动态云计算的静态 IPv4 地址。 “弹性”部分意味着您可以将 EIP 分配给任何 EC2 实例并使用它,直到您选择停止。 这些地址可让您通过将地址重新映射到您账户中的不同实例来无缝地将不健康的实例与健康的实例交换。 您还可以使用 EIP 为域指定 DNS 记录,使其指向 EC2 实例。
AWS 每个区域的每个账户仅提供五个 EIP,这使其资源有限且成本高昂且使用效率低下。 如果您在一个月内重新映射 EIP 超过 100 次,AWS 会为每个额外的 EIP 收取较低的小时费率和额外费用; 保持在这些限制之下将降低成本。
终止和停止状态
AWS 提供了两个选项来管理正在运行的 EC2 实例的状态:终止或停止。 终止将关闭实例,为其配置的虚拟机将不再可用。 任何附加的 Elastic Block Store (EBS) 卷都将被分离和删除,并且本地存储在实例中的所有数据都将丢失。 您将不再为该实例付费。
停止实例是类似的,只是有一点不同。 附加的 EBS 卷不会被删除,因此它们的数据会被保留,您可以随时重新启动实例。 在这两种情况下,Amazon 不再对使用实例收费,但如果您选择停止而不是终止,只要 EBS 卷存在,它们就会产生成本。 AWS 建议仅在您希望尽快重新激活实例时才停止该实例。
但是有一个功能可以在月底扩大您的 AWS 账单,即使您终止了一个实例而不是停止它:EBS 快照。 这些是存储在 Amazon 简单存储服务 (S3) 中的 EBS 卷的增量备份。 每个快照都包含您使用以前的数据创建新 EBS 卷所需的信息。 如果您终止一个实例,其关联的 EBS 卷将被自动删除,但其快照将保留。 由于 S3 是按存储的数据量收费的,因此如果您短期内不使用这些快照,我建议您删除它们。 AWS 能够使用 CloudWatch 服务监控每个卷的存储活动:
- 登录 AWS 控制台后,从左上角的服务菜单中,找到并打开 CloudWatch 服务。
- 在页面左侧的Metrics可折叠菜单下,单击All Metrics 。
- 该页面显示具有可用指标的服务列表,包括 EBS、EC2、S3 等。 单击EBS ,然后单击Per-volume Metrics 。 (注意:只有在您的账户上配置了 EBS 卷时, EBS选项才可见。)
- 单击查询选项卡。 在编辑器视图中,复制并粘贴命令
SELECT AVG(VolumeReadBytes) FROM "AWS/EBS" GROUP BY VolumeId
,然后单击运行。 (注意:CloudWatch 使用具有独特语法的 SQL 方言。)
CloudWatch 提供了多种用于分析存储活动的可视化格式,例如饼图、折线图、条形图、堆积面积图和数字。 使用 CloudWatch 识别非活动 EBS 卷和快照是优化云成本的一个简单步骤。
口袋里有多余的钱
尽管 CloudWatch 等 AWS 工具为云成本监控提供了不错的解决方案,但各种外部平台与 AWS 集成以进行更全面的分析。 例如,VMWare 的 CloudHealth 等云管理平台显示了可用于趋势分析、异常检测以及成本和性能监控的最高支出领域的详细细分。 我还建议您设置 CloudWatch 计费警报,以在费用过高之前检测到任何费用激增。
Amazon 提供了许多出色的云服务,可以帮助您将服务器、数据库和硬件的维护工作委托给 AWS 团队。 尽管云平台成本很容易因错误或用户错误而增加,但 AWS 监控工具为开发人员提供了保护自己免受额外费用的知识。
考虑到这些成本优化,您已准备好启动您的项目,并在此过程中节省数百美元。