Сервер под пиковую нагрузку: как пережить распродажу

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

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

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

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

Вторая причина важнее. «Помощнее» — это не одно измерение. Под нагрузкой первым сдаётся что-то одно: чаще всего база данных, иногда единственный процесс приложения, иногда исходящий канал. Увеличение памяти не поможет, если упирается диск, а быстрый диск бесполезен, если запрос к базе ждёт блокировки. Пока не известно, что именно упирается, «помощнее» — это покупка наугад.

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

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

• База данных. Растёт хуже всех: её нельзя просто продублировать, а под нагрузкой она первой упирается в диск и блокировки.
• Приложение и фоновые задачи. Растут лучше всех: добавили ещё одну копию — стало вдвое больше.
• Статика и картинки. Не должны жить на том же сервере вовсе: их место в объектном хранилище, откуда они отдаются, не занимая процессор.
• Исходящий трафик. Считается отдельно и заканчивается внезапно: именно он превращает удачную распродажу в счёт за превышение.

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

Дальше — что из этого во что превращается у провайдеров, которых мы ведём. Цены сверены с их сайтами 15 августа 2026 года, все — при оплате за месяц.

База данных — единственное, за что имеет смысл платить круглый год. Здесь выбор из двух подходов. Свой сервер: дешевле, но обновления, резервные копии и репликация ложатся на вас. Управляемая база: у Timeweb Cloud она начинается с 790 ₽/мес, и за эти деньги копии и обновления делает провайдер.

Приложение в будни живёт на скромной машине. Младший сервер у AdminVPS стоит 299 ₽/мес при оплате за месяц, у Timeweb Cloud — 900 ₽/мес, публичный IPv4 входит в тариф.

Отдельно стоит сказать про администрирование. Если в команде нет человека, который ночью починит упавший сервер, смотрите в сторону AdminVPS: там администрирование Linux входит в тариф, а не продаётся отдельной услугой.

Всё, что нужно только на пик, берётся почасово и гасится после. Из троих, кого мы ведём, почасовая оплата есть у Timeweb Cloud.

Порядок цены посчитать легко. Тариф Cloud MSK 100 — 8 ядер, 12 ГБ памяти, 100 ГБ NVMe — стоит 2 790 ₽/мес. Трое суток это семьдесят два часа, то есть примерно десятая часть месяца: около 280 ₽ за разовое усиление вдесятеро. Точную почасовую ставку смотрите у провайдера — она может немного отличаться от деления месячной цены на число часов.

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

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

Список для письма провайдеру. Он короткий, но каждый пункт хоть раз кого-то подводил:

• За какое время поднимается дополнительный сервер: минуты по кнопке или заявка с ожиданием. Это главный пункт — всё остальное вторично.
• Тарификация посекундная, почасовая или посуточная. Сервер, поднятый на три дня, при посуточной оплате обойдётся как неделя.
• Есть ли снимки и за сколько разворачивается копия. Снимок, который восстанавливается сорок минут, в пик бесполезен.
• Что входит в защиту от DDoS и с какого объёма атаки она включается. Рекламная кампания и атака для фильтра выглядят одинаково.
• SLA и как считается компенсация простоя.
• Можно ли увеличить диск без остановки — и можно ли потом уменьшить. Пункт неочевидный: у многих провайдеров диск растёт на ходу, а уменьшить его нельзя вовсе. После распродажи вы останетесь с диском, за который платите весь год.

Если у вас не пик на три дня, а постоянный исходящий трафик — лимиты и ширина порта важнее скорости подъёма. Про них отдельно: инфраструктура для сбора данных.

• Не переносите инфраструктуру за неделю до пика. Переезд сам по себе рискованнее нагрузки.
• Не масштабируйте базу вместе с приложением: копий приложения может быть много, база остаётся одна.
• Не оставляйте статику на сервере приложения. В пик она съест канал, который нужен заказам.
• Не забывайте погасить временные серверы. Забытый на месяц Cloud MSK 100 стоит не 280 ₽, а 2 790 ₽.
• Не полагайтесь на «должно выдержать». Час репетиции стоит несколько рублей и отвечает точно.

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

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

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