Slide-share.ru: как мы сделали испытательный полигон для маркетологов и разработчиков

Часто хочется попробовать новое: архитектурное решение, рекламную партнерскую сеть или новый фреймворк. В боевых проектах новое применить не получится, так как не хочется нарушать принцип «работает — не трогай». Для этих целей подходят pet projects — небольшие проекты, которые «не жалко».

Представьте: почти бесконечный поток презентаций в PPT и PPTX, которые можно брать и использовать как угодно.

Презентации — это контент. Часто хорошо написанный, часто обучающий. Почему бы их не преобразовывать для просмотра в браузере? Почему бы не поработать с пользователями, которые в поисковых системах пытаются найти что-то вроде «москва и её жители в 16 веке презентация»? Вместе с этим поэкспериментировать с поисковиками, партнерками, и творить ВООБЩЕ что угодно в коде? Для этого нет никаких препятствий. Осталось только придумать, как презентации преобразовывать, показывать и отдавать.

Начнем с команды проекта, это:

  • Денис — идея и SEO,
  • Костя — разработка архитектуры,
  • Миша — код,
  • Софья — дизайн.

Хочешь участвовать в разработке без долгих согласований, пробовать новые технологии или другие роли в команде? Есть идея, которую хотелось бы реализовать? В Revolt Lab такое приветствуется — вливайся в команду.

Реализация

Основную архитектуру заложил Костя, наш тимлид. Всё основано на очередях сообщений. Этапы обработки:

  1. Ищем файлы PPT и PPTX и получаем ссылку для загрузки.
  2. Загружаем презентации по полученной ссылке.
  3. Извлекаем из презентации слайды, из слайдов — текст.
  4. Фильтруем презентации. Не берем работы с матом или запрещенным контентом, с малым количеством текста или со слишком большим количеством слайдов.
  5. Извлекаем из слайдов картинки.
  6. Рендерим презентацию, чтоб каждый слайд представлялся одной картинкой.
  7. Сохраняем обработанную презентацию в базу.

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

После обработки для каждой презентации формируем страницу на сайте, где можно эту презентацию посмотреть и скачать.

Обработка PPTX

С обработкой PPTX никаких проблем не должно было быть — это открытый формат, для него есть OpenXML SDK. Начали мы с таких презентаций.

Самые «тяжелые» с вычислительной точки зрения компоненты — это извлекатель картинок и рендерер презентации. Картинки надо пережимать в JPEG, чтобы много места не занимали.

Казалось бы, проблем нет, но мы смогли их себе устроить.

Мы пишем под .NET, последнее время — только под .NET Core. Запускаться собирались на линуксовой виртуалке. Под .NET почти вся работа с графикой сделана через GDI/GDI+, реализация которого есть в рамках проекта Mono, но…

Короче, мы нарвались на сильно текущую память. Вроде и Dispose делали для всех Image/Bitmap, но память всё равно текла. Пришлось проводить исследование, как вообще можно работать с картинками на .NET под линуксом. Возможные решения: упомянутая реализация из Mono (libgdiplus), биндинги для ImageMagick, биндинги для Skia. Выбор пал на ImageMagick: он не тёк и легко ставился в систему в отличие от Skia.

Рендеринг

Еще одна проблема возникла с рендером презентаций. Надо было делать свой рендерер или использовать готовое решение. Готовым решением оказался LibreOffice. У него есть headless режим: операции выполняются через командную строку.

Не нашли возможности, чтобы сразу резать картинки. Работу построили по схеме:

  1. Преобразовывали PPTX в PDF с помощью LibreOffice.
  2. Резали PDF на слайды с помощью ImageMagick. Не обошлось без приключений: люди любят шрифты. Хлебом не корми, дай использовать какой-нибудь красивый шрифт. Решилось прозаично: накатили шрифты рядом с LibreOffice.
Slide-share.ru: как мы сделали испытательный полигон для маркетологов и разработчиков

Серверная часть

Мы не знали, выгорит ли затея, поэтому сразу брать в аренду выделенный сервер казалось нецелесообразным. Особенно когда есть BizSpark, с подачи которого можно развернуть на Azure тестовую виртуалку и не вылезти из лимита по деньгам.

Виртуалка была не самая мощная: два ядра два гига игровая видеокарта, восемь гигабайт оперативки, SSD для системы и HDD для данных, объем которых ожидался большим.

Хозяйке на заметку 1: в Azure медленные диски, которые еще режутся по IOPS. Это было очень больно.

Хозяйке на заметку 2: текущая память в извлекателе картинок привела к активному своппингу. При условии медленных дисков это было ещё больнее. Своп в итоге отключили.

Каждый компонент обернут в Docker-контейнер. Помимо описанных компонентов для работы системы потребовались:

  • RabbitMQ в качестве очереди сообщений,
  • MySQL в качестве РСУБД,
  • фронт, написанный под ASP.NET Core, с которого отдавались страницы презентаций;
  • nginx в качестве web-сервера для отдачи статики и reverse proxy для фронта,
  • MongoDB в качестве хранилище для метаданных об обработанных презентациях,
  • Elasticsearch, Logstash и Kibana для работы с логами.

Довольно много. ELK-стек сразу вынесли на другой сервер, ибо жрал он знатно. Остальное крутилось рядышком, что привело к очередным трудностям.

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

Конвейер пришлось останавливать и думать (зачем думать сначала-то?). Docker умел ограничивать ресурсы для каждого контейнера, это стало решением. Рендерер, как компонент с самым большим аппетитом, получил выделенное ядро и не получил ограничений по процессорному времени. Остальные компоненты конвейера были раскиданы на второе ядро так, чтоб в сумме процент использования был меньше 100. У нас еще фронт, база и очередь.

С такой реализацией удалось добиться скорости около 1500 презентаций в сутки. Под конец 2018 года в базе было порядка 80000 презентаций. Поисковые системы индексировали контент. Мы готовились к прохождению модерации в РСЯ и Google AdSense. Ничего не предвещало беды.

Неожиданные проблемы

После новогодних праздников нас ждала неожиданная новость: BizSpark закончился без объявления войны на другой учетной записи. Это был первый звоночек. Сервер восстановили на ещё одной учетке, мы продолжили работать. Потом BizSpark закончился и на ней. Второй звоночек нельзя было игнорировать: 1.5 гигабайта базы и 500 гигабайт файлов очень не хотелось терять.

Конвейер остановили. Базу забэкапили и вытащили на локальный компьютер. Как быстро утащить 500 гигабайт — идей не было. Решили заархивировать нужные файлы, а потом вытянуть архивы. Это должно было быть быстрее, чем вытягивать по одному файлу, как казалось. Однако дали о себе знать ажурные диски. На упаковку всего требовалось примерно 10 часов. В тот момент молились всем богам сразу, чтобы BizSpark не кончился внезапно, и мы успели всё вытащить. Не повезло. 10 января 2019 года, в 16:48 по Перми виртуалка кончилась.

Было грустно. Жалко контент, жалко потраченное время, жалко проиндексированные страницы. Всё, что осталось из контента — база.

Slide-share.ru: как мы сделали испытательный полигон для маркетологов и разработчиков

Решение, что мы запустим всё ещё раз, приняли сразу. Оставили заказ на аренду сервера. Нормального, честного сервера с 8 ядрами и 32 гигабайтами памяти. С двумя НОРМАЛЬНЫМИ дисками по 4 ТБ. Оставалось придумать, как восстановить всё с минимальными потерями.

Появилась идея. Уточнили у Дениса, нашего маркетолога, насколько критично, если выкатим всё без картинок. Оставим старые тексты и URL, вместо изображений пока поставим заглушки, а потом как-нибудь вытянем со старого сервера. Идея понравилась всем. Как только новый сервер заработал и получили доступы, приступили к минимальной настройке: Docker, база, nginx, фронт. Конвейер пока был не нужен, остальное бы запустить скорее.

DNS обновлялись долго, но оно хотя бы работало. Оплатили виртуалку Azure на один день. Запустили rsync в три потока между серверами: один для презентаций, второй для картинок, третий для слайдов. Попутно перекинули данные RabbitMQ и MongoDB.

К утру 12 января 2019 года все файлы перенесли. Сайт работал как обычно. Осталось восстановить конвейер и поток презентаций, что сделали в тот же день. Обновление сервера принесло плоды. Сразу выросла посещаемость сайта и презентаций в сутки стало обрабатываться в 4 раза больше.

Slide-share.ru: как мы сделали испытательный полигон для маркетологов и разработчиков

Мы прошли модерацию в РСЯ, Google AdSense и нескольких партнерских программах. Разместили рекламные блоки и получили первый доход.

Подключаем обработку PPT

В какой-то момент поток презентаций сократился. Вместо старых 6000 в сутки получили жалкие 100­–200, что сильно нас печалило. PPTX стало не хватать, надо было обрабатывать PPT.

PPT — формат закрытый, бинарный. Лучше всего с ним работает Microsoft Office (неожиданно, правда?), а у нас всё под линуксом крутится. Но бредовые идеи — лучшее, что периодически случается с нами. Почему бы не запустить на физическом сервере свою виртуалку с виндой, а в ней развернуть приложение для конвертации PPT в PPTX с помощью Office? А работать с PPTX мы умеем. Бредово? Да. Попробовать сделать? Конечно!

Запустили ещё один экземпляр поисковика презентаций. Его цель — PPT-файлы, ссылки на которые писались в отдельную очередь. Пока там плавно копились презентации, собрали первый прототип, который работал по принципу:

  1. Скачать PPT.
  2. Открыть через Interop PPT в Office.
  3. Сохранить PPT в PPTX.
  4. Положить результат в очередь «загруженных».

Процесс пошёл. Поток восстанавливался. А потом приложение наткнулось на презентацию с паролем, и PowerPoint ждал, пока кто-нибудь его введёт. Проблему решили через передачу произвольного пароля. Это приводило либо к ошибке, если пароль не совпал, либо к открытию презентации, если пароля там не было.

Также добавили тайм-аут на обработку одной презентации. В случае слишком долгой обработки убивали процесс PowerPoint. Причина — большие презентации, которые не приносят пользу и требуют много ресурсов. Один из примеров — презентация по языкознанию из 812 слайдов, которая не сконвертировалась за 1,5 часа.

На текущий момент всё работает нормально (не сглазить бы!). Мы плавно прикручиваем кэши (для сайтмапа с более 140 000 записей), админки (для управления рекламой), и готовимся к новым экспериментам.