Введение
В настоящее время онлайн-видеореклама является обычной для всех практикой. Мы привыкли получать персонализированную рекламу, не задумываясь о том, как она отобрана и предоставлена. В данной статье рассмотрены некоторые технологические аспекты процесса торга в реальном времени (RTB), что может быть полезно и как ориентир для начинающих исследовать подобные технологии, и для тех, кто уже реализовывал такие решения.
Различные исследования оценивают, что глобальный доход в сегменте видеорекламы составил $27799 млн в 2018 году, а годовой темп роста в течение следующих четырёх лет ожидается на уровне 14,6% [1]. Средний доход на одного интернет-пользователя в настоящее время составляет $9,34. Это вовсе не удивительные данные. Просто обратите внимание на два факта: (а) около трёх четвертей интернет-трафика связано с видео и, как ожидается, этот показатель вырастет до 80% в 2019 году [2]; (б) более половины специалистов по маркетингу называют видео типом контента с наилучшим ROI. В самом деле, прогноз, сделанный экспертами The Guardian 4,5 года назад, оказался верным [3].
Торг в реальном времени (RTB) означает «способ продажи и покупки рекламных инструментов на основе оплаты за показ, с помощью автоматизированного мгновенного аукциона». Несмотря на то, что эта технология уже получила широкое распространение и её правила, казалось бы, чётко определены, она всё ещё активно развивается. Отметим некоторые основные черты RTB, которые повышают эффективность интернет-видеорекламы.
(а) показы являются товаром, который продаётся на аукционе в реальном времени, и несколько покупателей (одновременно или в определённом порядке) могут предложить цену за него;
(б) контекстный таргетинг [4]: конечный пользователь устройства получает рекламу в том случае, когда он рассматривается рекламодателем как целевая аудитория на основании его характеристик (например, географического местоположения, сайта или категории приложения, косвенно оценённого дохода);
(в) интерактивность процесса показа (т.е., фиксация действий пользователя, таких как пропуск рекламы, что даёт подробную информацию для анализа поведения конечного потребителя);
Эти свойства отличают RTB от программатик-рекламы и предоставляют как продавцу, так и покупателю дополнительную возможность увеличить свои доходы. Например, интерактивность обеспечивает механизм для отслеживания «пропуска», что имеет большое значение для анализа отношения конечного пользователя к бренду – особенно на Youtube, где доля пропуска превышает половину всех показов [5].
Для участия в RTB в качестве продавца (со стороны предложения) или покупателя (со стороны спроса) вам следует использовать одну из существующих «платформ» (Ad Exchanges, Supply Side Platforms, Demand Side Platforms) [6] или ввести новую, которая будет поддерживать определённые стандарты для операций передачи данных. Среди ключевых игроков на этом рынке такие IT-гиганты, как AOL, Google, Microsoft и Facebook. Поскольку RTB интересен как для компаний, уже вовлечённых в рекламную индустрию, так и для новичков, число платформ постоянно возрастает.
Немного насчёт стандартов. Interactive Advertising Bureau (IAB) привлекает более 650 ведущих медиа- и технологических компаний к сотрудничеству по созданию общих правил для программатик-рекламы, разрабатывает и распространяет технические стандарты и практические рекомендации. Стандарты позволяют различным компонентам (сервисам, работающим на серверах, а также программному обеспечению (игрокам) от конечных пользователей) легко осуществлять связь в процессе обмена запросами. Можно рассматривать процесс RTB как обработку и передачу данных (обмен запросами между серверами) среди многочисленных серверов (или даже кластеров), осуществляемые с помощью опредёленных аппаратных и программных решений. С точки зрения отдельного сервера, обработке подлежит огромное количество входящих запросов (от партнёров со стороны предложения), затем должны быть сформированы производные запросы для дальнейшей отправки (партнёрам со стороны спроса), чтобы впоследствии из полученных и обработанных ответов можно было сформировать собственные ответы на изначальные входящие запросы [7]. Кроме того, каждый производный запрос может привести к группе новых производных запросов на серверах партнеров.
Процессы обмена информацией в рамках RTB (рисунок)
Поскольку основное представление об онлайн-видеорекламе и RTB дано во вводном разделе выше, мы можем двигаться дальше, к описанию RTB-решения. Сначала ради общей картины будет дан обзор «системной архитектуры», а затем будет рассмотрен каждый из основных компонентов, чтобы изложить некоторые подробности используемых технологий.
Обзор архитектуры
На стадии проектирования архитектуры были учтены общие принципы проектирования систем с высокой нагрузкой. Система должна быть реализована с учётом следующих особенностей:
а) высокий уровень масштабируемости (чтобы система была способна справиться с ростом траффика, числа соединений или размера базы данных путём выполнения горизонтального и вертикального обновления масштабирования),
б) разбиение на сервисы,
в) высокая доступность и структура, обеспечивающая отказоустойчивость (позволяющая резервирование и продолжение мониторинга, даже если часть системы даёт сбой),
г) каждый компонент может быть реализован с помощью различных технологий (языков программирования и т.д.), и, наконец,
д) открытость (все внешние взаимосвязи реализуются по стандартам для RTB-платформ).
Сотни тысяч часов могут быть потрачены на проектирование и внедрение такой системы. Поэтому желательно использовать доступные и хорошо проверенные решения с открытым исходным кодом. Мы рассматриваем стек Hadoop [8] в качестве технологической базы для нашего решения. Кроме того, мы использовали Hortonworks DataFlow (HDF) [9] и Stream Analytics Manager (SAM) [10] для настройки и управления необходимыми компонентами Hadoop.
Группы компонентов
Все компоненты могут быть разделены на 3 группы: (а) аналитика, (б) RTB-сервисы и (в) администрирование.
Группа RTB-сервисов принимает запросы от партнёров со стороны предложения, обрабатывает эти запросы, формирует производные запросы к партнёрам со стороны спроса, собирает их ответы и передаёт данные аналитической группе. В свою очередь, аналитическая группа осуществляет сбор, хранение и обработку передаваемых данных и предоставляет сводные данные по запросу группы администрирования. Последняя группа содержит инструменты и пользовательские интерфейсы для мониторинга и управления.
Обзор архитектуры (компоненты и поток данных)
В настоящее время стандарты VAST/VPAID и OpenRTB наиболее часто используются для торга видеорекламой в режиме реального времени, поэтому рекламные платформы взаимодействуют с помощью HTTP/HTTPS-запросов, а ответы POST содержат XML или JSON в соответствии с выбранным стандартом. Как правило, содержание ответов POST заархивировано (желательно с gzip-кодированием контента), что уменьшает сетевой трафик, но увеличивает вычислительную нагрузку сервера.
Обзор компонентов
Рассмотрим каждый компонент схемы.
А. Аналитические сервисы
A.1. Stream Analytics Manager
Stream Analytics Manager (часть Hortonworks DataFlow) обеспечивает пользовательский интерфейс для создания приложений, соединяя компоненты аналитической группы. Это довольно упрощённый процесс для создания новых приложений в SAM. Всё, что требуется, – получить необходимые компоненты из стека Hadoop и настроить их параметры. Некоторые из этих компонентов обозначены как источники данных, некоторые – как накопители данных.
А.2. Distributed Streaming Platform (менеджер потоковой передачи данных в распределённой системе)
Distributed Streaming Platform используется для приёма и временного хранения потоковых данных. В стеке технологий Hadoop есть Kafka, предоставляющая возможность получать данные одновременно по нескольким разделам (параллельная потоковая передача данных), а также обеспечивающая репликацию (резервирование).
А.3. Distributed Data Store (распределённое хранилище данных)
Druid [11] представляет собой распределённое хранилище данных с открытым исходным кодом, разработанное на основе колоночно-ориентированной технологии. Он предназначен для быстрого поглощения большого количества данных о событиях и обеспечения запросов с малой задержкой.
Druid работает как кластер специализированных процессов (называемых узлами) для поддержки отказоустойчивой архитектуры, где данные хранятся избыточно. Кластер включает в себя внешние зависимости для координации (Apache Zookeeper), хранилище метаданных (СУБД, например MySQL, PostgreSQL или Derby) и файловую систему (например, HDFS или Amazon S3) для постоянного резервного копирования данных.
Б. RTB-сервисы
Группа RTB-сервисов содержит несколько видов сервисов, работающих в пределах одного или нескольких кластеров. Каждый кластер может быть реализован либо как единый высокопроизводительный физический сервер, либо как набор близкорасположенных физических серверов (в пределах одной и той же локальной сети).
Обозначим несколько подгрупп внутри группы RTB-сервисов, такие как:
1) балансировщик нагрузки,
2) биддеры,
3) сервис-менеджер,
4) трекеры событий, а также
5) регистраторы.
Эти сервисы разработаны с учётом возможности распределения между различными машинами (серверами), в то время как каждый кластер должен содержать все виды сервисов. Рассмотрим вышеуказанные подгруппы детальнее.
Кроме того, мы можем определить несколько типов событий в нашей архитектуре:
а) непрерывный поток (входящих) запросов к биддерам (управляется балансировщиком нагрузки и затем биддерами),
б) производные запросы и ответы от серверов партнёров как результат входящих запросов (генерируются и управляются биддерами),
в) эпизодические события, такие как изменения конфигурации, инициируемые вручную администратором или происходящие из-за действий какого-либо автоматического обработчика правил (управляются сервис-менеджером), и
г) события отслеживания (отслеживание показов и т.д.).
Б.1. Балансировщик нагрузки
Балансировщик нагрузки является фронтальной составляющей архитектуры. Он принимает запросы от клиентов "извне" и стремится сбалансировать нагрузку между несколькими биддерами (работающими на одном или нескольких физических серверах). Таким образом, балансировщик нагрузки выполняет оптимизацию нагрузок, а следовательно, увеличивает доступность и уменьшает среднее время отклика. С использованием избыточности биддеров (компонентов, дублирующих одни и те же функции) надёжность системы возрастает (коэффициент готовности повышается за счёт резервирования в пределах одного физического сервера), в то время как избыточность на уровне физических серверов повышает устойчивость системы в случае аппаратных сбоев.
Мы предлагаем использовать сервис Nginx в качестве балансировщика нагрузки благодаря его доказанным высокой производительности и надёжности [12]. Он достаточно гибок для такой целесообразной настройки, которая позволяет справиться с различными конфигурациями кластеров (по количеству физических серверов и распределению сервисов между ними).
Б.2. Биддеры
Биддеры получают OpenRTB- и VAST/VPAID-запросы от клиентов "извне" через балансировщик нагрузки. Каждый биддер оперирует и прислушивается к назначенному порту. API реализован таким образом, что биддер получает HTTP/S-запросы от балансировщика нагрузки и обрабатывает эти запросы, после чего набор исходящих производных запросов отправляется соответствующим клиентам, чтобы получить их ответы и сформировать собственный ответ на первоначальный входящий запрос. Кроме того, конечно же, биддеры собирают сообщаемые данные во временный буфер и периодически передают их регистратору.
Целью биддера является формирование OpenRTB- или VAST/VPAID- (в зависимости от выбранного стандарта) ответа с подходящим рекламным контентом и его обратная отправка. Ключевым словом здесь является "подходящий". Это означает, что мы анализируем информацию, полученную с первоначальным запросом, и выбираем тех рекламных партнёров со стороны спроса, которые могут быть заинтересованы.
Разработать и внедрить биддеры, соответствующие самым высоким QPS-требованиям при высоких нагрузках, было непростой технологической задачей. Здесь следует отметить две взаимосвязанные проблемы:
а) огромное количество открытых соединений должны быть обрабатываемо одновременно,
б) каждый запрос должен быть обработан в течение некоторого приемлемого отрезка времени (среднее время на обработку запроса), но это зависит от производных запросов.
Первый пункт относится к известной проблеме 10000 соединений [13], и многие полезные советы можно найти в литературе [14]. Второй частично решён путём сочетания повышенных эффективности программных решений и аппаратной мощности, но в значительной степени он зависит от среднего времени отклика на производные запросы.
Для связи с серверами партнёров биддер должен быть проинформирован об их параметрах соединения (хосте, пути API, протоколах и т.д.). Во время работы биддеры используют оперативную память для хранения параметров спроса и предложения, и это гораздо быстрее по сравнению с решением, использующим СУБД хранилища файлов.
Б.3. Сервис-менеджер
Постоянные изменения спроса и предложения требуют от биддеров использовать обновлённые данные в своих операциях. Поэтому наша архитектура содержит специализированный сервис-менеджер с целью:
а) запуска, остановки и перезапуска биддеров (поэтому сервис-менеджер может изменять количество биддеров),
б) наблюдения за изменениями конфигурации в реестре и обновления локальных файлов конфигурации,
в) принуждения биддеров к перезагрузке конфигурации,
г) тестирования биддеров.
Б.4. Трекеры событий
Трекеры событий получают запросы от устройства конечного пользователя, и таким образом сигнализируют о показе. Хотя мы ожидаем получения запросов от устройств реальных конечных пользователей, эти запросы должны быть проверены на подлинность с целью устранения возможности мошенничества.
Б.5. Регистраторы
Регистраторы получают пакеты зарегистрированных сообщений от биддеров и трекеров событий, преобразовывают эти сообщения в формат AVRO и передают их Kafka. AVRO-сжатие было выбрано для уменьшения сетевого трафика, в то время как механизм валидации схемы основан на едином сервисе Schema Registry [15].
В. Администрирование
Интерфейс администратора
Для управления параметрами RTB-сервисов, хранения и редактирования данных о серверах партнеров (параметров запросов), а также для визуализации аналитических данных мы создали интерфейс администратора. Этот компонент не так нагружен по сравнению с RTB-сервисами или компонентами аналитической группы. Поэтому мы рассматривали удобство использования и безопасность в качестве основных критериев при выборе технологии для реализации интерфейса администратора, и среда Laravel [16] представилась наиболее подходящим вариантом.
Мониторинг сервисов
Как на Data-Lake, так и на Bidder-Lake необходимо предоставить инструменты для мониторинга сервисов. Для мониторинга компонентов Data-Lake мы использовали Ambari [17]. Это упрощает управление сервисами и их мониторинг.
Для мониторинга Bidder-Lake мы использовали Zabbix [18]. Его клиент установлен на наблюдаемом сервере, а сервер Zabbix отдельно установлен в Data-Lake, чтобы получить пользовательский интерфейс мониторинга данных. Кроме того, Zabbix настроен на отправку сообщений в нашу группу в Telegram всякий раз, когда наблюдается какая-либо неисправность сервисов.
Кроме того, конечно же, на ранних стадиях разработки мы провели серию симуляций с высокой нагрузкой на наши сервисы и собрали данные мониторинга с использованием инструментов эталонного теста Apache (AB и JMeter [19], [20]).
Заключение
В данной статье рассмотрены некоторые технологические аспекты процесса торга в реальном времени (RTB), что может быть полезно и как ориентир для начинающих исследовать подобные технологии, и для тех, кто уже реализовывал такие решения.
Напоследок мы хотели бы поделиться несколькими выводами, сделанными из нашего опыта.
• Во-первых, хотя есть много уже доступных RTB-решений, а платформы используют различные технологии, все операции между серверами производятся по общим стандартам. Система должна функционировать так, как это предусмотрено IAB-стандартами для OpenRTB и VAST/VPAID.
• Во-вторых, желательно использовать проверенные решения с открытым исходным кодом. Это придаст вашему решению согласованности.
• В-третьих, принципы проектирования систем с высокой нагрузкой должны быть тщательно соблюдены в каждом компоненте вашего решения.
• И, наконец, использование виртуальных машин для серверов способно значительно понизить производительность системы.
Mykhailo Makhno, Dmytro Biriukov
