Мы давно ничего не писали в наш блог и возвращаемся с рассказом о нашем новом проекте: Relap.io (relevant pages).
Мы запустили рекомендательный B2B-сервис Relap.io полтора года назад. Он облегчает жизнь редакции и читателям СМИ. В будние дни Relap.io обслуживает 15 млн уников и выдаёт 30 миллиардов рекомендаций в месяц.
Сейчас Relap.io крупнейшая рекомендательная платформа в Европе и Азии.
Зачем нужен Relap.io
В зависимости от поведения пользователя мы подбираем статьи, которые будут ему интересны. Выглядит это как блок «Читать также» или «Вам будет интересно»:
Сейчас сервисом пользуются РИА Новости, AdMe, COUB, TJournal, Лайфхакер и другие медиа. Виджеты Relap.io установлены на более чем 1000 сайтов. 50 из них — миллионники (1 млн и более уникальных посетителей в сутки).
Relap.io начался с простенькой беты. Мы взяли рекомендательные алгоритмы Surfingbird и адаптировали их для сторонних площадок.
Из чего сделан Relap.io
Каждую секунду на сервера 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
