Как выбрать сервер под маркетплейс или каталог с большим количеством товаров

Каталог на 300 тысяч товаров может работать быстрее магазина, в котором всего 30 тысяч позиций. Разница обычно не в красивой цифре из административной панели, а в том, что происходит с данными: сколько фильтров одновременно нажимают покупатели, как часто обновляются цены и остатки, сколько изображений нужно отдать и какой трафик приходит за одну минуту. Поэтому сервер для маркетплейса выбирают не только по количеству товаров, а по реальному профилю нагрузки.

Ошибка здесь обходится дорого. Слабая конфигурация превращает поиск и оформление заказа в полосу препятствий, а чрезмерно мощная месяцами расходует бюджет, не принося заметной пользы. Разберёмся, какие ресурсы действительно важны большому каталогу и как собрать инфраструктуру с запасом, но без бессмысленной переплаты.

Количество товаров — плохой калькулятор мощности

Число товарных карточек важно, но само по себе почти ничего не говорит о нагрузке.

Представим два проекта. Первый хранит 500 тысяч редко меняющихся товаров. Посетители приходят в основном из поисковых систем, открывают конкретную карточку и уходят. Второй содержит 50 тысяч позиций, но у каждой есть десятки вариантов, остатки обновляются каждые несколько минут, а пользователи постоянно комбинируют фильтры.

Во втором случае сервер может испытывать гораздо более серьёзную нагрузку. Ему приходится не просто читать готовую страницу, а пересчитывать выборки, проверять наличие, сортировать результаты, обращаться к поисковому индексу и синхронизироваться с внешними системами.

У маркетплейса картина ещё сложнее. Помимо каталога, работают личные кабинеты продавцов, импорт прайс-листов, модерация, отзывы, рекомендации, корзина, заказы, уведомления и аналитика. Один товар может иметь несколько продавцов, цен, складов и правил доставки. Формальные 100 тысяч карточек в интерфейсе легко превращаются в миллионы связанных записей внутри базы.

Поэтому первый вопрос должен звучать не «сколько у нас товаров?», а «какую работу инфраструктура выполняет с этими товарами?».

Какие данные собрать перед заказом сервера

Выбирать конфигурацию по предположениям — всё равно что строить склад, не зная размеров коробок и числа ежедневных отгрузок. Нужен хотя бы упрощённый профиль нагрузки.

Пиковое количество запросов

Среднее значение почти всегда выглядит безобидно. Допустим, в течение суток магазин получает 20 запросов в секунду. Но после рекламной рассылки показатель может вырасти до 150–200 запросов, а в первые минуты распродажи — ещё выше.

Считать нужно не только посещения. Открытие одной страницы каталога может вызвать несколько обращений к API, базе данных, кешу и поисковому сервису.

Для предварительной оценки можно использовать простую модель:

Пиковая нагрузка =
  обычная нагрузка × коэффициент всплеска + фоновые операции

Фоновыми операциями часто забывают считать импорт товаров, обновление остатков, генерацию изображений, построение поискового индекса и выгрузку заказов. Между тем такой процесс способен занять диск и процессор именно тогда, когда на сайт приходит больше всего покупателей.

Количество одновременных пользователей

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

Важно знать не только общее число сессий, но и пользовательские сценарии

• какая доля аудитории открывает карточки

• сколько посетителей использует поиск

• как часто применяются фильтры

• сколько товаров добавляют в корзину

• сколько заказов оформляется в минуту

запускаются ли в это время импорты и интеграции.

Частота обновления каталога

Статичный каталог можно хорошо кешировать. Если же цены и остатки меняются каждую минуту, задача становится сложнее: данные нужно быстро записать в основную базу, передать в кеш, обновить поисковый индекс и показать пользователю актуальное значение.

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

Рабочий набор данных

Размер всей базы и объём данных, с которыми приложение активно работает, — не одно и то же.

Например, база занимает 800 ГБ, но 90% запросов приходится на популярные категории, актуальные остатки и товары, добавленные за последние месяцы. Этот «горячий» набор желательно удерживать в оперативной памяти и системном файловом кеше. Тогда сервер реже обращается к диску и быстрее отвечает пользователям.

Объём изображений

В каталоге изображения нередко занимают больше места, чем все таблицы базы данных вместе взятые.

Возьмём условный проект

• 300 тысяч товаров

• шесть фотографий на товар

• оригинал размером около 1,2 МБ

несколько уменьшенных версий общим размером около 450 КБ.

Получается примерно 3 ТБ файлов ещё до учёта резервных копий, истории изменений и дальнейшего роста. Хранить всё это на том же диске, где находится база данных, — плохая идея: два совершенно разных типа нагрузки начинают бороться за один ресурс.

Не заставляйте один сервер делать всё

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

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

Для развивающегося каталога разумная схема выглядит так:

Веб-сервер и приложение → запросы пользователей
Redis → кеш и сессии
Основная БД → товары, цены, остатки, заказы
Поисковый движок → полнотекст и фильтры
Объектное хранилище + CDN → изображения
Очередь → импорт, уведомления, превью, переиндексация

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

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

Такой подход обычно дешевле, чем бесконечно увеличивать один огромный сервер.

Процессор, память и диски: что важнее для каталога

Универсального победителя нет. Каждый ресурс отвечает за свою часть работы, а узкое место способно перемещаться после очередной оптимизации.

Процессор: важна производительность на ядро

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

Скорость отдельного ядра особенно важна для

• выполнения коротких SQL-запросов

• обработки одного HTTP-запроса

• работы PHP, Node.js, Python или другого серверного стека

• расчёта отдельных фильтров

• формирования товарной карточки

сериализации большого ответа API.

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

Практический вывод прост: для базы и приложения лучше выбирать современный процессор с хорошей производительностью на ядро, а не старую модель с внушительным, но малоэффективным числом потоков.

Если импорт или обработка изображений регулярно загружают CPU на 100%, эти задачи стоит вынести в отдельные воркеры. Покупатель не должен ждать открытия карточки только потому, что сервер в этот момент создаёт десять тысяч миниатюр.

Оперативная память: главный запас скорости

Оперативная память нужна не только приложению. Её используют

• кеш базы данных

• файловый кеш операционной системы

• Redis

• поисковый движок

• очереди

• процессы веб-сервера

• сортировки и объединения SQL-запросов

активные соединения.

Особенно осторожно нужно настраивать параметры памяти базы. Например, в PostgreSQL ресурсы для сортировки и хеширования могут выделяться не один раз на весь сервер, а отдельно для разных операций и рабочих процессов. Завышенная настройка при высокой параллельности легко приводит к резкому росту потребления RAM.

Сервер не должен жить на границе доступной памяти. Как только система начинает активно использовать swap, задержки могут вырасти непредсказуемо. Для каталога это выглядит неприятно: сегодня фильтр открывается за 200 миллисекунд, а через минуту — за четыре секунды.

Выбирать объём RAM стоит по размеру активного набора данных и числу одновременно работающих сервисов. Если база, Redis и поиск размещены вместе, их потребности нужно складывать, а не оценивать по отдельности.

Диски: объём важен, но задержка важнее

Большой каталог создаёт множество мелких случайных чтений и записей. База обновляет индексы, фиксирует транзакции, создаёт временные файлы и читает данные из разных участков хранилища.

Поэтому для нагруженной базы предпочтительны NVMe-накопители. Они особенно заметно помогают там, где рабочий набор уже не помещается в RAM или выполняются массовые обновления.

Смотреть нужно не только на общий объём диска, но и на

• производительность случайных операций

• задержку чтения и записи

• допустимую интенсивность записи

• наличие резервирования

• скорость восстановления после сбоя

фактические ограничения дисковой подсистемы у провайдера.

Для критичной базы разумно использовать зеркалирование или другой подходящий вариант резервирования. Но важно помнить: RAID защищает от части аппаратных отказов, а не от ошибочного удаления таблицы, повреждения данных или неудачной миграции. Резервные копии всё равно обязательны.

База данных: фундамент большого каталога

Мощный сервер не исправляет неудачную структуру данных. Он лишь позволяет проблеме дольше оставаться незаметной.

Индексы должны соответствовать реальным запросам

Индекс помогает базе быстрее находить нужные строки, но занимает место и добавляет работу при вставке или обновлении данных. Поэтому стратегия «проиндексируем каждое поле на всякий случай» редко заканчивается хорошо. Документация PostgreSQL прямо отмечает, что индексы ускоряют получение строк, но создают дополнительную нагрузку и должны использоваться обоснованно.

Предположим, покупатель выбирает

• категорию

• бренд

• наличие

• диапазон цены

сортировку по популярности.

Отдельный индекс только по цене может оказаться недостаточным. Базе приходится учитывать сочетание условий и порядок сортировки. Здесь могут понадобиться составные, частичные или покрывающие индексы — в зависимости от конкретной СУБД и структуры запроса.

Решения нужно принимать по плану выполнения, а не по интуиции. В PostgreSQL для этого используют EXPLAIN и EXPLAIN ANALYZE: инструменты показывают выбранный план, фактическое время, число обработанных строк и обращения к буферам. При этом EXPLAIN ANALYZE действительно выполняет запрос, поэтому изменяющие данные операции следует проверять особенно осторожно.

Хорошая привычка — регулярно собирать статистику тяжёлых запросов. В PostgreSQL для этого может использоваться pg_stat_statements, который учитывает время планирования и выполнения, число вызовов, чтение блоков, временные файлы и другие метрики.

Не пересчитывайте одно и то же при каждом открытии страницы

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

Часто выгоднее хранить подготовленное значение и обновлять его после соответствующего события либо по расписанию. Это пример денормализации: часть данных дублируется ради более быстрого чтения.

У метода есть цена — нужно следить за актуальностью. Однако для горячих страниц он способен значительно снизить число тяжёлых запросов.

Контролируйте количество соединений

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

Пул соединений позволяет ограничить их количество и повторно использовать уже открытые подключения. Пользовательские запросы становятся посетителями ресторана, а соединения — столиками: нет необходимости каждый раз строить новый стол, достаточно грамотно управлять существующими.

Реплика помогает чтению, но не лечит всё

Если каталог в основном читают, часть запросов можно направить на реплику. Основной сервер продолжит принимать изменения, а резервный — обслуживать отдельные страницы, отчёты или интеграции.

Однако репликация может работать с задержкой. Пользователь только что изменил цену, а читающая реплика ещё показывает старое значение. PostgreSQL отдельно предупреждает, что данные на standby-сервере могут отставать от primary, поэтому одновременные запросы способны возвращать разные результаты.

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

Импорт не должен парализовать магазин

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

Практичная схема выглядит иначе:

1. Файл проверяется до загрузки в основные таблицы
2. Данные → временная область
3. Изменения пакетами
4. Обновлённые товары → очередь переиндексации
5. Изображения → отдельные воркеры
6. Прогресс и ошибки → мониторинг

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

Кеш: снимайте нагрузку, но не теряйте актуальность

Кеш полезен там, где одинаковый результат запрашивается много раз. Он позволяет не обращаться к базе и не выполнять повторные вычисления.

Главная сложность заключается не в сохранении данных, а в правильном удалении устаревшей версии.

Используйте несколько уровней кеширования

Первый уровень — браузер и CDN. Изображения, стили и скрипты можно хранить долго, особенно если имя файла содержит версию или хеш. HTTP-заголовки Cache-Control, ETag и связанные механизмы позволяют управлять сроком жизни и повторной проверкой ресурсов.

Второй уровень — кеш веб-сервера или reverse proxy. Он может отдавать готовые публичные страницы и не запускать приложение для каждого запроса.

Третий уровень — кеш приложения. Здесь сохраняются меню, настройки, популярные категории, результаты тяжёлых запросов и подготовленные фрагменты страниц.

Четвёртый уровень — in-memory-хранилище, чаще всего Redis. Оно подходит для сессий, счётчиков, временных результатов, токенов, ограничителей запросов и других быстро меняющихся данных.

Для разных данных нужен разный срок жизни

Нет единственного правильного TTL.

Описание товара может оставаться в кеше несколько часов. Список популярных категорий — десятки минут. Цена — минуты или секунды. Остаток перед оформлением заказа лучше проверить в основной системе ещё раз.

Пример разумного разделения:

описание и характеристики → длительный кеш
список категорий → средний TTL
поисковая выдача → короткий TTL
цена → короткий TTL + сброс по событию
остаток → очень короткий TTL или прямое чтение
корзина → персональное хранилище
заказ и платёж → без общего публичного кеша

Redis не является бездонным. При достижении лимита памяти поведение зависит от выбранной политики вытеснения: система может удалять недавно неиспользуемые или редко используемые ключи, ключи с ближайшим сроком истечения либо вообще отклонять новые записи. Политику необходимо выбирать осознанно и контролировать число evictions.

Защититесь от лавины после истечения кеша

Представим популярную страницу категории. Её кеш истёк, и в ту же секунду приходит тысяча запросов. Если каждый запрос отправится в базу за новой версией, кеш не поможет — он сам создаст пик нагрузки.

Это называют cache stampede, или лавиной кеша.

Снизить риск помогают

• небольшое случайное отклонение TTL

• блокировка на пересчёт одного ключа

• фоновое обновление до истечения срока

• выдача слегка устаревшего результата во время обновления

предварительное прогревание популярных страниц.

Кеш должен работать как амортизатор, а не как люк, который внезапно открывается под ногами базы данных.

Изображения: вынесите тяжёлые файлы за пределы основного сервера

Фотографии товаров не стоит хранить в таблицах базы данных. База должна управлять товарами, ценами и заказами, а не перекачивать мегабайты изображений.

Более устойчивая схема состоит из трёх частей:

Объектное хранилище → оригиналы и производные
CDN → раздача пользователям
База → только id, URL, размеры, метаданные

Так основной сервер освобождается от тысяч однотипных запросов, а медиафайлы масштабируются отдельно от приложения.

Не отдавайте оригинал в товарной плитке

Если фотография загружена в разрешении 4000 × 3000 пикселей, нет смысла отправлять её в блок шириной 300 пикселей.

Для одного изображения обычно создают несколько вариантов

• маленький для списка товаров

• средний для карточки

• крупный для увеличения

при необходимости — версии для экранов разной плотности.

Современные браузерные механизмы srcset, sizes и <picture> позволяют выбирать подходящий размер и формат. WebP и AVIF могут уменьшить объём передаваемых данных, но количество вариантов тоже нужно контролировать: каждая дополнительная версия занимает место и создаёт отдельный объект в кеше.

Обрабатывайте изображения в фоне

Пользователь или продавец загружает оригинал и сразу получает подтверждение. После этого задача отправляется в очередь, а воркеры:

• проверяют файл

• удаляют потенциально опасные метаданные

• создают нужные размеры

• конвертируют форматы

• оптимизируют качество

• загружают результат в хранилище

обновляют статус в базе.

Если обработка не удалась, задача повторяется. Такой подход не заставляет веб-приложение ждать завершения тяжёлой операции и позволяет увеличивать число воркеров независимо от основного сервера.

Поиск и фильтры: когда возможностей SQL уже не хватает

Для небольшого каталога поиск можно реализовать средствами основной базы. Это упрощает архитектуру и избавляет от синхронизации нескольких систем.

Отдельный поисковый движок становится полезен, когда проекту нужны

• полнотекстовый поиск по нескольким полям

• исправление опечаток

• поиск по синонимам

• управление релевантностью

• автодополнение

• сложные фильтры

• подсчёт количества товаров по значениям

• сортировка по нескольким факторам

поиск по миллионам документов.

Фильтры с числами рядом — «бренд: 214», «в наличии: 860», «до 10 000 рублей: 375» — называют фасетами. Поисковые системы рассчитывают такие группы и диапазоны в рамках запроса, позволяя последовательно сужать выдачу.

Поисковый индекс не должен быть источником истины

Основная база хранит достоверные сведения о товаре, цене и остатке. Поисковый индекс — оптимизированная копия, которую можно пересоздать.

Типовой процесс обновления выглядит так:

1. Изменение в основной БД
2. Приложение создаёт событие
3. Событие → очередь
4. Индексатор обновляет документ
5. Мониторинг задержки и ошибок

Если поисковый сервис временно недоступен, изменение не должно пропасть. Оно остаётся в очереди и применяется после восстановления.

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

Не превращайте каждый атрибут в фильтр

У товара могут быть сотни характеристик, но покупатель использует лишь часть из них.

Если для каждой характеристики строить фасеты, поисковый запрос станет тяжелее, индекс разрастётся, а интерфейс заполнится бесполезными переключателями.

Лучше определить набор фильтров для каждой категории. Для ноутбуков важны процессор, объём памяти и диагональ. Для одежды — размер, материал и цвет. Для мебели — габариты и тип помещения.

Хорошая фильтрация начинается не с сервера, а с понятной модели каталога.

Как подготовиться к пиковому трафику

Пик создаёт не только Чёрная пятница. Нагрузка резко растёт после телевизионной рекламы, массовой рассылки, выхода популярного товара, публикации у блогера или запуска распродажи.

Иногда всплеск вообще не связан с покупателями. Каталог могут одновременно обходить поисковые роботы, парсеры цен и партнёрские системы.

Проверяйте реальные сценарии, а не только главную страницу

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

В сценарий стоит включить

• открытие каталога

• переключение страниц

• поиск

• несколько комбинаций фильтров

• карточку товара

• добавление в корзину

• авторизацию

• оформление заказа

• обращение к API

• обновление остатков

фоновый импорт.

Инструменты нагрузочного тестирования позволяют моделировать разные группы виртуальных пользователей, скорость поступления запросов и параллельное выполнение нескольких сценариев. Например, k6 поддерживает отдельные сценарии с постоянным или постепенно растущим числом пользователей и заданной интенсивностью запросов.

Смотреть нужно не только на среднее время ответа. Гораздо полезнее p95 и p99 — границы, в которые укладываются 95% и 99% запросов. Среднее значение может выглядеть прекрасно, пока небольшая, но важная часть покупателей ждёт по десять секунд.

Оставляйте запас

Сервер, который во время обычной работы постоянно загружен на 90–100%, уже не имеет пространства для манёвра. Достаточно тяжёлого запроса, резервного копирования или краткого всплеска, чтобы очередь начала расти.

Размер запаса зависит от характера проекта. Если трафик стабилен и хорошо прогнозируется, он может быть умеренным. Если магазин зависит от рекламных запусков, лучше предусмотреть более широкое окно.

Главное — оценивать запас по результатам испытаний, а не по свободным гигабайтам в панели управления.

Переводите тяжёлые операции в очередь

Пользователь не обязан ждать, пока система:

• отправит письмо

• сформирует PDF

• обновит рекомендации

• передаст заказ во внешнюю ERP

• пересчитает аналитику

построит поисковый документ.

Сначала нужно надёжно зафиксировать действие, затем передать фоновую работу воркерам.

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

Предусмотрите упрощённый режим

Во время экстремального пика можно временно отключить необязательные функции:

• персональные рекомендации

• сложные блоки похожих товаров

• точные счётчики в каждом фильтре

• тяжёлую аналитику

• часть внешних интеграций

фоновые экспорты.

Карточка, корзина и оформление заказа должны получить ресурсы первыми. Лучше показать покупателю чуть менее персонализированную страницу, чем красивую ошибку 500.

VPS/VDS или выделенный сервер

Тип сервера следует выбирать после оценки архитектуры. Сам по себе переход на выделенную машину не исправит медленные запросы, а виртуальный сервер не обязательно является слабым решением.

Для растущего проекта часто подходит гибридная схема. Приложение и фоновые воркеры размещаются на нескольких VPS/VDS, а база данных получает выделенный сервер с быстрыми NVMe и большим объёмом RAM.

Следующий шаг — резервная база, отдельные Redis и поиск. Так инфраструктура развивается постепенно, а не превращается в дорогой кластер раньше, чем он действительно понадобится.

Примерные конфигурации

Ниже приведены стартовые инженерные ориентиры, а не универсальные нормативы. Каталог с тяжёлыми фильтрами может перерасти указанную конфигурацию раньше, а хорошо оптимизированный проект — работать на ней гораздо дольше.

Небольшой или новый каталог

Примерный профиль:

• до 50–100 тысяч товарных позиций

• умеренная посещаемость

• редкие импорты

• простой поиск

нет резких рекламных всплесков.

В качестве отправной точки можно рассматривать:

• 4–8 производительных vCPU

• 16–32 ГБ RAM

• 200–500 ГБ NVMe

• отдельное внешнее хранилище для изображений

• Redis с ограниченным объёмом памяти

• ежедневные резервные копии

мониторинг CPU, RAM, дисков и времени ответа.

Приложение и база ещё могут находиться на одном VPS/VDS. Но поиск и обработку изображений лучше с самого начала проектировать так, чтобы их можно было вынести без полной переделки системы.

Растущий интернет-магазин

Примерный профиль:

• 100–500 тысяч SKU и вариантов

• активные фильтры

• частое обновление цен и остатков

• несколько интеграций

заметные дневные и рекламные пики.

Разумный вариант:

• отдельный сервер приложения с 8–16 vCPU и 32–64 ГБ RAM

• сервер базы с 8–16 производительными ядрами и 64–128 ГБ RAM

• резервируемое NVMe-хранилище

• Redis на отдельном узле или с гарантированным лимитом памяти

• поисковый сервер с 16–32 ГБ RAM

• объектное хранилище и CDN

• очередь фоновых задач

балансировщик с возможностью добавить второй сервер приложения.

Здесь уже важно тестировать не только общую мощность, но и отказ отдельных компонентов. Например, что увидит пользователь, если Redis перезапускается или поисковый сервер временно недоступен?

Крупный каталог или маркетплейс

Примерный профиль:

• от нескольких сотен тысяч до миллионов товаров и предложений

• много продавцов, складов и вариантов

• непрерывные импорты

• развитый поиск

• серьёзные пики

высокие требования к доступности.

Возможная архитектура:

• два и более сервера приложения за балансировщиком

• выделенный сервер базы с 16–32 производительными ядрами и 128–256 ГБ RAM

• резервный сервер базы

• отдельный кластер поиска

• отдельный Redis

• несколько групп фоновых воркеров

• объектное хранилище с CDN

• централизованные логи и метрики

• автоматизированные резервные копии

заранее проверенный план аварийного переключения.

На этом уровне важнее не купить «самый мощный сервер», а убрать единичные точки отказа. Если вся система зависит от одного узла, его внушительные характеристики не делают архитектуру отказоустойчивой.

Сеть, расположение и защита

Даже быстрый сервер может ощущаться медленным, если он находится далеко от основной аудитории. Локацию желательно выбирать с учётом географии покупателей, внешних интеграций и требований к размещению данных.

Для каталога с большим количеством изображений также важны

• пропускная способность порта

• ограничения по трафику

• стабильность маршрутов

• скорость соединения с объектным хранилищем

• возможность подключить CDN

защита от сетевых и прикладных атак.

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

King Servers предлагает VPS/VDS и выделенные серверы в России, Нидерландах и США, а также конфигурации на Intel и AMD, NVMe-накопители и варианты с многоуровневой защитой от DDoS. Техническая поддержка доступна круглосуточно.

Резервное копирование: хранить мало, восстанавливать быстро

Фраза «у нас есть бэкап» ещё не означает, что данные защищены.

Нужно заранее ответить на два вопроса

• сколько данных бизнес готов потерять

сколько времени допустимо потратить на восстановление.

RPO — сколько данных бизнес готов потерять
RTO — сколько времени допустимо на восстановление

Если остатки и заказы изменяются каждую минуту, ночной снимок может оказаться недостаточным. Для базы можно сочетать полные резервные копии с архивированием журнала транзакций и восстановлением на выбранный момент времени. PostgreSQL, например, поддерживает базовые копии, непрерывное архивирование WAL и point-in-time recovery.

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

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

Какие метрики контролировать после запуска

Сервер нельзя подобрать один раз и забыть. Каталог растёт, пользователи меняют поведение, появляются новые фильтры, интеграции и фоновые процессы.

Минимальный набор наблюдения включает несколько уровней.

Пользовательский уровень

• время открытия каталога

• время ответа поиска

• скорость применения фильтров

• открытие карточки

• добавление в корзину

• успешность оформления заказа

доля ошибок.

Приложение

• количество запросов в секунду

• p95 и p99 времени ответа

• число ошибок 4xx и 5xx

• занятость пулов

• длительность внешних запросов

количество и возраст фоновых задач.

База данных

• самые тяжёлые SQL-запросы

• блокировки

• число активных соединений

• чтение с диска

• временные файлы

• объём журналов

• задержка репликации

продолжительность транзакций.

PostgreSQL предоставляет системные представления для наблюдения за активностью, ожиданиями, репликацией и накопленной статистикой. Эти данные позволяют отличить нехватку ресурсов от блокировки, неудачного запроса или проблемы с вводом-выводом.

Redis

• используемая память

• hit rate

• число вытесненных ключей

• количество подключений

• задержка команд

самые горячие ключи.

Поиск

• время ответа

• доля запросов без результатов

• ошибки и отклонённые запросы

• скорость индексации

• задержка обновления документов

• размер индекса

нагрузка на память и диски.

Сервер

• CPU и нагрузка по ядрам

• RAM и swap

• дисковые задержки

• длина очереди ввода-вывода

• свободное место

• сетевой трафик

• потеря пакетов

температура и аппаратные ошибки для выделенных серверов.

Технические метрики полезно связывать с бизнесом. Если время ответа фильтра выросло с 300 миллисекунд до двух секунд, а конверсия одновременно снизилась, команда получает аргумент для оптимизации, понятный не только системному администратору.

Чек-лист перед заказом сервера

Зафиксировать текущее и прогнозируемое количество товаров, вариантов и предложений.

Измерить обычный и пиковый RPS.

Описать основные пользовательские сценарии.

Оценить размер базы и активного набора данных.

Посчитать объём оригиналов и производных изображений.

Определить частоту импорта цен и остатков.

Решить, нужен ли отдельный поисковый движок.

Выбрать данные и страницы, которые можно кешировать.

Определить правила сброса кеша.

Провести нагрузочное тестирование поиска, фильтров, корзины и заказа.

Проверить работу системы при одновременном импорте.

Предусмотреть запас CPU, RAM и дисковой производительности.

Выбрать подходящую локацию сервера.

Подготовить защиту от DDoS и ограничение подозрительных запросов.

Настроить резервные копии вне рабочего сервера.

Провести тестовое восстановление.

Подключить мониторинг, централизованные логи и уведомления.

Составить план вертикального и горизонтального масштабирования.

Проверить, как система работает без Redis, поиска или одного сервера приложения.

Назначить ответственных за действия во время пиков и аварий.

Как не переплачивать за инфраструктуру

Экономия начинается не с выбора самого дешёвого тарифа, а с понимания узкого места.

Если 80% времени процессор простаивает, переход на вдвое более мощную модель ничего не даст. Если база постоянно читает с медленного диска, дополнительные ядра тоже не помогут. Если изображения забивают канал, нужно работать с CDN и форматами файлов, а не увеличивать RAM.

Хорошая последовательность выглядит так

Измерить текущую работу системы.

Найти ограничивающий ресурс.

Устранить очевидные проблемы в коде и запросах.

Провести повторный тест.

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

Такой подход защищает сразу от двух крайностей: покупки слабого сервера «на пробу» и аренды дорогой машины «на всякий случай».

Вместо огромного запаса на несколько лет полезнее иметь понятный план роста. Например: до определённой нагрузки база и приложение работают вместе, затем база переезжает на отдельный узел, после этого добавляются поиск, реплика и второй сервер приложения.

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

Итог

Сервер для маркетплейса или большого каталога выбирают не по одной цифре. Количество товаров — лишь начало расчёта. Настоящую нагрузку создают сочетания фильтров, частота обновления цен, поисковые запросы, изображения, фоновые импорты и резкие всплески аудитории.

Для базы особенно важны производительный процессор, достаточный объём RAM и быстрые NVMe-диски. Кеш снимает повторную нагрузку, но требует продуманной инвалидации. Изображения лучше хранить отдельно и раздавать через CDN. При развитом поиске и фасетах стоит выделить отдельный поисковый сервис, оставив основную базу источником достоверных данных.

А главное — конфигурацию нужно подтверждать нагрузочным тестированием и мониторингом. Сервер на бумаге может выглядеть мощно, но только реальные сценарии покажут, сколько покупателей он обслужит без замедления.

В King Servers можно подобрать VPS/VDS или выделенную конфигурацию под базу данных, приложение, кеш и поиск, а затем масштабировать компоненты по мере роста проекта. Чем раньше инфраструктура получает понятный план развития, тем спокойнее магазин встречает рекламные кампании, распродажи и первые по-настоящему большие пики.