Онлайн-сервис для сравнения цен на экипировку

WeighMyRack — онлайн-сервис, который помогает любителям активного отдыха искать и сравнивать экипировку: каски, обвязки, верёвки, карабины, страховочные устройства, обувь и одежду.

Платформа собирает информацию о товарах из разных интернет-магазинов и позволяет пользователям:

- искать экипировку с помощью фильтров;

- сортировать товары по бренду, цене, цвету, форме, размеру, весу, наградам и скидкам;

- сравнивать цены в разных интернет-магазинах;

- читать и оставлять отзывы;

- сохранять товары в личный список снаряжения или вишлист;

- переходить в выбранный интернет-магазин для совершения покупки.

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

Задачи:

- подключить к платформе новые товарные фиды интернет-магазинов;

- разобраться в архитектуре и синхронизации двух серверов;

- исправить ошибки пользовательского интерфейса, в том числе отображение скидок и фильтрацию товаров по их размеру;

- повысить скорость и производительность сайта по PageSpeed Insights;

- обновить Drupal и контрибные модули;

- исправить существующие баги;

- обеспечить стабильную работу сервиса при регулярном обновлении большого объёма товарных данных.

Настройка серверной инфраструктуры

В проекте использовалось два сервера. Main-сервер хранит контент и обслуживает пользователей, а sync-сервер отвечает за обработку товарных фидов ритейлеров. Взаимодействие между серверами организовано через Jenkins API.

Разделение нагрузки необходимо из-за ресурсоёмкого процесса импорта. Если обрабатывать фиды непосредственно на основном сервере, обновление большого количества товарных данных может существенно замедлять работу сайта для пользователей.

При этом существующая архитектура создавала дополнительный риск: оба сервера синхронизировались с одной базой данных, поэтому сбой во время импорта мог привести к потере актуальной информации о товарах.

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

Дополнительно настроили Monit для мониторинга и автоматического перезапуска процессов. Если MySQL, Apache или httpd перестают отвечать в течение трёх минут, система автоматически перезапускает соответствующий процесс или сервис. Это помогает быстрее восстановить нормальную работу сайта в том числе после повышенной нагрузки или атаки.

Добавление новых товарных фидов

Изначально WeighMyRack получал данные только от двух продавцов. Фиды обновлялись последовательно: после завершения обоих импортов изменения баз данных sync-сервера и main-сервера объединялись.

Обновление двух фидов занимало в среднем 3–5 часов. По мере развития сервиса количество подключённых ритейлеров увеличивалось, и последовательный импорт перестал справляться с объёмом данных: полный цикл обновления начал занимать больше суток.

Мы перевели обновление товарных фидов в параллельный режим. Это позволило запускать несколько импортов одновременно, но создало новую проблему: несколько Drupal-процессов могли обращаться к одним и тем же данным и перезаписывать изменения друг друга.

Во время тестирования это приводило к тому, что из 1000 товаров корректно обновлялись только 500–600.

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

В результате время обновления всех товарных фидов сократилось примерно в два раза — с 26–28 до 12–15 часов.

Обновление Drupal и контрибных модулей

Во время технического аудита проекта мы обнаружили девять контрибных Drupal-модулей, код которых ранее был изменён непосредственно внутри самих модулей.

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

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

Это позволило продолжить развитие существующего сайта и избежать дорогостоящей разработки платформы с нуля.

Оптимизация скорости загрузки сайта

Ещё одной проблемой была низкая производительность. До начала работ показатели отдельных страниц в Google PageSpeed Insights составляли всего 1–2 балла из 100.

Для ускорения Drupal-сайта мы:

• оптимизировали серверную часть;

• настроили агрегацию CSS и JavaScript;

• внедрили ленивую загрузку (Lazy Load) для тяжёлых страниц.

После оптимизации показатели PageSpeed Insights выросли в несколько раз, а загрузка ресурсоёмких страниц стала быстрее.

• Подключили более 10 дополнительных интернет-магазинов и их товарные фиды.

• Сократили время полного обновления данных примерно в два раза: с 26–28 до 12–15 часов.

• Настроили синхронизацию двух серверов и безопасную обработку параллельных импортов.

• Реализовали ежедневное резервное копирование данных и механизм восстановления.

• Настроили мониторинг и автоматический перезапуск серверных процессов.

• Обновили Drupal и контрибные модули без разработки платформы с нуля.

• Повысили производительность сайта и показатели PageSpeed Insights.

После выполнения основных задач мы продолжили сотрудничество с WeighMyRack: поддерживаем существующий Drupal-проект и разрабатываем для платформы новые функции.