Как оптимизировать работу высоконагруженной системы

Что такое высоконагруженная система?

Есть мнение, что высоконагруженная информационная система — это система с большим количеством пользователей (примерно от 1 000 человек). На мой взгляд, определение высоконагруженной системы пора пересмотреть. Сегодня в системе может работать и не больше 10 человек, но мы будем считать ее высоконагруженной в том случае, если она должна:

• быть постоянно доступной и отказоустойчивой, то есть работать в режиме 24/7 и практически не допускать простоев;
• предоставлять пользователям быстрый отклик, то есть позволять получать и отправлять данные без задержки;
• обрабатывать и хранить большие объемы данных.

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

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

Почему о производительности систем стали говорить все чаще?

До массового перехода на импортонезависимое программное обеспечение большинство российских корпораций вело учет в зарубежных ERP-системах и на зарубежных же серверах. Здесь важно понимать, что классические Windows и Microsoft SQL «прощают» большинство ошибок, на которых Astra Linux и Postgres Pro начинают заметно подвисать. Например, встроенный в сервер Microsoft оптимизатор автоматически выправлял неоптимальности программного кода. Благодаря этой особенности, многие компании не задумывались о вопросах производительности, не проводили нагрузочное тестирование и не следили за оптимальностью кода.

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

Чем чревата низкая производительность?

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

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

• Конфигурация: «1С:Управление производственным предприятием».
  • Проблема: с определенного момента в системе стало возникать очень много блокировок ожидания, работа пользователей была практически парализована, хотя никаких существенных доработок не выполнялось.
  • Источник проблемы: ИТ-служба заказчика отключила ночной пересчет итогов в системе (функция автоматического исправления ошибок, возникших из-за сбоев технического характера), потому что его проведение показалось администраторам необязательным. Этот технический долг ударил по работе системы через полтора года, когда объем неисправленных вовремя ошибок в системе серьезно повлиял на ее производительность.
  • Решение: обратно включили перерасчет итогов.
• Конфигурация: «1С:Управление торговлей».
  • Проблема: при переходе на новую версию платформы 1С расчет себестоимости на типовом коде стал выполняться вместо 30 минут минимум за 8 часов.
  • Источник проблемы: заказчик использовал более раннюю и сильно кастомизированную конфигурацию, которую, как раз по причине сильной кастомизации, не получилось гладко обновить до новой улучшенной версии.
  • Решение: ручная оптимизация кода запросов, которая помогла сократить время расчета себестоимости с 8 часов обратно до получаса.
• Конфигурация: «1С:Управление холдингом».
  • Проблема: долгое проведение документов по бюджетированию — до 30 минут, при желании заказчика проводить документы за 30 секунд — и большое число блокировок.
  • Источник проблемы: в документах использовался регистр накопления, при обращении к которому в запросах не использовался период, что приводило к получению больших выборок со сканированием всей таблицы на сотню миллионов записей.
  • Решение: перестроение индексов таблиц регистров, которое помогло проводить документы менее, чем за одну минуту, и значительно сократить количество блокировок.
• Конфигурации: «1С:Бухгалтерия предприятия» и «1С:Управление торговлей».
  • Проблема: множество блокировок и долгое проведение практически всех документов (до 10–15 минут) — а их проходило через системы по несколько тысяч за день.
  • Источник проблемы: не было настроено выполнение регламентных операций на уровне СУБД, вследствие чего статистика была устаревшей, а индексы — фрагментированными.
  • Решение: настройка плана обслуживания СУБД, которая привела к существенному сокращению времени проведения документов (менее 1 минуты) и значительному уменьшению блокировок.

Как оптимизировать высоконагруженную систему?

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

1. Оптимизация кода, алгоритмов и архитектуры: поиск и рефакторинг неоптимального/некачественного кода; поиск более производительных алгоритмов для решения определенных сложных и ресурсоемких задач; распараллеливание/многопоточность; поиск более изысканных архитектурных решений (например, наличие двух синхронизирующихся баз данных — одной для оперативного учета, а второй — для формирования отчетности или кэширования/предварительного расчета данных).
2. Оптимизация инфраструктуры и оборудования: увеличение мощностей серверного оборудования; замена устаревшего и выработавшего свой ресурс оборудования; оптимизация сетевой и прочей инфраструктуры; балансировка нагрузки. Если компания имеет дело со старыми серверами, то вопрос производительности обязательно упрется в «железо», и сколько бы мы ни переписывали код, мы не почувствуем рост оптимальности, пока не приведем в порядок инфраструктуру.
3. Оптимизация программного обеспечения и регламентов обслуживания: выполнение тонких настроек различного программного обеспечения для более оптимальной работы; настройка и разработка оптимальных регламентных операций обслуживания и частоты их применения.
4. Оптимизация бизнес-процессов: отказ от избыточных или поиск более оптимальных бизнес-процессов, которые позволят упростить алгоритмы и снизить нагрузку на систему. Бывает, что какая-то процедура просто слишком часто запускается в системе — чаще, чем это в действительности необходимо бизнесу — и при этом она блокирует работу другой процедуры. В таком случае система может быть оптимизирована благодаря элементарному пересмотру частоты и времени выполнения пользовательских запросов.

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

Любая ли система поддается оптимизации?

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

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