亚马逊AWS官方博客

在电商推荐系统中利用 S3 Express One Zone 优化性能和降低成本

引言

随着电子商务的快速发展,个性化推荐系统已成为提升用户体验和销售转化的关键技术。然而,推荐系统的模型训练和在线推理对存储系统提出了很高的要求,既需要大容量存储海量的用户行为和商品数据,又要求低延迟高吞吐的读写性能。传统的文件存储系统如 EFS(Elastic File System)虽然易用性好,但在大规模应用场景下存在性能瓶颈和较高的成本。

本文将介绍如何在 HAQM EKS(Elastic Kubernetes Service)环境中,利用 S3 Express One Zone 作为推荐系统的存储后端,以优化性能并降低成本。我们将从技术可行性、性能优化和风险管理三个方面,深入探讨 S3 Express One Zone 在电商推荐场景下的应用。

电商推荐服务的特点

推荐系统在电商中至关重要,其推荐模型的质量和性能直接决定了用户的购物体验和平台成交量。随着电商公司加大在推荐系统中的投入的同时,运行推荐系统时面临着一些独特的挑战:

  • 电商推荐模型的训练频率通常很高。由于用户行为、商品信息和市场趋势的快速变化,推荐模型需要频繁更新以保持其准确性和相关性。
    • 日常更新:很多系统每天或每周进行增量更新。
    • 全量更新:每隔几周或几个月进行一次全量重训练。
    • 实时更新:有些系统采用在线学习,可以实时更新模型。
  • 推荐模型加载频繁
    • 电商业务访问的弹性,这导致推荐模型需要被频繁地加载到新的计算节点上;
    • 当模型更新时,也需要推荐系统及时加载最新的推荐模型;

模型的频繁更新和加载对模型存储的效率和性能提出了较高的要求,例如,当业务扩容或者模型更新时,每个批次有 100 个应用需要同时加载 30GB 的模式的时候,如果需要在 30 秒内加载完。这时候存储系统需要 100GB/s 的读带宽才能实现,这是 EFS 不能支撑的。 同时,如果每天需要更新一次模型,并且随着业务的弹性扩缩,如果每天有 6000 次应用加载模型,那么每天加载模型将产生 180TB 的流量。如果我们使用 EFS 弹性吞吐模式,按照当前 us-west-2 区域的官方列表价,每个月预计产生约 184000$ 的吞吐费用。

因此,使用传统的共享文件存储(EFS)在吞吐性能、流量成本上都面临巨大的挑战。

为什么选择 S3 Express One Zone

S3 Express One Zone 是亚马逊网络服务(AWS)在 2023 年推出的新型存储类别,它是 HAQM S3 存储服务的一个重要扩展。S3 Express One Zone 专为需要极低延迟和高吞吐量的工作负载而设计,特别适合于频繁访问的数据。

S3 Express One Zone 的主要特点包括:

  • 超低延迟:相比标准 S3,可提供高达 10 倍的性能提升,单位请求延迟最低可达毫秒级。
  • 高吞吐量:支持每秒数万次的读写操作,适合高并发场景。
  • 单可用区部署:数据仅存储在单个可用区内,降低了数据复制成本,但可用性略低于跨可用区的标准 S3。
  • 成本效益:虽然单位存储成本较高,但由于性能提升显著,在某些场景下可以降低总体运营成本。
  • 兼容性:与现有的 S3 API 完全兼容,便于集成和迁移。

开始在电商推荐系统中使用 S3 Express One Zone

性能和成本评估

成本分析

  • 存储费用:高性能存储,可存储您最常访问的数据。
  • 请求费用:S3 Express One Zone 对最大 512 KB 的请求按请求收取固定费用。对于请求中超过 512KB 的部分,按 GB 额外收取 PUT 和 GET 请求的费用。

性能分析

  • 性能:使用 S3 Express One Zone 可以实现数百 GB/秒的吞吐,目录桶将数据按层次结构组织到目录中,而不是通用桶的扁平存储结构。每个 S3 目录存储桶均可支持数十万个每秒事务数(TPS),与存储桶内的目录数量无关。
  • 可靠性:使用 S3 Express One Zone,您的数据将冗余地存储在单个可用区中的多个设备上。S3 Express One Zone 设计为在单个可用区内提供 99.95% 的可用性,并由 HAQM S3 服务等级协议提供支持。

性能优化

为了在容器中更好的提升访问性能,我们建议通过如下的方式优化性能:

  • maximum-throughput-gbps:设置最大吞吐量。Mountpoint 会调整并行请求的数量和速率,以达到目标最大网络吞吐量。 这个最大值由单个 Mountpoint 进程对所有文件和目录的访问共享。 默认情况下,当在 EC2 实例上运行时,Mountpoint 会将最大网络吞吐量设置为可用网络带宽,其他情况下则设置为 10 Gbps。
  • max-threads:控制并发线程数。默认情况下 Mountpoint 最多可并发 16 个文件或目录操作,并自动扩展到这一上限。 如果你的应用程序的并发读写(包括对相同或不同文件的读写)次数超过这个上限,你可以使用 —max-threads 命令行参数来提高性能。 此标志的数值越大,可能会导致 Mountpoint 占用更多实例资源。
  • part-size:优化大文件传输。在向 S3 读取或写入文件时,Mountpoint 会将文件分成若干部分,并使用并行请求来提高吞吐量。这些参数的默认值是 8 MiB(8,306,688 字节),在我们的测试中,这是实现最大吞吐量的最大值。 较大的值会减少 Mountpoint 发出的计费请求数量,但也会降低对象读取和写入 S3 的吞吐量。 Mountpoint 1.7.2 后,支持分别设置读写的分段传输(--read-part-size--write-part-size)。
  • metadata-ttl: 控制元数据缓存时间。用于控制 Mountpoint 在从 S3 重新抓取之前,认为文件系统元数据(文件存在性、大小、对象 etag 等)准确的时间长度。 如果单独配置或与本地缓存或共享缓存一起配置,Mountpoint 通常会减少对挂载的 S3 文件桶的请求,但不保证其报告的信息与挂载的 S3 文件桶内容一致。 当配置为本地缓存或共享缓存时,在元数据 TTL 过期之前,存储的数据被认为是准确的。 过期后,Mountpoint 会通过验证对象的 etag 是否发生变化,重新验证缓存数据是否仍然准确。
  • max-cache-size: 设置本地缓存大小。默认情况下,Mountpoint 会限制本地缓存的最大大小,使文件系统的可用空间不低于 5%,并在缓存新内容时自动从本地缓存中删除最近使用最少的内容。 你可以使用 —max-cache-size <MiB> 命令行参数手动配置本地缓存的最大大小。

注意:调整 metadata-ttl 可能会增加 ListObjectV2 API 调用,需要权衡性能和成本。

mountOptions:
  - uid=1000
  - gid=2000
  - allow-other
  - region us-west-2
  - allow-delete
  - maximum-throughput-gbps 100
  - max-threads 40
  - part-size 5242880
  - metadata-ttl 60
  - allow-overwrite
  - cache /tmp
  - max-cache-size 100000

风险管理

在应用程序中访问 S3 的方式有多种,包括 AWS CLI,AWS SDK,AWS API 以及,通常在容器中我们使用对业务无耦合的 CSI Driver 方式,可以无需业务代码变更即可无感的替换 EBS、EFS 等存储服务。虽然这些访问技术均由 AWS 实现并开源,但这里需要注意不同访问方式的技术差异和可能存在的潜在风险:

访问方式 技术特点 潜在稳定性风险 解决方案
AWS CLI – 命令行工具
– 适合脚本和自动化
– 易于使用
– 依赖网络连接
– 可能受到 AWS 凭证过期的影响
– 使用 IAM 角色而非长期凭证
– 实施重试机制
– 定期更新 AWS CLI
AWS SDK – 编程语言特定的库
– 深度集成到应用代码
– 提供丰富的 API
– 版本兼容性问题
– 可能引入应用程序依赖
– 定期更新 SDK
– 使用依赖管理工具
– 实施错误处理和重试逻辑
AWS API – RESTful HTTP 接口
– 语言无关
– 灵活性高
– 需要自行处理认证和签名
– 可能受网络延迟影响较大
– 使用适当的 HTTP 客户端库
– 实现请求重试和超时机制
– 缓存常用数据
mountpoint-s3-csi-driver – 将 S3 挂载为文件系统
– 对应用透明
– 易于与现有应用集成
– 性能可能不如直接 API 访问
– 可能存在文件系统操作的兼容性问题
– 优化缓存策略
– 仔细测试文件系统操作
– 监控挂载点的健康状态

Mountpoint for HAQM S3 使用了 FUSE 技术。FUSE 允许非特权用户创建自己的文件系统,而无需修改内核代码。Mountpoint for HAQM S3 CSI 驱动程序存在着进程崩溃可能导致文件系统不可用的极端场景的风险。通常为了解决此类问题,我们有多种办法保障可靠性:

  1. 针对 Mount Point S3 CSI Driver 实施监控和自动重启机制;
  2. 在应用服务侧实现针对 S3 CSI Driver 不可用时实现备用存储方案,将 EFS 作为备用读取模型的存储。

从 EFS 迁移至 S3 Express One Zone

从 EFS 迁移到 S3 Express One Zone 可能面临一些风险:

  • 数据一致性:确保迁移过程中数据不丢失、不损坏。
  • 服务中断:最小化迁移对业务的影响。
  • 回滚机制:制定详细的回滚计划,以应对迁移失败的情况。

迁移策略:

  • 分阶段迁移: 先迁移非关键业务,逐步扩大范围。
  • 双写机制: 在迁移期间同时写入 EFS 和 S3,确保数据安全。
  • 灰度发布: 使用流量控制,逐步将请求切换到新系统。

从 EFS 存储切换到使用 Mountpoint for HAQM S3 CSI 驱动程序的 S3 存储在 EKS 集群中并不是特别复杂,但需要一些步骤和注意事项。以下是切换过程的概述:

  1. 创建一个 S3 存储桶用于存储数据;
  2. 安装 Mountpoint for HAQM S3 CSI 驱动程序:
  3. 定义一个使用 Mountpoint for HAQM S3 CSI 驱动程序的新 StorageClass;
  4. 创建新的 PVC,使用新的 StorageClass 指向 S3 存储;
  5. 修改 Deployment、StatefulSet 等,使用新的 PVC
  6. 数据迁移:将最新的模型数据存储至 S3 Express 存储桶中;
  7. 测试和验证:在生产环境应用更改之前,在测试环境中验证新的存储配置。

结果

应用了 S3 Express One Zone 后,推荐服务的并行加载能力得到了显著提升的同时存储和访问成本得到了大幅下降:

  1. 得益于 S3 的吞吐带宽的优势,当 200-500 个应用同时加载模型是,S3 总吞吐达到 200GB 以上,相比 EFS 的最大吞吐量提升 3-5 倍:
  2. 因为没有流量费用,整体成本降低 90%;
  3. 得益于 S3 的低延迟,单个 10GB 级别的模型加载速度相比和 EFS 提升 38%,相比 S3 标准存储提升 14%。

总结

在电商推荐场景下,利用 S3 Express One Zone 作为 EKS 的存储后端,可以在保证性能的同时显著降低成本。通过合理的配置和优化,S3 Express One Zone 能够满足推荐系统对存储的高性能需求。随着 AWS 不断完善 S3 Express One Zone 的功能和工具支持,相信这种存储方案在未来会有更广泛的应用,为更多高性能、大规模的云原生应用提供强有力的支持。

本篇作者

张凯

亚马逊云科技解决方案架构师,主要负责基于亚马逊云科技的解决方案架构设计和的方案咨询;具有多年的架构设计、项目管理经验。

戴逸洋

亚马逊云科技数据存储资深架构师,致力于推广存储技术在云上的各种最佳实践。