Acoustic 在 亚马逊云科技 上对发送引擎进行现代化改造的吞吐率提高了 10

营销技术活动平台必须从客户的数据集中发送动态来源的丰富内容，从而向客户发送高度个性化和相关的信息。在一年中的多个关键时刻无缝扩展以实时满足大量客户数据需求的能力可能对资源构成挑战。Acoustic 的现代化发送引擎实现了这一目标，吞吐率无可否认地提高。

关于声学

Acoustic是一家全球营销和客户互动技术公司，致力于将从活动到转化的各个环节联系起来。Acoustic 利用深入的行为洞察来揭示整个客户旅程中的每一次互动，从而实现超个性化的数字体验。2022 年，他们在短短10个月内将6,300台服务器和8个全栈（服务即软件）SaaS应用程序 迁移到亚马逊云科技，从而完成了通往亚马逊网络服务 (亚马逊云科技) 云的旅程。 采用 亚马逊云科技 云使得 Acoustic 能够利用本地数据中心所没有的新技术和扩展能力。

在这篇博客文章中，我们将回顾Acoustic如何利用亚马逊云科技云原生服务对其战略性Send Engine应用程序进行现代化改造，并构建可扩展、具有成本效益和弹性的解决方案。发送引擎是Acoustic的全渠道应用程序，用于对Acoustic客户的客户进行个性化设置、发送和跟踪电子邮件、短信、移动推送和WhatsApp消息。通过现代化，Acoustic不仅可以根据客户需求进行扩展，还可以与Acoustic客户希望吸引受众的未来渠道快速整合。

发送引擎：以前的架构

Acoustic 之前的 Send Engine 技术很好地达到了其目的，但是随着数据量的增长，对超个性化消息的需求和渠道整合的灵活性不断演变，需要新的架构。该应用程序是围绕访问传统关系 SQL 数据存储库的 Java 代码库创建的。由于所有活动功能（包括细分、受众管理和营销自动化）都使用同一个数据存储，因此可以访问数据库的连接和代码实例数量有限制。这为发送执行创建了基本约束。根据数据存储的负载，观察到的最大吞吐量为每小时约500万至2000万笔交易，这无法满足不断增长的业务需求。

图 1：发送引擎先验架构

实现发送引擎现代化的关键驱动因素

2021/2022 年，Acoustic 对其 Send Engine 应用程序进行了技术改造，通过优化运营来支持针对不稳定的客户负载模式进行扩展。Acoustic 的 Send Engine 应用程序更新在技术上并不可行，从管理不可扩展的基础设施容量资源的角度来看，这样做的成本会高得令人望而却步。Acoustic 需要利用易于扩展的服务，在这些服务中，他们可以根据工作负载控制成本性能概况。这需要重新构想他们的 Send Engine 应用程序，以利用可用的 亚马逊云科技 云原生解决方案和服务。

发送引擎：新架构

为了解决先前架构的限制，Acoustic 迁移到云原生、基于事件的架构，以灵活地扩展实时事件。Acoustic 利用了 Aws 服务，包括 亚马逊弹性 Kubernetes 服务（亚马逊 EKS）、适用于 Redis 的亚马逊 ElastiCache、A mazon Kinesis、Amazon Lambda 、A ma zon S imple Storage Servic e（亚马逊 S3），以及用于基于事件的 Kubernetes pod 扩展的 Kubernetes pod。

Acoustic 实现了基于 Kinesis 流的自动缩放器（图 1）。系统会计算出来自 Amazon S3 的待处理记录数量以及向 ElastiCache 输入的数量。然后，Lambda 每分钟检查一次计算出的计数（利用 亚马逊 Cloud Wat ch）。根据当前的缩放次数、预期的负载和任何冷却时间，它要么什么都不做，要么根据需要向上或向下扩展所有直播。Lambda 逻辑还可在 24 小时的时间窗口内有限次数地扩展 Kinesis 流。

图 2：发送引擎自动扩展架构

图 3：瞬态缩放

实施

图 3 说明了分片随时间推移的临时状态自动扩展。直播以最小缩小比例设置为五个分片开始。当评估一条 34M 的发送消息时，自动缩放器会再扩展两个分片来处理需求。为了连续地在新的间隔内继续处理现有的 34M 和另外 15M 条发送消息，自动缩放器会再扩展四个分片。在时间段结束时，当合并的消息数量减少到2,600万条消息时，流将缩小到三个分片。

现在 Kinesis 直播可以向上和向下扩展，Acoustic 需要根据分片数量调整亚马逊 EKS 吊舱。为了使用当前的分片数量快速扩展 Amazon EKS 容器，引入了一款基于事件的 KEDA 容器缩放器，它使用 Kinesis 分片数作为衡量标准。

为了在亚马逊 EKS 方面实现真正的节省，还需要向上或向下扩展 亚马逊弹性计算云（Amazon EC2） 实例。由于就亚马逊EC2扩展而言，需要在不到一分钟的时间内扩展新的亚马逊EC2节点，而默认的Amazon EKS水平自动扩缩器太慢了，因此利用了Karpenter。这使得 Acoustic 能够将特定的节点组分配给 Send Engine，并仅针对此应用程序定制节点类型和缩放。Diagram-4 中给出了更新后的发送引擎的参考架构。

图 4：现代化发送引擎参考架构

采用新模式后，最大吞吐量增加了 10 倍，达到每小时超过 1 亿笔交易。在实施的新数据访问模式中，Acoustic 利用亚马逊 S3 和 亚马逊 DynamoDB 来克服单一关系数据库的扩展限制。

结论

在这篇博客文章中，我们概述了Acoustic的现代化之路如何利用亚马逊云科技云原生服务和开发模式来构建可扩展且具有弹性的Send Engine解决方案，以应对业务波动和增长。采用新模式并整合可在产品线中轻松利用的平台技术，借助云加速了 Acoustic 的业务优先事项和敏捷性。

如果您想开始应用程序现代化，请参阅 迁移和现代化 解决方案页面 ，在那里您可以找到各种各样的示例来帮助您，或者 随时 联系 亚马逊云科技 代表 。

进一步阅读

• 使用亚马逊 CloudWatch 和 亚马逊云科技 Lambda 自动扩展亚马逊 Kinesis Data Streams
• 介绍 Karpenter — 一款开源的高性能 Kubernetes 集群自动扩缩器