Как мы сделали испытательный полигон для маркетологов и разработчиков

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

Статью написал Михаил Киляков, разработчик Tados.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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