船舶越快,风险越来越少。获得优化的推出,为开发人员提供免费功能标志。 建立免费账户



国家零售联合会 报告了超过18960万美国人从2019年通过网络购物了感恩节。 调查发现,12400万人在商店购买,而在线购物14220万;展示今天的无缝购物世界,7570万参加了两者。鉴于优化与零售在线企业的合作,感恩节假期是今年最重要的时期之一。我们的内部系统和基础设施可能会处理高流量体积而无需停机或性能下降至关重要。确保客户可以可靠地运行实验,受众瞄准和功能卷展览,并使用我们的实验,目标​​和功能管理平台来衡量对它们的指标来衡量重要的指标。 

在正常的一天, 在世界各地的客户体验中,优化收集和处理数十亿的信号(称为事件)。在感恩节假期期间的高峰时期,平台流程超过10亿次活动,提供33亿种独特的体验(印象)以超过6.93亿游客。

在本博客文章中,我们展示了优化的数据平台和详细信息,详细介绍了我们的数据平台的摄取和流媒体组成的详细信息,以满足黑色星期五和网络星期一交通的高要求,而不会影响稳定性或可用性。

数据平台

数据平台在优化的是负责收集,处理,存储和查询客户实验数据的系统和API。此外,它还支持产品UI中呈现的产品特征和用户体验。数据平台在优化可以分为两个主要区域:

  • 数据处理: 收集,流程和存储数据的基础架构
  • 数据分析: 实现实验分析的基础设施

 

优化’s Data Platform

 

准备 

黑色星期五和网络周一的准备和规划在购物季节前几周开始。这是一种跨学科的努力,涉及分布式系统工程师,站点可靠性工程师,技术支持工程师和客户成功管理人员。

我们的目标是按照交通规模平台需要维护我们的内部服务级别目标(SLO),同时平衡增加托管费用。为此,我们需要从客户和内部系统中收集几个不同的指标。 来自零售客户的事件数据占典型事件量的近一半,每天为8-10亿场。大多数零售客户希望看到与黑色星期五/网络星期一销售相关的零售网站上的访客互动。我们的客户成功管理人员与我们的零售客户合作,收集了预期的活动统计数据。基于此,我们确定了处理以下内容所需的基础架构:

  • 2 –3x增加日常事件量
  • 峰值事件吞吐量的2x增加
  • 1.5倍增加独特的每日游客
  • 每日瞄准要求的2倍增加为提供个性化体验

缩放

摄取管道

第一行的数据摄取发生在我们的事件记录端点处发生,其中事件被缓冲到嵌入式水槽(内存通道)中。这 水槽代理商 与事件记录层共处,它们从E-Flume中消耗事件,过滤事件并将其写入各自的Kafka主题和S3。该组件称为 Logtier. (事件-API + Flume)。我们用 Apache Kafka. 广泛作为消息总线以传输数据和电源实时流服务,例如分区,丰富,聚合和归因,最终使企业能够在网站,移动应用和连接设备上提供连续的实验和个性化。

作为Logtier和Kafka是我们基础设施的骨干,我们需要确保摄取管道可以处理2–3倍的当前体积。我们的Logtier拥有维护的服务级别目标(SLO) 99.98% 可用性. 为识别我们的扩展需求,我们考虑了以下几个月的Logtier和Kafka的以下关键指标: 

关键指标

Logtier.

  • ELB请求计数:通过elb的请求数量
  • E-Flume通道尺寸:三个内存通道的大小,用于共同定位的水槽代理的缓冲事件消耗
  • Flume Agent通道尺寸:在最终生产到Kafka和S3之前,将事件缓冲到磁盘的文件通道的大小
  • Kafka.产生时间: Kafka产生定时必须很小,以便保持事件记录端点的低延迟
  • 磁盘使用/ IOPS:磁盘使用情况必须保持在配置的EBS卷以下,因为事件存储在Sidecar Flume代理的文件通道中以进行耐用性

Kafka.

  • 收到的消息:每个经纪人收到的消息数量
  • 消息产生请求率:想要将消息写入Kafka主题的客户端发送给代理的生成请求数量 
  • 磁盘利用率: 当前正在使用的磁盘存储的部分或百分比
  • CPU利用率: CP处理的工作量
  • 使用堆:此过程使用的堆的大小
  • 请求产生时间(在MS中): 用生产者将消息写入Kafka所花费的时间。
  • 复制滞后: Kafka.分区追随者与分区的领导者同步所需的时间。

在调查这些指标的历史数据并预测预期增加后,我们将Logtier集群扩展为大约30%到250 M5.xlarge实例。同样,我们通过几乎将经纪人的数量加倍来扩展我们的一个Kafka集群,以应对增加的CPU和磁盘需求。我们的主要Kafka集群已经装备以处理更高的事件卷。我们有仪表板突出显示所有关键指标以及在我们的活动摄取管道中堵塞的情况下快速做出反应和响应的Playbook。以下是黑色星期五的Logtier可用性指标仪表板&网络星期一假期,可用性为99.98%。

在黑色星期五期间的Logtier度量仪表板&网络星期一假期,可用性为99.98%。

Kafka.仪表板在峰值交通周期间突出显示关键指标。

流媒体管道

Apache Samza. 一直是我们的活动摄取和流媒体管道的伟大资产。它使我们能够执行大规模的实时流计算,例如每天的数据丰富和会话聚合。更多关于我们如何利用Samza的信息可以在以下博客中找到: 从批处理到换流– part 1从批处理到换流– part 2.

我们确定了估计我们的缩放需求的关键指标。关键指标对每个功能的不同流处理作业有所不同,但常见的是如下:

关键指标

  • 处理率:每秒处理的消息数
  • Kafka.消费者滞后:消费者偏移与Kafka主题的最新偏移之间的三角洲
  • RocksdB. gets vs puts: 这被用作Samza的国家管理的键值商店。我们的会话和归属任务利用RockSDB执行有状态流处理功能。

我们的Samza部署依赖于 (又一资源谈判者)来管理资源和容器,每个都运行应用程序进程。容器计划在节点管理器(Workers)上运行,该管理员是我们设置中的M5.xlarge实例。我们通过停止所有流消耗来估计峰值处理速率。这导致滞后在我们的Kafka消费者中积累。经过一段时间,我们再次开始注明我们可以赶回到实时速度的速度。 

通过历史数据集,我们的预处理和会话化作业有足够的余量来处理4倍的流量。我们的有状态流媒体作业,归因,通过从属于归属数据库获取信息来丰富层状态(事件归因于事件的实验/变型)的每个事件 HBase.。我们想准备以下方案:1)如果容器丢失,则任务应快速从外部商店启动本地状态。 2)如果容器不会丢失,则处理率应保持活动摄取率..以防止容器被杀死,我们将容器内存从2GiB增加到4GiB;为了使Kafka消费者滞后尽可能接近零,我们将集装箱数量加倍。我们的流媒体管道在没有任何打嗝的情况下处理事件量,结果不受影响。

监控和警报

我们的大多数应用程序和系统指标都通过 Tcollector. 或者 DATADOG.-Agent. 并被推动到 OpentsDB. 或者 DATADOG. 分别。我们已定义监视器和仪表板以跟踪应用程序和系统级度量。我们确保有数据平台的每个组件都有剧本,以便我们的随叫随到的工程师知道如何在适当和解决事件而不影响可用性的情况下进行反应。

黑色星期五和网络星期一的199年星期一是巨大的成功,因为平台优雅地处理了2-3倍的正常峰值流量。在下一个博客文章中,我们将详细介绍我们的存储和报告基础架构的缩放故事。由于每个人的辛勤工作和准备在整个旅程中,有助于缩放平台以满足黑色星期五和网络的规模。 

如果您有兴趣入门逐步交付,则可以免费注册 优化 Rollouts account.

优化 X