Назад | Перейти на главную страницу

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

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

Я уже прикрепил том EBS для хранения данных MySQL. В моем веб-приложении люди могут загружать изображения, и я должен настаивать на этом.

На мой взгляд, есть две альтернативы:

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

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

Я не могу определиться и прошу совета.

Что касается затрат, то не всегда верно, что S3 будет стоить больше, чем EBS. Если у вас есть том EBS объемом 15 ГБ, вы платите за все это хранилище, независимо от того, содержит ли он 1 ГБ данных или даже еще нет данных. С S3 вы платите только за фактически сохраненные данные.

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

Вот несколько фактов, подтверждающих эту рекомендацию, а также общее сравнение EBS и S3:

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

  • S3 избыточен (я думаю, 6 копий), а EBS - нет. http://www-differencebetween.net/technology/internet/difference-between-amazon-s3-and-amazon-ebs/

  • С точки зрения производительности S3 имеет более высокую задержку, а также более высокую вариацию задержки. Задержка записи S3 также может быть выше задержки чтения. EBS, с другой стороны, имеет меньшую задержку с меньшими вариациями. Он также имеет кэширование с обратной записью для очень низкой задержки записи. http://www-cloudiquity.com/2009/03/differences-between-s3-and-ebs/

  • EBS (с 20 ГБ измененных данных) ожидаемая ежегодная частота отказов от 0,1% до 0,5%.

  • При использовании EBS вы платите 0,10 доллара США за ГБ в месяц за размер тома, независимо от того, сохранили ли вы какие-либо данные на этом томе или нет.

  • С S3 вы платите 0,15 доллара США за ГБ в месяц за моментальные снимки - ТОЛЬКО ЗА ДАННЫЕ, ДЕЙСТВИТЕЛЬНО СОХРАНЯЕМЫЕ.

  • Надежность EBS зависит от сохранения последних снимков состояния. Как описано Amazon на http://www-amazon.com/b/ref=sc_fe_c_0_201590011_1?node=689343011 , надежность EBS зависит от объема данных, хранящихся на томе, для которого не было выполнено резервное копирование на S3 с помощью моментального снимка. Поэтому для обеспечения надежности с EBS важно сохранять данные на томе, резервные копии которого хранятся на S3, путем частого создания моментальных снимков.

  • Вы будете платить 0,10 доллара за ГБ в месяц за размер тома EBS, плюс 0,15 доллара за ГБ в месяц за моментальные снимки S3. Но несколько снимков хранятся постепенно. Если у вас есть устройство со 100 ГБ данных, но с момента создания последнего моментального снимка изменилось только 5 ГБ данных, в Amazon S3 будут сохранены только 5 дополнительных ГБ данных моментального снимка. http://aws.amazon.com/ebs/

  1. Затраты: хранение изображений на S3 обойдется вам дороже, особенно если вы используете CloudFront. Плата Amazon за трафик и запросы GET / PUT, а также стоимость запросов GET / PUT могут быть даже выше, чем затраты на трафик для небольших файлов.

  2. Что безопаснее? Согласно Amazon, S3 действительно более безопасное хранилище, чем EBS, но я думаю, что это не имеет большого значения, поскольку вы можете легко периодически создавать резервные копии EBS на S3.

  3. API: S3 API довольно прост, и сохранить файл на S3 не составляет большой проблемы.

  4. Безопасность. Безопаснее размещать загруженные пользователем файлы отдельно от веб-приложения - для хакеров сложнее загрузить вредоносный контент на сервер веб-приложений.

  5. Скорость. Я не думаю, что файлы, размещенные в EBS, обслуживаемые tomcat, могут быть быстрее, чем файлы, размещенные на S3, особенно при использовании CloudFrond (CDN).

Другой вариант, который я бы порекомендовал, - это настроить отдельный легкий веб-сервер (nginx идеально подходит для таких задач) для обслуживания статического контента из EBS. Это решение будет достаточно быстрым, безопасным (при обслуживании с отдельного экземпляра) и экономичным.

Какой у вас объем трафика? Стоит ли вам использовать S3 в качестве сети доставки контента или вы будете использовать обычный S3?

Насколько сложнее для вас будет использовать S3, а не локальное хранилище на диске с EBS? Доставка статических данных может быть фактором в зависимости от вашего приложения.

Обслуживание статики из EBS может отрицательно повлиять на производительность моего веб-сервера

Ну, каков объем ваших статических данных? Если он меньше 1 ГБ, он, скорее всего, застрянет в кеше и, следовательно, вообще не повлияет на производительность.

Если у вас будет серьезный трафик и пользователи, вы можете выбрать S3, потому что он позволяет использовать его в качестве CDN. Возможно, вам придется учитывать затраты, если вы ожидаете большого количества пользовательских данных. Для S3 вы должны платить за GET / PUT, поэтому много небольших файлов будет стоить вам. Используя EBS в образе EC2, вы платите только за пропускную способность.

Я предлагаю вам проверить цифры. Также посмотрите, что проще сделать вашему аппликатино.