4 разных способа загрузки изображений в AWS
Три подхода и AWS для загрузки изображений локально, в облако или и то, и другое.
Загрузка изображений — это всегда хлопотно, поэтому вот сравнение каждого подхода, который я нашел, чтобы помочь вам решить, какой из них подходит вам лучше всего.
Начнем прямо сейчас!
Хранение изображений на сервере
Традиционный способ хранения изображений. Пользователь загружает изображение, и сервер сохраняет его локально на диске.
Маленькие файлы
Плюсы
- Загрузка небольших файлов, как правило, не слишком нагружает сервер, а процесс хранения изображений прост.
- Отсутствие зависимости от внешних сервисов и полный контроль над обработкой и хранением изображений.
Минусы
- Обслуживание изображений не будет оптимальным, поскольку они хранятся на одном сервере; скорость передачи будет зависеть от пропускной способности и местоположения сервера, если не используется собственная сеть доставки контента (CDN).
- Этот подход также создает единую точку отказа для нашей системы, так что это может быть не очень масштабируемое решение.
Тем не менее, это отличный стартовый подход для небольших и локальных проектов, о которых известно, что они не слишком сильно разрастаются или масштабируются.
Большие файлы
Большие файлы, как правило, создают больше проблем, чем нет, и я бы не рекомендовал этот подход для хранения файлов размером более 100 МБ.
Плюсы
Единственное преимущество, о котором я могу думать, — это полный доступ и контроль над хранением ваших данных. Контроль может быть полезен при хранении конфиденциальных данных, хотя его можно легко защитить в облаке, если все сделано правильно.
Минусы
Управление сервером и масштабирование станут кошмаром. Подумайте о стоимости сервера, накладных расходах на управление, защите от сбоев, общих эксплуатационных расходах, резервном копировании и т. д.
Пропускная способность сети также пострадает.
Временно сохранить на сервере, обработать, а затем загрузить в AWS
Гибрид между облачным и локальным. Пользователь загружает изображение. Сервер временно хранит изображение на диске, выполняет обработку, после чего загружает в облако
Маленькие файлы
Плюсы
Этот подход представляет собой идеальный баланс между контролем и масштабируемостью для небольших файлов.
У вас есть контроль над предварительной загрузкой изображений и всеми дополнительными преимуществами облачного хранилища, такими как снижение затрат, масштабируемость и простая интеграция CDN.
Можно развернуть серверы меньшего размера, при этом пространство на диске образа будет использоваться только в течение всего срока действия запроса. (в среднем пару секунд).
Минусы
Вы должны быть осторожны с этим подходом, потому что всплеск трафика одновременных запросов может быстро занять хранилище и память сервера.
Всплеск трафика может привести к сбою ваших запросов из-за нехватки памяти на устройстве.
Эту проблему можно элегантно решить с помощью групп автоматического масштабирования (ASG) в AWS, инициируя развертывание новых экземпляров по определенным параметрам сервера. Например, вы можете инициировать запуск нового экземпляра, когда хранилище или память вашего сервера (или и то, и другое) достигает 70% использования.
Большие файлы
плюсы
Полный контроль над обработкой изображения перед загрузкой.
минусы
Если вы не хотите поддерживать хранение, масштабируемость и доставку контента самостоятельно, хранение больших изображений становится проблематичным.
Например, если вы не храните изображения на диске, память вашего сервера станет узким местом. В результате память может быстро закончиться.
Дисковое пространство также станет проблемой при получении большого количества одновременных запросов, и, конечно же, пострадает пропускная способность сети.
Загрузить напрямую в корзину S3
Бессерверный или преимущественно клиентский подход.
Пользователь загружает изображение, серверную или бессерверную функцию, создает предварительно подписанный URL-адрес S3 для изображения, а затем загружает непосредственно в корзину S3 с клиента.
Маленькие файлы
Плюсы
Общий плюс этого подхода — бессерверный аспект. Таким образом, нам не нужно беспокоиться об ограничениях памяти или хранилища сервера.
Прямая загрузка значительно снижает нагрузку на сеть или полностью ее устраняет. (лямбда-функция против бэкэнд-функции предварительной подписи)
Минусы
Один из наиболее существенных недостатков этого подхода заключается в том, что мы теряем контроль над рабочим процессом. Например, мы больше не можем выполнять обработку или оптимизацию перед загрузкой изображения, поскольку пользователь делает это напрямую.
Вызов холодной бессерверной функции может потребовать времени ожидания до 10 секунд (или даже больше).
Для небольших изображений это неприемлемо и ухудшает взаимодействие с пользователем, поскольку использование предыдущих подходов обычно занимает менее 2 секунд. (для изображений размером 5 МБ или меньше)
Большие файлы
плюсы
Вот где проявляется этот подход. Даже после значительного времени ожидания лямбда пользователь ожидает, что для загрузки больших файлов потребуется гораздо больше времени.
Прямая загрузка устраняет ограничения сервера и хранилища, и сервер может оптимально использовать пропускную способность сети для фактических запросов к серверу, кроме загрузки изображений или файлов.
минусы
Здесь нечего сказать, кроме того, что мы потеряем контроль перед загрузкой. Однако, на мой взгляд, преимущества значительно перевешивают эту проблему.
Динамический подход
На данный момент мы проанализировали и реализовали все три подхода к загрузке изображений.
Мы узнали, что каждый из них имеет свои преимущества и недостатки в зависимости от размера файла, масштабируемости и контроля.
Однако почему бы не использовать каждый подход в зависимости от ситуации? В этом случае я бы сказал, что первый подход создает больше проблем, чем пользы, но мы можем динамически использовать гибридный и бессерверный подход, чтобы получить лучшее из обоих миров.
Используя гибридный подход (для небольших файлов), мы сохраняем контроль и обработку небольших изображений и файлов, пользуясь преимуществами облачной масштабируемости и управления.
Мы сохраняем высокую скорость загрузки для наших пользователей, поскольку нам не нужно полагаться на бессерверные функции для прогрева перед выполнением.
Реализация бессерверного подхода (для больших файлов) может устранить все головные боли, которые мы обсуждали, такие как ограничения пропускной способности, памяти и хранилища.
Бонус (обработка CDN на лету)
Некоторые сервисы могут интегрироваться с существующими сетями CDN, чтобы обеспечить оперативное преобразование изображений, оптимизацию и изменение размера.
В нашем случае сервис под названием ImageKit может легко интегрироваться с CDN AWS CloudFront.
Эта услуга позволяет нам восстановить контроль над всеми размерами файлов, по крайней мере, для изображений. Если это была единственная проблема, удерживающая вас от внедрения облачного подхода, вам повезло.
Эта услуга выходит за рамки этой статьи, но я хотел упомянуть о ней, чтобы вы могли получить полную картину и принять соответствующее решение, поэтому я призываю вас провести исследование этих типов услуг.
Какой подход вы нашли лучшим для вашего варианта использования? Дайте мне знать в разделе комментариев!
