我们的流数据渠道上的AWS成本降低了67%

在塔洛夫洛，我们决心不成为孩子们赤脚走路的鞋匠。我们处理自己的AWS成本时，就好像是在帮助我们的一位客户。结果令人震惊，值得分享。并且，无需任何预付或预留承诺！

这篇文章展示了一点点勤奋和一个明确的成本目标如何最终对盈利能力产生巨大影响。

一条AWS Glue ETL管道，以及几项作为Glue、ECS或Sagemaker作业运行的数据科学服务；

每个环境有两个EMR集群，因为我们选择将一些Flink管道拆分成它们；

我们还为每个环境运行了一个Amazon MSK集群，因为有一些使用Kafka的流媒体管道。

管理成本的第一个主要关键🔑是某种成本监控平台，它可以方便地与开发人员沟通成本目标。这样就可以很容易地了解各种成本因素。快速检测不利变化的某种形式的警报也有很大帮助。幸运的是，我们知道在哪里可以找到一个。

同样关键的是，如何将我们平台上的用户活动与我们的AWS成本关联起来(即：云支出的边际分析)。这使我们可以在没有数量差异的情况下跟踪效率。如果我们的账单上涨了20%，我们知道这是由于工程效率低下、架构或产品更改，甚至是业务需求的增加。

我们的目标是以我们这边的最佳边际和平均云成本点提供我们的客户想要的服务。这意味着跟踪工作或活动单元(例如：客户数量、API调用、生成的报告)，并将它们与我们提供的服务相关联。然后，我们可以确定成本的变化如何也与这些活动的变化相关。下面是我们非常密切跟踪的两个问题。

它是一个代表以下内容的综合单位：(1)我们预测的服务数量，(2)我们对任何特定客户进行预测所依据的数据大小，以及(3)预测的频率。

我们接收大量不同大小的AWS成本和使用报告，因此我们跟踪接收的每100K行的边际成本，以更好地了解客户的盈利能力。

我们计算出，我们在某些服务上的费用占账单的百分比要比其他服务高得多。我们需要对我们的基础设施和代码进行一些小的和大的调整来处理这个问题。因为.学分快用完了🕚。按照顺序，最昂贵的服务是：AWS Glue、Amazon EC2、Amazon S3和Amazon MSK。

当然，我们的更改特定于我们的用例，但我们在本文中强调了方法。对你来说，关键是首先专注于最低的挂果，然后逐渐转向规模较小但不断增长的AWS成本。在我们的示例中，这是我们按以下顺序执行的操作：

这很难做到。此任务的复杂程度将取决于您公司的规模以及允许多少人创建EC2实例。有些人有看门人，有些人没有。有人可能需要问别人，出于某种原因，他们是否还在使用一些看似无用的实例。我们知道，追人很烂。🤦🏽良好的标记可能有助于查找不需要但仍处于活动状态的实例。

附注：如果你不给任何东西加标签，开始做什么永远都不会太晚。下一次您必须削减云成本时，稍加努力会有所帮助。

创建一些S3生命周期策略有助于查找和删除不必要的文件。当您的服务的一部分处理一些文件，并且您也有一些部分处理的文件时，很容易积累大量的文件。定义删除或更改各个文件的存储类别的策略可能会产生很大的不同。

我们调整了作业大小，以便在没有AWS Glue的情况下运行。它们被“停靠”，在AWS Fargate上作为Amazon ECS任务运行。我们对Glue Job进行了重构，使其需要更少的内存，并在更小的块中运行。这使我们能够将大部分工作转移到Fargate，这花费了我们Glue Run成本的三分之一。

我们没有使用AWS Athena查询，而是通过直接从S3拉取数据库，减少了爬行数据库所需的数据量。(使用过滤的拉取)这使我们能够优化GetObject请求的数量，这开始成为一个令人头疼的问题。此外，它还极大地减少了为数据拉取保持分区更新所需的爬行量。

=>；结果：与将镶木地板重新加工为更大文件大小相结合，这可将AWS S3 GET OBJECT和PUT OBJECT请求和成本降低90%+。

我们将负责将大型CSV转换为去重复拼图文件的AWS Glue作业转换为Apache Flink管道作业。我们已经在EMR群集内运行Flink了。因此，我们简单地引入了一个新的Flink作业，该作业具有与AWS Glue作业相同的功能。从本质上说，我们的Flink管道是我们招致的沉没成本。我们决定使用它，避免因使用按小时收费的AWS Glue管道而产生的边际成本。

虽然我们实现了新的Flink作业来替换AWS Glue作业，但我们更改了生成的拼花地板文件的大小。我们的Glue作业在我们的一个S3存储桶中创建了数量惊人的小文件。这反过来又导致AWS S3 GET和PUT操作走得更高，并大幅增加了我们的AWS账单。

我们平台的第一个版本大量使用Apache Kafka。让一个强大而稳定的卡夫卡集群始终运行是至关重要的。但是，随着我们过去的一些变化(在这些调整之前)，我们对卡夫卡的使用变得不那么苛刻了。虽然我们使用MSK的费用是固定的，但我们不再那么依赖卡夫卡了，所以使用MSK并不划算。我们能够将我们的卡夫卡转移到ECS，并将其作为一个集装箱化的集团运营。我们毕竟不需要一些裁员。

我们极大地减少了活动日志记录，同时确保可以重新启用它以进行调试。这是一个有趣的监控成本，因为它上升得很快。对于开发人员来说，在没有计划如何在生产中利用日志记录的情况下，就很容易投入调试日志记录。最终的结果不仅是潜在的安全违规，(哎呀！)。但是不必要的费用。我们认为生产测井和开发测井应该有不同的要求。我们知道不能用同样的方式记录每件事。

我们过去在每个环境上都有2个电子病历群集，并对每种节点类型(主节点、核心节点或任务节点)使用按需实例组。

首先，我们使用实例车队和Spot实例进行了一些测试。如果发生资源调配超时，我们启用了切换到按需实例的功能，但这并不起作用。这就是为什么..。

我们的集群可以在启动时提供所有实例。但是，如果AWS回收给定机群(核心或主)中的所有实例，群集就会崩溃！他们没有切换到按需，并且调整队列大小以使用按需实例或不同数量的Spot实例没有任何改变。

为了解决这个问题，我们将2个EMR集群转换为单个集群。我们一直使用一个按需实例作为主节点，另一个作为核心节点的一部分。作为Spot实例的所有其他Core或Task节点。这种实现的失败率很低。但是，AWS可以随时回收实例，这可能会导致某些步骤失败。为此，重要的是要有一定的容错能力来处理这一问题。在我们的示例中，我们实现了一个简单的重试机制来重新运行失败的步骤。啊，真灵。

在所有这些调整之后，我们可以对结果感到惊讶。同样，这也是不同之处：

这些变化意味着我们每月的AWS账单减少了近67%。😺我们甚至不需要承诺任何新的储蓄计划或预留实例。(那可以为我们节省更多的钱，但我们会把钱留到另一个职位去做。)。同样令人兴奋的是，我们改进了每个客户的边际成本，这是一个关键的SaaS指标！我们知道我们的一些成功是特定于用例的。但是，我们采取的方向可以为任何AWS用户节省资金。如有任何问题，请发电子邮件给我们：[email protected]