Как устроен Relap.io — сервис, который выдает 30 миллиардов рекомендаций в месяц

в 11:56, , рубрики: big data, elasticsearch, Hadoop, nginx, perl, postgresql, Блог компании Surfingbird, Веб-разработка, высокая производительность, машинное обучение, Медиа, рекомендательные системы, СМИ, сми в интернете

Мы давно ничего не писали в наш блог и возвращаемся с рассказом о нашем новом проекте: Relap.io (relevant pages).

Мы запустили рекомендательный B2B-сервис Relap.io полтора года назад. Он облегчает жизнь редакции и читателям СМИ. В будние дни Relap.io обслуживает 15 млн уников и выдаёт 30 миллиардов рекомендаций в месяц.

Сейчас Relap.io крупнейшая рекомендательная платформа в Европе и Азии.

image

Зачем нужен Relap.io

В зависимости от поведения пользователя мы подбираем статьи, которые будут ему интересны. Выглядит это как блок «Читать также» или «Вам будет интересно»:

Сейчас сервисом пользуются РИА Новости, AdMe, COUB, TJournal, Лайфхакер и другие медиа. Виджеты Relap.io установлены на более чем 1000 сайтов. 50 из них — миллионники (1 млн и более уникальных посетителей в сутки).

Relap.io начался с простенькой беты. Мы взяли рекомендательные алгоритмы Surfingbird и адаптировали их для сторонних площадок.

Из чего сделан Relap.io

image

Каждую секунду на сервера Relap.io от пользователей поступает 15 000 http-запросов. Из них:

  • 10К статика: изображения для виджетов, стили, статический js.
  • 5К динамика: сбор сигналов, формирующих обучающее множество и формирование блоков рекомендаций.

Когда мы создавали архитектуру у нас было 2 требования:

  • она должна выдерживать высокие нагрузки;
  • масштабироваться.

Бэкенд — это два сервера с большим количеством памяти и объёмными SSD в RAID1. На них стоит PostgreSQL свежей версии, на одном сервере — мастер, на втором — слейв.

Рабочие лошадки — сервера поскромнее. Они принимают запросы из внешнего мира. На двух из них стоят Nginx-ы, которые балансируются друг с другом просто по DNS. Они раскидывают запросы. Их ловят перловые FCGI-воркеры.

FCGI-приложение построено таким образом, что отказ PostgreSQL не приводит к мгновенному отказу всего сервиса, у нас есть примерно 10 минут на устранение фатальных неисправностей. Даже если автоматическое переключение на реплику не спасло ситуацию.

Эти же сервера выполняют и другие роли — на них крутится бОльшая часть очередей, выполняющих в оффлайне всё, что можно делать в оффлайне; инстансы memcached и Redis, крон-скрипты.

Особняком стоят сервера, которые формируют рекомендациями. Для всех, кроме команды математиков, это более-менее чёрная коробка. Туда FCGI и очереди кидают данные, а они в ответ вставляют в PostgreSQL свежие рекомендации, посчитанные по разным алгоритмам, для каждой активной ссылки в базе. Ключевые слова — Hadoop, Spark, Elasticsearch как сторадж, толстый слой Java.

Коду остаётся только забирать готовое, накладывать некоторое фильтрование. Его мы стараемся делать минимальным и максимум фильтровать на этапе генерации и сортировки.

Всё что можно обвешано кешами. Кеш PostgreSQL в памяти, дисковый кеш, мемкешед или redis, где он удобнее, несколько видов кеширования прямо внутри процесса.

Почему все так?

PostgreSQL — самая полнофункциональная open-source база данных. Предсказуемая, стабильная, популярная. Nginx — куда лучше выдерживает масштабирование нагрузки, чем Apache.

MySQL или Apache более популярны, но нам кажется, что выбирать их для новых проектов можно только на shared-хостинге, где больше ничего нет. Или если вы очень хорошо умеете их готовить и масштабировать.

Выбирать shared-хостинг для нового проекта можно, только если вы заранее знаете, что рост ему не грозит. Тогда технологии стоит выбирать уже по принципу «а людей с какими знаниями я найду дешевле и быстрее всего» — это, скорее всего, люди со знанием PHP, MySQL и Apache. Замкнутый мир проектов на shared-хостингах.

Hadoop взяли потому, что особого опыта ни с одним из подобных решений у команды не было. А это некий стандарт в обработке больших данных. Здесь мы просто шли за всеми.

Ещё нам было нужно отдельное хранилище данных для Hadoop-а — PostgreSQL не подходил. Для этого мы выбрали, как ни странно, Elasticsearch, получив заодно полнотекстовый поиск и возможность строить алгоритмы, его использующие. Впрочем, это оказалось неправильным решением. Он может быстро все индексировать и находить, но не отдавать большие объёмы данных.

В следующей серии расскажем, как мы решали эту проблему.

Где хостится Relap.io

С ростом нагрузки перед нами вставала проблема выбора надёжного хостинг-провайдера. Сейчас мы хостимся на Servers.com. Они достаточно мощные, чтобы выдержать нагрузку 900 000 запросов в минуту. Это не пиковые нагрузки, а нормальное состояние в будние дни.

В прошлом году мы несколько раз меняли датацентр. Сначала был ДЦ Славянский. Там до сих пор хостится Surfingbird.ru.

Потом в марте 2015 переехали на Hetzner. Тогда мы выдавали 2К рекомендаций в секунду. При последнем переезде на Servers.com было 6К в секунду. Сейчас 15K.

Интеграция Relap.io на сайт:

Как виджет
Коробочное решение. Пользователь ставит наш код в head страницы, на которой должен быть виджет. Выбирает тип виджета и собирает дизайн во встроенном конструкторе. Формирование рекомендаций и фронтенд полностью происходит на нашей стороне. Так к Relap.io подключено большинство площадок. Например, Лайфхакер.

Через jsonp api
Площадка получает описание нашего api. Мы отдаём большой пакет рекомендаций, а площадка фильтрует их уже на своей стороне и подставляет в дизайн. Интеграция через JSONP API позволяет использовать кастомные элементы: историческое количество просмотров, лайков и любую другую информацию о ссылке. Таким способом к Relap.io подключены, например, AdMe или COUB.

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

Автор: Surfingbird

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js