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

Аватар пользователя 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, сначала показалось, что коэффициент кэширования пошел вверх, оказалась случайная флуктуация, сейчас даже ниже, чем неделю назад. Ну что ж, нет так нет.

Аватар пользователя bsyomov bsyomov 23 марта в 10:55
1


Вот довольно похожий кейс, только с куда большим трафиком (60ТB в месяц), и немногим большим суммарным объёмом(до 40GB). Тоже бесплатный аккаунт на CF.

Так что продолжаю настаивать, что что-то было совсем не так у вас настроено.

В данном случае, статика в одной папке, и использовано одно Page rule, для включения принудительного кеширования и установки максимального TTL на edge серверах, для соответствующего /url/*.

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

bsyomov wrote: только с куда большим трафиком (60ТB в месяц)

Вот это принципиально. С таким трафиком уже даже неважно, насколько он географически распределен. А мой трафик практически равномерно размазан по глобусу. Вот тут обсудили и вроде как нашли причину:
https://community.cloudflare.com/t/why-is-my-percent-cached-so-low/251019

bsyomov wrote:продолжаю настаивать, что что-то было совсем не так у вас настроено

Настаивать, что "что-то не так" несложно. Сложнее указать что именно, и как сделать "так" Wink
CF у меня пока не отключен, и я открыт для экспериментов.

Аватар пользователя bsyomov bsyomov 23 марта в 11:16

То, что обсуждалось в том топике я выше писал уже, но чтобы это было так, должно бы быть уж очень равномерное распределение запросов по всем картинкам, и это уж очень мало вероятный сценарий для веб сайта. И 10% конечно очень плохой, и мало вероятный результат.
Впрочем, это же можно проверить если вести статистику запросов.

Чтобы указать на то, что именно не так, надо заняться анализом. Посмотреть на страницы, посмотреть на заголовки ответов. Точно-ли вообще всё то, что надо, пытается хотя бы закешироваться? И.т.п. Это время, которое я всё же не готов вот так просто потратить. А вот поделиться опытом - пожалуйста.

P.S. То, что там писали о оптимизации изображений, очень правильная мысль, кстати. Это конечно надо сделать вне зависимости от CDN. Это и трафик уменьшить может, и размер хранилища, и пользователям лучше.

Аватар пользователя marassa marassa 23 марта в 11:43

bsyomov wrote: должно бы быть уж очень равномерное распределение запросов по всем картинкам

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

bsyomov wrote: это же можно проверить если вести статистику запросов

Логи сервера имеются, что именно нужно проверить? Тут достаточно нетривиальный анализ нужен, в логе за январь (до включения CF) около миллиона записей.

bsyomov wrote: То, что там писали о оптимизации изображений, очень правильная мысль, кстати

Да я не спорю, я этим занялся уже, сделал интересные открытия. У меня styled-картинки занимают примерно треть места на диске от всех картинок, две трети - full-screen оригиналы. Исходя из этого я раньше оптимизировал только full-screen картинки в соответствии с pagespeed insights. При этом я давно и специально переключился на ImageMagick toolkit чтобы сохранялся EXIF, из которого я извлекаю дату съёмки при загрузке фото. Так вот, при анализе логов выяснились две интересные вещи:
1. Доля styled-картинок в трафике заметно больше, чем на диске (хотя все равно меньше чем трафик оригиналов).
2. EXIF занимает несуразно большое место в маленьких styled-картинках, причем там-то он точно не нужен. Вычистил EXIF из всех styled картинок, освободил 2ГБ из 6.5.
Из оригиналов EXIF пока не решился вычищать, но и так очевидно, что в процентном отношении огромной экономии не будет.

Аватар пользователя bsyomov bsyomov 23 марта в 13:35

marassa wrote: Логи сервера имеются, что именно нужно проверить? Тут достаточно нетривиальный анализ нужен, в логе за январь (до включения CF) около миллиона записей.

Это не много совсем, на самом деле. Smile Для анализа есть разные анализаторы логов. Надо смотреть запросы в разрезе по url.

Аватар пользователя marassa marassa 23 марта в 13:52

bsyomov wrote: Это не много совсем, на самом деле. Для анализа есть разные анализаторы логов

Для экселя многовато, awstats от провайдера статистику по картинкам не даёт, больше ничего нет под рукой Wink
Посоветуете годный анализатор под винду, чтоб не тратить полдня на гуглоисследования, пробы и ошибки?

Аватар пользователя marassa marassa 23 марта в 21:11

В общем, проанализировал - какая-то вот такая загогулина получается (в каждой строке суммарный трафик картинок, скачанных указанное количество раз за месяц):

Hits    Traffic, kB        %%
1       4 458 853        8,1%
2       5 770 485       10,5%
3       5 574 335       10,1%
4       4 860 062        8,8%
5       4 045 931        7,3%
6       3 149 902        5,7%
7       2 696 089        4,9%
8       2 143 839        3,9%
9       1 860 047        3,4%
10      1 783 835        3,2%
11      1 495 179        2,7%
12      1 250 637        2,3%
13      1 185 654        2,2%
14      1 005 493        1,8%
15        790 324        1,4%
16        773 808        1,4%
17        668 413        1,2%
18        501 254        0,9%
19        422 164        0,8%
20-49   5 401 784        9,8%
50-99   1 831 102        3,3%
>=100   3 437 661        6,2%
Total   55 106 851      100,0%

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