Линейка HighFreq или как выжать из облака максимум для инференса, ML и других высоких нагрузок

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

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

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

Небольшое предисловие

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

Многие считают, что «премиальное железо» всегда лучше. Это не так! Если запустить простой лендинг или интернет‑магазин на мощнейшем процессоре с частотой 3,9 ГГц, сайт не станет работать быстрее — он просто не загрузит вычислительные ресурсы даже на десятую часть. В итоге придется переплачивать за мощности, которые не участвуют в деле — классический пример когда «деньги на ветер».

С другой стороны, попытка сэкономить, запустив ML-модель на обычном процессоре вместо видеокарты, приведет к тому, что задача будет обрабатываться годами.

Секрет эффективности — в правильном подборе инструментов.

Стандартная линейка — в ее основе выделенные ядра процессоров AMD 2,2−2,4 ГГц, гарантирующие изоляцию и производительность. Фиксированные конфигурации предлагают от 2 до 32 ядер, произвольные — до 232. Такие серверы отлично подходят для большинства сервисов: сайтов, корпоративных порталов, сред разработки. Стандартная линейка — это «рабочая лошадка», в которой сбалансировано соотношение компонентов для неспецифичных задач, что оптимально по цене и достаточно для 80% типовых случаев.

Высокочастотная линейка HighFreq — предлагает выделенные ядра процессоров AMD 3,0−3,6 ГГц в сочетании с быстрой памятью. Фиксированные конфигурации позволяют задействовать от 2 до 64 ядер, произвольные — до 176. HighFreq выручит там, где сказывается скорость каждого ядра — это базы данных, «1С: Предприятие», игровые серверы, торговые роботы. Многие процессы, как например транзакции в БД, не умеют распараллеливаться на множество ядер — им нужно одно, но очень быстрое. В таких случаях не получить прирост производительности простым увеличением их количества.

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

Наши герои

Виктор — технический директор крупного e-commerce проекта. Его компания готовится к «Черной пятнице», и он с тревогой вспоминает прошлый год. Тогда его инфраструктура, не рассчитанная на подобные пики, не справилась. Сайт начал «тормозить» под наплывом покупателей. Время ответа росло, страницы «буксовали», пользователи разбегались. Задача Виктора — обеспечить молниеносный отклик и абсолютную стабильность даже под пиковой нагрузкой.

Анна — руководитель разработки в стартапе, который запустил популярный сервис генерации изображений по текстовому описанию. В отличие от Виктора, ее проблема не в пиковых нагрузках, а в постоянной борьбе за низкую задержку для каждого пользователя. Анна развернула сервис на стандартных облачных серверах с GPU. Однако беспристрастные дашборды показывают удручающую картину: утилизация дорогих ускорителей едва достигает 30%. Деньги тратятся впустую, а дорогое железо простаивает в ожидании данных.

«Медленная» база данных

Для Виктора «Черная пятница» — это тысячи одновременных обращений: поиск товаров, проверка остатков, оформление заказов. Он анализирует метрики и видит, что узкое место — система управления базами данных. Даже при неполной загрузке всех ядер CPU продолжительность обработки запросов стремительно растет.

Это классическая ситуация для OLTP-нагрузок (Online Transaction Processing, онлайн-обработка транзакций). Многие операции в традиционных СУБД по своей природе однопоточны. Производительность упирается в таком случае в тактовую частоту, а не общее количество ядер. Их может быть и несколько десятков, но если критическая транзакция выполняется только на одном из них, то вся очередь будет ждать ее завершения.

Медленные запросы к БД напрямую увеличивают TTFB (Time to First Byte, время до первого байта). Считается, что хороший показатель TTFB — менее 800 мс, а все, что выше 1 800 мс — уже проблема, которая негативно влияет на SEO‑ранжирование и конверсию, если быстрота взаимодействия с БД напрямую сказывается на скорости веб‑страницы.

Решение № 1 — переход на линейку HighFreq

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

В серверах HighFreq — самые производительные процессоры, такие как Intel^® Xeon™ Gold 6354 или AMD EPYC™ 9474F. Под нагрузкой частота автоматически увеличивается до 3,95 ГГц. Память — DDR5 до 4,8 ГГц. Высокая однопоточная скорость работы подтверждается независимыми тестами.

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

• системы управления базами данных (СУБД);
• некоторые алгоритмы высокочастотного трейдинга (HFT);
• приложения на платформах 1С и Битрикс24;
• игровые серверы.

Чтобы проверить гипотезу, Виктор создает тестовый стенд. Он разворачивает две копии своей инфраструктуры на конфигурациях с одинаковым числом vCPU и объемом RAM: одну на стандартной линейке, другую — на HighFreq. Затем запускает нагрузочное тестирование, имитирующее наплыв покупателей.

На стандартной машине при росте нагрузки среднее время ответа начинает расти экспоненциально. На сервере HighFreq оно остается низким и стабильным гораздо дольше. Высокая тактовая частота позволяет обрабатывать транзакции значительно быстрее, очередь запросов не накапливается, и сайт остается отзывчивым.

Решение № 2 — быстрые локальные диски

Разобравшись с CPU, Виктор замечает новое узкое место. Теперь производительность упирается в дисковую подсистему, что видно по высоким значениям метрики IO Wait. Особенно это проявляется на действиях, требующих множества хаотичных операций чтения и записи: обновление остатков на складе, проверка статусов заказов, сохранение пользовательских сессий.

Самый производительный процессор бесполезен, если он постоянно простаивает в ожидании данных с диска. Чтобы этого не случилось, все серверы линейки HighFreq в обязательном порядке комплектуются быстрыми локальными NVMe SSD, подключенными напрямую по высокоскоростной шине PCIe.

В отличие от сетевых дисков, локальные находятся непосредственно на том же физическом сервере, что и виртуальная машина. Время отклика — не более 1 мс. Задержки на пути обмена данными перестают быть «узким местом», а скорости 300 МБ/с достаточно для большинства задач.

Разница критична для:

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

Для СУБД, где важна минимальная задержка каждой транзакции, разница колоссальна.

Итак, Виктор переносит свою базу данных на сервер HighFreq с локальным NVMe-диском и видит многократное снижение времени ответа на запросы. Он доволен — инфраструктура подобрана правильно.

Скорость для отказоустойвости и масштибирования

Однако полного спокойствия на душе нет. Чтобы пережить «Черную пятницу», одного, пусть и очень быстрого, сервера может быть недостаточно. Вдруг в работе ПО произойдет сбой? Что, если система или развернутые на ней многочисленные сервисы на какое‑то время перестанут реагировать на события внешнего мира?

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

Но вот беда! Возникает новое потенциальное «бутылочное горлышко». При активной репликации данных между мастер-сервером БД и его копиями, а также при интенсивном обмене информацией между веб-серверами и базой, универсальной сети 3 Гбит/с может не хватить. Реплики начнут отставать от мастера, появится промедление и в работе приложения.

Решение № 3 — сверхбыстрая сеть до 10 Гбит/с

Для таких задач в Selectel предусмотрена высокоскоростная сеть до 10 Гбит/с.

Она не только обеспечивает в несколько раз бо́льшую пропускную способность, что критически важно для кластерных систем, где постоянно идет обмен служебными сообщениями, репликация данных и распределенные транзакции. Например, данные с master-сервера высоконагруженной БД успевают передаваться на slave — задержка репликации минимальна. Так поддерживается консистентность и производительность всего комплекса.

Виктор объединяет все свои серверы в приватную сеть 10 Гбит/с. Теперь его архитектура не только быстра, но и надежна. Он выявил и устранил три узких места — CPU, диск, сеть — и готов к пиковым нагрузкам. Теперь Виктор спокоен: чем «чернее» окажется пятница, тем «зеленее» будет в бухгалтерии его проекта.

Голодающие GPU и высокая задержка инференса

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

• Холодный старт. Новый сервер запускается долго, потому что ему нужно скачать и загрузить в память GPU огромную модель из сетевого хранилища. Первый пользователь ждет и негодует.
• Высокая задержка. Даже на «прогретом железе» общее время от получения текстового запроса до выдачи готовой картинки значительно выше расчетного. Анализ метрик показывает, что мощные GPU периодически простаивают, ожидая данных от CPU.

Классическое «бутылочное горлышко» на этапе ввода-вывода! Графический процессор — это сверхмощный параллельный вычислитель, но производительность всей системы зависит от скорости подготовки и передачи ему данных. Если диск читается медленно или центральный процессор не справляется с препроцессингом, то видеопроцессор простаивает в ожидании нового батча.

Решение № 4 — GPU с быстрыми локальными дисками

Первое узкое место в пайплайне Анны — медленная загрузка моделей. Решение — использовать облачные серверы с GPU и быстрыми локальными NVMe-дисками. Скорость чтения таких устройств позволяет «кормить» данными память GPU без потери темпа.

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

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

Анна перенесла свой датасет на быстрый локальный диск сервера с GPU. Теперь тот не простаивает в ожидании данных.

Решение № 5 — оптимизация препроцессинга с HighFreq и GPU

Однако задержка на каждый отдельный запрос все еще неприемлема. Анна видит, что GPU не всегда загружен на 100%, в то время как CPU показывает пики активности. Узким местом стал препроцессинг — подготовка данных для модели.

Для каждого запроса пользователя система на CPU выполняет несколько последовательных шагов: токенизацию текста, то есть преобразование слов в числовые векторы, подготовку начального «шума», нормализацию данных, формирование итогового пакета (тензора) для отправки в GPU.

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

Протестировав комбинацию с линейкой HighFreq, Анна получила очевидный результат: высокочастотный CPU обрабатывает входящие текстовые запросы и подготавливает данные значительно быстрее. Конвейер «запрос → CPU → GPU → ответ» становится сбалансированным. Утилизация GPU приближается к 100%, а главное — среднее время генерации изображения для пользователя даже превзошло расчетное благодаря общей производительности системы.

Заключение

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

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

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

Высоконагруженная OLTP-база данных — сайт, CRM, биллинг

• Узкое место — производительность одного ядра CPU, задержка диска.
• Решение — линейка HighFreq с быстрыми локальными дисками NVMe дают максимальную скорость обработки транзакций, минимальное время ответа.

Отказоустойчивый кластер приложений/БД — микросервисы, репликация

• Узкое место — пропускная способность.
• Решение — высокоскоростная сеть 10 Гбит/с убирает лаг репликации, обеспечивает быстрый обмен данными между нодами.

Инференс ML-моделей в реальном времени — Generative AI, CV

• Узкое место — задержка загрузки моделей, скорость препроцессинга.
• Решение — GPU с быстрыми локальными дисками NVMe или линейка HighFreq, чтобы исключить задержку «холодного старта» и ускорить обработку каждого запроса.

Обучение ML-моделей — большие датасеты, особенно с мелкими файлами

• Узкое место — скорость чтения и записи данных.
• Решение — быстрые локальные диски NVMe позволят утилизировать ресурсы GPU на 100% и сократят время ожидания данных.

Хранение архивов, бэкапов, «холодных» данных

• Узкое место — стоимость хранения.
• Решение — сетевые диски или холодное и ледяное хранилище S3, у которых низкая стоимость за гигабайт, при этом они не требуют частого доступа.

В облаке могут быть не просто виртуальные серверы, но и гибкие и мощные строительные блоки для производительной IT-инфраструктуры. Попробуйте новые конфигурации в панели управления. Для каждой виртуальной машины из линейки HighFreq доступло до 176 ядер, 900 ГБ RAM и 2 ТБ локального диска. Если проект требует нестандартной конфигурации или нужна консультация по миграции, наша команда инженеров всегда готова помочь.