Comments 38
В полное говно превратился этот Badoo из-за неуёмной алчности владельцев. Искренне надеюсь, что загнётся вместе с остальными подобными сервисами, где главенствует безграничная алчность, а не желание помочь людям найти друг друга.
О Боже, я точно на профессиональном ресурсе?
Я тоже задавал себе этот вопрос некоторое время назад. Увы, меня загнали «в минуса» за убеждения и теперь я подготовленную статью даже в черновики сохранить не могу. Остаётся говорить что думаю и плевать на «игры» в «саморегулируемую систему», как называет весь этот цирк администрация.
Ну, на мой взгляд, правильно загнали.
Мы тут обсуждаем профессиональные темы, алгоритмы хранения, базы данных. Мы не говорим в указанных хабах об этике, капитализме и социализме, мы даже о бизнес-моделях редко говорим.
Моя мечта — привести на HighLoad++ разработчиков порносайтов. Потому что у них дикая нагрузка и они обкатывают все новейшие технологии. Если получится, то это будет подарок сообществу, а вы меня обвините в том, что я этику нарушаю и порнографию распространяю.
Мы тут обсуждаем профессиональные темы, алгоритмы хранения, базы данных. Мы не говорим в указанных хабах об этике, капитализме и социализме, мы даже о бизнес-моделях редко говорим.
Моя мечта — привести на HighLoad++ разработчиков порносайтов. Потому что у них дикая нагрузка и они обкатывают все новейшие технологии. Если получится, то это будет подарок сообществу, а вы меня обвините в том, что я этику нарушаю и порнографию распространяю.
Почему так сложно?
Чем не устроило решение вида:
ZFS->Glusterfs->lighttpd/nginx->Varnish
Отдельный фейспалм, это анализ файловых логов энжинкса.
Чем не устроило решение вида:
ZFS->Glusterfs->lighttpd/nginx->Varnish
Отдельный фейспалм, это анализ файловых логов энжинкса.
Призываю bo0rsh201
Здравствуйте, я не уверен, что из расшифровки это понятно, но в докладе я как раз и пытаюсь донести мысль, что наш опыт в большей степени продиктован историческими и организационными причинами + специфическими требованиями, но тем не менее он может быть полезен, потому что концептуально мало что поменялось.
Грубо говоря, и в современной и в той архитектуре, которая эволюционирует 10 лет будет
— Слой хранения, основные требования к которому это надежность и резервирование. Хорошее время ответа и throughput на чтение при больших объемах данных тут физически невозможен.
— И слой отдачи (читай — кэш), для которого в приоритете быстрое конкурентное чтение горячего датасета.
— Также надо где-то исполнять специфическую продуктовую логику (вроде шифрованных урлов или динамического ресайза/модификации картинок)
Их все нужно уметь без особых проблем масштабировать, зная потенциальные риски и трудности.
Я рассказываю о том, как организована каждая часть инфраструктуры у нас, объясняю почему был сделан тот или иной выбор, но каждый раз акцентирую внимание на том, что в последние годы появилось много классных и современных альтернатив вроде относительно стабильных и широко распространенных стораджей (а-ля ceph, glusterFS, minio) и облачных сервисов для хранения / отдачи больших объемов данных (на видео это хорошо заметно).
Также пытаюсь объяснить слушателям, что при проектировании надо в первую очередь исходить из требований конкретного проекта к каждому слою.
Важнее скорость разработки и простота поддержки? Берите готовые коробочные / облачные решения (сейчас правда есть крутые, но это всегда blackbox для вас и минимум гарантий).
Важнее стабильность, предсказуемость и контроль? Можете попробовать реализовать эти части самостоятельно — я рассказал, как это сделали мы и почему.
Мы тоже много экспериментируем с более современными сторонними продуктами — используем ceph + s3 api для новых/экспериментальных проектов и посматриваем на minio, но в продакшене его пока нет.
А в ключевом для сервиса функционале сидим на самодельной проверенной годами схеме и особого смысла куда-то переезжать не видим.
Грубо говоря, и в современной и в той архитектуре, которая эволюционирует 10 лет будет
— Слой хранения, основные требования к которому это надежность и резервирование. Хорошее время ответа и throughput на чтение при больших объемах данных тут физически невозможен.
— И слой отдачи (читай — кэш), для которого в приоритете быстрое конкурентное чтение горячего датасета.
— Также надо где-то исполнять специфическую продуктовую логику (вроде шифрованных урлов или динамического ресайза/модификации картинок)
Их все нужно уметь без особых проблем масштабировать, зная потенциальные риски и трудности.
Я рассказываю о том, как организована каждая часть инфраструктуры у нас, объясняю почему был сделан тот или иной выбор, но каждый раз акцентирую внимание на том, что в последние годы появилось много классных и современных альтернатив вроде относительно стабильных и широко распространенных стораджей (а-ля ceph, glusterFS, minio) и облачных сервисов для хранения / отдачи больших объемов данных (на видео это хорошо заметно).
Также пытаюсь объяснить слушателям, что при проектировании надо в первую очередь исходить из требований конкретного проекта к каждому слою.
Важнее скорость разработки и простота поддержки? Берите готовые коробочные / облачные решения (сейчас правда есть крутые, но это всегда blackbox для вас и минимум гарантий).
Важнее стабильность, предсказуемость и контроль? Можете попробовать реализовать эти части самостоятельно — я рассказал, как это сделали мы и почему.
Мы тоже много экспериментируем с более современными сторонними продуктами — используем ceph + s3 api для новых/экспериментальных проектов и посматриваем на minio, но в продакшене его пока нет.
А в ключевом для сервиса функционале сидим на самодельной проверенной годами схеме и особого смысла куда-то переезжать не видим.
Хороший доклад! Это было актуально лет 10 назад. Но ясное дело текущие технологии никто сюда выкладывать не будет из-за соглашений о конфиденциальности.
Интересный доклад, спасибо. Скажите, пожалуйста, Elliptics от Яндекса не щупали?
Здравствуйте, щупали, и он даже выглядел вполне привлекательно, но показался слишком сильно «внутренним проектом яндекса» — велик риск оказаться без поддержки и большого комьюнити по сравнению с более широко распространенными вещами (типа ceph), а из более хипстерских сейчас привлекательным выглядит minio (говорил с их инженерами на gophercon в этом году — они прямо смотри заинтересовать, хотя какого-то целостного мнения еще не получилось сформировать — почти нет опыта эксплуатации)
bo0rsh201 а можно подробней о том, как вы используете lua в nginx? Что используете для манипуляции с картинками? Храните ли модифицированные изображения только в кеше или отправляете обратно в сторедж?
конкретно для манипуляций над картинками мы используем отдельный модуль, написаный на Си. мой коллега — автор этого модуля отвечал по поводу его внутренностей тут.
lua хоть и хорошо интегрирован, но все же не нативный для nginx и при использовании часто возникают абсолютно невероятные сюрпризы и подводные камни, мы стараемся минимизировать его количество в конфиге.
используем для 3х вещей:
— гибкий подбор параметров для ресайза (там много сложных правил) и проброс их в модуль
— логика поиска самой свежей версии фотки на паре сторадж машин
— обновление и чтение части конфигурации без reload на кэширующем слое (доступные/недоступные сторадж хосты)
github.com/openresty не используем
модифицированные изображения мы даже не кэшируем, просто изменяем при отдаче (downscale дешевый). кэшируем и храним только несколько базовых размеров, которые берем за основу.
lua хоть и хорошо интегрирован, но все же не нативный для nginx и при использовании часто возникают абсолютно невероятные сюрпризы и подводные камни, мы стараемся минимизировать его количество в конфиге.
используем для 3х вещей:
— гибкий подбор параметров для ресайза (там много сложных правил) и проброс их в модуль
— логика поиска самой свежей версии фотки на паре сторадж машин
— обновление и чтение части конфигурации без reload на кэширующем слое (доступные/недоступные сторадж хосты)
github.com/openresty не используем
модифицированные изображения мы даже не кэшируем, просто изменяем при отдаче (downscale дешевый). кэшируем и храним только несколько базовых размеров, которые берем за основу.
А у вас нет защиты приватности на уровне обращений к файлам фото? Имея url приватного файла можно получить доступ к нему?
на уровне обращения к файлам на сторадже нет, т.к. они даже потенциально никак не доступны снаружи, да и я честно говоря не особенно представляю, как это реализовать.
в основном проблема приватности решается шифрованными урлами с коротким временем жизни для совсем приватных фото и подписанными урлами (тоже короткоживущими) для фотографий, которые хочется защитить от перебора.
в первом случае url шифруется целиком и расшифровывается на nginx с помощью самодельного модуля. снаружи выглядит как
во втором случае это выглядит примерно так
c_* это контрольная сумма, в которую зашиты параметры, закрытые от перебора, время жизни урла и несколько user specific вещей вроде ip адреса клиента.
при этом технически внутри целиком шифрованного урла тоже находится такая подпись
в основном проблема приватности решается шифрованными урлами с коротким временем жизни для совсем приватных фото и подписанными урлами (тоже короткоживущими) для фотографий, которые хочется защитить от перебора.
в первом случае 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=1333833023c_* это контрольная сумма, в которую зашиты параметры, закрытые от перебора, время жизни урла и несколько user specific вещей вроде ip адреса клиента.
при этом технически внутри целиком шифрованного урла тоже находится такая подпись
Артем маленько не по теме. Но все же глядя на схемы возник вопрос у вас нигде не было статьи как вы менеджите свои железные сервера. Наверняка есть система по их учету, установке и диагностике.
думаю, на этот вопрос лучше сможет ответить banuchka
Привет,
1. старое, но инструменты теже – events.yandex.ru/lib/talks/1123/?lipi=urn%3Ali%3Apage%3Ad_flagship3_profile_view_base%3BXnAhThbkTce%2FTd2Xe7Nmnw%3D%3D
2. habrahabr.ru/company/badoo/blog/133387/?lipi=urn%3Ali%3Apage%3Ad_flagship3_profile_view_base%3BXnAhThbkTce%2FTd2Xe7Nmnw%3D%3D
3. habrahabr.ru/company/badoo/blog/134228/?lipi=urn%3Ali%3Apage%3Ad_flagship3_profile_view_base%3BXnAhThbkTce%2FTd2Xe7Nmnw%3D%3D
4. ну и чуть обновленная информация будет в рамках доклада на HL++ 2017
1. старое, но инструменты теже – events.yandex.ru/lib/talks/1123/?lipi=urn%3Ali%3Apage%3Ad_flagship3_profile_view_base%3BXnAhThbkTce%2FTd2Xe7Nmnw%3D%3D
2. habrahabr.ru/company/badoo/blog/133387/?lipi=urn%3Ali%3Apage%3Ad_flagship3_profile_view_base%3BXnAhThbkTce%2FTd2Xe7Nmnw%3D%3D
3. habrahabr.ru/company/badoo/blog/134228/?lipi=urn%3Ali%3Apage%3Ad_flagship3_profile_view_base%3BXnAhThbkTce%2FTd2Xe7Nmnw%3D%3D
4. ну и чуть обновленная информация будет в рамках доклада на HL++ 2017
А с чем связана такая сложность? Вы пробовали переложить фотки в кассандру / hbase, которые предоставляют их коробки:
— избыточность данных (фактор репликации)
— доступ по ключу
— репликацию данных между датацентрами
— кэширование
— прекрасно работает на бытовом железе.
— горизонтально масштабируется
— избыточность данных (фактор репликации)
— доступ по ключу
— репликацию данных между датацентрами
— кэширование
— прекрасно работает на бытовом железе.
— горизонтально масштабируется
Здравствуйте! да, слой хранения вполне можно перенести в кассандру или другой распределенный сторадж и я знаю как минимум один пример использования кассандры в таком ключе. более подробно на этот вопрос я отвечал тут
Интересно. У нас не так много данных, где-то 0.5 Пб, но мы пришли к очень похожей схеме.
Пара моментов:
1. Последней каплей, после чего мы отказались от SAN — это была дорогущая (относительно) полка от IBM. Очень крутая, и тп. Одна проблема — IBM внезапно продал этот бизнес Lenovo. А те — просто прекратили поддерживать нашу линейку. И мы в глубокой… оказались, т.к расходники теперь искать — это бешеные деньги и месяц ожидания. Спасибо IBM & Lenovo! Горите в аду.
2. Второе, в схеме автора мне лично кажется ненужным MySQL. Это и точка отказа, и… да просто — зачем? Организовать очередь на небольшом входящем потоке можно элементарно на уровне ФС + симлинки/хардлинки. Хотя, возможно, там есть какие-то еще внутренние требования.
Пара моментов:
1. Последней каплей, после чего мы отказались от SAN — это была дорогущая (относительно) полка от IBM. Очень крутая, и тп. Одна проблема — IBM внезапно продал этот бизнес Lenovo. А те — просто прекратили поддерживать нашу линейку. И мы в глубокой… оказались, т.к расходники теперь искать — это бешеные деньги и месяц ожидания. Спасибо IBM & Lenovo! Горите в аду.
2. Второе, в схеме автора мне лично кажется ненужным MySQL. Это и точка отказа, и… да просто — зачем? Организовать очередь на небольшом входящем потоке можно элементарно на уровне ФС + симлинки/хардлинки. Хотя, возможно, там есть какие-то еще внутренние требования.
1) у нас был отдельный доклад про железо, вендоров и свои собственные полки, но к сожалению без видео www.highload.ru/2016/abstracts/2421
так что мы разделяем вашу боль :)
2) к сожалению, без внешней асинхронной очереди тут никуда. мы для этого как правило используем mysql (если нагрузка не огромная), хотя конечно можно взять и традиционный брокер.
очереди на локальной ФС честно говоря не выглядят хорошим решением, т.к. при аварии мы рискуем потерять еще и текущий changelog + технически мне это видится гораздо более сложным решением (велосипед)
так что мы разделяем вашу боль :)
2) к сожалению, без внешней асинхронной очереди тут никуда. мы для этого как правило используем mysql (если нагрузка не огромная), хотя конечно можно взять и традиционный брокер.
очереди на локальной ФС честно говоря не выглядят хорошим решением, т.к. при аварии мы рискуем потерять еще и текущий changelog + технически мне это видится гораздо более сложным решением (велосипед)
А, я пропустил, что мускуль у вас еще и вынесен отдельно. Надеюсь, что он в реплике, хотя и в этом случае он не сильно меньше локальной фс является точкой отказа. Но, возможно, я просто недолюбливаю mysql? :) Я бы взял redis, там лаконичные структуры на которых легко делать удобные очереди.
Про велосипед и сложность — тоже я бы поспорил. Файлы очереди вам всё равно придется где-то держать и в решении с БД вы вынуждены следить за синхронизацией: очереди в БД и файлах на дисках. Плюс атомарность операций (удалить из БД + удалить с ФС, создать в БД + создать в ФС).
А что может быть проще каталога с файлами для загрузки в качестве очереди — с трудом представляю.
Думаю, мы по-разному себе представляем реализации.
А что может быть проще каталога с файлами для загрузки в качестве очереди — с трудом представляю.
Думаю, мы по-разному себе представляем реализации.
А что может быть проще каталога с файлами для загрузки в качестве очереди — с трудом представляю.
Это могло бы быть так, если бы это была планет Маленького Принца в Сферическом Вакууме. Уверен что у любого проекта где используются очереди есть удобный фремворк для работы с ними (и они лежат в базах данных, не обязателно SQL-ных), и писать реализацию очередей на файлах для отдельной подсистемы выглядит просто как трата времени.
Думаю, мы по-разному себе представляем реализации.
А как вы будете на файлах реализовывать, допустим, откладывание событий?
> писать реализацию очередей на файлах для отдельной подсистемы выглядит просто как трата времени.
Погодите, вы подменяете.
Речь шла про сложность. Мой тезис — что очередь на уровне ФС, если её фич достаточно, в реализации очень проста, точно проще, чем связка с СУБД.
Если проект уже существует и там уже куча очередей, то, конечно, нет смысла делать отдельный механизм.
> А как вы будете на файлах реализовывать, допустим, откладывание событий?
Мне кажется мы обсуждаем достаточно абстрактный уровень. Если вы спрашиваете решение, то сформулируйте задачу более подробно, пожалуйста. А то я снова что-то предложу, а вы потом скажете, что — хе хей, ну это же трата времени, когда вот у нас уже всё есть готовое =)
Погодите, вы подменяете.
Речь шла про сложность. Мой тезис — что очередь на уровне ФС, если её фич достаточно, в реализации очень проста, точно проще, чем связка с СУБД.
Если проект уже существует и там уже куча очередей, то, конечно, нет смысла делать отдельный механизм.
> А как вы будете на файлах реализовывать, допустим, откладывание событий?
Мне кажется мы обсуждаем достаточно абстрактный уровень. Если вы спрашиваете решение, то сформулируйте задачу более подробно, пожалуйста. А то я снова что-то предложу, а вы потом скажете, что — хе хей, ну это же трата времени, когда вот у нас уже всё есть готовое =)
Требования к очереди:
1. Возможность иметь много (миллионы) элементов в очереди
2. Возможность многопоточного разгребания, желательно с возможностью регулировать количество потоков «на лету»
3. Репликация для отказоустойчивости
4. Возможность откладывать события на какое-то время, у каждого события время может быть своим (нужно для возможности ретраев, ведь если один из серверов в «паре» недоступен или «моргает», то нужно попробовать ещё раз отреплицировать фотографию через некоторое время).
1. Возможность иметь много (миллионы) элементов в очереди
2. Возможность многопоточного разгребания, желательно с возможностью регулировать количество потоков «на лету»
3. Репликация для отказоустойчивости
4. Возможность откладывать события на какое-то время, у каждого события время может быть своим (нужно для возможности ретраев, ведь если один из серверов в «паре» недоступен или «моргает», то нужно попробовать ещё раз отреплицировать фотографию через некоторое время).
Как расшифровывается SHD?
Знаю — СХД — система хранения данных.
Если не секрет, какая файловая система используется в SAN?
Знаю — СХД — система хранения данных.
Если не секрет, какая файловая система используется в SAN?
Sign up to leave a comment.
Архитектура хранения и отдачи фотографий в Badoo