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

[Breeze]

@Breeze, Для новостного сайта при предварительных расчетов нужно всех брать униками.

Ну дак товарищ @S.Chushkin тут говорил, что уников считать не надо =)
Всегда хорошо знать, что движок в бэкенде вытянет сам по себе охулиард запросов, но не он один работает.

Собственно все мои излияния тут ровно для того, чтоб @Volodya не уверовал в единого всемогущего сервера и понял, что жизнь сложнее и однозначно посоветовать ему железку под его 100к юзеров в сутки нельзя.
Ибо, как я ранее приводил пример, один и тот же проект, но написанный по-разному требует принципиально разных ресурсов.

@MiksIr уже давал хороший совет под какие параметры выбирать.

Но, опять же, какой смысл выбирать железку, если продукта ещё нет? Будет новый сайт, его на тестовом стенде(если утрировать, то на машине разработчика) можно грузить через ab, siege, JMeter и что там ещё есть, если покажет что может отдавать over 9000 rps, то под это и выбирать хостинг, глядя во время тестов на то, что жрётся больше всего: память, проц, диски или всё вместе.

Т.е. под готовый продукт считается по полученным параметрам на тестовом стенде итоговый серверный ландшафт, тестируется уже там и делается вывод, всё ли хорошо.

 

[Breeze]

А самое интересное, что у ТС уже есть работающий старый сайт, откуда он может снять метрики: сколько уников в месяц/сутки/час, количество запросов в месяц/сутки/час, трафик, время пиковых нагрузок и т.д.
Это ж клондайк для новой системы.

 

[grigori]

если бы ТС знал как снимать метрики и что с ними делать, он не задал бы вопрос

 

[Breeze]

если бы ТС знал как снимать метрики и что с ними делать, он не задал бы вопрос

В итоге он уже знает про метрики и может задать соответствующий вопрос.

 

[Volodya]

Спасибо всем за поддержку темы!

В итоге он уже знает про метрики и может задать соответствующий вопрос.

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

Сейчас рассматриваю примерно следующую структуру серверов:
- 1 сервер под БД
- 1 сервер под приложение
- 1 сервер под поисковый движок (ElasticSearch или sphinx)
Это то, что 100% считаю нужным.


Так же есть идеи:
- сервер для почтовых рассылок новостей для пользователей вынести отдельно. Там точно будут использоваться очереди типа RabbitMQ или аналогичные. Кто-то выносил подобное на отдельный сервер? Может есть у кого опыт насколько это сложно в реализации.
- использовать Load Balancing и несколько нод серверов-приложений
- вынести приложение админки на отдельный сервер. (там есть довольно ресурсоемкие операции ). Или сделать отдельный сервер под эти ресурсоемкие операции, если админку оставить на сервере приложения.

Суть в том, что должно быть в первую очередь надежно все, и не падать, и довольно оптимально по цене и поддержке железа.

 

[Breeze]

сервер для почтовых рассылок новостей для пользователей вынести отдельно

Почтовик и должен быть отдельно, фронтенды дают таски в очередь на отправку писем, потом где-то это выгребается и формируются сами письма. В общем ничего сложного.

Что касается структуры серверов. Всё зависит не только от нагрузки, но и от требований к устойчивости системы и удобству обслуживания.

Если нужно будет обновлять, например, ОС сервера приложения, то это означает его остановку на какое-то время, но чтоб юзеры не видели надпись "Извините, мы тут работаем, а вы подождите", нужен второй такой сервер.
При этом распределение должно быть такое, чтоб один этот сервер тянул всех юзеров, пока второй в ауте. Или делать их 3-4 штуки, чтоб более равномерное распределение было.
В такой схеме разумеется нужен балансер, причём желательно балансеров два, один основной, а второй резервный, который может в случае поломки первого взять на себя всю работу и его ip, а потом вернуть обратно

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

А можно воспользоваться для начала виртуализацией типа kvm (решение proxmox) или xen. Взять два железных сервера, на каждом поднять по две виртуалки для приложений, на каждом поднять по виртуалке балансера, по серверу БД (основной и реплика), виртуалка с smtp, виртуалку с сервером cron-задач и т.д.
И далее в случае роста нагрузки переносить сервисы на третий/четвёртый/пятый железный сервер в виртуалках, либо на реальное железо.

Вариантов масса.

PS: и главное никакого RAID0 чтоб не было

 

[1482909]

Не давно был случай, новый отдел, менеджеры call-центра из Кёнигсберга стали жаловаться руководству в Мск. и Спб. мол страницы каталога и карточки товара у них открываются через минуту и не только в офисе. При этом скорость интернета 200MB. Те не сразу отреагировали так как у них такой проблемы не наблюдалось. Обнаружили что через браузер TOR такая проблема исчезает, была задача на время некой проверки привязать к домену Белорусский IP и настроить проксирование, заодно проверили, страницы загрузились быстро.
Получается что нужно учитывать надежность интернет канала, причем в каждой точке откуда будет поступать запрос?

 

[Breeze]

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

Не надёжность как таковая, а время, требуемое для подключения к ресурсу.
Сервера никто в здавом уме на плохой канал не сажает. Остаётся клиент.

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

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

Например, если у части юзеров через разных провайдеров установление соединения с вебсервером занимает стабильно 500ms, а TTFB всего 30ms, то скорее всего есть проблема с хопами.
Как правило кроется в том, где клиент сидит географически и где географически находится сервер.
Крупные ресурсы решают этот вопрос путём размещения серверов в датацентрах на разных континентах,
чтоб юзер из Европы, например, не ходил за данными куда-нибудь в Калифорнию через океан и 20 хопов с общим пингом 500,
а пошёл в "хетцнер" с пятью хопами и пингом 15.

В общем каждый раз это специфика отдельно взятого проекта, где надо смотреть, что именно тормозит и как оптимизировать