Как грамотно повысить отказоустойчивость WEB приложения?

Question

[jenya7771]

Здравствуйте, у меня есть WEB приложение, оно располагается на одном сервере Ubuntu 18.04. Приложение написано на Node Js, и работает с БД PostgeSql, Redis. Все запросы на сервер проходят через Cloudflare.

Суть вопроса в том, как повысить отказоустойчивость и доступность приложения, разместив его на нескольких серверах. Но мне тогда не понятно:
1) Как распределять запросы между серверами;
2) Как работать с PosgreSql. Работать с одной базой или как-то синхронизировать несколько баз, на каждом сервере по копии. Если с одной базой, то на сколько я слышал, работа по сети достаточно замедляет ответы от БД и это не безопасно;

У кого был подобный опыт, расскажите как более правильно реализовать?

Answer 1

[Александр Докин]

Почитайте про балансировку нагрузки, шардинг и репликацию.

как более правильно реализовать

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

По поводу балансировки запросов между серверами можете почитать например это.

Answer 2

[Karpion]

Две СУБД можно запустить в режиме "мастер+мастер" с автоматической синхронизацией. Два Web-приложения - тогда должны обращаться каждый к своей СУБД и не хранить никаких данных кроме как в СУБД. Как-то так.

Comments

[Лев Забудкин]

Тогда смысла в распределённом доступе не будет, это зеркало по сути получается.

[none7]

Лев Забудкин, Речь ведь о надёжности, если крашнется один из серверов в режиме балансировки, то и второй не будет работать.

[Karpion]

Лев Забудкин, Смысл зеркала - надёжность.

Обратите внимание: у меня зеркалится только БД/СУБД; а Web-сервер балансируется.

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

[Валентин]

Две СУБД можно запустить в режиме "мастер+мастер"

правильный "мастер-мастер" требует знаний, до которых автору вопроса еще далеко.

Answer 3

[Melkij]

повысить надёжность приложения, разместив его на нескольких серверах

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

Для бюджетного веба болезненный вопрос "как быстро перекинуть запросы пользователей на нужный IP". Через DNS даже с маленьким TTL это всё равно долго. Посмотрите у вашего хостера и у Cloudflare раз вы его используете, нет ли у них подходящего решения.

работа по сети достаточно замедляет ответы от БД

На время латентности сети, от этого никуда не деться. В пределах одной стойки можно пренебречь.
Безопасность - разумеется об этом при настройке надо будет подумать.

Answer 4

[Vitaly Karasik]

Суть вопроса в том, как повысить надёжность приложения, разместив его на нескольких серверах.

Я бы начал с анализа причин нерабочего сайта - чтобы понять поможет ли использование нескольких серверов повысить надежность. Во многих случаях это не так. Например - проблемы у хостера. Тогда надо переходить к другому. Например - сервис базы данных падает. Тогда надо правильно его настроить, оптимизировать запросы и т.п.

как повысить надёжность приложения, разместив его на нескольких серверах

Несколько серверов помогают защититься от "железной" проблемы на конкретном сервере (что бывает очень редко), плюс в определенных случаях решить проблему scale.
Это будет стоить денег - и на серверы, и на имплементацию решения. И при неправильной имплементации это может ухудшить надежность.
Так что советую вернуться к вопросу - почему сайт ненадежен сейчас?

Answer 5

[xmoonlight]

Если кратко:
Каждый сервер - это клиент БД для всех остальных. При изменении данных, он обращается асинхронно сразу ко всем БД и как только получает со всех одинаковые ответы - возвращает управление скрипту.
Статика и скрипты - работают на этом же сервере.

Comments

[Karpion]

xmoonlight , А если крешится одна из СУБД - то крешится и вся система.

[xmoonlight]

Karpion, почему? Продолжают работать остальные БД.
А закрешенная, сносится и на новый серв реплицируется с существующей и всё.
По готовности реплики - она, снятием комментирования одной строчки в коде, подключается в общий рабочий процесс.

Никто не мешает настроить репликацию средствами СУБД, но это нужно понимать, что доп.трафик будет между сервами. Тут - уже нужно смотреть по количеству и типу данных, с которыми придётся работать.

Answer 6

[vl65]

В большинстве случаев перевод одноузлового приложения в многоузловое только ухудшит эксплуатационные характеристики вашего приложения. Либо Вы фактически заново разработаете ваше приложение при адаптации его в многоузловое.

"Мир" давно изменился. Одноузловые приложения встречаются очень редко. Либо ваше приложение пользуется сервисами других приложений (узлов), либо рано или поздно будет предоставлять свои сервисы другим приложениям (узлам). Отсюда вытекает требование разрабатывать ваше приложение сразу многоузловым. Многоузловое приложение можно в частном случае эксплуатировать в одноузловом варианте.

Для создания производительного приложения экономить целенаправленно нужно сразу и на всем на этапе разработки приложения по всей цепочке прохождения вызовов: клиент -> сеть -> программные слои вашего приложения -> сеть -> БД или другой узел -> сеть -> программные слои вашего приложения -> сеть -> клиент (не самая "сложная" цепочка)! Неоправданная потеря нескольких миллисекунд в каждом звене этой цепочки может Вам принести "на выходе" к потере нескольких или десятков секунд.

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