作为实时出价（RTB）一部分的Ad Exchange是正在改变在线广告市场的AdTech解决方案之一。 其主要功能是将大量彼此之间没有直接集成的SSP和DSP停靠在一起，并在它们之间转售各种广告流量。
由于获得了美国市场的订单，我们全力投入了构建Ad Exchange平台的细节。 在本文中，我们提出了一些想法和结果。
问题陈述
实时出价（RTB）可以实时出售网站上的广告空间，以向目标受众展示相关广告。
简而言之，流程图如下：
- 最终用户请求在网页或移动应用程序中保留横幅位置（内置用于销售广告资源的平台的代码-SSP，供应方平台）；
- 为了确保最高的库存销售价格，SSP通过Ad Exchange组织各种DSP（需求方平台）之间的招标，其目标是尽可能便宜地购买库存；
- 在宣布拍卖中标者之后，中标DSP发送SSP标语代码，并显示给用户；
- 流程的另一面是DMP，这是一个第三方系统，可为DSP提供有关最终用户的详细信息（除了SSP可以cookie形式传输的信息之外），以证明购买的便利性和建议的成本。
今天有很多Ad Exchange交易平台。 此外，许多SSP都执行自己的出价（实际上是关闭Ad Exchange的功能）。 但是我们的客户确信，由于一些新想法，他可以迅速进入市场并经受竞争。
交易所遵循不同的原则：某人提供更大的利润，某人提供更少的利润，某人出售独特的设备，其他人专注于有条件的消费品。 这个市场还很年轻，并且正在积极发展，因此多年来没有经过测试的商业模型：一切都基于大胆的假设和实验。 大多数玩家按照一个简单的方案工作：他们从他们能够同意的几个SSP中接收一个请求，然后将其发送给所有集成DSP，以期更好地押注。 Ad Exchange收入-在SSP和DSP上广告库存的买卖价格之差减去运营成本。
我们的客户建议通过正确地将SSP请求分配给DSP来优化此方案，而不是故意发送“丢失”的请求，从而降低运营成本。 因此，您可以在不损失收入的情况下减少交换的佣金，并使您的报价在竞争SSP和DSP的Ad Exchange竞争背景下更具吸引力。 与更多的合作伙伴建立联系将带来收入和市场稳定。
为了在美国市场实施此策略，我们的任务是使Ad Exchange的请求分配合理，以提供良好的回购百分比。 从理论上讲，对于这样的分发，您可以使用大量伴随请求的信息，甚至包括来自上述第三方系统（DMP）的数据。 但是，复杂的分析需要资源，因此实际上的任务是在智能分配的成本和实施中所获得的收益（与其他市场参与者相比）之间找到平衡。 在相对较新的不成熟市场中，构建十分复杂的解决方案，压缩十分之一的优化，根本没有道理。
除预期的高负荷外，该项目的一个重要特征是满足了SSP提出的拍卖速度方面的非功能性要求。 在这个细分市场中，足够的等待超时是等待SSP响应300毫秒，这必须与对外部系统（DSP）的调用一起得到满足。
该项目于2016年秋季开始。 感谢团队在此领域的经验，三个月后，我们制作了第一个原型，再准备了三个MVP（最低可行产品），这使我们能够收集第一个分析数据，以开始在Ad Exchange中智能分配请求。
MVP的推出表明，有关该项目的商业成功的假设是正确的-Ad Exchange开始为客户赚钱。 Ad Exchange的初始开发计划包括对数据进行更深入的研究-将最终用户信息从外部系统连接到分析。 但是在MVP阶段，决定仅使用SSP拥有的数据。 这足以赚取预期的利润。
解决方案架构
该解决方案建立在责任链模板的基础上，该模板不允许固定系统中的请求路由，而从拍卖本身到过滤工具，很容易添加处理器和各种服务。
客户并没有限制我们使用的技术堆栈。 因此，考虑到项目的未来开发和支持，我们使用Postgres和Hadoop构建了可横向扩展的解决方案。
Ad Exchange本身是用Java编写的-同时，我们没有使用任何框架，以免降低负载（我们在较低级别上工作）。
为了保持在上述SSP超时之内，我们选择了垃圾收集器参数（使用了G1），并完成了与大量请求的同步工作-我们使用了不会阻止流的HTTP客户端，以及keep-alive HTTP协议的扩展，该协议允许在内部发送多个请求一个TCP连接。
软件组件部署在从主机租用的硬件上，如下 由于虚拟云机的资源重叠，因此任务的条件不允许使用云（分配必要的资源可能需要时间，但是我们没有）。 目前，Ad Exchange使用了四台物理服务器，其中一台是冗余的（用于无缝更新等）。
开源Apache Kafka用作消息代理-理想情况下，它已集成到我们的“一个订户-许多发布者”模型中，尽管它必须稍作扭曲才能避免重复消息到达。
每个服务器在正常模式下每秒提供大约1万个请求（这些参数是在解决方案的开发过程中确定的）。 现在，平均负载为每秒152,000个请求，在几个小时内，高峰时的请求流达到每秒4万个，Ad Exchange做到了这一点。
服务器之间的请求分配由nginx软件负载均衡器执行，该负载均衡器是为我们的任务配置的。 根据我们的经验，在nginx上，您每秒最多可以保留60-70000个请求，而无需分配单独的硬件平衡器。 如果将来Ad Exchange的负载会超过此阈值，我们计划购买一个硬件平衡器，该硬件平衡器将在多个相同类型的nginx之间分配请求。
它会监视正在发生的事情（在不断增加的负载下）一个监视系统，该系统是已创建的Ad Exchange的一部分。
贮藏
考虑到查询分发过程中对分析的依赖，数据库是Ad Exchange不可或缺的一部分。 该系统存储有关投标，拍卖参与者和交易的信息。
在整个Ad Exchange期间收集如此大量的数据是没有意义的，因此存储具有多层结构。 每周都会存储所有拍卖数据。 在此基础上，构建了更高级别的中间单元，可以存储几个月。 在中间的基础上，使用最终的汇总，这些汇总用于长期分析以及与SSP和DSP的对帐。 在这些单位的其他信息中，还有关于下注多少以及交易所将向SSP支付或期望从DSP接收多少钱的数据。
在Ad Exchange的整个过程中都存储了端点。
分析的收集和汇总的形成提供了单独的服务。
为了使存储与系统本身的速度相对应，我还必须使用它。 特别是一段时间以来，我们与托管人作战，因为 事务数据根本没有时间写入数据库。 事实证明，故障是RAID阵列的硬件问题。 替换它之后，我们能够在Postgres上每秒压缩90,000个请求（通过将数据插入数据库）。
Ad Exchange的其余部分是无状态的，将来可以轻松进行横向扩展。 它不存储任何请求数据-应接收有关应选择哪个DSP的最大信息。 这样我们就可以根据需要添加新服务器来处理请求。
流量过滤
系统的一个关键要素是流量过滤，它可以减少负载并保持在客户指示的超时范围内。
根据手头的任务，任何Ad Exchange：
- 接受SSP的请求；
- 举行拍卖（向多个DSP发送请求，比较报价，确定获胜者）；
- 同意SSP的胜利（报告获胜者的价格减去他的佣金，等待以演出的最终价格做出回应）；
- 完成交易（向胜利者报告必要的DSP，进行用户流量）。
拍卖的初始阶段便包含了Ad Exchange中的智能请求分发。
当我们收到来自SSP的带有某些信息（IP，用户代理）的请求时，我们将使用系统中累积的信息（已知的用户信息，向其发送类似请求的DSP列表，它们的响应等）来详细说明该请求。 必须为每个请求选择最有利的DSP组合。 由于选择了这种组合，因此系统不允许您将请求发送到那些没有出价或没有出价但太低的DSP。 为此，一个单独的服务会实时编译DSP如何响应请求的映射（这些卡存储在Redis中）。
同时，我们检查DSP的状态-如果超时时间内响应的比例下降，系统会自动减少对此DSP的请求数量。 一旦DSP的负载减少（并且可接受的时间内正确答案的比例不断增加），请求的数量便逐渐恢复到其先前的水平。
在按时答复的DSP中，我们进行内部拍卖-选择最佳报价并将其发送给SSP。 根据行业要求，从SSP发出请求开始到我们的响应，最多不超过300毫秒。
由于我们将数据发送到举行拍卖的SSP，因此我们需要考虑在那里赢得的竞标。 在处理用户流量时，拍卖服务器已经在下一阶段进行了日志记录。 多亏了他，DSP响应图才充斥着新数据（以及有关最终用户的收集信息）。
将拍卖阶段获得的数据与用户访问量已知的参数进行比较，我们就可以过滤出漫游器（广告点击器，搜索漫游器等）。 DSP无法赎回此类流量，并且在没有自己的过滤系统的情况下，它变成了客户损失，必须用保证金弥补。
应当指出，漫游器流量过滤不是立即开始的。 但是，在包括简单的锁之后，保证金收益约为50％。
顺便说一句，除了我们系统中的自动流量过滤工具之外，客户还可以手动更改许多参数的阈值，从而调整裕度。
用户流量本身对我们来说至关重要，但是在处理之后，不再需要适应300毫秒。 它使用一个单独的处理系统，该系统可以保留用户一点时间，但不会丢失此请求。
为了确保解决方案的稳定性，引入了一个子系统，该子系统了解当前的Ad Exchange负载，“切断”了它实际上无法处理的拍卖请求。 因此，可以保护系统免受来自SSP的不受控制的负载增长。
前景展望
迄今为止，我们创建的Ad Exchange运作良好并获得了可观的利润。 并且我们根据需要提供支持和集成新的合作伙伴（DSP / SSP）。 总共已经集成了几十个系统。 每个这样的集成不仅意味着软件连接，而且还意味着对服务的全面测试，因为在重负载下，所连接服务的问题可能会影响其他合作伙伴。
通常，市场正在朝着SSP和DSP直接连接的事实发展，这将使交换变得不必要。 但是集成取决于SSP和DSP的功能。 尽管存在公开描述的API（OpenRTB协议），但尚未在市场上普遍认可。 例如，像Appnexus这样的主要公司最近已经集成了对OpenRTB的支持。
本质上，Ad Exchange是流动性提供商。 因此，在不久的将来做出该决定的可能性不大。 而且，交换模型仅在其余广告市场中得到普及。
文章作者：Nikolay Eremin
PS：我们在Runet的多个站点上发表文章。 订阅我们在
VK ，
FB或
Telegram频道上的页面，以查找有关我们所有出版物和其他Maxilect新闻的信息。