В Depop у нас есть огромный ассортимент уникальных продуктов. Для сообщества наших покупателей это здорово; существует широкий спектр продуктов, которые они могут искать, а также сотни Лучших продавцов, которые подбирают товары для определенного стиля, которому они могут следовать; 2000 год и винтажная сумка? Или прямо эстетика 90-х? Однако мы также хотим иметь возможность предлагать персонализированные рекомендации нашим пользователям, чтобы помочь им изучить огромное количество доступных продуктов. Это то, чем мы занимаемся в Depop уже несколько лет, но с беспрецедентным ростом платформы за последние несколько лет нам пришлось пересмотреть наши конвейеры рекомендаций, чтобы продолжать предоставлять рекомендации в масштабируемом и экономически эффективном формате. способ.

Проблемы с нашим предыдущим решением

До недавнего времени наш конвейер рекомендаций работал с пакетной обработкой. Каждое утро мы использовали Airflow для запуска пакетных заданий Spark в Amazon Elastic MapReduce. Это позволит просмотреть наше Озеро данных и сгенерировать предварительно рассчитанные рекомендации для миллионов пользователей с использованием наших моделей машинного обучения. Затем они были сохранены в корзине S3, готовой для извлечения в Redis для предоставления пользователям. Пользователи будут иметь право на получение рекомендаций, если за последние несколько месяцев у них было достаточно подходящих взаимодействий, таких как нажатие на продукт для его просмотра. Затем мы запустим лямбда-функцию, которая перенесет эти рекомендации из S3 в большой кластер Redis, откуда их можно будет быстро предоставить пользователям.

При таком подходе возникает ряд проблем:

  • 💸 Стоимость хранения: по мере масштабирования растут и наши затраты на хранение. Необходимость хранить миллионы рекомендаций по продуктам в кластере Redis обходится недешево.
  • 🔨 Излишняя работа и затраты: не все пользователи, для которых мы создаем рекомендации, войдут в приложение в тот же день. Это означает, что мы заплатили за создание и хранение рекомендаций, которые не будут использоваться.
  • 😢 Отсутствие рекомендаций для новых пользователей. Мы генерируем рекомендации только один раз в день, поэтому новые пользователи не видят преимуществ рекомендаций, пока не вернутся в приложение на следующий день.
  • 🏃‍♀️ Отсутствие адаптивных рекомендаций: мы не можем улучшить рекомендации текущих пользователей, когда они взаимодействуют с приложением. Их рекомендации будут улучшены только на следующий день.

Решение этих проблем позволит нам создавать более эффективные, полезные и актуальные рекомендации для наших пользователей.

Новое решение

Прежде всего, нам нужно сформулировать некоторые требования к новому решению:

  • 💾 Удалить хранилище состояний: мы хотим устранить необходимость в кеше, в котором хранятся рекомендации, чтобы система могла масштабироваться без необходимости масштабирования базы данных или кеша.
  • 🧪 Возможность экспериментировать с моделями: нам нужна возможность экспериментировать с одной моделью машинного обучения в сравнении с другой или между разными версиями одной и той же модели.
  • 🏃‍♀️ Рекомендации в режиме реального времени: мы хотим иметь возможность обновлять рекомендации пользователей, как только они совершают соответствующее взаимодействие.
  • ⚡ Низкая задержка: поскольку это функция, ориентированная на пользователя, задержка должна составлять десятки миллисекунд.
  • 📈 Масштабируемость. Решение должно масштабироваться в зависимости от нашего профиля трафика в течение дня.

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

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

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

С новой архитектурой мы также смогли увидеть другие улучшения в следующих областях:

  • Затраты. Удалив наш большой кластер Redis и создав рекомендации по запросу, мы сократили расходы в 25 раз! Кроме того, мы экономим на вычислительных затратах на ежедневное выполнение пакетных прогнозов.
  • Рекомендации в режиме реального времени. В настоящее время мы создаем модель, которая может принимать действия пользователей и обновлять рекомендации на лету. Это означает, что мы можем улучшить рекомендации пользователей по мере их просмотра, что было бы невозможно с нашей предыдущей архитектурой. Вернитесь в Depop в ближайшее время, чтобы увидеть эту захватывающую новую функцию!
  • Масштабируемость: Sagemaker можно настроить на масштабирование в зависимости от нагрузки, поэтому его легко масштабировать по горизонтали.
  • Простота: удалив кеш Redis, нам не нужно беспокоиться об эксплуатационных расходах на обслуживание кластера Redis.

Проблемы, с которыми мы столкнулись

Доступ к данным между аккаунтами; Если вы не предоставили ключ KMS для учебного задания Sagemaker, Sagemaker по умолчанию использует ключ шифрования S3 на стороне сервера. Это не может быть передано или использовано другим аккаунтом AWS. Для нас это было проблемой, поскольку наши модели машинного обучения хранятся и запускаются в одной учетной записи, а наша конечная точка вывода Sagemaker — в другой, поэтому мы не можем расшифровать объекты из первой учетной записи. Решение здесь состояло в том, чтобы создать ключ KMS, зашифровать модели с помощью ключа, а затем позволить Sagemaker в другой учетной записи расшифровать модели с помощью этого ключа.

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

Итак, что дальше?

Учитывая постоянное распространение решений машинного обучения в различных функциях в Depop, мы хотим предоставить инженерам машинного обучения быстрый, многоразовый и эффективный способ развертывания и размещения моделей машинного обучения в режиме реального времени. Наряду с тем, что наши типичные сервисы развернуты в Kubernetes, в настоящее время мы оцениваем платформы обслуживания моделей на основе K8s, такие как KServe и Seldon, вместе с Sagemaker, чтобы увидеть, что ближе к нашим общим требованиям, а также многое другое. в соответствии с нашим технологическим стеком.

Оставайтесь с нами, чтобы узнать больше по этой теме!

Хотели бы работать в доме экологичной моды? Мы нанимаем специалистов всех специальностей, включая инженеров, инженеров по прикладному машинному обучению и инженеров-менеджеров.