Задать вопрос
evgensenin
@evgensenin
Yii2 || Laravel, vue & nuxt

Как организовать надежную инфраструктуру для веб-проекта?

Здравствуйте!
У меня есть несколько вопросов касательно построения НАДЕЖНОЙ инфраструктуры нашего веб-портала (PHP Yii2 + Mysql + Vue js SPA, никаких докеров (кроме пары микросервисных штук) + Cloudflare)
Начну с проблем
1. падение сети в ДЦ, наш сервер становится недоступен
2. лаги сети в ДЦ, сеть вроде есть, но часть коннектов идут очень долго и обрываются, связь со смежными системами рушится.
3. ддос-атаки

Не хотелось бы хранить все в одной корзине (ДЦ), поэтому выделю сервисы в разные ДЦ.
Например, самое главное (БД) перенесу в Amazon AWS RDS
Основной мощный веб-сервер с SPA и Backend останется в текущем ДЦ в Нидерландах
Хочу сделать резервный веб-сервер в другом ДЦ
Оба веб-сервера будут работать с одной базой в AWS RDS (MultiAZ для надежности)

Но появилась проблема - все SQL запросы сильно лагают(каждый по 100-500мс, смотрел в Yii2 Debug panel).
если в личном кабинете клиента это еще терпимо, там немного запросов, то в админке это сущий ад, страница по 30 секунд открывается.

Поделитесь пожалуйста своим опытом работы (если конечно все ваши сервисы работают в разных ДЦ, а не в одном ДЦ типа амазон)

думал держать Mysql MASTER-MASTER на основном и резервном веб-серверах, без единого SQL-сервера, но возникает вопрос - как поведут себя мастера, если разрыв связи будет более 3-7 часов?

в общем, главная цель - чтобы при поломках в одном ДЦ, работа ресурса не прекращалась и клиенты могли пользоваться порталом.
  • Вопрос задан
  • 1252 просмотра
Подписаться 10 Сложный 4 комментария
Пригласить эксперта
Ответы на вопрос 4
@vitaly_il1
DevOps Consulting
Например, самое главное (БД) перенесу в Amazon AWS RDS
Основной мощный веб-сервер с SPA и Backend останется в текущем ДЦ в Нидерландах
Хочу сделать резервный веб-сервер в другом ДЦ
Оба веб-сервера будут работать с одной базой в AWS RDS (MultiAZ для надежности)

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

Варианты от простого к сложному (кроме нанять опытного архитектора):
- выбрать надежного провайдера - самый дешевый и простой вариант
- AWS (или GCP/Azure) - разбросать компоненты по разным AZ
- несколько систем в разных регионах AWS, с GeoIP loadbalancing
- несколько систем у разных провайдеров (разные датацентры), loadbalancing Cloudflare or Incapsula, ...

В случаях 3 и 4 вы сами должны обеспечивать репликацию данных.
Ответ написан
xmoonlight
@xmoonlight
https://sitecoder.blogspot.com
Клиент - всегда за одну сессию посещения работает ТОЛЬКО с одним сервером обслуживания. Это может быть как отдельная структура, так и внутри структуры CDN. Я предпочитаю использовать второй вариант.

Сервера - постоянно синхронизируют данные асинхронно между собой (канал обмена данными - поднят всегда!).
После закрытия/смены сессии клиентом - происходит централизованное оповещение сразу всем серверам и они ставят себе в очередь синхронизацию данных именно по этому пользователю.
При этом, стандартная синхронизация серверов БД работает параллельно в штатном режиме.

все SQL запросы сильно лагают
Только пакетный конвейер запросов с контролем загрузки сервера исполнения запрос-пакета и необходимого приоритета исполнения всех нужных запрос-пакетов! Система должна знать (сама принимать решение!): когда ей выполнить запрос, а когда допускается повременить (приоритезация).

Также, можно использовать HAProxy для отказоустойчивости/балансировки, в качестве "головы".
Или, как альтернативу ему, Envoy.

PS:
1. Кэширование статики и данных из БД - Вы там не забыли поделить на: EVERYONE, GUEST, USER?
2. Соединение к БД - не переоткрываете по несколько раз, когда делаете обращения к БД за время исполнения скрипта?
3. Объединяете ли запросы с стэки для получения всех нужных данных ОДНИМ запросом из БД?
Ответ написан
Sanes
@Sanes
Это называется паранойя. 100% всё равно не добьетесь. А если приложение интерактивное, еще и коллизий хапните. Падение ЦОД настолько редкие, что нет смысла заморачиваться.
Ответ написан
Комментировать
Noizefan
@Noizefan
А может быть у вас проблема не в архитектуре сети а все таки в архитектуре продукта?
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы