Вступ
Нині онлайн-відеореклама є звичною для всіх практикою. Ми звикли отримувати персоналізовану рекламу, не замислюючись про те, як її відібрано та надано. У цій статті розглянуто деякі технологічні аспекти процесу торгу в реальному часі (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
