Какой подход выбрать для горизонтального масштабирования?
Подскажите, как правильно масштабировать проект.
У меня в голове идеальная картина выглядит так:
Несколько одинаковых серверов, которые через балансировщик получают пользовательский трафик.
Например, 5 серверов, каждый сервер - это копия других серверов, то есть они одинаковые, запросы между ними распределяются равномерно. Если один из них падает, то система продолжает работать без него.
Почитав разные статьи я пришел к выводу, что тут есть несколько проблем:
1) Синхронизация данных, если это репликация, то могут быть задержки. Они могут быть незначительные, несколько сотен миллисекунд, но если у пользователя один запрос ушел на сервер, где есть данные, а второй на сервер, на котором нет данных, то получится каша.
2) Выходом из первой ситуации может быть одновременная запись на все сервера. То есть бэкэнд пишет сразу во все базы. Тут проблемой становится задержка, потому что во-первых, время будет расти с ростом количества серверов, если мы решим докупить еще 10 серверов, то запись на все сервера увеличиться. Во-вторых, если сервера расположены в разных дата центрах, то задержка еще более ощутима.
Я в тупике, это ведь стандартная ситуация, все масштабируются горизонтально, но внятного руководства я так и не нашел.
Мне видиться вариант с горизонтальным масштабированием идеальным, потому что во-первых, можно бесконечно докупать сервера и увеличивать мощности, во-вторых, сервера находятся в разных дата центрах, может сломаться целый дата центр, а система продолжит работать. У меня нет опыта в администрировании, подскажите как правильно масштабироваться. PS. Вы будете спрашивать в какие ресурсы заканчиваются на сервере. В основном диск и немного процессор, но тут еще одна проблема, хотелось бы, чтобы сервера находились в разных дата центрах, потому что, например, Hetzner часто падает и это затрагивает много серверов.
Проблем гораздо больше.
1. Сессия. Отказаться от нее или хранить ее в БД и синхронизировать на все сервера.
2. Балансировщик, который должен знать, какой из серверов насколько доступен и регулярно обновлять эту информацию.
3. Сам балансировщик - узкое место, точка отказа
4. master-master репликация БД
Boris Korobkov,
1. Сессий нет, у нас авторизация на токенах, которые хранятся в базе.
2, 3. По поводу балансировщиков, их ведь тоже может быть несколько? У амазона есть health check, который проверяет доступность сайта, что если завести два балансировщика и с помощью амазон проверять их доступность и просто направрять пользователей на доступный?
4. Да, об этом я писал в вопросе.
Ну вот вы пишете об узких местах, то есть горизонтальное масштабирование - это довольно нетривиальная задача, получается? Везде пишут о недостатках того или иного метода, но как работают крупные сервисы? Это ведь первое, что приходит в голову, докупить железа.
WebDev, да, горизонтальное масштабирование - достаточно сложная и дорогая операция со множеством проблем. Крупным сайтам деваться некуда.
Если у вас нет опыта системного администрирования - лучше нанять специалиста и вместе с ним обсуждать различные варианты, чем вы готовы пожертвовать ради экономии денег на всю инфраструктуру.
Если нужно просто подстраховаться на случай падений в Hetzner, возможно, подойдет бюджетный вариант типа запасного сервера, master-slave репликации и смены IP в случае проблем у первого сервера.
У вас тут просто два вопроса в одном - fault-tolerance и нагрузка. и хотя эти проблемы могут решаться сходными методами - резервированием и масштабированием, но я бы их не смешивал.
Вообще, синхронизация между БД в разных датацентрах - это весьма нетривиальная задача. И я бы пока с ней погодил.
А все остальное в принципе решаемо.
https://www.youtube.com/watch?v=pn7IT_cG8ck
Мастер-класс Алексея Рыбака из Badoo.
"Основы построения масштабируемых высоконагруженных веб-проектов"
Длинный (5 часов), но очень подробно рассказывает, что и как делать для масштабирования. Очень хороший материал.
Бессмысленный коммент.
Вот реально не хватает стаковерфлойского правила про "link-only answers". или пиши в ответе выжимку из ссылки, или пости ссылки в своем личном бложике.
при том что эта ссылка отвечает вообще на другой вопрос
FanatPHP, вообще-то не совсем так. Правила, изложенные в 12factor это то что лежит в основе подобных систем. Это не инструменты, а практики и многие решения вытекают именно из них если подумать головой дольше чем несколько секунд
Каких "подобных"? Ты вопрос вообще читал? мог бы еще ссылку на пхп мануал запостить, с такой же релевантностью. "правила синтаксиса, которые соблюдают все авторы подобных систем".
Средний
