Pull to refresh

Comments 38

В полное говно превратился этот Badoo из-за неуёмной алчности владельцев. Искренне надеюсь, что загнётся вместе с остальными подобными сервисами, где главенствует безграничная алчность, а не желание помочь людям найти друг друга.
О Боже, я точно на профессиональном ресурсе?
Я тоже задавал себе этот вопрос некоторое время назад. Увы, меня загнали «в минуса» за убеждения и теперь я подготовленную статью даже в черновики сохранить не могу. Остаётся говорить что думаю и плевать на «игры» в «саморегулируемую систему», как называет весь этот цирк администрация.
Ну, на мой взгляд, правильно загнали.

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

Моя мечта — привести на HighLoad++ разработчиков порносайтов. Потому что у них дикая нагрузка и они обкатывают все новейшие технологии. Если получится, то это будет подарок сообществу, а вы меня обвините в том, что я этику нарушаю и порнографию распространяю.
Накипело просто, не обижайтесь.
Почему так сложно?
Чем не устроило решение вида:
ZFS->Glusterfs->lighttpd/nginx->Varnish

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

Грубо говоря, и в современной и в той архитектуре, которая эволюционирует 10 лет будет
— Слой хранения, основные требования к которому это надежность и резервирование. Хорошее время ответа и throughput на чтение при больших объемах данных тут физически невозможен.
— И слой отдачи (читай — кэш), для которого в приоритете быстрое конкурентное чтение горячего датасета.
— Также надо где-то исполнять специфическую продуктовую логику (вроде шифрованных урлов или динамического ресайза/модификации картинок)

Их все нужно уметь без особых проблем масштабировать, зная потенциальные риски и трудности.

Я рассказываю о том, как организована каждая часть инфраструктуры у нас, объясняю почему был сделан тот или иной выбор, но каждый раз акцентирую внимание на том, что в последние годы появилось много классных и современных альтернатив вроде относительно стабильных и широко распространенных стораджей (а-ля ceph, glusterFS, minio) и облачных сервисов для хранения / отдачи больших объемов данных (на видео это хорошо заметно).

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

Важнее скорость разработки и простота поддержки? Берите готовые коробочные / облачные решения (сейчас правда есть крутые, но это всегда blackbox для вас и минимум гарантий).
Важнее стабильность, предсказуемость и контроль? Можете попробовать реализовать эти части самостоятельно — я рассказал, как это сделали мы и почему.

Мы тоже много экспериментируем с более современными сторонними продуктами — используем ceph + s3 api для новых/экспериментальных проектов и посматриваем на minio, но в продакшене его пока нет.
А в ключевом для сервиса функционале сидим на самодельной проверенной годами схеме и особого смысла куда-то переезжать не видим.
Спасибо, за развернутый комментарий.
Спасибо вам за доклад, очень круто!

Читал, и всё думал, где ceph. А оказывается — есть :)
Хороший доклад! Это было актуально лет 10 назад. Но ясное дело текущие технологии никто сюда выкладывать не будет из-за соглашений о конфиденциальности.
ответил в соседней ветке, зря вы думаете что мы что-то утаиваем — конечная версия описанной схемы и сейчас в таком виде работает на продакшене и хорошо справляется с достаточно большой нагрузкой — мы просто доставляем железо и вносим мелкие правки/багфиксы
Интересный доклад, спасибо. Скажите, пожалуйста, Elliptics от Яндекса не щупали?
Здравствуйте, щупали, и он даже выглядел вполне привлекательно, но показался слишком сильно «внутренним проектом яндекса» — велик риск оказаться без поддержки и большого комьюнити по сравнению с более широко распространенными вещами (типа ceph), а из более хипстерских сейчас привлекательным выглядит minio (говорил с их инженерами на gophercon в этом году — они прямо смотри заинтересовать, хотя какого-то целостного мнения еще не получилось сформировать — почти нет опыта эксплуатации)
bo0rsh201 а можно подробней о том, как вы используете lua в nginx? Что используете для манипуляции с картинками? Храните ли модифицированные изображения только в кеше или отправляете обратно в сторедж?
конкретно для манипуляций над картинками мы используем отдельный модуль, написаный на Си. мой коллега — автор этого модуля отвечал по поводу его внутренностей тут.
lua хоть и хорошо интегрирован, но все же не нативный для nginx и при использовании часто возникают абсолютно невероятные сюрпризы и подводные камни, мы стараемся минимизировать его количество в конфиге.
используем для 3х вещей:
— гибкий подбор параметров для ресайза (там много сложных правил) и проброс их в модуль
— логика поиска самой свежей версии фотки на паре сторадж машин
— обновление и чтение части конфигурации без reload на кэширующем слое (доступные/недоступные сторадж хосты)
github.com/openresty не используем
модифицированные изображения мы даже не кэшируем, просто изменяем при отдаче (downscale дешевый). кэшируем и храним только несколько базовых размеров, которые берем за основу.

А у вас нет защиты приватности на уровне обращений к файлам фото? Имея url приватного файла можно получить доступ к нему?

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

в первом случае url шифруется целиком и расшифровывается на nginx с помощью самодельного модуля. снаружи выглядит как
//pcache-eu1.badoocdn.com/p67/hidden?euri=Nm948rwNNukihaQzRWtMZ5dn5NH98HdQU4pJ3uAM8XbXS0imLcYYgk1OJvp2lRRT3S3DISw4G70dD9M8ga55cbrVYz2lrpZYLbAL6Pv57pStffb1Z9o3AmAWihBX2aovrIrQ3nEyhLPlv-nz5EWZ356VViVVgyy6xU5jDllinXg&id=1322701078&size=__size__&wm_size=117x117&wm_offs=21x21

во втором случае это выглядит примерно так
//pcache-pv-eu1.badoocdn.com/p92/30243/5/6/3/581405335/d1333833/t1502006733/c_lHsee02j0sw2LIp4-.7wq7mdBXEmCTs8cQmd0w.I64w/1333833023/dfs_180x180/sz___size__.jpg?t=30.1.0.00&id=1333833023
c_* это контрольная сумма, в которую зашиты параметры, закрытые от перебора, время жизни урла и несколько user specific вещей вроде ip адреса клиента.
при этом технически внутри целиком шифрованного урла тоже находится такая подпись

Подписи проверяют кеш-сервера?

да. это единственное, что доступно извне и общается с клиентом
Артем маленько не по теме. Но все же глядя на схемы возник вопрос у вас нигде не было статьи как вы менеджите свои железные сервера. Наверняка есть система по их учету, установке и диагностике.
думаю, на этот вопрос лучше сможет ответить banuchka
Спасибо. Почти тот же путь прошли только другими инструментами :)
Продолжение 8 числа в 18:00 как я понял, это же дожить надо
А с чем связана такая сложность? Вы пробовали переложить фотки в кассандру / hbase, которые предоставляют их коробки:
— избыточность данных (фактор репликации)
— доступ по ключу
— репликацию данных между датацентрами
— кэширование
— прекрасно работает на бытовом железе.
— горизонтально масштабируется
Здравствуйте! да, слой хранения вполне можно перенести в кассандру или другой распределенный сторадж и я знаю как минимум один пример использования кассандры в таком ключе. более подробно на этот вопрос я отвечал тут
Интересно. У нас не так много данных, где-то 0.5 Пб, но мы пришли к очень похожей схеме.
Пара моментов:
1. Последней каплей, после чего мы отказались от SAN — это была дорогущая (относительно) полка от IBM. Очень крутая, и тп. Одна проблема — IBM внезапно продал этот бизнес Lenovo. А те — просто прекратили поддерживать нашу линейку. И мы в глубокой… оказались, т.к расходники теперь искать — это бешеные деньги и месяц ожидания. Спасибо IBM & Lenovo! Горите в аду.

2. Второе, в схеме автора мне лично кажется ненужным MySQL. Это и точка отказа, и… да просто — зачем? Организовать очередь на небольшом входящем потоке можно элементарно на уровне ФС + симлинки/хардлинки. Хотя, возможно, там есть какие-то еще внутренние требования.
1) у нас был отдельный доклад про железо, вендоров и свои собственные полки, но к сожалению без видео www.highload.ru/2016/abstracts/2421
так что мы разделяем вашу боль :)
2) к сожалению, без внешней асинхронной очереди тут никуда. мы для этого как правило используем mysql (если нагрузка не огромная), хотя конечно можно взять и традиционный брокер.
очереди на локальной ФС честно говоря не выглядят хорошим решением, т.к. при аварии мы рискуем потерять еще и текущий changelog + технически мне это видится гораздо более сложным решением (велосипед)
А, я пропустил, что мускуль у вас еще и вынесен отдельно. Надеюсь, что он в реплике, хотя и в этом случае он не сильно меньше локальной фс является точкой отказа. Но, возможно, я просто недолюбливаю mysql? :) Я бы взял redis, там лаконичные структуры на которых легко делать удобные очереди.

да, редис тут отлично подойдет :) у нас это скорее историческое/общее решение, т.к. мы хорошо умеем готовить mysql в любых условиях и слегка недолюбливаем редис.
Редис плохо подойдет для очереди с ретраями, потому что в редисе есть только списки и нет «кучи».
Про велосипед и сложность — тоже я бы поспорил. Файлы очереди вам всё равно придется где-то держать и в решении с БД вы вынуждены следить за синхронизацией: очереди в БД и файлах на дисках. Плюс атомарность операций (удалить из БД + удалить с ФС, создать в БД + создать в ФС).
А что может быть проще каталога с файлами для загрузки в качестве очереди — с трудом представляю.
Думаю, мы по-разному себе представляем реализации.
А что может быть проще каталога с файлами для загрузки в качестве очереди — с трудом представляю.

Это могло бы быть так, если бы это была планет Маленького Принца в Сферическом Вакууме. Уверен что у любого проекта где используются очереди есть удобный фремворк для работы с ними (и они лежат в базах данных, не обязателно SQL-ных), и писать реализацию очередей на файлах для отдельной подсистемы выглядит просто как трата времени.


Думаю, мы по-разному себе представляем реализации.

А как вы будете на файлах реализовывать, допустим, откладывание событий?

> писать реализацию очередей на файлах для отдельной подсистемы выглядит просто как трата времени.
Погодите, вы подменяете.
Речь шла про сложность. Мой тезис — что очередь на уровне ФС, если её фич достаточно, в реализации очень проста, точно проще, чем связка с СУБД.
Если проект уже существует и там уже куча очередей, то, конечно, нет смысла делать отдельный механизм.

> А как вы будете на файлах реализовывать, допустим, откладывание событий?
Мне кажется мы обсуждаем достаточно абстрактный уровень. Если вы спрашиваете решение, то сформулируйте задачу более подробно, пожалуйста. А то я снова что-то предложу, а вы потом скажете, что — хе хей, ну это же трата времени, когда вот у нас уже всё есть готовое =)
Требования к очереди:

1. Возможность иметь много (миллионы) элементов в очереди
2. Возможность многопоточного разгребания, желательно с возможностью регулировать количество потоков «на лету»
3. Репликация для отказоустойчивости
4. Возможность откладывать события на какое-то время, у каждого события время может быть своим (нужно для возможности ретраев, ведь если один из серверов в «паре» недоступен или «моргает», то нужно попробовать ещё раз отреплицировать фотографию через некоторое время).
Как расшифровывается SHD?
Знаю — СХД — система хранения данных.
Если не секрет, какая файловая система используется в SAN?
Это просто опечатка того, кто расшифровывал, там таких ляпов несколько ещё есть, насколько я видел :-)
Polyceph -> polyserv
Uport-> viewport
SHD -> СХД
У нас есть пользователи — целых 33 млн. -> 330 млн.
Sign up to leave a comment.