В данной статье рассматривается создание сервиса для динамического изменения размеров изображений с функциями проксирования и кэширования, а также приводится вариант его применения.
Введение
В современной веб-разработке работа с изображениями занимает важное место. Проблемы оптимизации скорости загрузки страниц, экономии трафика и адаптивности под разные устройства заставляют искать эффективные способы обработки графики на лету. Такой подход избавляет от необходимости хранить десятки вариаций одного и того же изображения на сервере. Вместо этого генерируется только то, что востребовано прямо сейчас.
Задача
Основная задача сервиса - выступать в роли умного прокси-сервера. Шаги его работы можно описать следующим образом:
Принимает запрос на изображение;
Проверяет наличие финального изображения в кэше;
Если в кэше нет финального изображения, то создает его:
Скачивает изображение;
Изменяет изображение согласно заданным параметрам (метод изменения, размеры (ширина/высота) финального изображения);
Сохраняет результат в кэше;
Если в кэше есть финальное изображение, то берет его из кэша;
Отдает финальное изображение.
Рассмотрим некоторые методы изменения изображений и кэширования, и затем определим, какие будем применять для решения этой задачи.
Методы изменения изображений
Выделяют три основных метода (Fill, Fit и Stretch), которые определяют, как именно изображение будет вписано в заданную область (контейнер), когда их пропорции не совпадают.
Fill (заполнить)
Метод заполнения масштабирует изображение так, чтобы оно полностью заполнило всю площадь контейнера, при этом пропорции оригинального изображения сохраняются. Однако если соотношение сторон изображения и контейнера разное, то часть изображения, выходящая за границы контейнера, будет обрезана. Этот метод рекомендуется использовать, когда важна эстетика заполнения, например для фотографий.
Fit (вписать)
Метод вписания масштабирует изображение так, чтобы оно полностью поместилось в контейнере, при этом пропорции оригинального изображения сохраняются. Однако если соотношение сторон изображения и контейнера разное, то появятся пустые области - полосы по бокам или сверху и снизу. Этот метод рекомендуется использовать, когда важно видеть все изображение целиком, например для схем.
Stretch (растянуть)
Метод растяжения изменяет ширину и высоту изображения так, чтобы они точно совпали с размерами контейнера, при этом пропорции оригинального изображения не сохраняются. Если соотношение сторон изображения и контейнера разное, то изображение может выглядеть искаженным, сплюснутым или растянутым. Этот метод рекомендуется использовать, когда пропорции не имеют значения, например для фона.
Помимо вышеперечисленных методов, существуют методы, которые меняют саму структуру изображения, его геометрию или содержание. Из наиболее сложных к таким можно отнести Content-Aware Scale (масштабирование с учетом содержимого) и AI Upscaling (масштабирование на основе ИИ). Не будем их рассматривать, так как для данной задачи подойдут три основных метода.
Методы кэширования
Рассмотрим основные методы кэширования, которые определяют, как именно приложение взаимодействует с кэшем.
Cache-Aside
В этом методе приложение сначала обращается в кэш. Если данные в нем есть, то возвращает их. Если данных в кэше нет, то приложение обращается в основное хранилище данных, затем помещает полученные из основного хранилища данные в кэш и отдает данные. Как видно из описания, первый запрос всегда медленный, так как данных в кэше нет. Однако, можно отметить, что кэш содержит только те данные, которые действительно запрашиваются, и новые данные добавляются в кэш только по мере необходимости. В этом случае система будет устойчива к сбоям кэша, так как, если кэш недоступен, то приложение может взаимодействовать с источником данных напрямую.
Read-Through
В этом методе приложение всегда получает данные только из кэша. Если данные в нем есть, то возвращает их. Если данных в кэше нет, то модуль кэширования сам обращается к источнику данных и получает их. В результате приложение никогда не обращается к источнику, логика приложения становится проще, нагрузка на источник данных минимизируется. Однако в этом случае система неустойчива к сбоям кэша. Так как приложение не взаимодействует с источником данных напрямую то кэш становится критической точкой отказа.
Write-Through
В этом методе данные сначала записываются в кэш, а затем в основное хранилище данных. Кэш обновляется при обновлении данных в основном хранилище, что упрощает процесс обновления кэша, и, как результат, кэш всегда актуален. Однако из-за двойной работы получаем медленную запись. Также возможен случай, когда кэш заполнен ненужными данными, к которым нет запросов, но которые занимают место.
Write-Behind
В этом методе данные пишутся сначала в кэш, а в основное хранилище отправляются с задержкой в фоновом режиме. За счет этого достигается очень быстрая запись, но есть риск потери данных, если кэш упадет до того, как произойдет запись данных в основное хранилище. Как и в прошлом методе, кэш также может быть заполнен ненужными данными, к которым нет запросов, но которые занимают место.
Write-Around
В этом случае, если данные есть в кэше, то при изменении данных происходит их обновление и в кэше, и в основном хранилище. Если в кэше нет данных, то тогда обновление происходит только в основном хранилище. Этот метод обычно комбинируют с Cache-Aside. Это позволяет избежать заполнения кэша лишними данными.
Алгоритмы вытеснения данных
Алгоритмы вытеснения данных из кэша - это методы, определяющие, какие элементы удалить при заполнении кэша для того, чтобы освободить место для новых данных. Бегло рассмотрим три распространенных алгоритма, не вдаваясь в детали.
LRU
В алгоритме LRU (Least Recently Used) вытесняется тот элемент, который не использовался дольше всех. Этот алгоритм стремится сохранить свежие часто используемые данные, поэтому его рекомендуют использовать, когда чаще запрашиваются те данные, к которым недавно обращались.
MRU
В алгоритме MRU (Most Recently Used) вытесняется тот элемент, который использовался последним. Этот алгоритм стремится сохранить старые данные, поэтому его рекомендуют использовать для циклического сканирования данных.
LFU
В алгоритме LFU (Least Frequently Used) вытесняется тот элемент, который реже всего использовался. Этот алгоритм стремится сохранить самые популярные данные, поэтому его рекомендуется использовать, когда частота обращений является показателем полезности данных.
Реализация
Весь исходный код сервиса можно посмотреть по ссылке https://github.com/dmitry-goncharov/image-previewer
Сервис ресайзинга
Сервис представляет собой веб-сервер, загружающий изображения, масштабирующий и/или обрезающий их до нужного размера и возвращающий их в ответе.
Обработчик
Основной обработчик обрабатывает пути, которые формируются следующим шаблоном:
{hostname:port}/{method}/{width}/{height}/{schema}/{source-image-URL}, где
{hostname:port} - имя хоста и порт на котором развернут сервис
{method} - метод изменения fill|fit|stretch
{width} - ширина финального изображения
{height} - высота финального изображения
{schema} - схема URL исходного изображения http|https
{source-image-URL} - URL исходного изображения без схемы
Пример обработчика с методом изменения fill
http://localhost:8080/fill/2000/1000/https/raw.githubusercontent.com/dmitry-goncharov/image-previewer/master/img/gopher_original_1024x504.jpg
Пример обработчика с методом изменения fit
http://localhost:8080/fit/2000/1000/https/raw.githubusercontent.com/dmitry-goncharov/image-previewer/master/img/gopher_original_1024x504.jpg
Пример обработчика с методом изменения stretch
http://localhost:8080/stretch/2000/1000/https/raw.githubusercontent.com/dmitry-goncharov/image-previewer/master/img/gopher_original_1024x504.jpg
Кэш
Наиболее подходящим методом наполнения кэша видится Cache-Aside.
Поскольку размер места для кэширования ограничен, то для удаления редко используемых изображений используем алгоритм LRU.
Выберем классическую реализацию LRU с использованием хеш-таблицы для быстрого доступа к данным по ключу и двусвязного списка для хранения порядка использования элементов. Каждый новый элемент данных вставляется в голову списка. При запросе элемента он перемещается в голову списка, вытесняя оттуда старый элемент. Если нужно освободить место, вытесняется элемент из хвоста списка.
Использование
Для визуализации работы собственного CDN (Content Delivery Network) на базе сервиса image-previewer можно представить следующую архитектуру: Клиент -> Граничный узел (cache) -> Процессинг (image-previewer) -> Источник (origin).
Описание компонентов
Global Edge Cache
Принимает запрос от пользователя. Если изображение с такими параметрами уже запрашивалось недавно, кэш отдает его, не беспокоя сервис.
Image Previewer
Сервис ресайзинга. Если Global Edge Cache не нашел изображение в своем кэше, то запрос уходит на сервис, который, в свою очередь, решает, можно ли взять изображение из своего локального кэша или надо скачивать оригинал и ресайзить.
Local SSD Cache
Внутренний кэш сервиса, который использует сервис ресайзинга. Даже если внешний кэш (Global Edge Cache) очистится, сервис не будет заново скачивать оригинал из источника и тратить ресурсы на ресайзинг, если файл есть в его локальном кэше.
Origin
Хранилище оригиналов. Это может быть S3-хранилище или основной сервер с исходными изображениями. Важно то, что сервис сюда обращается, только если не нашел изображение в своем локальном кэше.
Выводы
Используя описанный выше подход, больше не нужно хранить изображения под каждый размер экрана (mobile, tablet, desktop). Можно хранить только один оригинал. Все вариации создаются на лету, что экономит место в облачном хранилище (например, S3). Процесс ресайзинга происходит быстро, и пользователь не замечает разницы между получением готового статического файла и динамически сгенерированного, а LRU-кэш гарантирует, что повторные запросы не будут приводить к скачиванию и ресайзингу изображения. Наличие собственного прокси-превьюера позволяет легко внедрять новые варианты кэширования (например, LFU), новые форматы (например, отдавать WebP вместо JPEG) и добавлять новые функции обработки изображений (например, обрезку по лицу или водяные знаки) централизованно.