Всем привет!
Появилась задача вынести хранение статики в Amazon S3.
По предварительным наброскам это выглядит примерно так:
Есть корзина в S3 он монтируется на сервера по s3fs. Сервера изменяют там данные. В EC2 также есть машина со смонтированной корзиной, эта машина используется для раздачи контента CDN провайдеру (а тот уже дальше раздает контент со своих площадок).
Так вот, тут всплывает несколько непонятных для меня вещей
— как в S3 реализованы блокировки? Что будет если 2 и более узла захотят поправить один и тот же файл?
— как фронтендам отдавать статику, т.е. я так понимаю они затягиваю файлики по s3fs, кэшируют в pagecache/nginx/etc и отдают клиенту?
Подскажите есть ли статьи которые описывают подобные решения, или может кто-то может поделиться собственным опытом?
P.S. пока читаю статьи из поисковой выдачи хабра по запросу «s3»
1) Почему s3fs? Используйте родное API.
2) Кто последний, тот и папа. Насколько я знаю, блокировок нет, это тупое хранилище.
3) Зачем лишнее звено в виде «pagecache/nginx/etc»? Отдавайте прямо с s3.
Автору вопроса:
кстати, если Вы пользуетесь CMS, то для многих CMS пункт 1 уже реализован.
по п. 2. Тоже не уверен про блокировки.
по п. 3. Смущают Ваши слова про CDN провайдера. Автор, Вы уверены, что Вам нужно использовать какого-то другого CDN провайдера? Во многих случаях хватит и S3 — просто скопируйте Ваш файлик в несколько корзин, в разных регионах. Или вы там стоимость оптимизируете? или у Вас CDN в России? А Вашему CDN провайдеру недостаточно будет просто отдать урл (который будет указываать прямо на файл на S3? а то по Вашей схеме, вы сперва заплатите за отправку файла с EC2 инстанса в бакет, потом из бакета на Ваш EC2 инстанс, который раздает файлы CDN провайдеру, а потом еще и за закачку этого файла с EC2 инстанса Вашему CDN провайдеру.
>> 1) Почему s3fs? Используйте родное API.
можно поподробнее в чем преимущества родного API (вообще вцелом, не сравнивая с s3fs)
>> 2) Кто последний, тот и папа. Насколько я знаю, блокировок нет, это тупое хранилище.
блин, фигово
>> 3) Зачем лишнее звено в виде «pagecache/nginx/etc»? Отдавайте прямо с s3.
не совсем понял, т.е. в страницах сразу подставлять амазоновские урлы?
>> Вы пользуетесь CMS,
нет, это не CMS но там есть команда разработчиков (интересно может есть гемы реализующие работу с S3? )
>> Вы уверены, что Вам нужно использовать какого-то другого CDN провайдера?
да, там основная аудитория Россия и ближнее зарубежье (UA, BY, KZ), сейчас все раздается через Ngenix и раздается достаточно быстро, не хотелось бы в новом решении потерять скорость отдачи.
может и фигня, если бы был уверен то не писал бы в Q&A ))
вариант с cloudfront тоже не весть какой фонтан, основные площадки раскиданы по миру непонятно какие задержки будут при отдаче (в той же статье 372ms)
В чем не фонтант то? площадка будет ближе всего к клиенту, то есть выбирается самая близкая.
Для s3 площадки теже самые, это теже самые сервера амазона, клоудфронт это просто оболочка над s3 только будет использоваться всего одна, то есть отклик для далеких клиентов будет не самый лучший в любом случае.
Вы приписали плюс клоудфронта почему то к его минусу.
если контингент только в россии — то да, будут задержка. Но как Вы (lesovsky) правильно сказали, площадки раскиданы по миру.
Это значит когда человек из пунтка А загружает статику, то cdn проверяет, есть ли она на ближайшем сервере, если нет, то загружается с другого и остается на этом в кэше. Второй человек (из этих же мест) уже получит статику из кеша из ближайшего сервера.
opium и alex_bel я знаю как работает CDN, я говорю о том что в случае именно Amazon CloudFront (чьих ДЦ нет в России) отклик для российских клиентов будет большой в отличие от использования того же Ngenix (чьих мощностей в РФ предостаточно)
>> Вы приписали плюс клоудфронта почему то к его минусу.
в данном случае минус не отдельного клаудфронта, а всего амазона вцелом (минус в том что он отсутствует в России)
Простой
