Каждую неделю в Criteo наши инженеры запускают, обновляют и останавливают десятки A / B-тестов. Они пробуют новые алгоритмы, новый код, новые модели машинного обучения и стремятся повысить точность рекламы Criteo. Учитывая тот факт, что запуск A / B-теста де-факто является изменением производственной среды, любой сбой может иметь катастрофические последствия. Итак, как нам сохранить свет во время масштабных экспериментов?

Перво-наперво: что такое A / B-тест?

Наша инфраструктура A / B-тестирования обеспечивает гибкость для изменения любой части кода, работающего онлайн в производственной среде, или для тестирования новой модели машинного обучения. Это делается с помощью флагов, параметров, идентификаторов - всего, что можно использовать в производственном коде для изменения его поведения. Например, коэффициент масштабирования, который изменяет внешний вид баннера.

Вот упрощенный вид производственной среды Criteo: веб-интерфейсы обрабатывают события (от рекламодателей, платформ Ad Exchange или издателей) и создают журналы в Kafka. Эти журналы затем сохраняются в HDFS для дальнейшей автономной обработки. Внутреннее веб-приложение, управляющее A / B-тестами, позволяет задавать пары ключ / значение (через базу данных), которые используются интерфейсными серверами для изменения своего поведения на фрагменте совокупности.

Возможность проведения A / B-тестирования - это круто, но не очень полезно, если вы не можете понять результат этих A / B-тестов. Таким образом, мы предоставляем возможность изучить влияние A / B-тестов по широкому спектру показателей и прогнозов (например, подсчет количества кликов по стране и сравнение его для A и B). Он обеспечивает отличное понимание, особенно для понимания влияния правильного A / B-теста на бизнес. Но что, если неправильная конфигурация или непредвиденное сложное взаимодействие препятствует отображению баннеров для тестовой группы? Эти подробные анализы проводятся с задержкой в ​​несколько часов, потому что соответствующие события, такие как показы, клики, продажа продукта и т. Д., Охватывают большое окно. Итак, мы увидим это, но очень поздно, и мы можем потерять довольно много денег в процессе, поэтому нам нужно что-то еще.

Мониторинг с помощью потоков Kafka, Graphite и Grafana

Мы хотим отслеживать все текущие A / B-тесты в режиме, близком к реальному времени. Это означает, что для любого данного A / B-теста визуализируйте и сравнивайте поведение популяций ref и test.

Давайте определим поведение: мы подсчитываем отображаемые баннеры, суммируем стоимость этих показов, подсчитываем клики, суммируем доход от этих кликов. Все эти метрики, хотя и являются необработанными и нуждаются в уточнении для анализа бизнес-результатов A / B-теста, достаточны для получения полезной информации о «работоспособности» A / B-теста без дополнительной обработки.

На данный момент в нашей системе у нас есть:
- Веб-интерфейсы, отправляющие записи данных через темы Kafka, но они не различаются по совокупности тестов A / B: каждая строка журнала содержит UUID (внутренний псевдонимный идентификатор) < br /> - Базы данных, содержащие конфигурацию для всех текущих тестов A / B
- Отображение (UUID, A / B Test) = ›Тип популяции: ref (ссылка) или тестовая совокупность.

Используя Kafka Streams, мы разработали приложение, которое получает журналы отображения баннеров и кликов, и для каждой строки, каждый A / B-тест, отправляет очки нашим кластерам Graphite для целей подсчета. Эти точки упорядочены по идентификатору A / B-теста и типу совокупности (ref или test) с использованием предоставленного сопоставления. Затем мы используем Grafana для построения на том же графике кривых ref и test для любого данного A / B-теста. Результатом является наша система мониторинга, которую использует каждый специалист по данным или разработчик программного обеспечения, выполняющий A / B-тесты в Criteo.

Нам нужно держать нашу систему мониторинга очень близко к веб-интерфейсам, как следствие, эта настройка дублируется для каждого центра обработки данных Criteo. Панель управления Grafana затем объединяет значения для всех центров обработки данных, чтобы обеспечить глобальное представление с возможностью выбора подмножества, только если A / B-тест выполняется на одном континенте, или для сужения проблемы, возникающей только локально.

Человеческий фактор или необходимость оповещения

Мониторинг обеспечивает наглядность наших A / B-тестов и является ценным дополнением от экспериментов к производственным функциям. Процесс хорошо отработан: «когда вы запускаете или изменяете A / B-тест, посмотрите на графики и убедитесь, что это не оказывает негативного влияния на наш бизнес». Что может пойти не так, если мы просим человека выполнить длительное задание с низкой интенсивностью, например, наблюдать за медленно развивающейся кривой в течение 30 минут, а затем остановиться, потому что «все будет хорошо»?

Очевидно, это требует автоматизированной системы для обнаружения проблем и создания предупреждений. Prometheus - это система, обычно устанавливаемая в Criteo для управления предупреждениями периметра, поэтому мы создали один экземпляр для наших нужд и модифицировали наше приложение, чтобы излучать не только в Graphite, но и в этот экземпляр Prometheus. Затем он будет получать те же данные, что и Graphite: отображает и отображает затраты, клики и доходы от кликов, для эталонных и для тестовых групп, а также для каждого A / B-теста. Посредством некоторой простой агрегации (аналогичной той, что используется для панели управления Grafana) и настроенной со значимыми пороговыми значениями, Prometheus затем может генерировать предупреждения, которые направляются в системы уведомлений Criteo (электронная почта, Slack, пейджинг). В зависимости от серьезности обнаруженной проблемы, электронное письмо будет отправлено владельцу или центральной группе управления инцидентами.

Итак, что именно мы проверяем с помощью наших пороговых значений? Мы можем определить два типа «безопасности»:

№1. безопасность бизнес-логики, проверенная одним A / B-тестом: «Правильно ли работает система для тестируемой группы в моем A / B-тесте?»,
# 2. безопасность производственной среды во всем мире.

Хотя эти два типа кажутся похожими, между ними есть большая разница. Возьмем пример:
- A / B-тест выполняется на 5%, что означает, что эталонная совокупность составляет 95% трафика, а тестовая совокупность - 5%.
- Для этого A / B-теста , возникает проблема, которая препятствует правильному отображению 1 из 5 баннеров.
- Таким образом, в целом 1% баннеров отображается некорректно в глобальном трафике.

В этом примере безопасность №1 находится под угрозой: система плохо себя ведет для тестируемой совокупности. Однако разница в 1% за короткий период времени для глобального трафика может быть поглощена ежедневным «шумом», и поэтому безопасность №2 не воспринимается как находящаяся под угрозой.

Мы считаем, что безопасность №1 лучше охватывается более подробным анализом A / B-тестов (кратко упомянутых ранее) - конечно, они имеют задержку в несколько часов, но они дают гораздо лучшее представление о ситуациях с низкой посещаемостью, таких как небольшая тестовая группа в пример выше. Кроме того, система мониторинга и пара человеческих глаз, смотрящих на нее, могут гораздо лучше обнаруживать подобные проблемы. Таким образом, мы сосредоточили нашу систему оповещения на безопасности №2, что означает, что мы стремимся защитить глобальную производственную среду.

Чтобы проверить глобальную безопасность продукта, мы сравниваем две «ситуации»:
- моделирование производственной среды, как если бы A / B-тест не выполнялся: мы берем статистику «эталонной» совокупности и масштабируем ее. до 100% (например, если ref / test составляет 50/50%, мы умножаем все характеристики на 2),
- реальная реальность, то есть глобальная ситуация с запущенным A / B-тестом.

Таким образом, мы пользуемся преимуществом того, что точно знаем, какой должна быть нормальная ситуация, чтобы сравнить ее с реальным трафиком и выдать предупреждение, когда наблюдаемая разница обычно превышает 10%. И единственное требование для этого - это базовое предположение о том, что разделение эталонной / тестовой популяции является справедливым (что обеспечивается с помощью «справедливой» хэш-функции).

Мониторинг системы мониторинга

На всех этапах разработки нашей системы мониторинга и предупреждений мы полагаемся на то, что можем читать журналы событий (отображаемые и клики, отправляемые веб-интерфейсами) практически в режиме реального времени. Мы не хотим накапливать задержки, так как мы можем получать предупреждения спустя много времени после того, как проблема действительно возникла. Чтобы избежать этого, мы отслеживаем задержку чтения, отправляя в графит разность между отметкой времени журнала и «сейчас» (время с момента чтения строки журнала). Затем мы используем оповещение Grafana, когда задержка чтения нашего приложения превышает некоторые пороговые значения. Нормальная задержка обычно составляет несколько миллисекунд, но может иногда увеличиваться, поэтому наши пороговые значения имеют порядок минут.

Эта система оказалась чрезвычайно ценной, когда мы начали развертывание нашего приложения в кластере Criteo Mesos, чтобы гарантировать работоспособность системы, поскольку мы наращивали количество экземпляров, настраивали ЦП и память и т. Д. В качестве побочного рассказа в предыдущей жизни эта система использовал Storm на голых металлических серверах, и тогда мы использовали 5 выделенных серверов на каждый центр обработки данных; сейчас мы охватываем примерно 20 экземпляров, но они меньше по объему ЦП / ОЗУ, что позволяет лучше использовать аппаратные ресурсы за счет совместного использования оборудования для разных приложений.

Прибыль на инвестиции

Система мониторинга и оповещения A / B-тестов стала важным компонентом бизнеса Criteo, поскольку она позволяет запускать A / B-тесты, не опасаясь пропустить производственный инцидент. В целом он включает в себя достаточно небольшую кодовую базу, и мы задействовали довольно много внешних компонентов, уже упакованных в Criteo. Добавление функции оповещения было особенно «дешевым» по сравнению с часами, потраченными специалистами по обработке данных и разработчиками, наблюдая за системой мониторинга.

Система мониторинга существует уже несколько лет, и, используя панели мониторинга, пользователи незамедлительно принимают меры, если их недавно начатый A / B-тест был неправильно настроен или в тестируемом коде возникла проблема. Система оповещения была развернута в начале 2018 года; и за тот же год было подано 8 предупреждений о запуске около 700 A / B-тестов. За исключением одного предупреждения, вызванного проблемой с базовой инфраструктурой (несоответствие между Consul и Mesos, что является редким явлением), это были реальные проблемы, связанные с тестом A / B (прямо или косвенно), и наше предупреждение появилось раньше других систем обнаружения аномалий. Это не только быстрее при обнаружении проблем, но и более точно по периметру оповещения, поскольку основная причина прямо указывается системой оповещения. Наконец, не было никаких ложных срабатываний или пропущенных серьезных проблем.

Об авторе: Хадриен Хамель (Hadrien Hamel) - руководитель отдела разработки программного обеспечения в группе инфраструктуры A / B-тестирования, базирующейся в Париже. Он хотел бы поблагодарить Тиболда Ниона, инженера-программиста, за его помощь и тщательную вычитку. Вам это показалось интересным? Criteo нанимает!