Heroku通过迁移至Amazon DynamoDB降低了运营成本

关键收获

Heroku是一个完全托管的服务平台(PaaS)，为开发者提供在AWS上部署、运营和扩展应用程序的便利。自2007年成立以来，Heroku隶属于Salesforce，并成为数百万应用程序的首选平台，从小型初创公司到拥有大型分布式部署的大企业。保持这么多应用程序高效运行需要持续投入基础设施资源，并利用AWS提供的构建块。

本文将探讨Heroku在2023年完成的一次基础设施升级，迁移了应用程序的指标和警报功能存储后端，从自管理的Apache Cassandra集群到Amazon DynamoDB。Heroku顺利完成这一迁移，且未对客户造成任何影响。迁移至DynamoDB提升了平台的可靠性，并减少了服务成本。接下来，我们将详细分析该系统的整体架构、为何选择DynamoDB、迁移过程及其带来的成果。

作为服务的指标

Heroku的应用程序指标由内部的指标即服务(MetaaS)提供支持。MetaaS负责收集在Heroku上运行的应用程序的不同观察数据，比如处理特定HTTP请求所需的时间。这些原始数据经过聚合，计算每个应用程序和每分钟的统计数据，如中位数、最大值和99百分位响应时间。这些结果以时间序列形式在Heroku仪表板上展示，同时用于驱动警报和自动扩展功能。

MetaaS的核心是一个高规模、多租户的时间序列数据处理平台。每秒钟会有数十万条观察数据被输入到Apache Kafka on Heroku。一系列流处理作业从Kafka中消费这些观察数据，计算每个客户应用程序的各种指标，最终将结果写入数据库最初使用的是Amazon EC2上的Apache Cassandra，进行长期的留存和查询。MetaaS的时间序列数据库存储了多个TB的数据，每秒写入数万条新数据，并在高峰时每秒处理数千条查询。

以下图解展示了最初的架构：

选择DynamoDB的理由

虽然MetaaS与Cassandra的结构已经服务了Heroku多年，但在2022年底，Heroku工程团队开始探索后端存储的其他选项。MetaaS所使用的Kafka集群由经验丰富的团队维护和调优，而Cassandra集群则是专门为MetaaS设计的。

Heroku意识到转向托管服务的重要性，这由一支专家团队运营和维护，类似于他们的Kafka集群他们的工程团队人数很少。团队希望在AWS上找到一个适合存储大量数据、可扩展的分布式系统，并保持快速写入性能的托管数据库。Heroku其他团队已经使用DynamoDB进行数据存储和处理，因此DynamoDB成为MetaaS工作负载的自然选择。

小心迁移

计划制定完成后，剩下的任务就是在不影响现有客户的情况下将高规模、高吞吐量的分布式系统的后端存储进行替换。MetaaS的架构为Heroku提供了显著优势他们已经具备了一套从Kafka向Cassandra写入时间序列数据的流处理作业。这使得他们能够轻松建立一套平行的流处理作业，将相同的数据写入DynamoDB，而对系统的其他部分没有可观察的影响，作为迁移的第一步。

运营指标对Heroku的客户至关重要。为了确保数据成功写入DynamoDB，团队实施了一系列基于传统单元和集成测试的测试。他们开始对MetaaS进行一小部分读取查询，从Cassandra和DynamoDB中读取数据，以确认两个数据库中的数据是一致的。任何产生不同结果的查询都会被记录。在预生产环境中进行测试后，他们逐步增加实验规模，直到100的查询都通过两个代码路径进行处理。这一变更也没有产生可观察的影响，因为客户仍然从Cassandra代码路径中获取结果，但这使他们能够发现并解决一些在传统单元和集成测试中遗漏的边界情况。

平滑过渡

随着数据验证实验表明DynamoDB一致性地返回与Cassandra相同的结果，Heroku准备切换的时间也就不远了。MetaaS仅存储不超过30天的数据，超过后会被删除对于DynamoDB，可以使用方便的TLL功能。这意味着不需要协调将历史数据从Cassandra迁移到DynamoDB。在确认两个地方能够写入相同数据后，他们可以简单地等待两个数据库同步。

首先从测试环境开始，他们逐步将查询切换为仅从DynamoDB读取，谨慎地处理，防止有客户报告任何早期遗漏的奇怪行为。结果没有出现任何问题，自2023年5月以来，MetaaS的100查询都从DynamoDB提供。Heroku又等待了几周，以确保没有需要回滚的变化。

以下图解展示了更新后的架构：

结果

在经历了一年的迁移后，Heroku对选择托管数据库服务感到满意。DynamoDB在规模上表现稳定且高效。Heroku减少了多达90的数据库服务器补丁和调优的运营开销，达成了最初目标。此外，DynamoDB表现更加快速且成本低于之前自托管的Cassandra集群，查询的最大延迟降低了75。

例如，如下图所示，在1800之前，他们正在查询Cassandra，并观察到明显的p99延迟高峰，但在1800之后，查询DynamoDB时不再出现这些高峰。

经验教训

Heroku通过VPC端点访问DynamoDB。AWS身份与访问管理IAM策略设置要求通过这些VPC端点发送流量，这使得VPC中的应用程序可以在不暴露在公共互联网的情况下访问DynamoDB。

Heroku还利用DynamoDB自动扩展管理MetaaS表的预配置读取能力，因为查询流量会根据有多少客户在Heroku仪表板上查看指标而自然波动。MetaaS的写入模式相对可预测，因此他们能够手动调整表的写入能力，超过自动扩展的最大目标90利用率。对于平均消耗并偶尔涌入的工作负载，自动扩展可以比为峰值容量进行配置来节省费用；而对于可预测的工作负载，它可以帮助精确配置所需的容量以降低成本。

写入DynamoDB总是至少消耗一个写入容量单位WCU，但可能根据记录的大小消耗更多每KB数据消耗1个WCU，DynamoDB的不超过400KB记录大小限制。虽然MetaaS存储的大部分记录十分小，他们发现一些超出400KB限制的异常情况。Heroku通过在写入DynamoDB之前对这些较大记录进行gzip压缩解决了这个问题，从而节省了一些费用。由于MetaaS数据的查询相对较少，因此压缩和解压缩数据的CPU时间成本相对于减少的WCU和无需更改模式的便利性来说是微不足道的。

最后，在测试初期，他们在写数据到DynamoDB时遇到了一些意外的性能瓶颈。限制因素显示为DynamoDB SDK所使用的HTTP客户端配置不足对于高规模工作负载，调优而非使用默认设置是很有必要的。他们在增加允许的并发连接数、调整保留打开的空闲连接数以及配置比默认设置更加激进的超时和重试选项后，获得了显著的性能提升。

结论

在本文中，我们讨论了Heroku如何通过将自管理的Cassandra集群迁移到DynamoDB来升级其基础设施。Heroku成功实现了这一迁移，且未对客户产生影响，从而提高了平台的可靠性并降低了成本。性能改善的原因在于DynamoDB的查询性能要更加可预测在Cassandra环境下，他们在峰值流量时偶尔会遇到高达80ms的延迟，而使用DynamoDB时，查询的延迟稳定在20ms以下，这大大提高了向客户交付指标结果的效率。

对于在DynamoDB上运行高规模工作负载的其他技巧或问题，欢迎在评论中告知我们！欲开始使用DynamoDB，请参阅开发者指南和AWS DynamoDB控制台。

本文为Heroku和AWS的联合协作，已在Heroku博客与AWS数据库博客中交叉发布