Pull to refresh
0

CTOcast #1: Кирилл Сафонов (RuTarget)

Reading time 8 min
Views 5.4K
Представляем первый выпуск подкаста о технологиях, процессах, инфраструктуре и людях в IT-компаниях (нулевой выпуск можно послушать и почитать здесь). Сегодня в гостях у “CTOcast” — Кирилл Сафонов, технический директор компании RuTarget.

Слушать подкаст

Несколько слов о нашем собеседнике и компании RuTarget:

Кирилл Сафонов живет и работает в г. Санкт-Петербург, Россия. Окончил Санкт-Петербургский государственный политехнический университет (2004), кандидат физико-математических наук (2007). В 2001--2004 гг. работал C++ разработчиком в компании Soft-Impact, в 2004--2006 гг. — программист в компании Borland. С 2006 по 2010 г. в SwiftTeams (с 2010 г. в должности CTO). В 2011--2013 гг. — разработчик в компании JetBrains. С апреля 2013 г. занимает должность CTO в компании RuTarget.
Компания RuTarget основана в 2011 г. Евгением Легким, тогда же привлечены первые инвестиции. Компания занимается разработкой RTB-решений под заказ. RTB-инфраструктура, предоставляемая RuTarget, позволяет агентствам и рекламодателям осуществлять автоматизированную покупку и продажу рекламы и данных. Наиболее известное решение — платформа для компании Segmento (тесно связана с RuTarget), оказывающей услуги RTB для рекламодателей и рекламных агентств.

Текстовая версия подкаста (1-ая часть)


Александр Астапенко: Поясни, пожалуйста, что же такое RTB (real-time bidding) и как устроено взаимодействие между различными участниками этой системы: рекламодателями, площадками, поставщиками данных.

Кирилл Сафонов: Конечно. RTB, или аукцион реального времени — это схема показа интернет-рекламы, суть которой сводится к тому, что в процессе загрузки web-страницы, в реальном времени, происходит аукцион между рекламной сетью (к ней подключена страничка) и несколькими выкупающими участниками (компания RuTarget в их числе).

Сеть предлагает рекламное место и, самое главное, некий идентификатор пользователя. А участники определяют насколько им интересно предложение сети, насколько привлекательны пользователь и площадка, и принимают решение показать ли один из баннеров тех рекламных кампаний, которые они крутят, этому пользователю или нет. Если решение положительное, участник должен предложить ставку рекламной сети. Максимальная ставка побеждает, и конечный пользователь видит баннер победителя.

Технически это происходит как взаимодействие серверов рекламной сети и выкупающих сторон. В реальном времени посылается запрос, на который выкупающая сторона должна ответить в течение короткого промежутка времени — 100 миллисекунд. Рекламная сеть собирает ответы, фильтрует их определенным образом, выбирает максимальную ставку и показывает баннер. Таким образом, в схеме RTB решение о том, какой баннер показать, принимается в процессе загрузки web-страницы.

Такая схема хороша тем, что реклама работает более эффективно как для рекламодателей, так и для пользователей. Рекламодатели могут показывать релевантную для пользователя рекламу, у которой будет более высокий процент кликов и вообще откликов. И пользователям реклама показывается с учетом их намерений или интересов. Таким образом, это своего рода win-win.

Понятное дело, что чем больше участник аукциона (выкупающая сторона) знает о пользователе, тем эффективнее он (участник — прим. ред.) может расходовать бюджет: ставить более высокие ставки на тех, кто кликнет на рекламу, и не ставить на тех пользователей, которые ему не интересны. Здесь начинается математика, математические модели, которые собирают информацию о пользователях, переваривают ее соответствующим образом и строят набор признаков, используя которые можно понять или предсказать, что будет делать человек: кликнет он на рекламу или нет.

Александр Астапенко: Что представляет собой RuTarget в этой цепочке как продукт?

Кирилл Сафонов: RuTarget — это платформа, DSP (demand-side platform), то есть выкупающая сторона, которая умеет подключаться к рекламным сетям (в нашей области они называются SSP — supply-side platform, продающая сторона) и делать ставки. Также система умеет собирать данные пользователей, хранить их и обрабатывать для того, чтобы делать ставки наиболее эффективно.

Павел Павлов: Кто ваши клиенты и как организовано их взаимодействие с платформой RuTarget?

Кирилл Сафонов: Конечные клиенты, как правило, взаимодействуют с компанией Segmento, которая является своего рода бизнес-фронтэндом. Segmento умеет выполнять, крутить рекламные кампании клиентов, обеспечивая им нужный объем кликов, конверсий и так далее. Segmento использует платформу RuTarget для того, чтобы эти кампании откручивать. Допустим, клиент приходит в Segmento, или компания Segmento находит клиента и заключает с ним договор, а все технические действия выполняет компания RuTarget.

Павел Павлов: Получается, что взаимодействия RuTarget с конечным клиентом нет?

Кирилл Сафонов: Сейчас нет. Хотя в планах есть вывод платформы RuTarget в паблик, чтобы у пользователей была возможность напрямую общаться с технологической платформой, например, подключаться к ней через API.

Александр Астапенко: А кто отвечает за формирование продукта RuTarget, то, что происходит за API? Являются ли текущие клиенты двигателями развития продукта? Как внутри RuTarget это происходит? Кто принимает решения и управляет процессом?

Кирилл Сафонов: У нас есть продакт-менеджер, человек, который находится между Segmento и RuTarget и аккумулирует все фичи и запросы, приходящие в наш баг-трекер, а также следит за тем, куда продукт движется. С другой стороны, есть команда разработки во главе со мной, которая эти фичи-запросы анализирует, определяет в какой момент они могут быть выполнены. А дальше происходит обычная координация и расстановка приоритетов, какие-то задания на ближайшие итерации.

Александр Астапенко: Все-таки хочу эту тему «докопать». Есть ли какой-то процесс расстановки приоритетов по фичам? Процесс попадания этих фич в ваш продуктовый бэклог?

Кирилл Сафонов: С одной стороны, это всегда входящие фичи, входящие запросы от продакт-менеджера. С другой стороны, понимание того, как долго это все делается и как ложится в текущую архитектуру, что требуется переделать. Дальше — дискуссия, и мы принимаем совместное решение в зависимости от приоритета, от бизнес-важности этой задачи и от времени, которое требуется на ее выполнение. В результате общения она и ложится куда-то раньше или позже в бэклог. Дальше, когда мы планируем операцию, то берем очередной кусок из бэклога, выбираем те фичи, которые в эту операцию попадают, и выполняем ее.

Павел Павлов: Кирилл, ты чуть раньше упоминал о 100 миллисекундах. Складывается впечатление, что к RTB-решениям есть довольно высокие требования. К быстродействию, в частности. Скажи, как вам удается соответствовать этим требованиям и есть ли другие технические сложности, с которыми приходится сталкиваться при разработке, создании и поддержке платформы?

Кирилл Сафонов: «Технические сложности» — звучит немножко пессимистично, я бы назвал это интересными моментами. Первый интересный момент — нагрузки и короткое время ответа, уникальное требование. У нас есть входящий поток запросов (порядка 10--20 тысяч запросов в секунду) и у нас есть, на самом деле даже меньше, чем 100 миллисекунд, — где-то от 20 до 30 миллисекунд на то, чтобы принять решение: показать баннер человеку или нет, какой именно баннер, какая ставка и так далее. Мы решили эту проблему, построили архитектуру так, чтобы она была горизонтально масштабируемой, чтобы мы добавляли дополнительные серверы при увеличении нагрузки. Сейчас мы подключены к десяти локальным сетям разного калибра и со всеми успешно работаем.

Еще один, может быть не уникальный, но важный момент — высокая доступность системы: круглосуточно, с высоким процентом. Нам нужно в дизайне компонентов архитектуры думать и о стабильности, и о дублировании компонентов при отказе какого-то блока.

Еще одно интересное место — это математические модели, которые должны максимально эффективно давать прогнозы о пользователях на основании тех данных, которые у нас есть. И это открытая область, без каких-то четких рамок. Здесь нельзя сказать удовлетворяем мы требованиям или нет, потому что предел совершенства в данном случае не найти. Это постоянная работа, постоянные раздумья, тесты, сравнения, выкатывание новых версий, откатывание назад, игра в математику, скажем так, игра в модели. Это, наверное, самое интересное место, самое нетривиальное.

Павел Павлов: Интересно, хотелось бы здесь немного остановиться. Есть такое понятие, как «data science», и ты специалист в данной сфере. Насколько это действительно наука? Или «игра в математику», по твоему собственному определению? Ближе к науке или к программированию? Как ты определяешь эту нишу в современной IT-технологии?

Кирилл Сафонов: У нас есть отдел data mining — несколько человек, которые разрабатывают эти модели и у них происходит настоящая наука: анализ больших объемов данных, построение моделей, прогон тестов. Когда они говорят, что есть какая-то идея, которая должна быть эффективной, мы имплементируем ее в нашей системе, выкатываем на тестирование на каком-то проценте запросов или рекламных кампаний и проверяем, работает она или нет. Дальше наши ребята смотрят, как оно пошло, анализируют логи и результаты. Мы утверждаем, что новая модель, подход приемлемы, распространяем его на все остальные рекламные кампании. Или же от него отказываемся, возвращаемся обратно и пробуем что-то другое. То есть, с одной стороны, это data science в том смысле, в каком ее все понимают: анализ больших данных, поиск закономерностей, построение моделей. И это некий эксперимент, который постоянно происходит в системе.

Павел Павлов: Ты говорил про big data, уровень масштабирования и нагрузки. Как вообще удалось достичь такой архитектуры, прийти к нужному решению? Личный опыт в предыдущих проектах или совместная работа сотрудников?

Кирилл Сафонов: Пожалуй, предыдущий опыт работы мне не очень помог, потому что до этого я занимался или десктопными проектами, или серверными, но не с такой нагрузкой и требованиями. Чтение литературы, Интернет помогли. В последнее время достаточно много появилось статей, продуктов, из которых можно составить систему. Общение с другими людьми на рынке в данной области. Как ни странно, достаточно часто приходится обсуждать какие-то технические вопросы с инженерами из компаний-конкурентов или партнеров. Таким образом, появляется некое понимание, которое на самом деле работает, которое можно применить и которое будет давать отдачу.

Павел Павлов: Раз решения приходили извне, может быть есть рецепты, которыми ты готов поделиться? Какой технологический стек исследовать людям, которые пытаются работать в сфере с таким уровнем нагрузок и безотказности?

Кирилл Сафонов: Что касается больших данных, мы достаточно очевидно используем Hadoop и компоненты, такие как HBase, задачи MapReduce. Как высоконагруженный фронтэнд у нас очень хорошо работает Nginx. Мы им очень довольны и практически никак его не кастомизировали. Он переживает очень большие нагрузки без каких-то отказов. Достаточно много сейчас есть высокопроизводительных NoSQL-баз, с помощью которых можно организовать различные кэши. Пожалуй, что никаких конкретных советов я дать не могу, потому как информация, которая у меня есть, она взята из Интернета, и в течение двух часов можно составить какое-то базовое представление, что и как там происходит.

Павел Павлов: На основе теоретических решений вы практическим путем подошли к тому, что вся эта связка — Hadoop, NoSQL, Nginx — работает и прекрасно ложится в серьезный продакшн.

Кирилл Сафонов: Да, все получается.

Павел Павлов: Ну, и закрывая тему высокого уровня безотказности, можешь поделиться SLA (service-level agreement)? Сколько там девяток, какие требования по безотказности предъявляются к подобным решениям?

Кирилл Сафонов: Формальных требований безотказности с девятками, конечно, нет. Но при этом как только что-то ломается вдруг, то сразу же партнеры из рекламной сети или поставщики данных жалуются, мол, что-то не так. Поэтому система проектировалась максимально безотказной. Так, чтобы даже если бэкэнд перестает отвечать, фронтэнд заглушкой формировал ответ, который бы устроил всех.

Павел Павлов: Судя по всему, по вакансиям, которые у вас открыты, ставка делается на Java-разработку и технологии. Чем обусловлен такой выбор? Связано ли это с твоим опытом, с возможностью поиска специалистов на рынке IT?

Кирилл Сафонов: Как мне кажется, Java представляет собой некую золотую середину. Она, с одной стороны, подтвердила, что является продакшн-языком, на котором можно делать высоконагруженные и высокоскоростные решения. С другой стороны, это достаточно простой и распространенный, с точки зрения навыков и уровня подготовки, язык. Плюс, у нас используется Hadoop. В любом случае клиентские приложения, компоненты для Hadoop будут делаться на Java.

Продолжение текстовой версии подкаста — в ближайшие дни.

Подпишитесь на подкаст
Tags:
Hubs:
+6
Comments 0
Comments Leave a comment

Articles

Information

Website
caspowa.ru
Registered
Employees
2–10 employees
Location
Беларусь