Как организовать масштабирование/отказоустойчивость интернет-магазина?

Question

[chipstore]

Имеется интернет-магазин с посещаемостью ~350к посетителей в месяц, крутится на VDS (Intel Xeon 2,4 х 6 ядер, 8 Гб Оперативы, SSD диск, debian 9 OVZ), стек стандартный nginx/php7.4/mysql, движок уже не актуальный, большей частью переписанный, но в общем все успешно работает... Заказы сливаются в 1С, остатки по товарам из нее загружаются.
Бывает случаются проблемы, да еще и в не удобное время, различного характера: то у хостера родительский сервер упадет, то nginx отвалится, то в php количество активных процессов границы достигнет (на ожидании внешних ресурсов повисли).
Хотелось бы увеличить стабильность работы в целом и с заделом на будущий рост нагрузки. Вопрос в следующем, какие есть пути достижения цели (концептуально)? Увеличение затрат не проблема, но и многократного роста затрат не хочется... И важно чтоб было приемлемо по количеству телодвижений для реализации (менять движок, глобально переписывать обмены и т.п. не хочется).
Поменять хостера? Взять второй VDS у другого и поставить в параллель? Как лучше и какие еще варианты?)

Answer 1

[smilingcheater]

Если без значительного переписывания кода:
Вынести БД на отдельный сервер. При росте нагрузки - добавлять сервера и настраивать репликацию между ними.
Сделать отдельный балансировщик - сервер, на который приходят запросы, и который раскидывает их на разные сервера, выполняющие код. При увеличении нагрузки - увеличивать число нод, выполняющих код. Если одна из нод по какой-то причине перестаёт отвечать - остальные продолжают работать.
Если у вас сессии хранятся в файлах - придётся переносить их хранение в базу/Redis/...

Comments

[chipstore]

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

[smilingcheater]

chipstore, делайте несколько серверов БД, делайте мастер-мастер репликацию (хотя в ней есть куча тонкостей и сложностей)
Делайте несколько балансировщиков на разных IP, раскидывайте между ними запросы либо через Round-Robin DNS (как самый примитивный вариант), либо используйте какой-то облачный сервис для балансировки, либо геозависимо (но опять же, это не совсем тривиально настраивать).

Answer 2

[Сергей П]

smilingcheater всё правильно написал. Дабвлю лишь, что нужно анализировать бутылочные горлышки и исправлять узкие места в первую очередь.
Разбирайтесь с проблемами детально. Что значит "nginx твалится"? Годами работает и ничего с ним не происходит. Выясняйте что произошло, если такое поторяется, то нужно разбираться, а не надеяться, что кто-то даст универасльный простой, но концептуальный совет, который победит все возможные проблемы наперед.
Правила тут простые: находим узкое место и расширяем его пока общая производительность в часы пик не будет удовлетворительной.
Надальте сохранение логов, протоколируйте нагрузки, помониторьте базу. Если проблема извне, то попробуйте подобрать хостинг понадёжнее, сменить OVZ на KVM, разнести БД и бэк на разные инстансы, прикрутите балансировщик,
Если где-то скорость не принципиальна и можно что-то отложить, добавляйте очередь.

Comments

[chipstore]

Это больше про производительность, с ней в принципе все нормально. Больший вопрос в отказоустойчивости...
Конфиг nginx подправили, больше не падает, до следующего проблемы... И таких точек отказа может быть много, какие-то и в следствии нашей некомпетентности, какие-то сторонних проблем. Хотелось бы чтоб от выхода из строя чего-то одного, не встало все. Понятно, что 100% sla не будет, но вероятность нескольких отказов одновременно, все же гораздо ниже.

[Anton_habr_2020]

chipstore, Несколько компьютеров в разных датацентрах, на каждом копия MySQL, web сервер.... MySQL связывайте в кластер.
В главный DNS прописывайте все IP ваших серверов. В итоге запросы пользователей будут иди на рабочую часть кластера.

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

[Сергей П]

chipstore, тут тоже не бывает серебряной пули, только общие правила:
- надёжность в простоте - если есть возможность отрендерить страницы сайта в статику и раздавать ее c CDN, вместо сложной взаимозависимой связки реплицирумеых баз, очередей и сервисов, то доставка контента пользователям будет более надежной.
- принцип паретто - грубо говоря 80% результат требуют 20% трудозатрат, а оставшиеся 20% результата потребуют гораздо больше времени. Продакат-менеджер с моей прошлой работы говорил: "Не так страшны первые 90% проекта, как вторые 90%". Идея тут в том, что, возможно малозначительные для продукта и конечного пользователя фичи будут стоить слишком дорого или внесут слишком много компромиссов в безопасность или надёжность решения.

Answer 3

[neol]

то у хостера родительский сервер упадет

Насколько часто это происходит? В принципе падают все, тут важнее как быстро реагирует поддержка и восстанавливается работа.

то nginx отвалится

Соглашусь с Сергей Паньков: nginx просто так не отваливается.

то в php количество активных процессов границы достигнет (на ожидании внешних ресурсов повисли).

Если вынести обращения к внешним ресурсам в фон невозможно, то создать отдельный пул php-fpm(возможно несколько: для каждого сервиса свой), который будет отвечать только за обращение к этим внешним ресурсам. Даже если внешний сервис упадёт, то у вас отвалятся только обращения к нему, а сайт продолжит работать.

Comments

[chipstore]

Раз в месяц например... В принципе поддержка хостера среагировала и в течении часа поднялся VDS. Ток проблема в том, что наши пользователи среагировали быстрее, связались с тех. специалистами, они начали расследовать проблему и т.д., а хотелось бы чтоб падение одного составного звена не привело к тому, что посыпались жалобы от пользователей.
Про отдельный пул php-fpm спасибо, попробуем...

[neol]

chipstore,

Раз в месяц например... В принципе поддержка хостера среагировала и в течении часа поднялся VDS.

Если такое каждый месяц (т. е. каждый месяц сервер падает на час или больше), то пожалуй стоит поискать другой VPS.

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

Отказоустойчивость без мониторинга - это фарс.

Я бы выбрал для этой цели Zabbix, но это просто по привычке и говорят сейчас есть более модные и молодёжные вундервафли.

Answer 4

[Alexey Dmitriev]

Для того, чтобы взять второй VPS, понадобится третий - для балансировки нагрузки\подключений между двумя. Он тоже может быть недоступен

Я бы посоветовал рассмотреть вариант облачных сервисов. Не VPS\VDS, а именно сервисов, которые могут сами следить за отказуйсточивостью и масштабированием, например https://docs.microsoft.com/en-us/azure/app-service...

Либо или полный перезд виртуальных машин в облако типа янжекса с использованием их балансера, или хотя бы использование их балансера https://cloud.yandex.ru/services/network-load-balancer либо другого аналогичного сервиса

Comments

[chipstore]

Только со стоимостью не все так радужно, по крайней мере раньше получалось... Взять несколько VDS по стоимости получалось дешевле)
Хотя балансировщик нагрузки можно попробовать (https://cloud.yandex.ru/docs/network-load-balancer...) если я все верно с ценообразованием понял: 3 Тб прокачать за месяц получается менее 1000руб?