Хранение мультимедиа на отдельном специализированном хостинге

Аватар пользователя marassa marassa 23 января в 8:34

Трафик сайта стал стабильно превышать 50 ГБ в месяц, что у ра-дона сто́ит 1300 рублей. Сумма не то чтобы напрягает, но заставляет задуматься об оптимизации.
90% трафика составляют jpg-файлы, то есть по факту проходит мимо друпала. Суммарный объем jpg-файлов на сервере порядка 20-25 ГБ.
Возникла мысль проработать хранение всей этой мультимедии не на ра-доне, а на некоем отдельном хостинге, на мультимедию заточенном.
Вопрос: кто-нибудь имеет реальный опыт такого распределенного хостинга? Имеет ли смысл при моих объемах, или только геморроя нового наживу при сомнительной экономии?

Комментарии

Аватар пользователя ivnish ivnish 23 января в 8:48

У радона есть тарифы без учета трафика, а по месту на диске.

Хотя с такими условиями пора бы уже про VPS задуматься, я думаю

Аватар пользователя marassa marassa 23 января в 8:59

А там то же самое по деньгам получится, так как в 25 ГБ диска я уже не влезу, а 50 (хоть такого тарифа и нет на сайте), думаю, будет стоить примерно столько же.
VPS не хочу, ибо лавры сам-себе-сисадмина меня нисколько не прельщают. Не люблю и не умею админить линукс с нуля, меня полностью устраивает поддержка и инфраструктура ра-дона.

Аватар пользователя ivnish ivnish 23 января в 9:34

marassa wrote: думаю, будет стоить примерно столько же.

Ну тут или платить радону или переезжать на VPS, других вариантов я не вижу. Платить кому-то всё равно придется, никто ваши данные у себя бесплатно хранить не будет

Аватар пользователя dmfaas dmfaas 23 января в 10:23

Что мешает файлы перенести на амазоновский S3? Цены там довольно демократичны для хранилищ.

Аватар пользователя marassa marassa 23 января в 10:34

ivnish wrote: Платить кому-то всё равно придется, никто ваши данные у себя бесплатно хранить не будет

Само собой, просто возможно платить придётся меньше.

Аватар пользователя marassa marassa 23 января в 10:41

dmfaas wrote:
Что мешает файлы перенести на амазоновский S3? Цены там довольно демократичны для хранилищ.

Отсутствие опыта. Поэтому и спрашиваю совета у тех, кто это реально делал. Например, почему именно Amazon, а не, скажем, Google или Яндекс?
У меня крутится EC2 t2.nano на AWS, а с S3 не сталкивался пока.
Интересно какие подводные камни могут быть при хранении картинок на отличном от Друпала сервере. Насколько хорошо сам Друпал поддерживает такую конфигурацию (картинки загружают юзеры через Друпал, и для них ничего не должно измениться). Насколько легко мигрировать существующие картинки в облако, при этом не потеряв позиции в гугле.
Еще раз, интересует мнение тех, кто это реально делал, а не тех, кто что-то читал про это в интернете.

Аватар пользователя bsyomov bsyomov 23 января в 17:59
2

Эту проблему может решить CloudFlare (или какой-нибудь другой CDN). Это будет прозрачно для Drupal.
Единственный минус - лаг кеша. Но статика редко меняется, и обычно, это не проблема.

Если сайт довольно статичный, можно даже не только статику кешировать, но и страницы, получится что-то вроде boost, но на стороне cdn, для CF есть https://www.drupal.org/project/cfpurge позволяющий селективно этот кеш чистить. Если ещё работает, конечно - API СF менялся. При этом что-то меняющееся часто, можно из кеша исключить в настройках CF.

В принципе, это всё будет работать даже на бесплатном аккаунте СF, если не пытаться делать что-то сложное(ограничение кол-ва правил в конфигурации).

Ну и плюсом защита, WAF с преднастройками для Drupal, защита от DDоS намного более работоспособная чем у 99% хостеров.
А минусом иногда ложно-позитивные срабатывания защиты, и показ пользователю промежуточной страницы.

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

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

Аватар пользователя marassa marassa 23 января в 19:49

bsyomov wrote: Эту проблему может решить CloudFlare

Отличная идея, посмотрю в эту сторону.

bsyomov wrote: Единственный минус - лаг кеша. Но статика редко меняется, и обычно, это не проблема

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

bsyomov wrote: Если сайт довольно статичный, можно даже не только статику кешировать, но и страницы

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

bsyomov wrote: В принципе, это всё будет работать даже на бесплатном аккаунте СF, если не пытаться делать что-то сложное(ограничение кол-ва правил в конфигурации).

По идее если я закэшу всего две директории, это должно снизить трафик в разы.

bsyomov wrote: WAF с преднастройками для Drupal,

WAF вроде только в платном плане, а он стоит в месяц чуть больше чем я плачу Радону, так что смысл экономический теряется.
Спасибо!

Аватар пользователя bsyomov bsyomov 23 января в 22:45

marassa wrote: WAF вроде только в платном плане, а он стоит в месяц чуть больше чем я плачу Радону, так что смысл экономический теряется.
Спасибо!

Да, верно, он начиная с Pro. Давно уже не пользовался Free.

Аватар пользователя gun_dose gun_dose 24 января в 16:42
1

S3 бывает не только амазоновский. Модуль s3fs позволяет работать с любыми s3-совместимыми хранилищами. Такие хранилища есть у любого уважающего себя провайдера. Даже если законодательно надо хранить всё в какой-то определённой стране, то и там найдётся свой провайдер s3.

Почему рекомендую s3? Всё просто: де-факто это один из самых распространенных стандартов. Не проблема найти мануал. Отличная интеграция как с 7, так и с 8 версией друпала. Можно легко развернуть своё s3-хранилище на локалке, чтобы не гонять тестовый контент в облако.
У нас у одного из клиентов общий объем картинок уже пошёл на сотни гигов, мы всё это дело перетащили в s3, в итоге экономия для заказчика оказалась около 3000$ в год.

Аватар пользователя marassa marassa 24 января в 16:52

gun_dose wrote: S3 бывает не только амазоновский

S3 - это зарегистрированный трейдмарк Амазона Wink

gun_dose wrote: s3-совместимыми

Вот это другое дело Wink

gun_dose wrote: Модуль s3fs

Посмотрел. Если правильно понял, файлы картинок хранятся в облачной фс, но всё равно доступны по адресам /sites/default/files, то есть запрос все равно прилетает на друпаловский сервер, тот достает файл из облака и отдает клиенту. Я вижу удвоение трафика моего сервера вместо экономии, или что-то не так понимаю?

Аватар пользователя gun_dose gun_dose 24 января в 19:45

Нет, все урлы картинок ведут на облако. Только стили в первый раз открываются специальным роутом, а потом берутся из облака. Хотя у меня никогда не было задачи уменьшить трафик. Но думаю, очевидно, что он уменьшится. У нас же в основном экономия была в том, что сервак на 10 гигов дешевле, чем на 20, а цена хранилища значительно меньше разницы в цене серверов.

Аватар пользователя marassa marassa 24 января в 20:08

gun_dose wrote: все урлы картинок ведут на облако

Тогда потенциально интересно. Но я всё же хочу сначала попробовать с CloudFlare ибо там вообще практически ничего ставить и делать не надо, да ещё и бесплатно, прям не верится Wink

Аватар пользователя marassa marassa 29 января в 12:22
1

Подключил CloudFlare (далее CF), делюсь первыми впечатлениями.
Сразу после переключения DNS серверов на CF сайт стал недоступен - too many redirects. Выяснилось, что по умолчанию CF сам отзывается по HTTPS, а далее связывается с вашим сервером по HTTP (это у них называется SSL/TLS encryption mode: Flexible). Если на вашем сервере стоит принудительный редирект с HTTP на HTTPS (как было у меня и, я подозреваю, у многих) получается бесконечный цикл редиректов. CF советует либо убрать редирект на сервере (мне не слишком нравится это решение, так как CF приходит и уходит, и каждый раз править под него .htaccess некомильфо), либо переключить на самом CF SSL/TLS encryption mode на Full (тогда коммуникации между CF и вашим сервером тоже делаются по HTTPS). Так и сделал, заработало.
Второе и самое для меня важное: как можно было сразу догадаться, CF заменяет исходные IP-адреса посетителей на свои собственные. В результате любая аналитика, основанная на логах веб-сервера (типа awstats) накрывается медным тазом. Что с этим делать я пока не придумал. В принципе есть приблуда для Apache, но на шаред ее не поставить, нужен VPS, которого я не хочу по ряду причин.

Аватар пользователя marassa marassa 29 января в 14:43

Добавлю: если у вас в настройках веб-сервера (.htaccess etc) были специфичные отлупы/редиректы по IP посетителя, то они тоже перестанут работать.

Аватар пользователя gun_dose gun_dose 29 января в 15:22
1

Скорее всего оригинальный IP-адрес приходит каким-то специальным заголовком, вроде того, как это происходит при использовании реверс-прокси.

Аватар пользователя marassa marassa 29 января в 15:30

Именно так, но чтобы вытащить этот заголовок в лог, нужно модифицировать глобальный Apache, на что хостер конечно же не идёт.

Аватар пользователя marassa marassa 29 января в 18:49

Задача ограничения доступа по IP через .htaccess решается просто:
RewriteCond %{HTTP:X-FORWARDED-FOR} !^(xxx\.xxx\.x\.xx|yyy\.yy\.y\.yy)
Нужно иметь в виду, что значение X-FORWARDED-FOR может содержать список IP-адресов, из которых первый - оригинальный адрес клиента, а дальше адреса последовательных прокси, которых теоретически может быть сколько угодно. Но так как нам обычно интересен первый, это упрощает дело.

Аватар пользователя marassa marassa 29 января в 19:25

Еще одно наблюдение: если у вас стоит какой-нибудь автобан при попытке доступа к стрёмным путям типа payload.php, то его лучше выключить, пока он не забанил весь пул адресов CloudFlare Wink

Аватар пользователя marassa marassa 30 января в 6:07

Это если он умеет. У меня используется (использовался) Http:BL, и я не вижу чтобы он так умел.

Аватар пользователя bsyomov bsyomov 31 января в 8:12

Если он так не умеет, то он просто откровенно плохо сделан.
Правильный алгоритм - посмотреть на наличие x-forwarded-for, если не пуст достать адрес оттуда, если нет, взять REMOTE_ADDR. Большая часть сайтов за какими-нибудь reverse-proxy... Очень странно, если в такого рода модулях это не учитывается.

Аватар пользователя marassa marassa 30 января в 6:45
1

PS Оказывается есть целый модуль CloudFlare, он в числе прочего должен и IP подменять. Посмотрим.

Аватар пользователя marassa marassa 31 января в 10:55

За двое суток процент отдачи из кэша CF поднялся до 9%. Негусто, но пока наверное рано еще - кэш ведь должен заполниться. Настроил срок хранения картинок в кэше CF 1 месяц, дольше не получается, а жаль.
Удручает отсутствие простой документации для начинающих: есть миллион настроечных параметров, в описании которых я половину слов-то не понимаю, а простого и внятного описания что конкретно я должен сделать чтобы все мои картинки закэшировались навсегда - нет.

Аватар пользователя marassa marassa 2 февраля в 14:31

Поставил модуль CloudFlare, IP-адреса в логе Друпала стали подменяться на настоящие, но там от них толку особого и нет. Отсутствие реальных адресов в логах веб-сервера удручает очень.
За четверо суток клаудфлейринга процент трафика, отдаваемого из кэша... снизился до 7%, что совершенно непонятно. Из пятидесяти картинок-тамбнейлов на главной странице, которые по идее видят все, заходящие на главную страницу, закэшено менее 30 процентов. Из этих же картинок в полном размере, открываемых по клику, не закэшена ни одна.
На данный момент результат (7% экономии трафика) никак не оправдывает затраченных усилий (которые оказались не совсем нулевыми).
Продолжаю наблюдение.

Аватар пользователя marassa marassa 2 февраля в 21:50

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

Аватар пользователя marassa marassa 3 февраля в 14:18

Читал конечно же. По умолчанию max-age в заголовках стоял на две недели, поставил месяц, но и с двумя неделями должно было быть получше чем 7% за четыре дня наблюдений.

Аватар пользователя marassa marassa 3 февраля в 10:09

Пытаюсь решить проблему с логами сервера. В веб-интерфейсе самого CloudFlare никакого намека на просмотр логов (для бесплатных пользователей) нет, в поиске по сайту намеки на logs появляются только в документации для Enterprise-пользователей. Однако в разделе Apps промелькнула реклама некоего приложения LogFlare (без рекламы я бы его в жизни не нашел), которое забесплатно (до 5 млн записей в месяц) вытягивает логи из CloudFlare (получается, что по API они вполне доступны даже для бесплатных юзеров), хранит их 7 дней (за деньги можно дольше, также можно складывать в собственное хранилище Google BigQuery) и весьма удобно показывает - с поиском, фильтрацией и т.п. Только начинаю разбираться, но похоже проблему с логами сервера это решает.

Аватар пользователя bsyomov bsyomov 3 февраля в 13:50

Это не суммарный размер кеша, а максимальный размер отдельного файла. С такими лимитами сложно столкнуться, если не размещать видео какое-нибудь. Smile

Аватар пользователя gun_dose gun_dose 3 февраля в 14:00

Точно. Затупил. Но ещё там же есть про заголовки Cache-Control. И что без них по умолчанию кэшируется на 2 часа.

Аватар пользователя marassa marassa 3 февраля в 14:57

Всё чудесатее и чудесатее Wink
После запуска LogFlare процент отдачи из кэша твёрдо установился на 100%!

Очевидно, что это неправда - в самом LogFlare отчетливо видно, что большинство ответов идут с кэш-статусом MISS или DYNAMIC, HIT попадаются редко. Что я опять сделал не так? Wink

Аватар пользователя gun_dose gun_dose 3 февраля в 15:26
1

У них там квантовый компьютер по ходу, поэтому результат эксперимента зависит от наличия наблюдателя Biggrin

Аватар пользователя marassa marassa 3 февраля в 18:40

Списался с автором LogFlare - говорит, известный глюк CloudFlare, они в курсе уже более года и ничего не делают. Весь этот дашборд можно реализовать внутри LogFlare с использованием Google Data Studio, но оно уже платное, и как-то слишком заморочисто это всё...

Аватар пользователя gun_dose gun_dose 3 февраля в 21:28

А почему бы не использовать для аналитики бесплатные решения, не основанные на логах сервера?

Аватар пользователя marassa marassa 3 февраля в 22:29

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

Аватар пользователя marassa marassa 4 февраля в 9:20

Зачем знать полную и точную статистику обращений к серверу? Из любопытства, естественно.

Аватар пользователя marassa marassa 14 февраля в 12:31

Прошло две недели экспериментов с CloudFlare. Результат пока скорее отрицательный: средний процент закэшированного трафика около 10%, и явной тенденции к росту нет. Кроме того, вскрываются все новые и новые неприятные моменты: у меня на сайте через htaccess организована нехитрая защита от хотлинкинга: если мою картинку кто-то вставляет в свою страницу (домен реферера не мой и не Гугл с Яндексом), вместо искомой картинки отдается картинка с надписью, что так делать нехорошо. Сегодня заметил эту картинку на своем собственном сайте: кто-то зашёл на страницу с хотлинком, получил от моего сервера картинку с предупреждением, cf ее закэшил и теперь отдает всем Wink У cf есть своя защита от хотлинкинга, но она крайне тупая и вообще никак не настраивается: с ней на Гугле с Яндексом мои картинки тоже не будут показываться.

Аватар пользователя marassa marassa 22 февраля в 15:23

Прошло больше трёх недель. Процент закэшированного трафика около 12%. Наверное можно считать эксперимент неудавшимся и начать всё же исследовать xранение картинок в S3-совместимом хранилище. Посмотрел бегло на предложения в этом сегменте, пока импонирует Digital Ocean.

Аватар пользователя bsyomov bsyomov 22 февраля в 15:45

Что-то очень не так с настройками кеширования, если такая ситуация. Если основу трафика составляют картинки, то ситуация должна быть кардинально другой.

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

Аватар пользователя marassa marassa 22 февраля в 16:21

Сначала создал 2 page rules таких:

[мой домен]/sites/default/files/ArtefactPictures/*
Cache Level: Cache Everything, Edge Cache TTL: a month
[мой домен]/sites/default/files/styles/*
Cache Level: Cache Everything, Edge Cache TTL: a month

Месяц - это максимальное Edge Cache TTL, которое можно выставить.
После того, как в течение дней десяти это не привело ни к какому результату, решил что настройки по умолчанию (respect origin headers) ничем не хуже. Заголовки, отдаваемые сервером для картинок, сейчас такие:

cache-control: max-age=7776000
cf-cache-status: MISS
date: Mon, 22 Feb 2021 12:53:52 GMT
expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
expires: Sun, 23 May 2021 12:53:52 GMT

После включения CF процент трафика сервера, который составляют файлы jpg, ПОДНЯЛСЯ с 89% до 92% Wink

PS Обратил внимание, что в заголовке max-age не прописано в явном виде public. Откуда этот заголовок берётся вообще не очень понятно, так как в htaccess в явном виде прописывается только Expires.

Аватар пользователя marassa marassa 22 февраля в 17:49

Наверное для полной чистоты эксперимента следовало бы попробовать с Cache-control: public, max-age=xxx, но я что-то с ходу не соображу как это сделать в htaccess для картинок, при этом не поломав заголовки ресурсов, генерируемых друпалом.

Аватар пользователя marassa marassa 27 февраля в 10:11

Добавил в cache-control public, сначала показалось, что коэффициент кэширования пошел вверх, оказалась случайная флуктуация, сейчас даже ниже, чем неделю назад. Ну что ж, нет так нет.