Какой сервис Amazon я должен использовать для обслуживания объединенных файлов из корзины S3?

Question

Мне нужен HTTP-сервис, обслуживающий файлы (1-10 ГБ) в результате слияния некоторых небольших файлов в корзину S3. Такой лог c довольно прост в реализации, но мне нужна очень высокая масштабируемость, поэтому я бы предпочел поместить его в облако. Какой сервис Amazon будет наиболее подходящим для этого конкретного случая? Должен ли я использовать AWS лямбда для этого?

Answer 1

Объединение файлов

Можно объединить файлы Amazon S3 с помощью UploadPartCopy :

Загрузка детали путем копирования данные из существующего объекта в качестве источника данных.

Однако минимально допустимый размер детали для многоэтапной загрузки составляет 5 МБ.

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

Потоковые файлы

В качестве альтернативы, а не создания новых объекты в Amazon S3, ваша конечная точка может просто читать каждый файл по очереди и передавать содержимое обратно запрашивающей стороне. Это можно сделать через API Gateway и AWS Lambda . Ваш AWS лямбда-код будет читать каждый объект из S3 и возвращать содержимое до тех пор, пока не будет обработан последний объект.

Answer 2

Во-первых, позвольте мне уточнить вашу цель: вы хотите иметь конечную точку, скажем https://my.example.com/retrieve, которая читает некоторый набор файлов из S3 и объединяет их (скажем, в виде ZIP)?

Если да, поддерживает ли какой-либо язык / каркас, который вы используете, кодирование чанков для ответов?

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

Однако, исходя из ваших требований к выводу 1-10 ГБ, Lambda не будет работать, поскольку имеет предел 6 МБ для полезных нагрузок ответа (и iir c, который следует за кодировкой Base64).

Таким образом, в мире AWS, который оставляет вас с постоянно работающим сервером, либо EC2, либо ECS / EKS. .

Если вы не выполняете какие-либо дополнительные преобразования по пути, для этого не потребуется много ресурсов ЦП, но если вы ожидаете большой трафик c, это потребует большой пропускной способности сети. Что для меня говорит, что вы хотите иметь относительно большое количество маленьких sh вычислительных блоков. Всегда оставляйте базовое число из них работоспособным и масштабируйте в зависимости от пропускной способности сети.

К сожалению, экземпляры smalli sh EC2 в целом имеют меньшую пропускную способность , хотя семейство a1, похоже, быть исключением из этого. И Fargate не публикует sh спецификации пропускной способности.

Тем не менее, я бы, вероятно, работал на ECS с Fargate из-за более простой модели развертывания.

Осторожно: Ваша самая большая цена с этой архитектурой почти наверняка будет передача данных. И если вы используете NAT, вы будете не только платить за передачу данных, но и ограничивать пропускную способность. Я бы по крайней мере рассмотрел запуск в publi c su bnet (с назначенными publi c IP).

Answer 3

К сожалению, вы не можете добиться этого с помощью лямбды, поскольку она предлагает только 512 МБ для хранения, и вы не можете подключать тома. Вам понадобится EBS или EFS для загрузки и обработки данных. Поскольку вам нужна масштабируемость, я бы рекомендовал Fargate + EFS. Простые экземпляры EC2 вполне подойдут, но вы можете потерять немного денег, потому что может быть сложно предоставить правильную сумму для ваших нужд, и в большинстве случаев она сверхобеспечена.

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