Как построить инфраструктуру большого проекта?

Question

[Pavel Blum]

Всем привет!
Подскажите пожалуйста, как должна выглядеть инфраструктура проекта, с примерно 10 000 одновременных посетителей, около 500 000 - 1 000 000 пользователей? Интересует именно вопрос правильного размещения такого проекта - количество серверов, зеркала, анти ддос. Как нужно правильно размещать на продакшене такие проекты? Буду рад любому совету, заранее спасибо.

Comments

[sim3x]

Если у вас есть талант и вы можете на нулевой проект привести 10к+ человек, то вам не стоит заморачиваться с технической частью
Совсем

[Arris]

У вас интерес практический или теоретический?

Answer 1

[xmoonlight]

1. Ставим линукс и увеличиваем кол-во постоянных соединений (запуск из под root: su/sudo):

echo 2000000 > /proc/sys/fs/nr_open
ulimit -n 2000000

2. А затем, настраиваем anti-ddos.
3. Ну и создаём CDN-кластер, если планируются разные гео-зоны и/или отказоустойчивость.
4. Ставим защиту на скрипты веб-сайта: здесь

PS: В зависимости от типа и сложности: можно использовать Docker на продакшне или же только для development-среды.

Comments

[Pavel Blum]

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

[xmoonlight]

Pavel Blum, Без подготовки ТЗ по ФТ - это в принципе нереально сделать. Нужно проектировать всю инфраструктуру. (ТЗ - техническое задание, ФТ - функциональные требования)

[Pavel Blum]

xmoonlight, согласен, извиняюсь за глупый вопрос, но все равно спасибо что откликнулись.

[Владимир]

xmoonlight,
По вашему пункту 2, прочтение статьи у меня оставило смешанные чуства, там есть как полезные вещи так вещи которые могут быть опасными:
1 - при большом колве коннектов имеет смысл вобще отказаться от conntrack так как он может закончится, и потребляет память.
2 - засунуть гору параметров в sysctl.conf не понимая их смысла и влияния - тоже очень опасно, а в статье описания к ним нет.

[xmoonlight]

Владимир, Согласен! Поэтому, "не знаешь - не гони". Нужно или изучать, или нанимать профи...

[xmoonlight]

Pavel Blum, Если мой ответ чем-то Вам помог - огромная просьба отметить решением. Заранее, Спасибо!

[Pavel Blum]

xmoonlight, Спасибо большое за помощь, решили вопрос другим способом, но Ваше решение тоже отлично подходит.

[xmoonlight]

Pavel Blum, Отлично! А как именно - не поделитесь инфой?

[Pavel Blum]

xmoonlight, Выбрали два дедика ( для зеркалирования ) + Route 53 на AWS для балансировки и всех остальных приблуд.

[xmoonlight]

Pavel Blum, а-а, ну это только хостинг... Я думал Вы уже до построения внутренней инфраструктуры дошли... Ясно.

[Pavel Blum]

xmoonlight, Да, извиняюсь, что очень расплывчато задал свой вопрос, но очень благодарен за помощь.

[xmoonlight]

Pavel Blum, Когда будете настраивать серверную ОС - мой ответ как раз и пригодится. Поэтому, сохраните текст моего ответа куда-нить не особо далеко.
Удачи!

Answer 2

[index0h]

Вопрос из серии пальцем в небо.
Не меряется нагрузка в посетителях. Она меряется в rps и *bit/s. Также нужно знать прожорливость вашего ПО к io+ram+cpu иногда еще и gpu.
Количество серверов, способы распределения нагрузки, всякие репликации бд, распределения между ДЦ подбираются по конкретный проект.
Не бывает в природе такого, что вот так хренак и у вас откуда не возьмись 1кк активных юзеров, ну разве что событийные проекты типа прямых трансляций. Именно по этому рекомендую начать с малого, а дальше оптимизировать и распределять нагрузку между серверами там, где это необходимо. Например, у вас фото сток: cdn - это то, что вам потребуется. У вас месенджер - стоит выделить кучку серверов на поддержание сокетов с пользователями + хорошо прработать историю сообщений.

Comments

[sim3x]

Она меряется в rps и *bit/s со стороны клиента

точнее
RPS - когда речь про нагрузку на бекенд
M(ega) PacketsPerSecond - когда речь идет про ддос или про нагрузку на чисто сетевой стек инфраструкткры

Answer 3

[Антон Кучеров]

Для начала изучите принципы приложения 12 факторов: https://12factor.net/ru/ Эти рекомендации позволяют создавать приложения которые легко и просто масштабируются, как горизонтально, так и вертикально.
После можете посетить хороший ресурс со статьями на тему высоких нагрузок: https://ruhighload.com/

Comments

[Arris]

Все бы ничего, но половина статей на рухайлоад устарела. А часть предлагает откровенно вредные решения... под центос.

[Антон Кучеров]

Во многих статьях рассматриваются исключительно концепции. Концепции как правило не устаревают. А готовых инструкций как готовить тот или иной хайлоад проект все равно ни кто не даст. Потому как "высокая нагрузка" понятие достаточно размытое и у всех она "своя". Так же как и стек технологий. При этом общие принципы везде одни и те же. Приложения нужно писать так, чтобы они достаточно просто и быстро масштабировались в обоих направлениях, как горизонтально так и вертикально. Напрмер соблюдение принципа 12 факторов при разработке это больше 50% успеха.

Вот еще вспомнил хороший источник информации на тему: https://www.highload.ru/

Answer 4

[Пума Тайланд]

Если все достаточно оптимально и нет каких то глупостей можно воткнуть на один сервер и все будет ок

Answer 5

[Иван Шумов]

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

Comments

[sim3x]

И насколько падает производительность у большой БД при размещении в облаке, а не на железе?

[Иван Шумов]

sim3x, если правильно настроена инфраструктура и подобраны инстансы то даже возрастает. Если руки не из того места то можно и в ноль положить производительность. Там же тоже железо, просто управляется иначе

[sim3x]

Иван Шумов, Оу
Хм
И как избавиться от проседания IO при виртуализации, делать тюнинг железа и др вещи которые характерны для нагруженных СУБД?

[Иван Шумов]

sim3x, в облаках есть специальные инстансы с повышенным IOPS и вообще с какой угодно конфигурацией. Ты не берешь себе сферический сервер в вакууме, а выбираешь конкретно что тебе требуется. Вот базовая информаци по AWS EC2 instances и RDS. В детали надо углубляться

[sim3x]

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

[Иван Шумов]

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

[sim3x]

Иван Шумов,

железо рулит

ЧТД

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

докидывания дисков или установки другого железа

В итоге, облака == дорого и не оптимально по скорости на большом и стабильном проекте
Но хорошо, когда проект експоненциально растет, не имеет админов и ресурсов, те может загнуться в любой момент

[Иван Шумов]

sim3x, во-первых в счет своего железа идет зарплата сисадмина, который может это настроить. во-вторых свое железо дороже (гарантированно). в-третьих если у вас облако что-то потеряло то виноват в первую очередь не облако (100% никто никому не гарантирует), а тот криворук что не позаботился о правильной кластеризации, репликации данных и все прилагающееся. Это справедливо и для AWS и для Azure, да и для всех остальных облаков тоже. Это IasS платформа, а не магическая коробочка. Ну и на своем железе вы гораздо проще потеряете все данные. Вот и считайте что вам дорого

[sim3x]

Иван Шумов,
Я уже ответил на все ваши аргументы в коменте выше

В итоге, облака == дорого и не оптимально по скорости на большом и стабильном проекте
Но хорошо, когда проект експоненциально растет, не имеет админов и ресурсов, те может загнуться в любой момент

[Иван Шумов]

sim3x, этим занимаются SysOps в наше время)

[sim3x]

Иван Шумов, чем?

[Иван Шумов]

sim3x, мониторингом проблем системы и оперативным вмешательством (а в идеале, проактивной профилактикой)

[Валентин]

sim3x,

И насколько падает производительность у большой БД при размещении в облаке

А какая разница? В облаке ж покупаешь производительность, с которой будешь работать. Купил 1000 условных IOPS - пользуешся. А под ними там хоть всё на коленке может быть сделано, и поднятно на железе с 1000000 IOPS и диким оверхедом - это ж не проблема пользователя.

[Иван Шумов]

Валентин, не слышат нас люди)

[sim3x]

Валентин,

условных IOPS

никому не нужны, нужны реальные и не за конские деньги

[sim3x]

Иван Шумов, Как построить инфраструктуру большого проекта?

[Иван Шумов]

sim3x, есть инстансы с плавающим IOPS и есть с фиксированным. Все честно.

[sim3x]

Иван Шумов,

0. Что именно честно?
1. Зачем плавающий IOPS на стабильном проекте, где ясны нагрузки?
2. Зачем переплачивать облаку?

[Валентин]

никому не нужны, нужны реальные и не за конские деньги

Вы не поняли, вы покупаете 1000 иопс и они для вас реальны, вы их видите и пользуете. А насколько ниже там инфраструктура оптимальна или нет, это никак не волнует вас как клиента облака. Вы отдаете свои деньги, требуете за них какие-то услуги. Почему вас волнует эффективность инфраструктуры облака, если вы её не видите и никогда не увидите?

[Иван Шумов]

Валентин, человек не понимает. Не трать свои силы на динозавров

Answer 6

[Ranwise]

почитайте The System Design Primer, там есть некоторые примеры архитектуры приложений