Однако со временем файлов становится все больше. А платить придется не только за новые данные, но за всю историю. Кроме этого, Amazon дерет деньги за GET и POST запросы, а также за трафик.
Несмотря на низкую стоимость на старте, с ростом это решение будет обходиться все дороже.
Стоит ли вообще использовать S3?
Безусловно, стоит. Особенно для небольших проектов. Несколько десятков тысяч файлов и несколько тысяч запросов в сутки. Все это обойдется в пару баксов в месяц.
Взамен не нужно будет тратить время и деньги на разные вопросы:
- Доступность. AWS будет работать всегда.
- Масштабирование. Не нужно решать сложные задачи распределения файлов между серверами.
- Нагрузка. Внезапные всплески популярности не приведут к отказу железа.
S3 отлично подойдет для хранения пользовательских файлов любых форматов — фотографий, документов и даже видео.
Когда использовать не стоит?
Однозначно не следует использовать S3 в качестве CDN. Всю статику (CSS, Javascript и иконки) лучше обслуживать самостоятельно либо использовать подходящего для этого CDN провайдера.
Сколько придется платить?
За хранение каждого терабайта файлов нужно платить около 30 баксов в месяц. Кроме этого в 90 баксов обойдется каждый терабайт трафика.
Хранилище в 1 терабайт — это около 5 млн фотографий или 50 тыс. коротких видеороликов.
Сайт со 100 тыс. просмотров в сутки, на каждой странице которого есть 5 фотографий, будет генерировать трафик в 1 терабайт в месяц.
Рост стоимости
Однако при росте количества просмотров в 10 раз, S3 трафик обойдется почти в 1 тыс. баксов в месяц.
Альтернативой такого решения станет аренда нескольких серверов с бюджетом в 300 долларов.
Гибридное решение
Существенной частью затрат при использовании S3 является именно трафик.
Хранилище и загрузка обходится сравнительно недорого.
В качестве хорошего решения имеет смысл использовать S3 только как надежное хранилище.
При этом существенное снижение в стоимости трафика можно получить используя простую схему кеширования.
Тогда загрузка файлов происходит непосредственно на Amazon S3, а отдача настраивается через собственные кеширующие сервера.
Решение на основе Varnish
Varnish — крутой сервер для HTTP кеширования. С его помощью можно настроить кеширование файлов с Amazon S3. Пример конфигурации:
backend s3 {
.host = "s3.amazonaws.com";
.port = "80";
}
sub vcl_recv {
if (req.url ~ "\.(gif|jpg|jpeg|png)$") {
unset req.http.cookie;
unset req.http.cache-control;
unset req.http.pragma;
unset req.http.expires;
unset req.http.etag;
set req.backend = s3;
set req.http.host = "my_bucket.s3.amazonaws.com";
lookup;
}
}
sub vcl_fetch {
set obj.ttl = 3w;
}
В примере используется букет my_bucket. Следует также следить за показателем hit rate. Приемлемое значение — 99%. Это значит, что 99% всех запросов будут попадать в кеш варниша и только 1% будет уходить на S3.
Дополнительные меры
Для еще большей оптимизации затрат нужно придерживаться правила — минимизировать размеры файлов. Если сохраняются фотки, можно преобразовать их в формат Webp перед сохранением на S3. Они будут занимать значительно меньше места, чем JPG. Даже без этого следует убедиться, что выбран верный формат изображений перед сохранением.
Текстовые файлы следует сжимать gzip'ом.
Другие облачные хранилища
Альтернатива есть. На S3 мир клином не сошелся, потому стоит попробовать работать и с другими облаками, например Azure или Google Cloud, особенно беря во внимание, что почти все сервисы предлагают опробовать их бесплатно.
Конспект
- Amazon S3 очень удобно использовать на старте и для небольших проектов.
- При росте популярности S3 становится дороже, чем собственное железо.
- Чтобы снизить стоимость решения необходимо снизить трафик. Для этого нужно отдавать файлы через кеширующий сервер.
- Для кеширования удобно использовать Varnish.
Комментарии (10)
Firfi
15.05.2015 19:36+3aws.amazon.com/cloudfront забыли. С s3 интеграция из коробки, запросы обходятся сильно дешевле.
golotyuk
15.05.2015 20:12От 85 до 140 USD за терабайт. Еще дороже выходит.
grossws
15.05.2015 22:37+2А что, остальные CDN бесплатные? Есть, конечно, cloudflare, но на бесплатном и дешевом полно ограничений.
TimsTims
15.05.2015 23:11+1Скажите, а что не так с cloudflare? Вполне себе неплохой CDN для частых статичных файлов.
Думается мне что связка S3+Cloudflare вполне себе ничего.grossws
15.05.2015 23:49На бесплатном приличное TTL кэша, сертификаты, подписанные cloudflare (что и плюс, и минус, требующие, чтобы клиент понимал поле SAN), HTTPS не поддерживает старый андроид и win xp.
nikitasius
17.05.2015 00:47На бесплатном приличное TTL кэша
Это же CDN. Чем вам не угодил TTL для файлов? У меня вообще стоит на нескольких серверах 10 лет. Пересчитайте еще раз для чего предлагают cloudflare использовать.
HTTPS не поддерживает старый андроид и win xp
FS нету, ECDHE нету. SSLv3 или TLS1.0? Сила науки, зачем вам XP? Если уж нужно — заставить клиентов использовать FF, так как FF использует свои криптобиблиотеки, в отличие от IE/Opera/Chrome.
На счет S3 по статье — я отказался от S3 так как дорого. Быстро, но дорого. Теперь на бесплатном cloudflare. Очень быстро и дешево.
На тему лимита у CF — в интернете есть одна публичная история, как человеку выключили CF на 3Тб в день.
Кстати, как хорошая конфетка для любителей 10 лет кешей: CF «уважает» заголовки сервера и если стоит 10 лет, то он будет хранить вашу статику 10 лет при условии что… что она запрашивается регулярно, по личной практике это раз в неделю на бесплатном тарифе, иначе их система периодически чистит старые файлы ("It is true what that we do not have a max limit of time on which we would cache, but our system will clear resources that are not accessed over a certain amount of time in an effort to save space").
mikhailov
17.05.2015 18:18CloudFront создан для дистрибуции данных, но не для экономии, платишь за запрос O(n)
mikhailov
17.05.2015 01:31CloudFlare использует proxy_pass и proxy_cache с инвалидацией по тайм-ауту и временем доступа. Это удобно, если вашим клиентам всё равно как выглядит URL, не важно где физически находятся раздающие сервера и нет необходимости проверять сессию перед доступом к проксированным ресурсам.
Для некоторых B2B проектов решение с Varnish при условии, что EC2 в том же регионе — идеальное, полный контроль над кэшированием при затратах $10/месяц. Отказоустойчивость достигается дублированием, про проксировании S3 ресурсов нет никакой сложной логики. В целом это решение — единственное для проектов с нестандартными требованиями.
В качестве альтернативы посмотрите наше решение Nginx S3 proxy, которое выполняет ту же задачу. В нашем случае это помогло справится с превышением лимита доступа к S3 ресурсам: 100 запросов/сек на запись/чтение. Есть мнение, что S3 шардирует лимит по маске префикса файлов, но это не всегда так. Решение описано здесь coderwall.com/p/rlguog/nginx-as-proxy-for-amazon-s3-public-private-files целесообразность вы его понимаете, так как оно решает ту же главную задачу: S3 как сторадж, Nginx на отдачу.
nfedyk
github.com/danilop/yas3fs очень наплохо с такой задачей справляется.