最佳实践｜Amazon DynamoDB 在 ZOZOTOWN 购物车的应用实践

在这篇文章中，我们将向您展示一个电子商务网站的案例研究，该网站存在关系数据库管理系统 (RDBMS) 性能问题，以及Amazon DynamoDB如何为其解决方案做出贡献。ZOZO 有大型销售活动，需要工程师实时监控和响应，以确保服务正常运行。DynamoDB 帮助 ZOZO 减少了 85.8% 的工程开销。我们还分享了一些 DynamoDB 最佳实践。

这篇文章重点介绍 ZOZOTOWN（日本领先的电子商务网站之一）对 DynamoDB 的体验。Shiori Hanzawa 是负责开发和运营 ZOZOTOWN 电子商务门户的工程师之一。在这篇文章中，她和我解释了 ZOZOTOWN 决定迁移到 DynamoDB 的原因。

ZOZOTOWN概述

ZOZOTOWN 是日本最大的时尚购物网站之一，拥有 1,500 多家商店和 8,400 个品牌。它列出了超过 830,000 件商品，平均每天有 2,900 件或更多新到货（截至 2021 年 12 月底）。ZOZO, Inc. 开发了各种 ZOZOTOWN 服务，包括专业商城 ZOZOCOSME 和 ZOZOSHOES，经营品牌二手服装的 ZOZOUSED，经营奢侈品和设计师品牌的 ZOZOVILLA，以及时尚协调应用程序 WEAR。此外，ZOZOTOWN 还开发并使用了 ZOZOSUIT 2、ZOZOMAT 和 ZOZOGLASS 等测量技术。

为什么 ZOZOTOWN 采用 DynamoDB

ZOZOTOWN 采用微服务架构来简化随着业务增长的扩展，包括他们的购物车提交功能。该函数的主要过程是拉取产品库存并将其注册到购物车商品数据库的表中。某些事件（例如热门产品发布）会导致请求数量激增，并且对特定库存数据的访问也会增加。结果，原来的数据库设计变得超载，导致错误频发。与此问题相关的运营成本非常高，并且现场工程师因排除这些事件而筋疲力尽。

为了解决他们的数据库吞吐量挑战，ZOZO 用 DynamoDB 替换了他们现有的数据库，DynamoDB 可以在任何规模上提供一致的性能，并且不会因维护窗口或版本更新而导致计划停机。

ZOZO 首先将使用 MS SQL Server 在本地运行的库存和购物车表替换为 DynamoDB。下面的图 1 说明了更新后的架构，将在后续段落中进行描述。

图 1：更新的 ZOZOTOWN 数据库架构

我们计划分几个阶段实施更换。作为第一步，我们决定在购物车提交过程中添加一个队列，并更改为容量可控的配置，以减少本地数据库的负载。在替换之前，Web 服务器调用本地数据库中的存储过程，该存储过程处理库存分配和购物车注册。在调用存储过程之前，替代品通过购物车的微服务使用Amazon Kinesis Data Streams。它还使用 DynamoDB 来确定热门产品并管理请求的排队状态。

工艺流程为：

1. 用户从 Web 服务器调用微服务的请求注册 API 进行购物车提交功能。
2. 请求注册API：
   1. 查询 DynamoDB 热门产品表。
   2. 将初始状态注册到 DynamoDB 状态管理表。
   3. 将状态管理表分区键和请求信息发送到 Kinesis Data Streams。因为流在流行产品和标准产品之间是分开的，所以流行产品被发送到它们各自的流。
   4. 返回状态管理表的分区键。
3. 工人：
   1. 从 Kinesis Data Streams 检索包含请求信息的记录。
   2. 将状态管理表中项目的状态更改为已请求。
   3. 调用后端存储过程执行 API。
4. 存储过程执行 API 执行库存储备和注册到购物车并返回结果。
5. 工作人员将这些结果存储在 DynamoDB 状态管理表中。
6. Web服务器调用状态获取API，将请求结果返回给用户。

DynamoDB 最佳实践

我们早期做出的一个决定是如何在 DynamoDB按需容量和预置容量之间进行选择，这控制了 DynamoDB 读/写吞吐量的收费方式和容量的管理方式。

按需模式是一种灵活的计费选项，无需容量规划即可扩展到几乎无限的吞吐量。DynamoDB 按需为读取和写入请求提供按请求付费的定价，因此您只需为使用的内容付费。

预置容量允许您指定应用程序所需的读取和写入吞吐量。您还可以将 Auto Scaling 与预置容量结合使用，以根据流量变化自动调整表的吞吐容量。这有助于您控制您的 DynamoDB 使用以保持在或低于定义的请求率，以获得成本可预测性。

我们发现，如果满足以下任一条件，按需是一个不错的选择：

• 您创建具有未知工作负载的新表。
• 您有不可预测的应用程序流量。
• 你更喜欢只为你使用的东西付费。

如果满足以下任一条件，预置容量是一个不错的选择：

• 您拥有可预测的应用程序流量。
• 您运行的应用程序的流量是一致的或逐渐增加。
• 您可以预测产能需求以控制成本。

我们发现在一段时间内从按需容量开始，然后在同一时间段内尝试预置容量以确定哪个选项最适合您的工作负载是一种很好的做法。

由于购物车请求的速度根据一天中的事件和时间而有很大差异，因此我们很难预测容量。因此，我们为购物车提交功能选择了按需容量。按需容量的灵活计费和易于扩展使我们无需为容量进行规划。迁移到 DynamoDB 后，几款热门产品开始销售。借助按需容量，我们能够支持这些高负载事件，而无需任何工程开销。

我们还受益于使用缓存来减少热门项目的读取负载，从而节省成本并提高性能。Amazon DynamoDB 加速器 (DAX)是适用于 Amazon DynamoDB 的完全托管、高度可用的内存缓存。我们为读取密集型工作负载实施了 DAX，尤其是那些对特定项目具有高请求率的工作负载。当我们的应用程序从 DAX 检索这些项目时，我们减少了读取容量单元 (RCU) 的消耗，从而降低了我们的成本结构。DAX 使用生存时间 (TTL) 驱逐策略，因此当规定的 TTL 到期时，数据会自动从缓存中清除。由于 DAX 是直写式缓存，因此我们的客户端在一次操作中更新我们的 DynamoDB 表和缓存。DAX 客户端支持与 DynamoDB 相同的操作，并且可以通过交换 DynamoDB 客户端终端节点来使用。这消除了对复杂缓存管理的需要。

在 ZOZOTOWN’s cart replacement 使用的技术

在本节中，我们分享一些 ZOZOTOWN 现在正在使用的功能。

使用条件写入控制队列

工作人员可能会多次从 Kinesis Data Streams 获得相同的记录。因此，如果您不控制任何东西，您可能会多次运行一个请求并将比用户请求的商品更多的商品添加到购物车中，如下面的图 2 所示。

图 2：发送到购物车表的重复请求

为了解决这个问题，我们使用了条件写入功能。工艺流程为：

1. 检查状态管理表中的项目。
2. 根据状态分支到以下进程：
   1. 如果状态为is_queuing（排队状态），则进行下一步。
   2. 如果状态为is_requested（已请求），则跳过下一步。
3. 有条件地将状态管理表的状态更新为is_requested。
4. 请求存储过程执行 API。

下面的图 3 是工作人员检索已处理的名为 a1 的请求以及 a2 和 a3 的新请求时的示例。

图 3：请求流程

确保请求与用户操作匹配的处理流程是：

1. a1 记录被处理。GetItemworker使用 a1 记录作为分区键发出 a ，返回 status is_requested。然后工人跳过后续处理。
2. 该过程移至a2。因为GetItemis not的结果，所以执行is_requested了后续UpdateItem操作。满足条件则更新成功，否则出错。
3. 请注意，为购物车提交请求设置了总体超时值。如果由于某种原因发生超时，则会将一个timed_out_at值添加到状态管理表中，并向用户返回一个错误。因为无法继续处理因错误而停止的请求，所以我们使用该操作并在不能存在UpdateItem的地方包含条件表达式。timed_out_at
4. is_queuing由于 Kinesis 客户端库的规范，我们还添加了状态是因为多个工作人员可能在同一个分片中处理记录的条件。
5. a2 无法更新，因为timed_out_at在UpdateItem. 因此，不进行后续处理，转移到a3处理。
6. a3 执行条件UpdateItem，就像 a2 一样。结果，更新成功，因为没有timed_out_at. 只有在这种情况下才允许处理后续请求。

检测热键和机器人访问

当 DynamoDB 中的数据访问不平衡时，可能会导致热分区接收到比其他分区更高的读写流量。在极端情况下，可能会发生限制。ZOZO 构建了增强的监控功能，支持由 CloudWatch 贡献者洞察力支持的热键检测。额外收费，以下信息以图表形式提供，显示 DynamoDB 表或全局二级索引 (GSI) 中访问次数最多或受限制的项目。在负载测试期间，我们专注于访问最多的项目的流量，这有助于我们验证我们的表设计是否有效地分配了负载。我们使用访问源作为分区键构建了一个 GSI，以帮助我们识别请求是来自普通用户还是机器人。下面的图 4 显示了每分钟访问次数最多的分区键。

图 4：每分钟的分区密钥访问

图 4 中图表底部的用户点表示一分钟内有几件商品被添加到购物车中，这是正常行为。但是，每分钟数百个连续请求（在图中标记为 Bot）可能来自一个或多个机器人。ZOZO 可以使用这些信息来识别机器人并做出适当的响应。

结论

用于购物车提交的高负载功能的 DynamoDB 替换项目取得了巨大的成功。减少了频繁事件时的错误和访问集中时的延迟，从而提高了性能。

原文标题：How Amazon DynamoDB supported ZOZOTOWN’s shopping cart migration project

原文作者：Shiori Hanzawa 和 Takashi Narita

原文链接：https://aws.amazon.com/cn/blogs/database/how-amazon-dynamodb-supported-zozotowns-shopping-cart-migration-project/