使用 Amazon DynamoDB 按需容量模式运行突增工作负载，并将成本降低超过 90％

本博文由 YourCast Inc. 软件工程师 Keisuke Utsumi 特约发表。他们表示，“YourCast Inc. 使用与电视广播同步的网站为用户提供交互式娱乐服务。”

YourCast Inc. 为日本的电视观众提供基于网站和应用程序的交互式内容。我们的许多应用程序都使用 Amazon DynamoDB 作为数据库来存储注册的用户信息，并在电视播放期间记录用户在投票直播活动中的投票活动历史记录。我们的应用程序经常用于每日早间节目和季节性流行音乐节目。在本博文中，我们介绍了如何利用 DynamoDB 的按需读/写容量模式来优化电视投票直播活动中使用的系统的成本和性能。

对于我们大多数的投票直播项目，我们只看到几个小时的用户访问，因为客户活动的时间仅限于电视节目的播放时间。在那几个小时内，访问请求突增仅持续几分钟。非高峰时间的工作负载与高峰时间相比几乎可忽略不计，其比例为 1:100 或 1:10000。

下面的图表显示了在一个吸引观众在网站上投票的电视节目播放期间，对我们的 Web 服务的访问请求记录。根据观众对投票活动的访问，在没有投票时，就没有任何请求。具体而言，在 19:30 到 20:15 之间没有请求，因为没有用户进行投票活动。然后在 20:15，由于观众开始投票了，我们看到有几分钟的工作负载突增，这时系统开始记录用户的数据。这种短暂的突增模式在投票期间反复出现，并发生不规律的蔓延，直到 22:30 节目结束。因为Amazon CloudWatch Logs是以分钟为单位进行记录收集，所以图中的数值是每分钟的平均值。实际上在一分钟内，也是存在高峰时间和非高峰时间的，高峰时间记录的实际数值也是会达到非高峰时间的两到三倍。

为什么选择 Amazon DynamoDB 按需模式？

在我们的案例中，我们发现 Amazon DynamoDB 按需模式最实用。我们原本可以使用 DynamoDB Auto Scaling，但是由于电视节目中发生计划外推广而导致请求突然或意外激增时，DynamoDB Auto Scaling 无法及时满足突增的流量需求。借助 DynamoDB 按需模式，我们可以节省资金并减少人工干预，而且不会出现任何延迟。

有些直播节目在节目进行期间并没有严格的事件时间表。因此，很难提前预测流量峰值出现的时间。如果我们预先预置 DynamoDB 容量来应对峰值流量，那么无论实际何时出现峰值流量，我们都必须为这些资源付费。在没有提供 DynamoDB 按需模式之前，我们在电视节目开始前一小时手动扩展容量以适应潜在的峰值，然后在电视节目结束后缩减容量。但这样为应对突增峰值流量做有备之需成本会很高。

使用 DynamoDB 按需模式之后，我们可以按请求付费。对于我们这种接收短时突发请求且两次突发请求之间长时间处于低流量状态的服务来说，DynamoDB 按需模式无疑是最佳之选。下图显示了我们其中一个电视节目的“请求计数”指标。我们收到少量请求，随后在 21:15-22:30 期间与电视节目内容相关的请求数达到了短时峰值。

投入使用

在 DynamoDB 按需模式于 re:Invent 2018 上发布后的第二天早上，我们就开始着手实施了。配置很简单，只需将 BillingMode 更新为 PayPerRequest。我们在下午 2:00 配置了 DynamoDB 按需模式，并于当天晚上 9:00 安排了节目播出。我们在当天下午 4:00 完成了负载测试，没有任何问题。

在我们转向使用 DynamoDB 按需模式之前，在每次节目结束后需要花一些时间来手动缩减诸多 DynamoDB 表。DynamoDB 按需模式正式发布后，我们立即开始将 300 个 DynamoDB 表的配置更新为 PayPerRequest。节目结束后，我们不再需要花时间进行手动缩减，开发人员现在可以专注于其他任务。在预置模式和按需模式之间切换需要在 AWS 管理控制台的 DynamoDB 表容量选项卡中进行简单的选择操作，如以下屏幕截图所示。

衡量成本节省

我们在多个服务中使用 DynamoDB，并将 95％ 的表设置为按需。此前将这些表配置为 预置模式。结果，我们在一个月内实现了成本节省，如下所示：

• 平台服务 – 这是所有其他服务的基础服务。每月成本由 1981 USD 降至 198 USD，节省了 90%。
• 网关服务器 – 该服务器与电视节目进行通信。每月成本由 2587 USD 降至 95 USD，节省了 95%。
• 观众请求 – 该服务接受观众对礼品图的请求。每月成本由 613 USD 降至 0.58 USD，节省了 99.9%。

目前面临的挑战

使用按需模式创建新的 DynamoDB 表时，默认情况下它们的初始最大容量为 4000 WCU 或 12000 RCU。按需表可立即容纳的流量峰值为此前最大容量的 200%，并且能实现每半小时翻倍。但是有时我们会需要多得多的容量，不希望等待表自然扩展。

在这种情况下，我们将“预热”具有足够的 WCU 和 RCU 的预置表以满足我们要求，然后将表切换为按需模式。这是因为 DynamoDB 的逻辑可以确定以前使用预置模式的按需表的容量；前一个峰值是为表预置的最大写入容量和读取容量的一半，或者是使用按需容量模式新创建的表的设置（以较高的值为准）。有关更多详细信息，请参阅《DynamoDB 开发人员指南》中的按需容量模式的最初吞吐量。

请注意，当您将配置更改为按需配置再更改回“已预置”时，则在 24 小时内无法再次更改为按需配置。在这 24 小时内，您必须调整预置的 WCU 和 RCU，来适应您的应用程序流量（或仅打开 Auto Scaling 功能）。

结论

如果您还将 DynamoDB 用于以下服务，也可以切换到按需模式获得相应的优势：接收多个高峰时刻请求并且遇到突然出现的工作负载激增的服务。但是，如果您的服务接收的流量稳定而且没有突然出现的激增，则最好使用具有 Auto Scaling 功能的 DynamoDB 预置模式。在开发和测试环境中，DynamoDB 按需模式也可以节省大量成本，因为此类环境通常只是偶尔接收到请求。当用例需要使用按需模式时，它将使YourCast Inc.节省资金并减少运营负荷。

本篇作者