Платформа элитной недвижимости NMH столкнулась с проблемой: после добавления водяных знаков время загрузки изображений выросло до нескольких минут. Разбор ситуации показал, что причина не в новом функционале, а в архитектурном долге — неоптимальной работе с облачным хранилищем S3. Рассказываем, как мы нашли четыре узких места и ускорили обработку изображений без переписывания всей системы.
О проекте: цифровое агентство недвижимости с фотокаталогом объектов
NMH (NewMoscowHouse) — цифровое агентство недвижимости с узкой специализацией по продаже загородных домов и участков на территории Новой Москвы. Благодаря собственным ИТ-решениям компания объединяет покупателей, продавцов и агентов по недвижимости. Публичный сайт позволяет клиентам просматривать каталог объектов: дома, участки, таунхаусы, коттеджные поселки. После просмотра клиенты могут записываться на просмотр. Личный кабинет агента предоставляет инструменты для управления объектами: добавление недвижимости с фотографиями, работа с заявками покупателей, аналитика, система напоминаний и SMS-уведомлений.
Публичный каталог NMH: пользователи выбирают объекты недвижимости по фото, параметрам и фильтрам
Проблема: водяные знаки сделали публикацию объектов неприемлемо медленной
Заказчик поставил задачу: добавить водяные знаки на фотографии объектов недвижимости, чтобы защитить контент от копирования конкурентами. Функционал реализовали, но загрузка изображений и публикация объектов замедлились до нескольких минут.
В личном кабинете агенты управляют объектами, статусами публикации, заявками и аналитикой
Масштаб проблемы становился критичным при работе с реальными объектами. Каждая фотография недвижимости весит до 10–15 Мб. Из одного оригинала система генерирует пять превью разного разрешения для адаптивного отображения на сайте. После добавления водяных знаков количество файлов удвоилось. Теперь на каждый оригинал приходится пять обычных превью и пять с watermark — итого десять изображений.
Самая чувствительная часть процесса: загрузка фотографий объекта с обработкой изображений через S3-хранилище
В базе агентства сотни объектов недвижимости. Типичный объект недвижимости содержит 15–20 фотографий. При публикации такого объекта система должна обработать 150–200 изображений. Время публикации выросло до неприемлемых значений и занимало по несколько минут, что делало работу агентов крайне неудобной.
Изначально было четкое понимание, что стало работать медленнее после добавления водяных знаков. А что там конкретно — стало понятно, когда начали разбираться и полезли внутрь Django. Выяснилось, что мы теряем время не на создании водяного знака, а на работе с сетью: скачивание, загрузка и прочие операции, которые можно было не делать.
Поиск причин: четыре точки избыточных запросов к S3
Первоначальная гипотеза указывала на сам процесс наложения водяного знака — операция требует обработки изображения и должна занимать время. Однако профилирование показало, что создание watermark выполняется быстро и не является узким местом.
Настоящая проблема скрывалась глубже — в архитектуре работы с файловым хранилищем. Проект использует Yandex Cloud S3 для хранения изображений, но стандартные компоненты Django проектировались для работы с локальной файловой системой. При миграции на облачное хранилище эти компоненты сохранили свою логику, которая оказалась неэффективной для удаленного хранилища.
Мы обнаружили четыре точки, где система избыточно скачивала файлы из S3:
- Валидация формы. При проверке загруженных изображений система запрашивала метаданные каждого файла (размер, формат, разрешение), для чего скачивала файл целиком — хотя эти данные для валидации не требовались.
- Копирование из временного хранилища в постоянное. Когда агент нажимал «Опубликовать», система скачивала каждое изображение из временной директории S3 на сервер приложения, а затем загружала обратно в S3 по новому пути. Фактически файлы дважды передавались по сети, хотя и источник, и назначение находились в одном хранилище.
- Создание превью. Для нарезки одного оригинала на пять превью разного размера система пять раз скачивала этот оригинал — по разу для каждого разрешения.
- Неоптимальная работа с фоновыми задачами. На каждое изображение создавалась отдельная Celery-задача для обрезки. При публикации объекта с 20 фотографиями система запускала 40 задач (20 оригиналов + 20 с водяным знаком), что создавало накладные расходы на управление очередью.
Проблема существовала и до внедрения водяных знаков, но не проявлялась критично: при 5 превью на фотографию задержки были терпимыми. Удвоение количества файлов обнажило архитектурный долг.
Решение: оптимизация Django при работе с S3
Оптимизация затронула все четыре выявленные точки в цепочке обработки.
Убрали избыточное скачивание при валидации. Переработали логику проверки загруженных файлов: теперь валидация использует метаданные, уже полученные при первоначальной загрузке, без повторного обращения к S3.
Заменили «скачать-загрузить» на копирование внутри S3. Вместо того чтобы гонять файлы через сервер приложения, мы используем API Yandex Cloud S3 для копирования объектов напрямую внутри хранилища. Сервер отправляет только команду с путями источника и назначения. Сами данные по сети не передаются.
Для реализации потребовалось расширить стандартный класс хранилища Django и переопределить метод копирования файлов. Также создали собственное поле ImageField, которое работает с новым хранилищем вместо стандартного.
Кэшировали оригинал при создании превью. Теперь оригинальное изображение скачивается один раз и хранится в памяти, пока из него последовательно создаются все пять превью. Это сократило количество сетевых запросов в пять раз для каждой фотографии.
Сгруппировали фоновые задачи. Вместо создания отдельной Celery-задачи на каждое изображение, мы группируем обработку. Теперь при публикации объекта создаются только две задачи: одна обрабатывает все оригинальные превью, вторая — все превью с водяными знаками. Каждая задача работает со своим набором файлов параллельно, но без накладных расходов на управление десятками мелких задач.
Результат: загрузка изображений за секунды вместо нескольких минут
Оптимизация вернула скорость публикации к комфортным значениям — изображения загружаются за считанные секунды, вместо нескольких минут. Агенты могут публиковать объекты с большим количеством фотографий без длительного ожидания.
Один объект может содержать десятки фотографий, из которых система создает превью и версии с водяным знаком
Снизилась нагрузка на сервер приложения: вместо постоянной передачи тяжелых изображений через память сервера, основная работа выполняется внутри облачного хранилища. Это особенно заметно при одновременной работе нескольких агентов.
Заключение
Проект NMH — пример того, как точечная оптимизация загрузки изображений может дать значительный результат без масштабного рефакторинга. За три недели работы одного разработчика удалось не только ускорить систему, но и заложить основу для дальнейшего масштабирования. Теперь система готова к росту количества объектов и фотографий без деградации скорости.
Ключевой урок для команд, работающих с облачными хранилищами: стандартные библиотеки фреймворков часто оптимизированы под локальную файловую систему. При переходе на S3-совместимые хранилища, стоит проверить, не тратит ли система ресурсы на избыточные сетевые операции. Иногда достаточно переопределить несколько методов, чтобы получить кратный прирост скорости.
Если вы замечаете замедление при работе с файлами — возможно, причина в тех же узких местах. Work Solutions проводит аудит проектов с облачным хранилищем: находим, где система теряет время, и предлагаем решение под вашу архитектуру. Расскажите о своем проекте в форме ниже — посмотрим, чем можем помочь.
