Нужна помощь в выборе между EBS и S3 на Amazon Web Services

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

В основном мое решение заключается в использовании хранилища EBS для размещения пользовательских файлов или S3. Система будет включать архивирование zip файлов на лету, когда пользователь захочет загрузить несколько файлов. Кроме того, когда пользователи загружают файлы, я не хочу, чтобы URL-адрес был открыт.

Два лучших варианта, которые я придумал, следующие:

Имейте экземпляр EC2, у которого есть несколько томов EBS, смонтированных для хранения пользовательских файлов.
- плюсы: он кажется намного быстрее, чем S3, и файлы zipping с объема EBS прямолинейны.
- cons: Я считаю, что Amazon закрывает количество хранилища EBS, которое вы можете использовать, и нет такого избыточного, как S3.
После загрузки и обработки файлов система подталкивает эти файлы в ведро S3 для долговременного хранения. Когда файлы запрашиваются, я получаю файлы с S3 и вывод обратно клиенту.
- плюсы: избыточность, отсутствие ограничений на хранение файлов
- cons: похоже, SLOW, не способ монтировать ведро S3 в качестве тома в файловой системе, обслуживание зашифрованных файлов означает перенос каждого файла на экземпляр EC2, zipping, а затем, наконец, передачу вывода (опять же, медленное!)

Являются ли какие-либо из моих допущений ошибочными? Может ли кто-нибудь подумать о лучшем способе управления огромными объемами хранения файлов?

Ответ 1

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

Что касается защиты URL-адреса, позволяющего только авторизованным пользователям загружать файлы, существует много способов сделать это, не требуя, чтобы ваша служба выступала в качестве промежуточного элемента, тогда вам нужно будет решить как минимум две проблемы:

Предсказуемость имени файла. Чтобы избежать предсказуемости URL, вы можете назвать загруженный файл как хэш и сохранить исходные имена файлов и владельцы в базе данных, например SimpleDB, при необходимости вы можете установить http заголовок, такой как "Content-Disposition: filename = original_file_name.ext", чтобы сообщить браузеру пользователей, чтобы назвать загруженный файл соответствующим образом.
авторизация: когда пользователь попросит загрузить данный файл вашей службы, выпустите временную авторизацию с помощью Query String Authentication или Временные учетные данные безопасности для этого конкретного пользователя, дающего доступ к чтению файла в течение определенного периода времени, а затем ваша служба перенаправляется в ведро S3 URL для прямой загрузки. Это может сильно разгрузить ваши экземпляры пула EC2, что делает их доступными для более быстрого обработки других запросов.

Чтобы уменьшить пространство и трафик на ваш ведро S3 (помните, что вы платите за каждый ГБ, хранящийся и переданный), я также рекомендовал бы сжать каждый отдельный файл с использованием стандартного алгоритма, такого как gzip, перед загрузкой на S3 и установить заголовок "Content-Encoding: gzip", чтобы автоматическая сжимаемость работала с браузером пользователей. Если ваш язык программирования является Java, я предлагаю взглянуть на код плагина webcache-s3-maven-plugin, который я создал для загрузки статических ресурсы из веб-проектов.

Что касается времени обработки при сжатии папки, вы часто не сможете гарантировать, что папки будут сжаты за короткое время, чтобы пользователь мог сразу загрузить его, так как в конце концов могут быть огромные папки, которые может потребоваться несколько минут или даже часов для сжатия. Для этого я предлагаю вам использовать службы SQS и SNS, чтобы разрешить обработку асинхронного сжатия, она будет работать следующим образом:

пользователь запрашивает сжатие папки
внешний экземпляр EC2 создает запрос сжатия в очереди SQS
экземпляр EC2 backend, потребляет запрос сжатия в очереди SQS
экземпляр backend загружает файлы с S3 на диск EBS, так как сгенерированные файлы будут временными, я бы предложил выбрать как минимум m1.small экземпляры с ephemeral типами дисков, которые локально к виртуальной машине, чтобы уменьшить задержку ввода-вывода и время обработки.
после создания сжатого файла служба загружает файл в ведро S3, опционально устанавливая свойства Object Expiration, которые будут сообщать S3 bucket для автоматического удаления файла через определенный промежуток времени (опять-таки, чтобы уменьшить затраты на хранение) и публикует уведомление о том, что файл готов к загрузке в теме SNS.
если пользователь все еще находится в сети, прочитайте уведомление из этой темы и уведомите пользователя о том, что zip файл готов к загрузке, если через некоторое время это уведомление не поступило, вы можете сообщить пользователю, что выполняется сжатие дольше, чем ожидалось, и служба сообщит ему по электронной почте, как только файл будет готов к загрузке.

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

Ответ 2

Если вы настаиваете на обслуживании zip файлов непосредственно из вашего экземпляра EC2, используя S3, это будет сложнее, чем их локальное хранение. Но S3 гораздо более долговечен, чем любые объемы хранилищ EC2, поэтому я бы рекомендовал использовать его в любом случае, если файлы должны храниться долгое время.

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

1 - Храните файлы, которые вы хотите обслуживать (застегните молнию, если хотите, таким образом) в приватном ведре S3.

2 - Когда пользователь запрашивает файл, аутентифицирует запрос и перенаправляет действительные запросы на подписанный, временный URL-адрес S3 файла. Существует множество библиотек на разных языках, которые могут создавать эти URL-адреса.

3 - Пользователь загружает файл непосредственно из S3, без необходимости проходить через ваш экземпляр EC2. Это экономит вашу пропускную способность и время и, вероятно, дает пользователю самую быструю загрузку.

Это показывает URL, но, вероятно, все в порядке. Там нет проблем, если пользователь сохраняет URL-адрес, потому что он не будет работать после истечения срока действия, установленного на нем. Для моего обслуживания я установил это время на 5 минут. Поскольку это цифровая подпись, пользователь не может изменить время истечения срока действия в URL-адресе без аннулирования подписи.

Ответ 3

Использование S3 - лучший вариант для этого использования. Он масштабируется лучше и будет проще. Почему вы обеспокоены тем, что он медленный? Передачи между EC2 и S3 довольно быстро.

Ответ 4

Некоторые соображения:

Объем затрат EBS в несколько раз выше, чем у S3.
Ограничения на размер тома EBS составляют 16 ТБ, поэтому это не должно быть проблемой. Однако объемы этого размера очень дороги.
Убедитесь, что ваше ведро расположено в том же регионе, что и экземпляры EC2.
Используйте конечные точки VPC для связи с S3. Это намного быстрее.
Убедитесь, что ваш тип экземпляра EC2 имеет требуемую пропускную способность сети. Скорость процессора и сети увеличивается с размером экземпляра.

Я бы сохранил все на S3, загрузив файлы по мере необходимости, чтобы застегнуть их в пакет. Затем загрузите zip на S3 и доставьте пользователю S3 Signed URL для загрузки с S3.

Вы можете разрешить загрузке пользователя из своего экземпляра EC2, но у многих пользователей возникают проблемы с ошибкой, проблемы с повторной попыткой, медленная пропускная способность и т.д. Если zip файлы являются небольшими (менее 100 МБ), доставляются локально, иначе загружаются на S3 и пусть S3 справится с проблемами загрузки пользователей.

Другой вариант - создать функцию Lambda, которая создает zip файл и сохраняет на S3. Теперь вам не нужно беспокоиться о пропускной способности сети или масштабировании. Функция Lambda может либо вернуть вам URL S3, который вы доставляете в браузер, либо Lambda может отправить клиенту ссылку. Посмотрите на SES для этого. Примечание. Файловая система Lambda имеет только 512 МБ пространства, а память может быть выделена до 1,5 ГБ. Если вы создаете zip файлы, превышающие это, Lambda не будет работать (в это время). Однако вы можете создать несколько zip файлов (part1, part2,...)