Задать вопрос

Теория: структура высоконагруженного сервиса?

Хотелось бы от хабралюдей узнать в чем мои суждения неверны. Итак, приступим-с.

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

Каковы мои размышления на тему, вопросы по каждому пункту прямо в нем:

— имеется домен (имя взято с потолка) hls.com

— у регистратора у этого домена прописано максимальное количество DNS серверов (6?), которые собственные и разбросаны по миру (имеет ли это смысл?)

— DNS зона содержит в себе максимальное количество A и AAAA записей (32?) дабы получить DNS round-robin.

— На каждом адресе, указанном в DNS, висит load-balancer (аппаратный или же софтовый? как load-balancer определяет какой сервер выдать, как он определяет самый менее нагруженный сервер?)

— Каждый load-balancer заведует неким количеством ngnix-серверов (или какой-то другой софт, если да, то какой? как ngnix может выбрать сервер самый менее нагруженный?)

— ngnix-сервер заведует неким количеством web-серверов, которые собственно дают контент.

— Каждый web-сервер имеет на машине Apache HTTP, PHP или Ruby и локальный memcached (или локальный не стоит?)

— За web-серверами стоят 2 вида баз данных — там где хранятся связи между объектами и собственно сами объекты. Все из них по условию должны уметь масштабироваться горизонтально.

— В качестве распределенного хранилища объектов используем что-то вроде memcacheDB или BigTable (или какую-то другую? т.е. у каждого объекта есть уникальный ключ, несущий в себе не только ID объекта как таковой но и информацию о типе объекта)

— В качестве распределенного хранилища связей нужно использовать какую-то БД на основе графа (правильно? если да, то какую?)

— Имеется также 2 набора memcached серверов которые кешируют запросы к обоим видам БД.


Хабралюди, мыслю ли я в правильном направлении? Что я не учел? Где почитать? Кто уже делал? Помогите просветлиться в этом.
  • Вопрос задан
  • 10327 просмотров
Подписаться 30 Сложный 5 комментариев
Пригласить эксперта
Ответы на вопрос 9
@immaculate
Программист-путешественник
В моем случае проект был написан «абы-как». Точнее, довольно грамотно, но без каких-либо мыслей о том, что пользователей станет много, и придется как-то масштабировать. Более-менее красивый код, куча таблиц, связанных друг-с-другом, то есть чуть ли не десятки JOIN'ов. Кэширование не использовалось вообще.

Все работало (и работает) на 3-х серверах: база PostgreSQL, nginx для статики, nginx с gunicorn для собственно приложения.

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

Просто описываю свой опыт. Мне кажется, мораль такая — не надо изначально все переусложнять. Надо думать о производительности, но не до фанатизма. Скорее всего, на первых порах хватит простого кода и одного-двух серверов. Вряд ли у вас сразу же получится вторая мордокнига по популярности. Напротив, те, кто думают, что их проект тут же захватит мир, чаще всего ошибаются.
Ответ написан
VBart
@VBart
У вас в вопросе написано «теория», а далее идет изложение каких-то практических фактов, причем очень отдаленно. Как уже тут было выше сказано, у вас кардинально не верный подход.

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

Никто вам не сможет помочь в данном случае по двум причинам:
1) Вы не изложили во всех технических подробностях и деталях свой проект. Про фотки, соц. сеть и прочее — этого не достаточно, нужно многостраничное подробное толковое описание всех требуемых функций, хотя бы… я уж не говорю, что хорошо бы конкретизировать и ресурсы, а так же прикинуть нагрузки.
2) Это не делается вот так вот на коленке. Толковый подробный анализ может занимать несколько месяцев, и разумеется бесплатно этим никто не будет заниматься. Есть некие теоретические основы, но они настолько теоретические, что вы их даже не изложили выше. Количество DNS-серверов, AA-записей, nginx-сы, php, устройство БД и т. д. — это все уже практическая область, которая сильно зависит от задачи. Вы можете реализовать все, что вы написали, и получить при этом громоздкое неповоротливое плохо масштабируемое приложение, требующее при этом огромных затрат. Исходя из того, что вы написали, могу лишь посоветовать не заниматься этим, ибо у вас изначально уже неверный подход и неверные представления. И любые практические советы, которые вам тут написали, или еще напишут — не более чем личный ничем не подкрепленный опыт, в решении собственных (а не ваших) задач, которые могут кардинально отличаться.

Могу лишь поделится советом, как делаю я при выборе конкретного технического решения, по шагам:
1) Сбор требований. Важно собрать и выявить как можно больше требований определяемых конкретной задачей по отношении к конкретному вопросу. Например, все требования к хранению данных такого-то сервиса.
2) Отобрать как можно большее количество вариантов с помощью которых задача в принципе решаема, а затем исключить из них те, которые заведомо не вписываются в требования, оставив только те, что наиболее им удовлетворяют (бывает так что всем требованиям в принципе невозможно удовлетворить).
3) Техническое решение — это всегда компромисс. Из оставшихся вариантов надо выбрать наиболее подходящий, зачастую для этого нужно провести сравнительное тестирование (причем именно свое собственное, на тестах так или иначе моделирующих вашу задачу). Если результат вас все равно не устроил, вероятно вам стоит пересмотреть требования или разбить задачу на несколько, по возможности. В любом случае, это отсылает вас к корректированию пункта 1.

Бонус трек 1: KISS
Бонус трек 2: One size never fits all
Ответ написан
Вы слишком заморачиваетесь… Вам на долго хватит грамотно спроектированной структуры БД и обычного кеширования.
Ответ написан
amarao
@amarao
не с того места начинаете. Начните с архитектуры приложения. Напомню, что из трёх: высокая доступность, консистентность данных и производительность можно выбрать только два.
Ответ написан
VBart
@VBart
Остальные ваши доводы, не касающиеся баз данных, тоже вызывают уйму вопросов. Во-первых, если у вас уже есть аппаратный балансировщик нагрузки, то зачем за ним еще nginx для того же самого? Зачем это нагромождение из http-серверов? Пропускание трафика через эту ёлку из веб-серверов скорости не только не добавляет, а наоборот. Почему бы nginx не балансировать сразу непосредственно application-сервера? Зачем вам апач? Вы же не хостингом торгуете, я так понял, где уже будет играть основная прелесть апача и его маленький дополнительный тормоз — .htaccess-файлы. Все ваши фразы про кэширование и про наборы — memcache также не имеют никакого смысла без четкого понимания, что кэшировать, когда и как, по какому принципу. Кэшировать бывает и даже вредно, и уж точно всегда трудоемко. К нему прибегают, во-первых, когда оно реально возможно, во-вторых, когда реально необходимо и способно что-то существенно ускорить.

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

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

Зато упомянули некую базу данных на графах, я вообще не слышал, чтобы они имели сколь угодно широкое использование в веб-проектах, в том числе и высоконагруженных. Как вы ее собираетесь использовать и масштабировать? Тоже возникает куча вопросов.
Ответ написан
Если вы изначально не правильно организируете архитектуру в будущем отгребете кучу гемора. Обычно создается проект лишь бы работал, а у появлением нагрузки масштабируют и устраняют узкие места.
Ответ написан
@Mox
Team Lead, RoR, React/React Native
Советую не морочить себе голову, а заниматься разработкой хоть чего-то, что заработает. Даже один сервер может выдержать много. Потом, когда придет время — вынесете SQL на отдельный сервак, потом поставите SQL кластер, поставите nginx c load-balance и проч, сообразите вообщем ;)
Ответ написан
@config
Как мне кажется 1 сервера с головой хватит на 25k пользователей. у нас был не самый мощный сервер и 150 000+ в день там присутствовало. конечно, зависит от проекта, в моем случае — это интернет-магазин. При бОльших нагрузках — можно вынести mysql на отдельный сервер.
если этого не хватит — достаточно легко с минимальными изменениями приложения построить схему Мастер+N slave, на мастер запись, со слейвов чтения. Этого хватит на пару миллионов посетителей точно. Если же предполагается много записывать — то масштабировать нужно с помощью шардинга. Но обо всем этом можно будет подумать и позже, когда будут посетители, которые будут генерировать прибыль.

Если же планируется лавинообразный рост посетителей и не понятно каков предел посещаемости — тогда, конечно, о масштабировании нужно позаботиться заранее.
Ответ написан
spry
@spry Автор вопроса
Кажется мне стоит почитать все — spb-borodin.livejournal.com/
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы