Представьте себе врача, который осматривает пациента раз в год. Пациент жалуется на усталость, врач кивает, назначает анализы – и через несколько недель выясняется, что проблема возникла ещё восемь месяцев назад. Лечить её теперь куда сложнее, чем если бы тогда стоял фитнес-трекер на запястье и каждый день снимал показатели.
Именно так выглядит традиционный подход к тестированию производительности суперкомпьютеров. Разработали программу, запустили на суперкомпьютере, получили цифры – и забыли до следующего большого теста. Где-то между этими моментами что-то пошло не так: обновили компилятор, изменили настройки планировщика задач, поменяли версию библиотеки. Программа вдруг стала работать на 30% медленнее. Кто виноват? Когда это случилось? Непонятно.
Команда, разрабатывающая фреймворк exaCB, решила поставить этот самый «фитнес-трекер» на один из самых мощных суперкомпьютеров Европы – систему JUPITER. И вот что из этого вышло.
Что такое «экзамасштаб» и почему это важно
Прежде чем разбираться с exaCB, нужно понять масштаб задачи. Слово «экзамасштаб» (exascale) означает вычислительную систему, способную выполнять 1018 операций с плавающей точкой в секунду. Это квинтиллион операций. Для сравнения: если бы каждый житель Земли делал по одному вычислению в секунду, всему человечеству потребовалось бы больше ста лет, чтобы сделать то, что такой компьютер выполняет за одну секунду.
JUPITER – это экзамасштабная система, развёрнутая в Юлихском суперкомпьютерном центре в Германии. Она создана для решения задач в области климатологии, материаловедения, молекулярной биологии, ядерной физики и десятков других научных областей. На такой системе одновременно работают сотни приложений, написанных разными командами на разных языках программирования, с разными алгоритмами и требованиями.
Вот здесь и начинается настоящий инженерный кошмар. Как убедиться, что все эти приложения работают корректно, эффективно и не деградируют со временем? Как поймать момент, когда одно из них начало потреблять вдвое больше энергии, не давая при этом больше результатов?
CI/CD: инструмент разработчиков, который пришёл в мир суперкомпьютеров
В мире обычной разработки программного обеспечения давно существует практика под названием непрерывная интеграция и непрерывная доставка (CI/CD – Continuous Integration / Continuous Delivery). Грубо говоря, это конвейер, который автоматически проверяет код каждый раз, когда разработчик вносит изменения. Написал новую функцию – система сама скомпилировала, прогнала тесты, проверила, не сломалось ли что-нибудь, и отчиталась.
Это как автоматическая проверка орфографии в текстовом редакторе: она работает постоянно, в фоновом режиме, и сообщает об ошибках сразу, а не когда вы уже отправили письмо.
Проблема в том, что обычные CI/CD-системы проверяют правильность работы кода, но не его производительность. Программа может работать корректно, но при этом делать это в два раза медленнее, чем раньше. Или потреблять значительно больше энергии. В мире ноутбуков это неприятно. В мире суперкомпьютеров, где счёт идёт на миллионы процессорных часов и мегаватты электроэнергии, это катастрофа.
Именно поэтому возникла концепция непрерывного бенчмаркинга (continuous benchmarking, CB) – расширение CI/CD, которое добавляет к проверке корректности ещё и постоянный мониторинг производительности и энергопотребления.
Знакомьтесь: exaCB
exaCB – это фреймворк (набор инструментов и правил) для организации непрерывного бенчмаркинга в масштабах экзамасштабных систем. Разработан он в контексте подготовки к запуску JUPITER и применялся в рамках программы JUREAP (JUPITER Research and Early Access Program) – своеобразного «периода раннего доступа», когда научные команды получили возможность тестировать свои приложения на системе ещё до её полного ввода в эксплуатацию.
Главная идея exaCB проста: пусть каждый запуск приложения на суперкомпьютере автоматически записывает данные о производительности в единую базу данных, откуда их можно в любой момент достать, сравнить и проанализировать.
Звучит логично. Но дьявол, как всегда, в деталях.
Архитектура: как это устроено внутри
Архитектура exaCB напоминает хорошо организованную редакцию газеты. Есть корреспонденты – приложения, которые собирают «новости» (данные производительности). Есть редакторы – парсеры, которые приводят эти данные к единому формату. Есть архив – база данных InfluxDB, куда всё это складывается. И есть дашборды Grafana – витрина, где можно увидеть картину целиком: тренды, аномалии, сравнения.
Конкретнее, система состоит из нескольких блоков:
- Хранилище бенчмарков – централизованный репозиторий, где хранятся конфигурации, скрипты запуска и параметры для всех приложений. Что-то вроде общей «книги рецептов»: вот как нужно запускать это приложение, вот что измерять, вот куда отправлять результаты.
- Конвейеры CI/CD – автоматизированные процессы на базе GitLab CI, которые запускаются по расписанию или при изменении кода. Они умеют работать с планировщиком задач Slurm, который управляет очередями заданий на суперкомпьютере.
- Сборщики метрик – модули, которые собирают данные из разных источников: время выполнения, потребление энергии, загрузка памяти, количество операций ввода-вывода. Для этого используются специализированные инструменты вроде Score-P (для профилирования параллельных приложений), LIKWID (для аппаратных счётчиков) и Perf (для профилирования на уровне ядра Linux).
- База данных результатов – InfluxDB, оптимизированная для хранения временных рядов. Идеально подходит для задачи «записать результат измерения с временной меткой».
- Система визуализации – Grafana с настроенными дашбордами, позволяющая видеть тренды производительности, сравнивать приложения и замечать отклонения.
Главная инновация: лестница зрелости
Если бы exaCB требовал от каждой команды сразу же внедрить полный набор инструментов мониторинга, подключить все счётчики и обеспечить идеальную воспроизводимость – большинство команд просто отказались бы участвовать. Это как требовать от бегуна-любителя сразу пробежать марафон.
Вместо этого авторы exaCB придумали четыре уровня зрелости интеграции, которые они назвали CoL (Continuity Levels – уровни непрерывности). Каждый следующий уровень добавляет детализацию и сложность, но начать можно с самого простого.
CoL 0: «Хотя бы запустись»
Нулевой уровень – это буквально проверка того, что приложение компилируется и запускается без ошибок. Фиксируется время выполнения и код возврата (успешно завершилось или нет). Никаких сложных инструментов, минимальные требования.
Это как первый визит к врачу: пульс есть, давление измерено, пациент жив – уже хорошо.
CoL 1: Базовые метрики производительности
На первом уровне начинается сбор количественных данных: время выполнения, пропускная способность, число операций в секунду (FLOPS). Данные записываются в базу и становятся доступны для анализа трендов. Теперь можно увидеть: «неделю назад это приложение работало за 10 минут, а теперь – за 15».
CoL 2: Энергоэффективность и детальный мониторинг
Второй уровень добавляет измерение энергопотребления и более глубокое профилирование: загрузка кэшей, использование памяти, векторные операции. Это позволяет ответить не только на вопрос «как быстро?», но и «ценой каких ресурсов?»
Один из самых интересных инсайтов, полученных в JUREAP, связан именно с этим уровнем: выяснилось, что пиковое потребление энергии не всегда совпадает с пиковой производительностью. Приложение может работать быстро, но крайне расточительно – или медленнее, но с гораздо лучшим соотношением результата и затраченной энергии.
CoL 3: Воспроизводимость и полный контекст
Высший уровень – это научная строгость в полном смысле слова. Фиксируется абсолютно всё: версии компилятора, флаги оптимизации, конфигурация узлов, переменные окружения, версии библиотек. Результат – полный «паспорт» каждого запуска, позволяющий воспроизвести его через год на другой системе и получить сопоставимые данные.
Именно этого обычно не хватает в научных публикациях: «мы запустили на кластере и получили такие-то результаты» – но кто и когда может повторить это измерение?
JUREAP: полигон для испытаний
Программа JUREAP стала идеальным тест-полигоном для exaCB. В её рамках более 70 научных приложений из самых разных областей – от молекулярной динамики до климатических моделей – были интегрированы в систему непрерывного бенчмаркинга.
Процесс интеграции для каждой команды выглядел примерно так:
- Создание репозитория с конфигурационными файлами для exaCB, описывающими, как собирать и запускать приложение.
- Написание скриптов сборки и запуска (exaCB предоставлял шаблоны – не нужно изобретать велосипед).
- Подключение инструментов мониторинга по мере готовности команды (CoL 1, 2 или 3).
- Настройка формата выходных данных в JSON, чтобы парсер exaCB мог автоматически извлекать ключевые метрики.
- Настройка конвейера GitLab CI для автоматических запусков.
Важно: не все приложения достигли одного и того же уровня CoL, и это было нормально. Одни команды ограничились нулевым уровнем – и уже это давало ценные данные о базовой работоспособности на новой системе. Другие дошли до полного мониторинга с энергометриками и детальным профилированием.
Что удалось обнаружить: реальные находки
Данные, собранные exaCB в ходе JUREAP, позволили сделать несколько конкретных и практически значимых открытий.
Узкие места в операциях ввода-вывода
Ряд приложений неожиданно показал значительное падение производительности – не из-за самих вычислений, а из-за медленного чтения и записи данных на диск. Без постоянного мониторинга это могло бы остаться незамеченным: приложение «работает», ошибок нет, но тратит 40% времени в ожидании файловой системы.
Визуализация в Grafana сделала эту проблему очевидной – команды смогли оптимизировать файловые операции ещё до начала полноценной работы на системе.
Влияние настроек планировщика Slurm
Slurm – это «диспетчер» суперкомпьютера, который решает, какое задание на каком узле запустить, как распределить ресурсы, в каком порядке обрабатывать очередь. Выяснилось, что разные конфигурации Slurm дают существенно разные результаты для одних и тех же приложений – причём не только по производительности, но и по энергопотреблению.
Это открытие позволило оптимизировать настройки планировщика под конкретные классы задач.
Межприкладной анализ: общие паттерны
Одно из самых интересных преимуществ единой базы данных – возможность сравнивать приложения из совершенно разных областей. В JUREAP обнаружилось, что несколько приложений, использующих схожие численные алгоритмы (например, итерационные решатели линейных систем), демонстрируют похожие паттерны производительности и энергопотребления. Это значит, что оптимизация, найденная для одного приложения, потенциально применима к другим.
Именно такого рода системные знания накапливаются только при наличии общей инфраструктуры данных – и именно это отличает exaCB от разрозненных разовых тестов.
Вызовы, с которыми пришлось столкнуться
Было бы нечестно не упомянуть о трудностях. Внедрение exaCB в реальную экзамасштабную среду обнажило несколько серьёзных инженерных проблем.
Гетерогенность приложений. Семьдесят с лишним приложений – это семьдесят с лишним разных историй: разные языки программирования, разные системы сборки, разные зависимости, разные форматы выходных данных. Модульная архитектура exaCB и инкрементальный подход помогли смягчить эту проблему, но полностью устранить её невозможно – каждая интеграция требовала индивидуальной работы.
Масштабируемость инфраструктуры. Когда десятки приложений запускаются регулярно и каждый запуск генерирует сотни метрик, объёмы данных быстро становятся значительными. InfluxDB справляется с этой задачей, но требует правильной настройки схем хранения и политик агрегации.
Воспроизводимость в нестабильной среде. Суперкомпьютер – это живая система: обновляются прошивки, меняются версии библиотек, проводятся технические работы. Обеспечить полную воспроизводимость в таких условиях крайне сложно. CoL 3 требует скрупулёзной фиксации всего контекста – и это требует от команд дисциплины и дополнительных усилий.
Человеческий фактор. Технические инструменты работают ровно настолько хорошо, насколько хорошо люди ими пользуются. Убедить команды регулярно обновлять конфигурации, следить за качеством данных и реагировать на обнаруженные регрессии – это задача не инженерная, а организационная. Инкрементальный подход и готовые шаблоны снизили порог входа, но не устранили его полностью.
Почему это важно за пределами суперкомпьютеров
Можно подумать, что всё это – история про очень дорогие и очень специализированные машины, которая никак не касается обычной разработки программного обеспечения. Но это не так.
Принципы, реализованные в exaCB, универсальны:
- Непрерывное измерение лучше периодического. Чем чаще вы измеряете производительность, тем раньше обнаруживаете проблемы и тем дешевле их исправлять.
- Единый формат данных открывает новые вопросы. Когда все результаты хранятся в одном месте в одном формате, можно задавать вопросы, которые раньше просто невозможно было задать: «Какие из наших приложений работают хуже всего после обновления компилятора?»
- Инкрементальное внедрение работает лучше революционного. Требование «сразу сделать всё правильно» убивает внедрение. Возможность начать с малого и постепенно усложнять – работает.
- Производительность и энергоэффективность – разные вещи. Быстро не значит экономно. В эпоху, когда стоимость электроэнергии становится всё более значимым фактором при эксплуатации вычислительных систем, умение измерять оба параметра одновременно – это не роскошь, а необходимость.
Переход к экзамасштабным системам в 2020-х годах обнажил проблему, которая в меньших масштабах была просто неудобством: без систематического и непрерывного мониторинга производительности невозможно управлять сложными программными экосистемами. exaCB – это один из первых практических ответов на этот вызов, проверенный не в лабораторных условиях, а на реальной системе с реальными приложениями и реальными командами разработчиков.
ИИ – как ребёнок, который учится на ошибках. Суперкомпьютер – как сложный организм, который нужно регулярно обследовать. И в обоих случаях хороший мониторинг – это не бюрократия, а честный разговор о том, что на самом деле происходит внутри.
