Должен ли я сохранять изображения на EBS или S3?

Question

Я переношу свой Java, Tomcat, сервер Mysql в AWS EC2.

У меня уже есть объем EBS для хранения данных MySql. В моем веб-приложении люди могут загружать изображения. Поэтому я должен их упорствовать. Есть две альтернативы в моем сознании:

1. Сохранение загруженных изображений в объем EBS.
2. Используйте сервис S3.

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

• EBS plus: хранение S3 стоит дороже. (0.15 $/Gb> 0,1 $/Gb)

• S3 plus: Статическая статистика от EBS может повлиять на производительность моего веб-сервера отрицательно. Это правда? Отражает ли обслуживание изображений на производительности сервера? Для S3 мой сервер не будет нести ответственность за обслуживание статики.

• S3 plus: Служебная статика от EBS может привести к стоимости ввода-вывода, возможно, она будет незначительной.

• EBS plus: говорят, что EBS быстрее.

• S3 plus: Люди говорят, что S3 более безопасен для настойчивости.

• EBS plus: нет необходимости изучать API, прямо сохранить фотографии в объеме EBS.

А именно, я не могу решить, будем рады, если вы поведете.

Спасибо

Answer 1

В настоящее время я использую S3 для проекта, и он работает очень хорошо.

EBS означает, что вам необходимо управлять томом + машины, чтобы подключить его. Вам нужно добавить пространство, поскольку оно заполняется и выполняет резервное копирование (не говоря о том, что вы не должны создавать резервные копии своих данных S3, просто это не так критично).

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

Я рекомендую S3: он установлен и забыт. Любое количество машин может выполнять параллельную загрузку, и вам не нужно уведомлять другие компьютеры о загрузке.

Кроме того, вы можете использовать Amazon Cloudfront в качестве дешевого CDN перед изображениями вместо прямой загрузки с S3.

Answer 2

Вы уже указали преимущества и недостатки обоих.

Если вы планируете хранить терабайты изображений, требования к хранению увеличиваются изо дня в день, S3, вероятно, будет вашим лучшим выбором, поскольку он создан специально для таких ситуаций. Вы получаете неограниченное пространство для хранения, не беспокоясь о sharding your data над многими EBS томами.

Периодическая стоимость S3 заключается в том, что она на 50% дороже EBS. Вам также придется изучить API и реализовать его в своем приложении, но это разовый расход, который, я думаю, вы должны быть в состоянии очень быстро поглотить.

Answer 3

Сравнение цен не совсем верно: Плата за S3 составляет 0,14 долл. США за ГБ USED, в то время как плата за EBS составляет 0,10 долл. США за ГБ ПРЕДОСТАВЛЯЕМОЕ (размер вашего объема EBS), независимо от того, используете вы это или нет. В результате S3 может быть или не быть дешевле EBS.

Answer 4

Ожидаете ли вы, что изображения длится бесконечно?

Часто задаваемые вопросы по Amazon EBS довольно четкие; годовой показатель отказов не «практически равен нулю»; они дают от 0,1% до 0,5%. Это лучше, чем диск под вашим столом, но для этого потребуется какая-то резервная копия.

Answer 5

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

P1) Храните Исходное изображение файл в S3 Стандартный вариант

P2) хранят воспроизводимые образы, как пальцы и т.д. в S3 Уменьшенный вариант Redundancy (РРП), чтобы сократить расходы

P3) Мета данные об изображениях, включая URL S3 могут быть сохранены в Amazon RDS или Amazon DynamoDB в зависимости от сложности запроса. Запросите записи из Amazon RDS. Если ваш запрос является сложным, также распространена практика хранения метаданных в Amazon CloudSearch или Apache Solr.

P4) Предоставьте большие пальцы пользователям с низкой задержкой, используя Amazon CloudFront.

P5) Queue Вашего преобразования изображения либо через SQS или RabbitMQ на Amazon EC2

P6) Если вы планируете использовать EBS, то они не являются масштабируемым с EC2. Таким образом, вы можете использовать GlusterFS в качестве общего пула хранения для всех ваших изображений. Несколько Amazon EC2 в режиме Auto Scaled могут все еще подключаться к нему и получать доступ/записывать изображения.