Проектирование и внедрение многоуровневой системы распределения ABTest для Ma Honeycomb

Что такое АБТест

Мы не вносим изменения в продукт случайно, «стреляя себе в голову», а должны основываться на реальных данных, что позволяет отзывам пользователей подсказывать нам, как лучше улучшить наши услуги. Как сказал генеральный директор Mafengwo Чен Ган в эксклюзивном интервью: «Некоторые вещи нуждаются в Разуме, но о большинстве вещей можно судить с помощью Науки».

Что касается ABTest, я думаю, что многие читатели знакомы с ним. Проще говоря, ABTest — это процесс разделения пользователей на разные группы, одновременного тестирования разных версий продукта онлайн и определения того, какая версия лучше, на основе реальных данных, полученных от пользователей.

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

Во многих случаях настройка кнопки, изображения или предложения в копирайтинге может привести к очень очевидному увеличению. Вот случай применения ABTest в Мафенгво:

Как показано на рисунке, команда отдела электронной коммерции нашего торгового центра хотела оптимизировать список поиска для «лыжного спорта». Видно, что отображение страницы до оптимизации относительно тонкое. Однако не все уверены, что более сложная форма представления заставит пользователей почувствовать ее недостаточно лаконичной и вызвать отвращение. Поэтому выкладываем страницы до и после доработки онлайн для ABTest. Окончательные данные обратной связи показывают, что оптимизированный стиль UV увеличился на 15,21%, а коэффициент конверсии увеличился на 11,83%. Использование ABTest помогло нам снизить риск итерации.

На этом примере мы можем более интуитивно понять некоторые функции ABTest:

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

Чтобы сделать наш вывод о проверке более точным, разумным и эффективным, мы внедрили набор алгоритмов гарантийного механизма в соответствии с практикой Google, чтобы строго реализовать научное распределение трафика.

Модель многослойного шунта на основе OpenResty

Большая часть ABTest компании выполняется путем предоставления интерфейса, а бизнес-сторона получает пользовательские данные, а затем вызывает интерфейс.Это удвоит первоначальный трафик, и вторжение в бизнес будет более очевидным.Сценарий поддержки относительно прост, что приводит к больше Потребности бизнеса требуют разработки многих систем распределения, которые трудно использовать повторно для различных сценариев.

Чтобы решить вышеуказанные проблемы, наша система разгрузки выбрана для реализации на основе Openresty и передает информацию о разгрузке по протоколу HTTP или GRPC. Таким образом, система распространения работает выше по течению от бизнеса, и вторичный трафик не будет генерироваться из-за собственных характеристик распределения трафика Openresty. Что касается бизнеса, ему нужно только предоставлять дифференцированные услуги, не вторгаясь в бизнес.

Основные причины выбора Openresty для проведения ABTest заключаются в следующем:

Общий процесс

При проектировании системы ABTest мы выделили три элемента: первый — определенный терминал, который содержит информацию об устройстве и пользователе, второй — определенный URI, третий — соответствующую стратегию распределения, то есть способ распределения трафика.

Во-первых, устройство инициирует запрос, а шлюз AB извлекает из запроса идентификатор устройства, URI и другую информацию.В это время были определены данные терминала и информация URI. Затем просмотрите информацию URI, чтобы соответствовать соответствующей политике.После того, как запрос найдет текущий соответствующий эксперимент и версию AB с помощью алгоритма шунтирования, шлюз AB уведомит нисходящий поток двумя способами. Для приложений, работающих на физических веб-машинах, в заголовок будет добавлен ключ с именем abtest, который содержит сведения об эксперименте и версии хита AB. Для приложений микрослужбы информация, попадающая в микрослужбу, будет добавлена в файл cookie для обработки шлюзом микрослужбы.

Гарантия стабильного шунта: алгоритм MurmurHash

Мы используем алгоритм MurmurHash для алгоритма разгрузки.Хэш-факторы, задействованные в алгоритме, включают идентификатор устройства, идентификатор политики и идентификатор уровня трафика.

MurmurHash — это алгоритм, широко используемый в ABTest в отрасли, который можно применять ко многим проектам с открытым исходным кодом, таким как Redis, Memcached, Cassandra, HBase и т. д. MurmurHash имеет две отличительные особенности:

Быстро, в десятки раз быстрее, чем безопасные алгоритмы хеширования
Изменения настолько радикальны, что для похожих строк, таких как «abc» и «abd», они могут быть равномерно распределены по хэш-кольцу, которое в основном используется для реализации шунтирования ортогональных и взаимоисключающих экспериментов.

Ниже приводится краткое объяснение ортогональности и взаимного исключения:

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

Экспериментальное маневрирование в транспортном слое

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

Схематическая диаграмма выглядит следующим образом:

Разделение экспериментальной версии

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

Гарантия стабильности: стратегия многоуровневого кэширования

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

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

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

Второй слой lua_shared_dict, как следует из названия, этот кеш может быть разделен между воркерами. При перезагрузке Nginx его данные не будут потеряны, только при перезапуске. Но есть фича, для безопасного чтения и записи реализована блокировка чтения-записи. Поэтому в некоторых крайних случаях могут быть проблемы с производительностью.

Третий слой Redis.

С точки зрения всего набора стратегий, несмотря на то, что многоуровневый кеш принят, все же существует определенный риск, то есть, когда оба кеша L1 и L2 выходят из строя (например, перезапуск Nginx), Redis может столкнуться с «полосатостью» из-за слишком много трафика. Риск, здесь мы используем lua-resty-lock для решения этой проблемы. Когда кеш недействителен, только часть запроса, которая получает блокировку, может вернуться к источнику, что гарантирует, что давление на Redis будет не будь таким великим.

Наша статистика по онлайн-данным в случае кэширования за 30 секунд показывает, что показатель попаданий в кеш первого уровня превышает 99 %, показатель попаданий в кеш второго уровня — 0,5 %, а запрос обратно к Redis – всего 0,03 %.

Ключевая особенность

пропускная способность: В настоящее время несет 5% трафика всего сайта.
низкая задержка: Средняя онлайн задержка составляет менее 2 мс
Все платформы: Приложение поддержки, H5, WxApp, ПК, межъязыковое
аварийное восстановление:
Автоматический переход на более раннюю версию: при сбое чтения политики из redis ab автоматически переходит в режим без разделения, а затем пытается читать redis каждые 30 с (каждая машина), пока данные не будут прочитаны, чтобы избежать частой отправки
Запросить понижение версии вручную: когда слишком много журналов server_event или нагрузка на систему слишком высока, закройте все эксперименты или закройте шунтирование AB через фоновое «отключение одним щелчком».

Представление

распределение времени отклика

Распределение TPS

Инструмент тестирования использует JMeter со 100 параллелизмом продолжительностью 300 секунд.

отВремя откликаС точки зрения, за исключением того, что значение отклонения запроса относительно велико в начале, после этого оно находится в среднем в пределах 1 мс. Причина большого разрыва в начале анализа в том, что в это время в многоуровневом кэше нет данных.

TPSПри измерении давления производительность немного снизилась, все-таки из-за алгоритма хеширования, но в целом в пределах допустимого.

А/Б выпуск

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

резюме

Следует отметить, что ABTest не полностью применим ко всем продуктам, потому что результаты ABTest требуют для поддержки большого объема данных, и сайт с большей суточной посещаемостью получит более точные результаты. Вообще говоря, мы рекомендуем, чтобы при проведении A/B-тестирования ежедневный трафик каждой версии мог гарантированно составлять более 1000 UV, иначе период тестирования будет очень долгим, или будет трудно получить точный результат (сходимость результатов). вывод результатов данных.

Чтобы спроектировать полный набор платформы ABTest, необходимо проделать большую кропотливую работу.Из-за нехватки места в этой статье основное внимание уделяется только обмену алгоритмом шунтирования. В заключение следует отметить, что система шунтирования Mafengwo ABTest показала некоторые результаты в следующих аспектах:

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

Последние запланированные улучшения:

Система наблюдения.
Пользовательский портрет и другие доработанные настройки AB.
Статистическая мощность поддерживает такие функции, как доверительные интервалы и собственные значения.
Влияние эксперимента на индикатор Polaris оценивали по модели AARRR.

В будущем в этой системе еще много областей для улучшения.Мы продолжим исследовать и с нетерпением ждем общения с вами.

автор этой статьи: Ли Пей, главный технический эксперт по исследованиям и разработкам платформы Mafengwo, Чжан Лиху, инженер отдела статических данных по исследованиям и разработкам отелей Mafengwo.

(Исходное содержание Ma Honeycomb Technology, пожалуйста, укажите источник и сохраните изображение QR-кода в конце статьи при перепечатке, спасибо за сотрудничество.)

Обратите внимание на технологию конских сот и найдите больше нужного контента.