Чем больше новых возможностей появляется в ПО, особенно в сфере ИИ, тем дороже обходится «железо» под него. Чтобы софт оставался доступным для бизнеса, разработчики должны искать баланс: развивать продукт так, чтобы наращивать аппаратные нагрузки экономично.
Введение
Дефицит оборудования на российском ИТ-рынке с годами не снижается. А «бум» нейросетей только ускоряет этот процесс. В корпоративных решениях стали появляться работающие ИИ-инструменты — и кратно «задрали» аппаратные требования.
DLP-системы — одни из самых требовательных. Они постоянно анализируют огромные потоки данных, а добавление любого нового модуля, например, для ИИ-аналитики, увеличивает нагрузку. Если просто следовать за трендами, продукт станет слишком дорогим для большинства.
Дилемма наглядно
Заказчики не хотят отказываться от передовых функциональных возможностей. У вендоров возникает дилемма: если слепо реализовать востребованную функциональность, стоимость внедрения вырастет так, что продукт окажется доступным только самому крупному бизнесу, не ограниченному в ресурсах. А если отказаться, есть риск отстать в технологической гонке и потерять заказчиков, так как софт перестанет решать их задачи.
Мы работаем в сегменте информационной безопасности: делаем DLP-систему «СёрчИнфом КИБ» для защиты от утечек, DCAP «СёрчИнформ FileAuditor» для контроля файлов, «СёрчИнформ SIEM» для мониторинга угроз в ИТ-инфраструктуре.
Каждая система обрабатывает огромные массивы данных и анализирует их: это уже ресурсозатратные процессы, требующие большой вычислительной нагрузки. И развиваем мы их в потребностях рынка, то есть функциональность постоянно растёт. Например, недавно в нашей DLP появилась ИИ-аналитика инцидентов. Соответственно, выросли аппаратные требования: новый модуль требует отдельные мощности.
Другими словами, если заказчик хочет получить новую «фичу», ему придётся «прокачать» инфраструктуру. Это дополнительно нагружает ИБ-бюджет. Повлиять на стоимость аппаратных компонентов мы как производитель ПО не можем. Зато можем оптимизировать свои системы, чтобы базовая функциональность расходовала ресурсы экономичней — тогда стоимость внедрения остаётся приемлемой.
Что и как урезать?
В случае DLP самый затратный компонент при внедрении — не память и CPU, а СХД (система хранения данных). Просто потому, что система, по сути, копирует весь трафик в корпоративных каналах связи, в том числе хранит пересылаемые файлы и другие крупные пакеты данных. Это не просто вопрос расхода места на дисках, но и нагрузки, которая ложится на систему (и железо) при навигации по хранимым данным для их дальнейшего анализа.
Мы понимали это со старта разработки, поэтому в первую очередь озаботились двумя вещами: экономичным хранением данных и скоростью их обработки. Для этого поэтапно оптимизировали систему на трёх уровнях.
Система хранения
Информация в DLP обычно собирается в базы данных с такой структурой, чтобы системе было удобно вычленить из них нужные для обработки данные «по координатам». Это хорошо работает со структурированными данными, но, когда дело доходит, например, до медиафайлов или больших текстов, внутри одной ячейки в базе оказывается слишком объёмный и сложный объект, чтобы система могла его быстро обработать.
Поэтому мы ушли от хранения всего в СУБД и используем одновременно 3 разных вида записи: табличные данные — в БД, файлы — в специальную структуру, оптимизированную для быстрого адресного доступа к цельным объектам, а тексты — в индексы. Это удобный формат, но, кроме того, экономичный: нигде данные не дублируются. В хранилищах реализована дедупликация, то есть КИБ записывает повторяющиеся данные — письма, пересылаемые файлы и т. д. — только один раз.
Сами данные при записи в базы сжимаются: мы используем эффективные кодеки, чтобы, например, аудио и видео занимали как можно меньше места без потери качества. В системе масса фильтров и исключений, заказчик может настроить хранение под свои задачи: подробнее и объёмнее или выборочно и экономично.
Когда данные накапливаются и число баз в хранилище растёт, их можно перемещать. Мы реализовали в КИБ удобные инструменты миграции — архив перехваченной информации автоматически отправляется на выбранные диски, причём можно подключать более медленные, а в «горячих» (т. е. самых производительных и дорогих) хранилищах оставлять только оперативную информацию. Перенос можно производить по расписанию или когда БД достигнет порогового объёма.
Аналитический движок
Мы строили КИБ на собственном поисковом движке, чтобы не зависеть от стороннего вендора и самостоятельно управлять производительностью системы. Такой подход, в том числе, позволил реализовать ту самую технологию гибридного хранения данных — и это стало залогом роста аналитических возможностей.
Трёхсоставное хранение данных облегчает для DLP аналитические операции. Например, чтобы «дотянуться» до файла во внутреннем хранилище, DLP больше не приходится вычитывать его целиком — она ориентируется по хеш-суммам. Поиск получается гибким и быстрым. Технология отлично показала себя на больших массивах данных и получилась такой успешной, что мы её запатентовали.
Кроме того, КИБ оптимизирует большие базы данных в цепочки более маленьких. При поиске система понимает, в каких из сотен маленьких баз могут лежать искомые события, и подключает для поиска только их. Поиск становится быстрее на порядки.
В результате растёт общая производительность системы: данные обрабатываются быстрее, а вычислительная нагрузка при этом остаётся низкой. Это снижает расход оперативной памяти.
Архитектура внедрения
В КИБ все вычисления — распределённые: данные фильтруются, обрабатываются, анализируются последовательно в разных компонентах ещё до того, как попадают в хранилища. Начиная с агентов на ПК пользователей. Это позволяет гибко распоряжаться ресурсами при внедрении, особенно в сложных инфраструктурах.
Например, для крупных компаний с разветвлённой структурой доступна кластеризация, когда в каждом филиале или даже подразделении стоит свой EndpointController — компонент, который управляет сбором данных от агентов и задаёт «маршрут» для записи этих данных в хранилища. Когда компонентов EndpointController несколько, заказчик может задавать индивидуальные параметры контроля в каждом кластере, включая объём собираемых данных. И наоборот: чтобы было удобно разом раскинуть настройки на все ПК в компании, можно объединять сервера EndpointController и управлять ими централизованно.
В прошлом году мы увеличили пропускную способность EndpointController втрое: теперь на одном сервере можно управлять данными сразу 10000 агентов. В больших инфраструктурах теперь требуется меньше узловых компонентов, стоимость внедрения снижается. Заодно оптимизация позволила снизить аппаратные требования для таких серверов на четверть и более, в зависимости от настроек.
В условиях ограниченных ресурсов доступен вариант, когда «узловой» EndpointController становится фактически независимой станцией предварительной обработки данных. Он собирает, очищает и максимально сжимает данные от агентов, прежде чем отправлять на «головной» сервер EndpointController: отправляет пакетами и по расписанию.
Это актуально, если между филиалами узкий канал, который нельзя перегружать. В таком случае в качестве EndpointController может выступать даже не сервер, а обычный ПК, потому что задачи по управлению параметрами перехвата и маршрутизации данных с него снимаются.
Что это даёт
Последовательная оптимизация позволяет перераспределять мощности внутри работающего продукта. В «СёрчИнформ КИБ» экономичное хранение данных расходует меньше места в СХД, ускоряет работу системы, повышая её производительность. А высвобождающиеся ресурсы можно выделить на новые инструменты: например, модули с ИИ. В результате достигается баланс: заказчику проще дорастить возможности DLP без опасений за дополнительную нагрузку на инфраструктуру и бюджет.
Попробовать оптимизированную DLP «СёрчИнформ КИБ» можно бесплатно в полной функциональности в течение 30 дней.
Выводы
Чтобы DLP оставалась доступной, её развитие должно идти через оптимизацию. Нельзя просто добавлять функции, увеличивая нагрузку, нужно постоянно искать, где сократить издержки.
Ключевые точки для работы: система хранения, аналитический движок и архитектура внедрения. Наш опыт показывает, что эффективное сжатие и дедупликация данных, собственный поисковый движок и распределённая обработка на периферии — работают. Эти меры снижают нагрузку на дорогие компоненты.
Можно внедрять ИИ-модули и новые виды анализа, не заставляя клиента каждый раз покупать новые серверы. Освобождённые за счёт оптимизации ресурсы — это и есть пространство для развития продукта, которое не бьёт по бюджету.
Реклама, 18+. ООО «СерчИнформ». ИНН 7704306397
ERID: 2VfnxxY9o8d
