Привет, Хабр! Я Смолин Максим, разработчик и администратор баз данных в продуктах RPA BluePrism и SaluteRPA в Блоке Технологий Сбербанка, руководитель ИТ-направления. Мы с командой развиваем продукт SaluteRPA — роботизированная автоматизация процессов Сбербанка. Я расскажу, почему нас не устраивала платформа от зарубежного вендора, и почему мы решились на создание собственной платформы роботизации.
В 2017 году в банке начали использовать систему RPA BluePrism. На этапе MVP всё было великолепно, но потом началось много вопросов. ЦПУ (центральное процессорное устройство) сервера БД зашкаливали за 95 %, процессы тормозили и не успевали отрабатывать в нужное время, инциденты сыпались как из рога изобилия. С этого момента началась наша работа по превращению софта, рассчитанного на малый бизнес, в софт уровня предприятия с тысячами роботов. В итоге она привела к написанию собственного продукта SaluteRPA.
Архитектура RPA BluePrism достаточно проработана. Но вот реализация на уровне БД имела много замечаний с нашей стороны. Что-то мы отправляли на переделку вендору, что-то дорабатывали сами, а что-то смогли реализовать только в своём продукте.
Забегая вперёд, скажу, что внедренные нами изменения позволили преодолеть ограничение RPA BluePrism в 100 роботов на одну БД и уверенно держать нагрузку до 500 роботов на одну БД.
Архивация данных
Мы попросили инженеров RPA BluePrism внедрить механизм архивации данных. Нам довольно быстро прислали DDL-скрипты для создания архивных таблиц и хранимые процедуры для их наполнения. Таблицы мы приняли, а вот процедуры пришлось переписывать. Заметили интересную особенность: при достижении 600 тысяч записей в таблице элементов очередей резко возрастала нагрузка на процессор сервера БД. Процессы начинают тормозить. Например, до этого рубежа элемент очереди обрабатывался за 1—5 секунд, а после него мог ждать более 2 минут. Для некоторых процессов в банке это означало отказ от автоматизации и переход к ручной обработке документов оператором.
Казалось бы, всё ясно: обработанные элементы нужно переносить в архив. Но есть нюансы. В некоторых процессах и роботах разработчики заложили «обратную связь»: если за последние три дня есть обработанные элементы (с определенными key-value), то новые элементы не создаются. А если три дня ничего не было, то нужно создать новые элементы и обработать их. Поэтому «наш механизм архивации» пополнился таким параметром, как период, в течение которого не нужно архивировать элементы очереди. А для некоторых очередей ввели признак запрета на архивирование (характерно для очередей, работающих с учётными записями). Также сделали защиту от «переполнения»: за один вызов процедуры не должно архивироваться больше 5 Гб и/или 100 000 строк данных.
Процесс архивации запускается каждый час. Первый архив в 300 Гб он архивировал порциями в течение суток, последующие уже пролетали за считанные секунды. В архивных таблицах мы удалили все внешние ключи, чтобы ускорить обработку. Перенос в архив и удаление из online-таблицы происходит в одной транзакции, поэтому данные не пропадают.
Через пару лет мы поняли, что в архивных таблицах у нас начинает накапливаться 90 % данных от всей базы, и нам показалось расточительным использовать так высокоскоростные диски. Мы разработали вторую очередь архивации: всё, что старше 6 месяцев, перемещается из архивных таблиц на отдельный архивный сервер и там лежит нужное по нормативам время. Это позволило сократить самую большую базу RPA BluePrism с 3 терабайтов до 300 Гб.
Многие эти наработки мы воплотили и в нашей собственной системе SaluteRPA.
Типы данных
Второе наше обращение к вендору было связано с желанием изменить тип данных для некоторых колонок с устаревшего TEXT на NVARCHAR(MAX). Мы сами написали и отослали DDL-скрипты, изменяющие такие типы данных, а вендор их внедрил в дальнейших версиях RPA BluePrism. В интернете вы легко сможете найти статьи, почему TEXT — «плохой» тип данных. Если вкратце: он медленнее, хуже хранится и в ранних версиях MS SQL не позволял искать по строке через Like. В SaluteRPA для коротких строк (до 1024 байт) мы используем тип VARCHAR, а для длинных и безграничных — тип TEXT. Кстати, Pangolin (Реляционная СУБД уровня enterprise, специальная сборка PostgreSQL), на котором построена БД SaluteRPA хорошо работает со строками и предоставляет всю палитру SQL-операторов — от канонических Like и Substring до регулярных выражений. А еще БД Pangolin российская разработка (продукт зарегистирован в Едином реестре российских программ) и бесплатна для использования, что вдвойне приятно.
Компрессия таблиц
Попутно, пользуясь функциями enterprise-версии MS SQL, мы включили компрессию данных на некоторых таблицах (аудит, логи, элементы очередей). Это позволило в моменте сжать некоторые таблицы в 5 раз и ускорить доступ к данным (так как уменьшается размер прочитанных страничек с диска, но немного возрастает ЦПУ). Вендор RPA BluePrism не стал включать эту опцию в поставку «по умолчанию», видимо, из-за того, что не у всех клиентов установлен MS SQL Enterprise. В Pangolin компрессия данных появилась не сразу, поэтому, начиная разработку, мы даже не рассматривали эту опцию. В 2024 году на последней версии мы проведем нагрузочное тестирование SaluteRPA с компрессией данных и решим, будем ли мы ею пользоваться.
Индексы
В ходе эксплуатации RPA BluePrism мы столкнулись с отсутствием нужных индексов. Из коробки вендор предложил только индексы под внешние ключи и некоторые явно напрашивающиеся индексы. С помощью динамических представлений MS мы регулярно проверяли места, где требуются индексы, и внедряли их, а неиспользуемые удаляли. Не все рекомендованные MS SQL индексы оказываются полезны. Бывало, сделаешь такой индекс, а хранимая процедура ни в какую его не хочет подцеплять. Можно, конечно же, прикрепить индекс хинтами, но это грозит проблемами в будущем (например, при разворачивании на новой БД или удалении индекса, деградация полезности, отказ от параллельности).
В SaluteRPA используется микросервисная архитектура, внешние ключи между таблицами из разных схем запрещены. Есть псевдо-внешние ключи, мы подкладываем под них индексы. Также добавляем нужные по мере развития системы и появления новых SQL-функций, используем многоколоночные индексы, индексы с включением колонок, фильтрованные индексы.
Работа над индексами ведётся постоянно, что-то добавляем, что-то удаляем, что-то меняем (например, после перевода таблиц логов и аудита на секционирование).
Мониторинг
В RPA BluePrism нет мониторинга. Эту функциональность мы развили с нуля. Сделали 33 метрики для бизнес-пользователей и группы сопровождения, например:
количество успешно и неуспешно обработанных элементов очередей;
отложенных и созданных за последние 5 минут в разрезе очередей;
количество созданных, завершённых и прерванных сессий за последние 5 минут в разрезе процессов;
средняя длительность обработки элемента очереди;
количество общих ошибок, ошибок Out of memory;
количество Deadlock в разрезе процессов и т.д.
Все данные собирались на сервере баз данных BluePrism, а результаты записывались в таблицы на отдельном отчётном сервере (MS SQL), к которому были настроены доступы из Grafana для визуализации графиков.
В SaluteRPA реализовано 59 метрик мониторинга, данные собираются в отдельную таблицу и могут быть оттуда прочитаны внешними системами — Grafana, SSRS и т. д.
Оповещения
Для RPA BluePrism мы разработали систему оповещения с рассылкой тревожных писем владельцам процессов и роботов, а также группе сопровождения. Мы предложили пользователям 32 различных оповещения, которые настраиваются на определённые процессы, очереди и агрегации. Например:
доля неуспешно обработанных элементов относительно успешных за час для определённых очередей превышает порог в 15%;
для заданного процесса должен был быть запуск сессии по расписанию, но его не произошло;
для заданных процессов после прерванных сессий не было успешных запусков сессий в течение 30 минут;
по заданному процессу генерируются слишком большие журналы;
у заданной очереди есть элементы с определёнными тегами, которые были обработаны с ошибками, и т. д.
Это тема для отдельной статьи. В среднем у нас рассылалось 2—4 тысячи оповещений в день.
В SaluteRPA оповещения будут в той или иной форме. Пока камнем преткновением является не выявление ошибок, а способ подружить ролевую модель (от команды безопасности) с массовой рассылкой писем.
Перевод очереди в состояние exception
Следующая большая функция — это автоматический перевод элементов очередей в состояние exception, если:
элемент старый (не брался в обработку больше трёх дней);
или слишком большой (больше 20 Мб);
или откладывался больше 50 раз;
или слишком долго обрабатывается (суммарно дольше 10 часов);
или находится в обработке (locked) дольше трёх дней.
Это нас спасло от десятков тысяч элементов очередей, которые требовали вмешательства оператора, потому что не могли сами обработаться и задерживали другие элементы.
«SQL DDOS» ad hoc-запросами к таблицам
В ходе эксплуатации мы столкнулись с интересной особенностью BluePrism: одним из самых частых запросов к базе был «select name, datatype, value, description from BPAEnvironmentVar». Фактически это полное чтение таблицы, и проходило оно с ужасающей частотой 15 000 раз в минуту. Если таблица маленькая, например, 336 Кб, то генерируется сетевой трафик в 5 Гб/мин. Но если разработчики роботов начинают сохранять в переменных окружения коллекции объектов, например, справочники организаций, телефонов и т. д., и таблица вырастала, скажем, до 5 Мб, то сетевой трафик достигал 75 Гб/мин и фактически забивал канал с SQL-сервером. Наше предложение вендору добавить в ad hoc-запросы какие-нибудь фильтры или уменьшить частоту вызова таких запросов было встречено истинным нордическим молчанием. В итоге родилось ЦУ для разработчиков роботов: отказаться от хранения в переменных окружения любых больших объектов, а группе сопровождения пришлось разносить роботов по разным базам, чтобы уменьшить число строк в таблице BPAEnvironmentVar, и, как следствие, снизить сетевой трафик с SQL server.
Динамический планировщик запусков
Последняя гигантская функция, которую мы сделали взамен имеющейся в RPA BluePrism — это собственное приложение для динамического распределения запусков роботов на доступных виртуальных машинах. Данное приложение является динамическим планировщиком заданий, который по определённой формуле ранжирования на освободившихся ресурсах запускает те или иные процессы. В формуле учитывается приоритет процесса, количество элементов очереди, время простоя с момента последней обработки, число выделенных под динамический планировщик машин, время суток итд. Внедрение планировщика позволило повысить утилизацию виртуальных машин с 50 % до 100 %, а так как каждая виртуалка это отдельная лицензия, стоящая десятки тысяч рублей, то мы очень хорошо оптимизировали расходы. Все наработки по планировщику мы в полной мере задействуем и в SaluteRPA.
Послесловие
Любой программист знает, что писать собственный код гораздо приятнее, чем разбираться и поддерживать код предшественников. Я горжусь тем, что Сбербанк дал мне возможность поучаствовать в таком важном для организации, да и всего банковского сектора продукта (кстати, SaluteRPA доступен и внешнему рынку).
