Как администрируют сайты картинок?

Question

[grabbee]

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

Как этот массив файлов обслуживают? S3 дико дорого.
Их же как-то резервируют. Дублируют. А что с отказом сервера делать?

Comments

[monday_suicide]

Почти первый линк в гугле

[grabbee]

monday_suicide, конкретно здесь не об этом. Там про обычный сайт. Голопом по всему. Там вообще про масштабирование.

[monday_suicide]

grabbee, а что, есть разница между обычным сайтом, и сайтом с большим кол-вом картинок?) Главное суть же уловить, и идти дальше гуглить

[grabbee]

monday_suicide, масштабирование подразумевает распределение нагрузки. Можно один сервер побольше взять или несколько поменьше. Обычная практика. Мне больше интересно администрирование и софт для этого используемый. Может распределенные ФС кто использует. И какие. Кластер распределенного хранилища. Это вообще не тоже самое что масштабирование вверх или в ширь. Это глубже.

Answer 1

[Иван Шумов]

Как раз таки S3. Надо понимать что кроме s3 задействуется cdn, а для старых картинок есть lifecycle policy по которому со временем они переводятся на более дешевое хранилище за счет крепкого обращения, а потом так и совсем удаляются

Comments

[grabbee]

Как посчитать бюджет? Например

1. 100GB картинок
   
2. 1000GB картинок
   

Посетителей 100.000 в сутки, просмотров на посетителя 50.
На одной странице 50 картинок. Одна картинка 500KB

100.000 * 50 * 50 * 500 - 125TB трафика в сутки
Картинки по принципу "пены". На главной только новые и хорошие.

Я не знаю как это высчитать. Из моих прикидок никакой рекламы не хватит чтобы это дело окупить.

[ky0]

grabbee, что это за страница такая, с 50 картинками по 500 КБ? Лента с воллпейперами, что ли? Так делайте превьюшки.

S3 действительно дорого получится в вашем случае. Просто несколько серверов с ёмкими дисками обойдутся дешевле. Синхронизация и бэкапы - вопрос обширный и дискуссионный, но в целом - не рокет саенс.

[Иван Шумов]

grabbee, такие проекты и невозможно оплатить рекламой. Реклама вообще не способна оплатить ни один проект)

[grabbee]

ky0, вы на джой и на пекабу никогда не заходили? Ссылки наспамить?) Длиннопост на +1MB на картинку самое обычное дело. Я взял среднее значение для простоты расчета

Иван Шумов, очень интересно. На пожертвования что-ли? Когда у нас пожертвования были выгоднее рекламы? Развлекательные сайты только этим и живут.

Можете условный расчет прикинуть? У меня за несколько касарей цифра вышла, даже с этим извращением что вы описали выше. Даже если всё в их CDN положить, экономия не очень...

[ky0]

grabbee, я вас понял. Да, трафика получится много - но не обязательно грузить сразу всю эту простыню, можно делать это постепенно, например с помощью lazy load`а.

С задачей раздачи относительно небольшого количества свежих картинок хорошо справляются CDNы. Если не хочется связываться с Клаудфлэром и тому подобными, возможен более кондовый вариант с покупкой пары десятков самых простецких VPSок у разных провайдеров (устанавливаем на них нгинкс с кэшированием и делаем по ним балансировку запросов к картинкам), до достижения необходимой пропускной способности. Денег за трафик они обычно не берут.

[Иван Шумов]

grabbee, я говорил об обычной рекламе в виде баннерокрутилок и тому подобной фигни. Такие же ресурсы как Пикабу берут за рекламу денег как крыло от боинга из-за нереальной посещаемости. В таких случаях это работает, да. Но не сказал бы что это сильно выгодно)

Условный расчёт не скажу по тому что надо сидеть и много циферок сравнивать и рычажков крутить) за это денег просят хороших)

[grabbee]

ky0,

например с помощью lazy load`а.

Никак не поможет. Они же скроллить будут всё равно :)

до достижения необходимой пропускной способности

Круто, только вопрос не об этом)) Я скорее всего не так спросил. Меня больше само администрирование интересует. А не нагрузки. Вот есть у меня 5ТБ картинок. Раз, и сервер умер. Мне просто на запуск с нуля сутки понадобятся. А вы говорите про несколько серверов. Значит неделю буду восстанавливать, например)))

[Иван Шумов]

grabbee,

Мне просто на запуск с нуля сутки понадобятся. А вы говорите про несколько серверов. Значит неделю буду восстанавливать, например)))

В современном мире все автоматизировано. Приложения рассованы по контейнерам и стоят за балансировщиком, хранилища на отдельных сетевых дисках, с репликацией и бэкапами, все разворачивается через такие вещи как k8s/terraform и много миллионов других инструментов. А можно вообще без серверов сделать, используя serverless подходы, например

[grabbee]

много миллионов других инструментов

Один назвали, осталось не так много)) Продолжайте :)
Хотя нет же. Вы только контейнеры в пример привели. А в контейнерах хранить ничего нельзя....
Серверлесс дорого. Сетевые диски. Хз, это кажется датацентр арендовать нужно, а не впски

[ky0]

grabbee,

Меня больше само администрирование интересует. А не нагрузки. Вот есть у меня 5ТБ картинок. Раз, и сервер умер. Мне просто на запуск с нуля сутки понадобятся.

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

[Иван Шумов]

grabbee,

Один назвали

k8s, terraform и контейнеры это уже 3, а если считать виды контейнеров то все 10, а если посчитать экосистему из этих трех компонент то сотни дополнительных инструментов для мониторинга, билда, деплоя и все их называть не имеет смысла. они учатся по ходу.

А в контейнерах хранить ничего нельзя.

Контейнеры для приложений. Сегодня 99.9% приложений stateless, им не надо ничего хранить. Хранилища отдельно идут.

Серверлесс дорого

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

Хз, это кажется датацентр арендовать нужно

TCO поддержки датацентра настолько велико что использовать on-demand виртуалки можно считать что бесплатное развлечение) Именно так они, в общем-то и появились.Ну и когда кажется - креститься надо, как говорили наши бабушки и деды

[grabbee]

Иван Шумов, ky0, вы здается байки травите. Условности в вопросе описаны и походу тоже. Тут применимо 2-3 подхода или инструмента которыми все пользуются. Вот пару лет назад все CEPH форсили - мол смотрите какая крутая весчь. Сейчас я уже про него так много не слышу нигде. И поднять на нем кластер ещё тот гемор...

То что хранилища отдельно, в этом и суть вопроса. Как отдельно? Что делать нужно и что использовать. Вы же сгрузили всё на контейнеры которые или не используются в задаче вообще, или уж очень специфически, по аналогии с s3(там как я понял именно контейнеры, но уж очень извращенно)

И инструментов ну не тысячи. И даже не сотня. Там пару десятков в лучшем случае, Из них массово используются 2-3... 5

[ky0]

grabbee, попрошу не обобщать :) Я к заявлениям предыдущего оратора про модное типа серверлесса, 99.99% в контейнерах и т. д. не готов присоединиться.

Подходов действительно всего несколько, а вот вариантов реализации - масса. Можно хранить картинки где-то у себя, можно использовать для этого облако. Храня у себя, можно сделать синхронизацию между нодами средствами ОС, распределённой ФС, а можно - в рамках приложения. То же самое с кэшированием, как я уже упоминал - можно заморочиться самому или отдать на откуп CDN-сервисов.

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

А у нас, простых комментаторов с Тостера, как минимум, недостаточно информации, чтобы советовать. Даже если у кого-то и возникнет желание безвозмездно помочь.

[grabbee]

можно сделать синхронизацию между нодами средствами ОС, распределённой ФС

Нужно новый вопрос кажется создать чисто по распределенным ФС кажется. А ток и будут все в S3 посылать

Answer 2

[Sanes]

Есть холодные и горячие данные.
Для горячих используют более быстрое и дорогое хранилище, для холодных наоборот.
https://cloud.yandex.ru/prices Object Storage

Answer 3

[Andrey Shatokhin]

Ну тут есть разные способы
1. S3 и его аналоги от разных провайдеров. Вплоть до яндекса/майлру. Самый дорогой вариант, но самый простой для вас. Очень дорого за хранение и за исходящий траффик.
2. S3 + cdn. К хранилищу добавим cdn cloudflare или cdnvideo. Выбирать по цене на траффик. Можно сразу уменьшить счет за трафик от s3 раз в 100. За счет кеширования на cdn конечно.
3. Аренда серверов и сами ставим и админим какой-нибудь ceph/gluster, ну или во что сейчас люди верят. Уменьшает ценник хранения раз в 5-10.
4. Теоретически есть вариант с покупкой своего железа от вендора/ или очень дешёвого железа с постоянным запасом расходников, но я такое вообще никому не посоветую.

Стоимость в каждом варианте будет падать, НО требует больший профессионализм в администрировании. Если скил слабоват - то первый большой факап помножит все что у вас есть на ноль.

Comments

[grabbee]

ну или во что сейчас люди верят.

Вот это больше всего интересует)) Во что сейчас верят?

Answer 4

[АртемЪ]

Как администрируют сайты картинок?

А в чем проблема?

В том плане, что в отдельную папку складываются файлы картинок - JPG|GIF - и складываются туда постоянно и бесконечно долго.

Делают по разному.
Одна из самых удачных схем -
Каждый файл хэшируется и хэш файла является путем и именем файла.
Это позволяет быстро и удобно искать файлы и масштабировать.

Например файл example.jpg имеет хэш d63d0e21fdc05f618d55ef306c54af82
Следовательно на диске этот файл имеет имя d63d0e21fdc05f618d55ef306c54af82 и хранится по пути, например d /6/3/.
В небольшой БД вы храните просто соответствие имя или описание и хэш
Это позволяет как угодно масштабировать количество серверов хранения, дисков, папок, и быстро искать нужный файл на нужном устройстве, равномерно распределять файлы по местам хранения, и удобно организовывать резервирование файлов

S3 дико дорого.

S3 это сервис.
Вы платите деньги и получаете результат. Как оно там работает вас интересовать не должно, это не ваши проблемы.
А если вы не хотите платить деньги сервису - реализуете собственное хранилище.

Comments

[grabbee]

Упал сервер 3, диск поврежден - Что дальше?..

[АртемЪ]

grabbee,

Упал сервер 3, диск поврежден - Что дальше?..

Это уже вопрос резервирования.
Направляете запрос на резервный сервер.
Сколько их у вас будет этих резервных серверов и будут ли они вообще зависит от задачи и финансов. Все в ваших руках.

В простейшем случае - резервирование по дискам в пределах одного сервера. Упал сервер, упало все.
Дальше - введение резервных серверов, чтобы данные хранились как минимум на двух серверах.
Еще дальше - введение резервных датацентров, чтобы данные хранились как минимум в двух датацентрах.

[grabbee]

АртемЪ, но это же и есть администирование. Ну не ставится же задача сайт картинок запустить. В этом нет ничего сложного. Как резервировать? Как восстанавливать? Какие инструменты/ОС/ФС использовать.

[АртемЪ]

grabbee, Когда я делал (там правда не картинки, а пдф) - логика хранения, выдачи, резервирования, и бэкапа реализовывалась на простых пайтон скриптах.
ФС - да хоть ext3

[grabbee]

АртемЪ, да можно и рсинком по крону. Но это выглядит как костыли.

[АртемЪ]

grabbee, Какая разница как это выглядит?
Значение имеет справляется ли с задачами, и удобно ли использовать.