Конфигурация сервера для веб-приложений, интернет-магазина или SaaS-сервиса, определяется числом одновременных пользователей и характером нагрузки на приложение. Та же логика расчета применима и к корпоративному порталу. Для CRUD-профиля до 500 одновременных пользователей ресурсов веб-слоя и базы данных обычно хватает на одном сервере среднего класса. При росте нагрузки свыше 1000-2000 сессий или переходе на микросервисную архитектуру веб-слой и базу данных разносят на отдельные серверы с индивидуальным расчетом ресурсов.
Читатель уже определился с архитектурой, монолит на одном сервере или распределенные микросервисы, и ищет конкретные цифры под нагрузку: сколько ядер и гигабайт памяти закладывать, какая дисковая подсистема нужна под базу данных и статический контент. Требования различаются не только по числу пользователей, но и по профилю запросов: интернет-магазин с частыми обращениями к каталогу нагружает сервер иначе, чем портал с преимущественно чтением статичных страниц.
От чего зависит конфигурация сервера для веб-приложения
Конфигурация сервера для веб-приложения зависит от нескольких параметров: числа одновременных пользователей и RPS, запросов в секунду. Дополнительно на расчет влияет архитектура приложения, монолит или микросервисы, а также соотношение чтения и записи в базу данных. Эти параметры вместе определяют, сколько ядер процессора и объема памяти нужно под конкретный сценарий, а какая дисковая подсистема потребуется под базу данных. Её считают отдельно.
Доля статического контента в трафике, изображений и файлов, тоже влияет на конфигурацию: чем она выше, тем важнее пропускная способность сети и скорость отдачи файлов, а не только производительность базы данных. У SaaS-сервиса с преимущественно динамическими данными акцент смещается в сторону процессора и оперативной памяти.
Дополнительно на расчет влияет доля запросов на запись против запросов на чтение: приложение с частыми изменениями данных, например биллинг или система бронирования, нагружает базу данных сильнее, чем каталог с преимущественно чтением.
Перед расчетом конфигурации стоит оценить четыре параметра:
- Число одновременных пользователей и RPS на пике нагрузки;
- Архитектуру приложения: монолит или микросервисы;
- Соотношение чтения и записи в базу данных;
- Долю статического контента в общем трафике.
Ресурсы под типовые профили нагрузки
Малый профиль нагрузки — CRUD-операции интернет-магазина или портала при не более чем 500 одновременных пользователях — укладывается в 8-16 ядер процессора серверного класса и 32-64 ГБ оперативной памяти на связке веб-слоя и базы данных. Это ориентир для старта расчета: точную нагрузку на сервер уточняют по факту реального профиля запросов.
Когда нагрузка превышает 1000-2000 сессий или проект переходит на микросервисную архитектуру, веб-слой и базу данных разносят по разным серверам с индивидуальным расчетом ресурсов на каждом уровне. Сервер для интернет-магазина с сезонными всплесками трафика стоит рассчитывать с запасом по процессору.
Ниже — характеристики по каждому из трех профилей нагрузки:
- Малый — до 500 одновременных пользователей, 50-200 запросов в секунду на пике;
- Средний — 1000-2000 сессий или переход на микросервисную архитектуру;
- Крупный — горизонтальное масштабирование при утилизации процессора от 70%.
Профиль нагрузки | CPU | RAM | Диски | Сеть |
|---|---|---|---|---|
Малый | 8-16 ядер серверного класса | 32-64 ГБ | NVMe RAID10, от 50 000 IOPS | от 1 Гбит/с |
Средний | 16-32 ядра на веб-слое | 32-64 ГБ на веб-слое, от 64 ГБ на БД | NVMe-массив RAID10 под базу данных | 10 Гбит/с |
Крупный | от 32 ядер на узел, несколько узлов | от 128 ГБ на узел БД | NVMe-массив с резервированием | от 10 Гбит/с между узлами |
Монолит и микросервисы: разница в требованиях к железу
Монолитное приложение работает на одном сервере: веб-слой и бизнес-логика выполняются в одном процессе, а обращения к базе данных идут в рамках того же стека. Расчет ресурсов проще: под весь стек закладывают один пул процессора и памяти, а рост нагрузки закрывают вертикальным апгрейдом этого сервера.
Микросервисная архитектура распределяет функциональность приложения между несколькими независимыми сервисами, каждый из которых можно масштабировать отдельно. Это увеличивает требования к сети между узлами и требует балансировщика нагрузки, зато позволяет наращивать ресурсы точечно — например, добавить мощности только под сервис обработки платежей, а не под все приложение целиком. При разнесении веб-слоя и базы данных на отдельные машины эти роли удобно размещать на серверах виртуализации: они позволяют гибко перераспределять ресурсы между сервисами без физической миграции железа.
Разворачивать микросервисы отдельными процессами на одном сервере тоже можно, но тогда теряется главное преимущество архитектуры: независимое масштабирование. На практике микросервисы чаще разносят по контейнерам с оркестрацией, а серверные ресурсы считают не на приложение целиком, а на кластер узлов, между которыми распределяются контейнеры.
Дисковая подсистема под базу данных и статику
Дисковая подсистема под базу данных веб-приложения — это NVMe SSD с производительностью от 50 000 IOPS для интенсивной записи: сессии и транзакции создают постоянный поток операций записи, к которому добавляются логи приложения, а медленный диск не успевает обрабатывать такой объем операций.
Для такой нагрузки подходит сервер с NVMe RAID 10: массив держит высокую скорость записи и переживает отказ одного диска без потери данных. Статический контент вроде изображений и медиафайлов можно размещать на менее скоростных SSD или выносить в объектное хранилище, если объем растет быстрее, чем окупается место на основном сервере.
Объем базы данных и объем статического контента растут с разной скоростью: база увеличивается пропорционально числу транзакций и записей, а статика, пропорционально числу загружаемых файлов и их разрешению. Планировать эти два объема стоит раздельно, а не закладывать общий запас диска на весь проект.
Сеть и пропускная способность
Сетевой интерфейс от 1 Гбит/с достаточен для типового веб-приложения с преимущественно текстовым и структурированным трафиком, каталог интернет-магазина или формы обратной связи с небольшими API-запросами.
При высоком трафике медиаконтента или интеграции с внешними API с большим объемом обмена данными переходят на сетевые карты 10 Гбит/с, которые снимают ограничение по пропускной способности на стороне сервера.
Для интеграции с внешними API, платежными системами и службами доставки, важна не только пропускная способность, но и задержка сети. Если сервер обменивается данными с несколькими внешними сервисами синхронно на каждый запрос пользователя, суммарная задержка отклика приложения растет вместе с числом таких интеграций.
Кеширование и снижение нагрузки на базу данных
Кеширование на стороне сервера, через Redis или Memcached, снижает число обращений к базе данных, обслуживая повторяющиеся запросы из оперативной памяти вместо диска. Для активного профиля запросов под кеш-слой закладывают от 4-8 ГБ оперативной памяти отдельно от объема, выделенного под саму базу данных.
Кеш особенно снижает нагрузку на связке с интернет-магазином или порталом, где одни и те же данные, каталог товаров, справочники, запрашиваются многократно в течение дня. Без кеш-слоя эта нагрузка целиком ложится на базу данных и дисковую подсистему.
Время жизни закешированных данных, TTL, тоже влияет на нагрузку: слишком короткий TTL заставляет сервер чаще обращаться к базе данных, слишком длинный, увеличивает риск отдать пользователю устаревшие данные. Значение TTL для каждого типа данных подбирают исходя из того, как часто эти данные меняются на практике.
Когда переходить к горизонтальному масштабированию
Горизонтальное масштабирование веб-слоя — несколько серверов приложений за балансировщиком — применяют, когда нагрузка не помещается в вертикальный апгрейд одного сервера. Типовой порог перехода к масштабированию веб-приложения наступает при устойчивой утилизации процессора выше 70% на пике.
До этого порога проще и дешевле выбрать вертикальное масштабирование: нарастить ресурсы одного сервера, добавить ядра или память. После — горизонтальная схема с балансировщиком дает более предсказуемый рост, потому что каждый новый узел добавляет фиксированный объем мощности, а не упирается в предел одной материнской платы.
На практике переход выглядит так: к существующему серверу добавляют второй узел с идентичной конфигурацией, настраивают балансировщик и переносят часть сессий на новый сервер. Пользовательские сессии при этом хранят вне серверов приложений, например в Redis, иначе балансировщик не сможет свободно распределять запросы между узлами.
Резервное копирование и отказоустойчивость
Резервное копирование базы данных веб-приложения, отдельная задача по объему дисков: инкрементные бэкапы требуют закладывать от 20-30% дополнительного места сверх объема продуктивной базы. Без этого запаса цикл резервного копирования упирается в нехватку места раньше, чем истекает срок хранения нужного числа копий.
Для архива бэкапов часто используют массив с SSD-кешированием: горячие данные читаются и записываются быстро, а основной объем хранится на более дешевых дисках большой емкости. Отказоустойчивость веб-приложения строится на нескольких уровнях: резервирование сервера базы данных и балансировка между серверами веб-слоя. Отдельный уровень: регулярная проверка восстановления из резервной копии, а не только факта ее создания.
Частота проверки восстановления зависит от критичности приложения: для интернет-магазина с ежедневными продажами тестовое восстановление имеет смысл проводить не реже раза в квартал, чтобы убедиться, что резервная копия действительно рабочая, а не просто существует на диске.
Конфигурация сервера для веб-приложений определяется не общими ориентирами, а конкретным профилем нагрузки: числом одновременных пользователей, соотношением чтения и записи в базу данных. Отдельно на расчет влияет доля статического контента в трафике. Ориентиры по ядрам и памяти из этого материала подходят для оценки на старте проекта, а расчет дисковой подсистемы стоит уточнять отдельно. Точный вариант под монолитную или микросервисную архитектуру собирают индивидуально, с учетом реальных пиковых нагрузок и планов на рост.