降低高负载系统基础设施成本的五种方法：AdTech 案例研究

随着云炒作浪潮的尘埃落定，越来越多的技术团队发现了云基础设施的副作用，而这些副作用通常被忽视。

尽管按需可扩展性、管理本地服务的时间更少以及其他听起来很有前途，但它们往往被一个重大缺点所抵消——高负载系统中基础设施成本的飙升。

在讨论基础设施成本时，对高负载系统的关注非常重要：对于小型公司来说，几乎没有比云更灵活、更便宜的替代方案了。

然而，随着 QPS 达到数十万，看似很小的供应商费用已不再可持续。

作为一家专门为 AdTech 构建和优化高负载系统的软件开发公司，我们探索了团队用来防止基础设施成本飙升的多种实践。 Xenoss 拥有超过 15 年的经验，帮助支持 Activision Blizzard、Verve Group、Smartly、Voodoo、Inmar Intelligence 等项目，构建强大而灵活的基础设施。

在这篇文章中，我们希望分享我们在与高负载平台相关的基础设施挑战方面的经验和专业知识，并探索简化成本的方法。为了说明帖子中展示的策略，我们将使用一个速度和规模都不容妥协的行业：广告技术。

我们还有一篇博客文章，更详细地介绍了基础设施成本优化，其中包括我们软件架构师的专家提示和评论，以及基础设施成本降低二十倍的案例研究。

AdTech 平台——高负载系统的海报案例

高负载平台支持银行、医疗保健等多个行业。程序化广告虽然通常不被视为开发的技术壮举，但可以与其他复杂的系统相媲美，因为其操作要求往往突破基础设施设计的界限。

让我们快速回顾一下为什么 AdTech 平台（SSP、DSP 等）是探索基础设施成本优化的绝佳镜头。

高容量和低延迟的压力

AdTech 平台陷入了高流量和低延迟需求之间持续的拉锯战。

一方面，他们需要处理在线广告产生的大量流量（ 根据 TPA Digital 首席执行官 Wayne Bloodwell的说法，每天的展示次数达到 9500 亿次）。

除了负载之外，生态系统的实时性还增加了新的复杂性。

AdTech 平台中的高延迟（即出价请求和响应之间的延迟）会导致广告商错过高质量的广告资源，因为他们的出价没有得到及时处理。

高延迟会导致发布商难以填补广告位，从长远来看会导致收入下降。

投标处理的标准时间范围徘徊在 80-120 毫秒左右，这是行业运行的平均时间范围。

实时决策

由于以下挑战，实时数据处理是 AdTech 项目经常遇到的另一个挑战：

需要快速检索数据（低于 100 毫秒）以做出实时决策，例如投标价格建模。

从多个来源收集受众数据会增加管道的复杂性，并扩展处理各种数据类型所需的工具集。

数据质量问题：错误的数据可能会导致广告商做出糟糕的出价决策。每个管道阶段（摄取、处理、消耗）的数据质量检查至关重要。

下面的剪辑说明了实时数据分析的复杂性和关键操作

https://www.youtube.com/watch?v=uaRzovqK3t0

可扩展性需求

广告科技行业具有周期性，经济起起落落会导致广告服务需求的波动。市场上涨迫使 AdTech 平台实施动态可扩展性功能。

再加上 SPO 的增长，AdTech 供应商感受到了根据需求变化可靠地上下调整容量的压力。因此，他们需要有能力和资源来处理峰值流量而不牺牲性能或可靠性（并缩小流量以适应市场波动）。

收集原始数据和汇总数据

使用原始数据对于 AdTech 平台的成功至关重要。这些系统收集大量聚合数据——人口统计信息、浏览历史记录、用户行为等。这些见解是从各种来源集成的，有助于促进定位和个性化。

原始数据在可供使用之前，需要经过 ETL 步骤：提取、转换和加载。然而，随着系统规模和数据量呈指数级增长，维护多个管道成为一项工程挑战。

Xenoss 用于优化高负载系统中基础设施成本的最佳实践

除非技术团队密切关注基础设施成本，否则他们很快就会失控。低效的数据建模和存储、缺乏依赖服务的选择性以及未能提前规划和应对威胁，使得基础设施变得不可预测、缓慢、昂贵且难以维护。

削减基础设施成本并非一日之功，但凭借对生态系统和平台的了解，您可以通过一些调整来显着降低成本。

以下是 Xenoss 技术团队用来帮助我们的客户实现更精简的基础设施的几种基础设施减少实践的列表。

探索混合云基础设施的优势

在早期项目中，没有太多考虑设计最佳的云基础设施。技术团队通常选择以下两种方式之一：

• 公共云服务提供商，例如 AWS、Google Cloud 或 Microsoft Azure。虽然在开发过程的早期依赖云供应商是可以理解的，但我们想提醒技术领导者，如果不是严格需要的话，不要使用托管服务。随着时间的推移，这些工具会显着增加项目的基础设施费用 - 当基础设施费用达到 250 万美元时，我们的一位客户向我们伸出了援手。
• 由内部团队维护的本地基础设施。如今，由于需要前期投资和人力，维护本地数据中心对于早期项目来说并不常见。值得注意的是，本地基础设施有其优点，例如更多的控制和更严格的安全性。

在广告技术中，灵活性和动态扩展的能力至关重要。对基础设施成本的完全控制和加强安全性的能力同样重要。前者通常与云相关，而后者通常被认为是本地部署的好处。

在 Xenoss，我们认识到这两种基础设施的优势，这就是我们在客户项目中使用这两种基础设施的原因。云和本地的组合通常被称为“混合云”，尽管有更多的组合适合这个术语。结合公共云和私有云或两个公共云（也称为多云）也符合这个概念。

根据 DZone 发布的 Data Pipelines 报告，33% 的受访组织结合使用云和本地基础设施。如果仅考虑企业组织（员工超过 1000 人），这一数字高达 42%。

混合模型为 AdTech 团队提供了更高的财务灵活性，使 AdTech 平台能够将对本地设置的控制与云平台的动态可扩展性相结合。

安全性是另一个显着优势；项目可以通过将敏感数据保留在本地并使用云来执行不太重要的任务来维持严格的数据保护标准。

我们更喜欢并提倡混合方法的另一个原因是它能够防止供应商锁定。将关键基础设施保留在本地，为企业提供了实现技术堆栈多样化的余地，而无需依赖单一云提供商。

此外，混合方法使产品团队能够更加有意识地构建特定于工作负载的基础架构。

AdTech 中的一些任务，例如实时广告竞价或受严格区域合规性约束的数据操作，更适合本地执行。

同时，其他工作流程（营销活动分析、分布式广告内容托管或协作广告设计）可以无缝迁移到云端。

优化数据存储

根据我们的经验，仅优化存储就可以显着降低基础设施成本。在 AdTech 中，SQL 和 NoSQL 数据库都用于管理结构化和非结构化数据。让我们回顾一下这两种类型的数据库之间的主要区别，以及它们在 AdTech 中的用例。

为了给讨论添加更多背景，让我们回顾一下两者之间的差异。

现在，让我们看看顶级 AdTech 平台选择的数据库及其数据存储方法。

AdTech 供应商如何使用 SQL 数据库来操作大量数据

公共的

Pubmatic SSP 通过独特的需求合作伙伴关系、高级分析和创意优化工具帮助发布商吸引广泛的受众并最大限度地提高广告收入。

挑战：该公司需要一个强大的数据库来处理大型数据集并解决复杂的问题。该公司想要一种经过实战考验的工具，最重要的是，它可靠且有效。

解决方案： MySQL

影响： PubMatic 的广告质量团队使用 MySQL 作为其主要数据源。该平台的数据库存储多达一亿条记录。 MySQL 以可靠性和稳健性而闻名，它允许 PubMatic 每天处理数百万个创意并维持 2 至 10 倍的数据负载。

广告问候语

AdGreetz 是一个个性化平台，可跨多个渠道分发定制的广告创意：社交媒体、CTV/OTT、应用内等。

挑战：该组织的工作流程是数据密集型的，需要支持数百万条用户记录的数据库管理解决方案。

选择的数据库： ClickHouse

影响：对于 AdGreetz 的工程团队来说，Clickhouse 被证明是一种经济高效且高性能的解决方案。该公司能够在小型计算中将查询时间从几秒缩短到亚秒级。

AdTech 项目如何使用 NoSQL 数据库

蜂蜡

Beeswax 是一个托管 RTB 平台，允许广告商简化程序化操作。该公司提供出价者即服务解决方案，每秒处理数百万次查询，每分钟消耗 125 GB 的数据。

挑战：快速扩展以确保高效的广告投放，需要在组织的机器上均匀分配负载。

选择的 NoSQL 数据库：在 Amazon EC2 上运行的 Aerospike。

影响： Beeswax 每秒可以处理数百万次查询，尾部读取延迟为 2 毫秒。

口香糖

GumGum 提供了一个由专有机器学习平台 Verity 支持的上下文定位平台。

挑战：该公司希望以最小的延迟处理大量的广告相关数据（展示次数、浏览次数、点击次数、转化次数）——尽管数据不是实时处理的，但目标是将差距保持在最低限度。

选择NoSQL数据库： ScyllaDB

影响：

• 减少工程资源的压力
• 体积增加 75%
• 通过按需资源配置促进可扩展性。

莫洛科

Moloco 是一个移动受众平台，可帮助广告商获取、吸引和零售移动受众。该平台严重依赖机器学习模型来进行活动优化和预测分析。

挑战：每秒处理数百万个出价任务且具有严格的延迟限制（低于 100 毫秒）的压力。

选择的NoSQL数据库： Google Cloud BigTable

影响：

• 将处理的请求数量从每秒 50 万个扩展到 500 万个
• 低延迟
• 托管基础设施使公司能够重新分配其软件工程资源，以专注于其他任务。

我们多年在 AdTech 平台开发方面的经验告诉我们，为 AdTech 数据存储基础设施选择合适的数据库并没有千篇一律的方法。数据库种类繁多，需要经验、产品知识和彻底的研究才能找到合适的数据库。

有时，在两个 NoSQL 数据库之间切换可能会产生很大的差异。上面提到的 GumGum 在转向 ScyllaDB 之前依赖于 Cassandra。我们发现，从 MongoDB 迁移到 Aerospike 后，客户（移动 DSP）的运营成本显着降低。

优化数据存储的其他方法

实施数据压缩和重复数据删除技术是减少所需存储空间的另一种方法，从而节省成本。

压缩意味着数据大小的减小，从而加快传输速度并降低存储成本。数据团队可以采用 GZIP 等技术。

重复数据删除，顾名思义，就是消除数据的冗余副本。它在广告技术中非常有用，因为重复的用户配置文件或类似的数据集很常见。

冷存储是一种经济高效的方式来存储很少访问的数据（旧的活动指标），并且不会影响性能。

选择基础设施供应商提供的优质服务

驾驭云服务需要明智的选择。如果您不注意，使用服务捆绑包很容易会增加基础设施成本，但对平台没有任何价值。

在下面的视频中，Xenoss 首席技术官 Vova Kyrychenko 解释了随着 AdTech 平台规模的扩大，“免费资金陷阱”如何导致基础设施成本高昂。

https://www.youtube.com/watch?v=q_57WdKDJI0

我们对广告技术供应商的重要建议是剖析优质服务的定价，以发现隐藏的成本或节省的费用。”

此外，由于新工具可能会降低平台速度，因此在将新服务投入生产之前对其进行小规模测试是合理的。

关注第三方或开源项目是昂贵的托管产品的另一种选择。免费或低成本平台可以提供比主流云供应商更好的性能。

通过在客户项目中采用这种方法，Xenoss 的工程师帮助将基础设施成本降低了 20 倍。

在下面的信息图中，我们展示了客户的旧基础设施和我们的建筑师设计的现代化版本。

平衡流量和负载

正如我们刚才提到的，AdTech 平台无法在稳定的负载下运行 - 某一时刻，平台可能会突然出现峰值，而下一刻，它拥有的计算资源超出了它的用途。

由于 Xenoss 的工程师相信高效的流量和负载平衡是 AdTech 系统的必备条件，因此让我们更深入地研究这些概念。

负载平衡意味着将传入请求均匀分布在多个服务器上，确保没有任何一台服务器被压垮。在此框架内，Xenoss 架构师优先考虑关键任务流程，这些基本任务如果中断，将破坏系统的核心功能（实时广告竞价或用户数据处理）。

通过优先考虑这些流程，我们可以保护重要运营免受潜在的放缓或故障的影响。

设计早期威胁检测机制

一句著名的格言说：“失败是每个计划的一部分”，简洁地警告 AdTech 产品团队防范威胁和停机。

为此，我们敦促供应商和内部技术团队利用监控工具来密切关注系统健康状况，确保不间断运行。如果您针对任何异常情况设置警报，团队可以立即收到警报，迅速采取行动，并确保小挫折不会演变成重大崩溃。

通过人工智能驱动的见解增强这种方法可以提供更精细的粒度。异常检测算法（例如隔离森林或单类 SVM）非常适合识别异常数据模式，这些模式可以指示威胁或系统漏洞。

我们再次建议部署长短期记忆循环神经网络来分析时间序列数据。

大型语言模型还可以通过分析日志和系统消息来检测异常，从而有助于威胁检测，从而理解可能被忽视的文本数据。

底线

基础设施成本优化是各个行业追求效率和盈利能力的公司的关键。

AdTech 是探索处理高数据量和流量负载的挑战和解决方法的绝佳场所，因为需要在毫秒时间内处理数千个查询，这将基础设施开发的极限推向了边缘。

好消息是，经验丰富的技术团队经常通过反复试验，开发出一本手册，以保持较低的基础设施成本，即使对于高负载系统也是如此。平衡云和本地解决方案、利用人工智能进行威胁检测以及不断完善数据存储策略，可帮助产品团队在不影响预算的情况下确保稳健运营。

在这个领域保持敏捷和知情是一种节省成本的措施，也是动态广告技术领域的竞争优势。