Рецепт высоконагрузочной архитектуры

1. Общая архитектура системы
Принцип автомасштабирования и автовосстановления. Вместо одного единого монолита (точки отказа) — система делится на несколько согласованных микросервисов, управляемых через механизм оркестрации в облачной инфраструктуре

2. Балансировщик нагрузки
в качестве балансировщика нагрузки выступает NGINX. Все входящие обращения через DNS запись A направляются на IP адрес балансировщика нагрузки. Т.к. нагрузка на скрипты распределена равномерно, а в качестве резольверов выступают сервера одинаковой мощности — нагрузка распределяется по алгоритму rolling, когда все входящие запросы подаются на следующий по очереди сервер.
Защита от DDOS осуществляется на стороне CloudFlare. Переключение DNS записей также осуществляется через CloudFlare API

3. Stateless ресольверы. Сервера, которые не хранят состояние внутри себя, могут быть запущены в параллель и масштабироваться как угодно. Это могут быть сервера PHP, Go, NodeJs, Python без каких либо ограничений в зависимости от ситуации для каждого отдельного случая. Желательно не плодить зоопарк на пустом месте
Нагрузка мониторится через Zabbix, который периодически проводит анализ использования процессорного времени на каждом сервере. Также нагрузку можно снимать через кастомный скрипт, который возвращает ответ консольной команды cpuusage. При приближении нагрузки к пиковому значению — оркестр принимает решение о поднятии ещё одного резольвера, после чего запускает процедуру синхронизации балансировщиков.
Самый трудный механизм в этой схеме — уловить момент резного возрастания нагрузки и необходимость поднятия сразу нескольких серверов, либо учесть период когда они будут подниматься. На поднятие сервера уходит порядка 40 секунд. Соответственно при резком увеличении нагрузки — всем, кто был направлен на увеличенную нагрузку и нехватку ресольверов — будет выдано статичная страница с заглушкой и автоматическим обновлением через 40 секунд. Также есть возможность оттюнинговать и ускорить время загрузки. При плановом увеличении нагрузки — сервера запускаются заранее и заглушка не воспроизводится.
Как вариант при резком увеличении нагрузки — выделить дополнительные мощности через api облачного хостинга на имеющихся ресольверов, т. к. это занимает гораздо меньше времени. Либо держать один запасной сервер включенным для быстрого реагирования.
При понижении нагрузки — механизм оркестрации принимает решение об удалении одного из резольверов по аналогичному ранее механизму. Прописывается конфигурация балансировщика, удаляется выбывший сервер.

4. Механизм кеширования и сессий.
Для хранения быстрообновляемых данных — предусмотрен механизм быстрого кеширования и получения данных по ключу. Организация происходит через хранение данных в памяти через Redis. Каждый резольвер связан с хранилищем для хранения сессий через расширение phpredis и настройки конфигурации.
Если мониторинг замечает проблемы с сервером хранения сессий — сервис оркестрации поднимает новый сервер хранения сессий, после чего поднимает все ресольверы с новой конфигурацией и перенаправляет весь поток на новые серверы
На сервере также предусмотрена система защиты от одновременного доступа на запись с разных ресольверов через систему блокировки и ожидания

5. Statefull сервера.

5.1 База данных
Базы данных по возможности не должна дробиться на сервера. Мощный сервер с 32 ядрами на nwse ssd дисках хранит всю базу проекта. Сервер бекапится в виде ленты
Поскольку нагрузка на запись будет значительно меньше нагрузки на чтение — сервер баз данных может быть подвержен горизонтальному масштабированию через репликации. Нагрузка проверяется с помощью системы мониторинга. При превышении порогового значения нагрузки — создается новая репликация, происходит копирование с мастера и встраивание нового сервера на чтение. В случае падения реплики — отключается не рабочая, создается новая, переключается на новую, уничтожается старая. В случае падения мастера — произвольная реплика становится мастером. Бекапами в этом случае являются реплики
В случае превышения нагрузки на мастер — можно дополнительно применить систему шардирования как вертикального, так и горизонтального. В случае вертикального шардирования — таблицы дробятся на отдельные сервера, связываются в сгустки там, где нужна транзакционная целостность. Базы, где транзакции не используются — могут быть отделены и связываться через механизмы ORM на стороне ресольверов. В случае горизонтального шардирования — база, в которой происходит нагрузка в зависимости от критериев запроса — определяется сервер, который содержит информацию именно по этому ключу и запрос происходит к нему.
Любое шардирование несет в себе дополнительную инфраструктурную сложность и ограничения, но этому по максимуму дробления стоит избегать
В качестве временного решения — большое число запросов на запись может быть буферизировано через очереди

5.2 Хранение файлов
Файлы хранятся через систему хранения S3 через API. Запросы осуществляются через CDN на отдельные сервера, подготовленные к быстрой отдачи файлов. Файлы автоматически бекапятся в случае отказа диска. Файлы не удаляются, чтобы не держать в системе отдельные бекапы и была возможность откатиться к любой точке времени.
Для экономии ресурсов — файлы изображений сжимаются через фоновые операции

6. Механизм защиты
Все поднятые сервера создаются с ключом. Подключиться к ним может только сервер оркестрации. Все взаимодействия происходят через него.
Доступ к админ панели на сервер оркестрации прописывается через hosts файл, в DNS он не указывается. Порт для подключения SSH меняется на нестандартный. На стандартный порт вешается заглушка. Сервер блокируется для доступов с неизвестных IP адресов

7. Очереди
Для возможности выполнения отложенных емких задач предусмотрены системы очередей. Задание падает в очередь со всеми параметрами, в последствии через отдельный ресольвер с воркерами принимается за обработку заданий из очереди. Если список заданий в очереди увеличивается — поднимаются новые ресольверы для решения очереди
К отложенным задачам могут относиться — синхронизация заказов с CRM, сжатие загруженных изображений, оповещения смс в случае необходимости, построение временных отчетов, обновление кеша, обновление цены при изменении курса валют
Очереди строятся с помощью системы хранения REDIS