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

MAATRIX

Выбор конфигурации сервера почти всегда происходит одним из двух способов: либо по метрикам — реальным цифрам загрузки, либо по страху — «возьмём с запасом, мало ли что». Второй способ побеждает чаще, потому что он проще и не требует данных. Результат предсказуем: сервер, который на 70-80% состоит из оплаченного, но не используемого ресурса. В этой статье — методика, которая закрывает вопрос раз и навсегда: не разовый подбор тарифа, а процесс, который можно повторять при каждом пересмотре инфраструктуры. Она объединяет то, что мы разбирали по отдельности для CPU, RAM и диска, в единую последовательность шагов.

Почему «страх» — плохой советчик при выборе конфигурации

Панический запас на сервер обычно рождается из трёх источников. Первый — отсутствие данных: если вы не знаете, сколько ресурсов реально ест приложение, единственная стратегия — взять с большим запасом. Второй — память о прошлом инциденте: один раз не хватило CPU в пиковый день, и с тех пор конфигурация выбирается «с запасом на всякий случай», без разбора, что именно тогда произошло. Третий — культура компании: проще утвердить бюджет на избыточный сервер один раз, чем объяснять начальству, почему через полгода понадобится апгрейд.

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

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

Шаг 1. Соберите реальные метрики за представительный период

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

Ошибка первая: смотреть на нагрузку один раз. Снимок «top прямо сейчас» ничего не говорит о поведении системы в целом — вы можете попасть в затишье или, наоборот, в случайный всплеск от фонового задания. Нужны данные за представительный период — не пара часов, а как минимум одна-две недели, а лучше месяц, чтобы захватить недельную цикличность (будни/выходные), суточную (рабочие часы/ночь) и, если применимо, сезонность (конец месяца для биллинга, распродажи для e-commerce, отчётные периоды).

Ошибка вторая: смотреть только на средние значения. Средняя загрузка CPU в 15% ничего не говорит о том, что раз в сутки, во время построения отчётов, она на 20 минут улетает в 100% с очередью процессов. Средняя память в 40% не говорит о том, что раз в неделю, во время бэкапа, потребление подскакивает до 90% и один раз чуть не упёрлось в OOM. Именно перцентили и пики — а не средние — определяют, хватит ли вам ресурсов в критический момент.

Что нужно собрать по каждому ресурсу:

• CPU: средняя загрузка, 95-й и 99-й перцентиль, максимальные пики и их длительность, число ядер, которые реально используются одновременно (не путать с общей загрузкой — однопоточное приложение на 8-ядерном сервере может показывать «20% CPU» и одновременно упираться в потолок одного ядра).
• RAM: используемая память без учёта дискового кеша (кеш страниц Linux охотно займёт всё свободное — это нормально, а не признак нехватки), пиковое потребление, наличие свопа (даже единичные обращения к свопу — сигнал, что памяти впритык).
• Диск: занятое место и скорость его роста во времени (не абсолютное число, а тренд — гигабайт в неделю), IOPS и throughput в пиковые периоды, задержки операций чтения/записи под нагрузкой.
• Сеть, если приложение сетевого профиля: полоса в пиках, число одновременных соединений.

Собирать эти данные можно системными средствами (утилиты вроде top, vmstat, iostat, free, df дают мгновенный срез, но для истории и перцентилей нужен инструмент, который пишет метрики во времени — конкретный выбор зависит от вашего стека и в эту методику не входит). Про то, какие метрики смотреть каждый день, у нас есть отдельный разбор — то, что вы отслеживаете постоянно, и есть источник данных для пересмотра конфигурации.

Отдельно зафиксируйте контекст: какие процессы дают основную нагрузку, есть ли периодические тяжёлые задачи (бэкапы, индексация, batch-обработка, генерация отчётов), совпадают ли пики CPU, RAM и диска по времени или размазаны — это важно для следующего шага.

Шаг 2. Разберитесь, что означают собранные цифры

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

Ровная нагрузка с редкими пиками. Типично для веб-приложений и API: базовая нагрузка стабильна, раз в сутки-неделю случается всплеск (бэкап, отчёт, рассылка). Здесь важно не путать «средний профиль» с «пиковым профилем» — сервер должен пережить пик, но не обязан быть рассчитан так, будто пик длится постоянно.

Растущая нагрузка. Метрики показывают устойчивый тренд роста месяц к месяцу — это сигнал не «взять сервер с запасом на год вперёд», а взять конфигурацию под текущую нагрузку плюс обоснованный запас на ближайший горизонт планирования (обычно квартал), с чётким планом на апгрейд, когда тренд подойдёт к порогу. Тренд роста — единственная метрика, которая оправдывает запас именно на будущее, а не на текущий момент.

Batch-нагрузка. Если тяжёлая работа выполняется пакетами (ночная обработка данных, обучение моделей, рендеринг), пиковая загрузка CPU/RAM может быть в разы выше базовой, но короткой по времени. Здесь стоит отдельно оценить: можно ли вынести batch-нагрузку на отдельный ресурс (например, временно поднимаемый сервер под задачу) вместо того, чтобы держать постоянно оплачиваемую мощность под редкие часы работы.

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

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

Шаг 3. Заложите разумный запас — не панический, а обоснованный

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

Запас на измеренные пики. Вы уже знаете 95-99-й перцентиль и абсолютный максимум по каждому ресурсу за представительный период — конфигурация должна свободно покрывать этот максимум, а не среднюю нагрузку. Это не «дополнительный» запас сверху, а обязательная часть расчёта: без него сервер будет захлёбываться каждый раз, когда наступает штатный, регулярно повторяющийся пик.

Запас на измеренный тренд роста. Если по данным нагрузка растёт на измеримую величину от периода к периоду, добавьте запас под этот тренд на горизонт до следующего планового пересмотра конфигурации (шаг 4 ниже). Здесь важно не путать «растёт» с «может вырасти» — запас на рост считается по фактическому тренду, а не по надеждам на взрывной успех проекта.

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

Панический запас отличается от разумного тем, что не опирается ни на один из этих трёх источников — это произвольное число («возьмём вдвое больше»), которое не проверяется и не пересматривается. Разумный запас всегда можно объяснить: «столько нужно на измеренный пик, столько — на тренд роста за квартал, столько — на буфер», и каждая цифра при необходимости проверяется по собранным метрикам.

Отдельно стоит правило для RAM и диска: у обоих ресурсов исчерпание — это жёсткий отказ (OOM-killer или сервис, который не может писать данные), в отличие от CPU, где нехватка проявляется как деградация скорости, но не как аварийная остановка. Поэтому запас по памяти и диску имеет смысл держать чуть щедрее, чем по CPU, — это не панический запас, а поправка на разную цену ошибки. Подробнее о логике запаса по каждому ресурсу — в материалах про то, сколько оперативной памяти закладывать с запасом, и сколько дискового пространства закладывать с запасом.

Шаг 4. Выберите конфигурацию под метрики плюс запас

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

Полезно свести расчёт в таблицу — не для отчётности, а чтобы увидеть, какой ресурс на самом деле определяет выбор тарифа:

Как правило, один ресурс в этой таблице оказывается «узким горлом» — именно он и определяет минимальный подходящий тариф, а не сумма всех запросов сразу. Например, если по CPU и диску у вас солидный запас, а по RAM конфигурация впритык — тариф выбирается по памяти, и переплачивать за более мощный CPU только потому, что он «идёт в комплекте» со старшим тарифом по RAM, экономически не всегда оправдано: иногда выгоднее взять отдельно оптимизированную под память конфигурацию, если провайдер такие предлагает, чем брать самый мощный тариф целиком.

Здесь же стоит учитывать не только вертикальный выбор (более мощный тариф), но и горизонтальный (несколько серверов вместо одного большого) — особенно если нагрузка делится на независимые компоненты; у этих двух подходов разная экономика, но методика подбора метрик одинаково применима к выбору как одного сервера, так и конфигурации из нескольких. И не привязывайтесь намертво к одной линейке тарифов: если ваш профиль нагрузки нестандартный (например, много RAM при скромном CPU), может быть выгоднее конфигурация под конкретный узкий ресурс, чем самый мощный тариф целиком «для надёжности».

Шаг 5. Пересматривайте конфигурацию регулярно, а не один раз

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

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

Есть и внеплановые поводы для пересмотра — их стоит явно зафиксировать как триггеры, а не ждать, пока сервер начнёт «тормозить»:

• запас по любому из ресурсов исчерпался быстрее, чем планировалось (тренд роста оказался круче измеренного изначально);
• в мониторинге регулярно появляются пики, которых не было на этапе первого замера (новая фича, новый источник трафика, новая фоновая задача);
• добавился новый сервис на том же сервере, который меняет суммарный профиль нагрузки;
• прошёл инцидент нехватки ресурса — это повод не «взять с запасом на всякий случай», а разобрать, какой именно ресурс и насколько не хватило, и скорректировать расчёт точечно.

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

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

Частые вопросы