Почему архитектура ИИ отличается от классических приложений
ИИ-системы имеют специфические требования, отличающие их от типичных веб-приложений. Языковые модели требуют значительных вычислительных ресурсов, но не всегда и не везде. Разные компоненты системы имеют кардинально разные профили нагрузки: модуль инференса на GPU — это узкое место по ресурсам, слой API должен обрабатывать тысячи параллельных запросов, а процессы обучения выполняются пакетно и могут длиться часами. Архитектура должна это учитывать.
Аргументы в пользу монолита на старте
Большинство ИИ-проектов должны начинаться как монолит. Причины прозаичны: монолитная архитектура проще в отладке, легче для понимания новой командой и быстрее в итерациях. Когда система находится на экспериментальной стадии и границы между компонентами ещё формируются, преждевременное разделение на микросервисы приносит больше вреда, чем пользы.
Классическая ошибка – проектировать десятки микросервисов ещё до того, как система обслужит первого реального пользователя. Неизвестные паттерны использования приводят к неверным границам сервисов, которые впоследствии порождают огромные затраты на рефакторинг.
Когда микросервисы – правильный выбор
Миграция на микросервисы имеет смысл, когда возникают конкретные, измеримые проблемы с монолитом:
- Разные требования к масштабированию: модуль OCR требует в 10 раз больше ресурсов во время кампании, остальная система остаётся стабильной.
- Независимые циклы развёртывания: команда ML-моделей выпускает новые версии несколько раз в день, а изменения в модуле отчётности – раз в месяц.
- Изоляция сбоев: ошибка в одном компоненте не должна останавливать работу остальных.
- Разные технологические стеки: модуль обработки изображений требует библиотек Python, недоступных в основном стеке.
Стратегии миграции из монолита
Безопасная миграция опирается на паттерн Strangler Fig: постепенное вырезание функциональности из монолита и замену её независимыми сервисами при сохранении работающей системы на протяжении всего процесса. Ключ – выявление естественных доменных границ: не искусственное разделение по техническим линиям, а деление в соответствии с бизнес-логикой.
Первым кандидатом на выделение должен стать компонент, который: хорошо определён функционально, имеет чёткий и стабильный API, порождает больше всего проблем из-за различий в требованиях к масштабированию. Обычно это как раз модуль инференса ИИ-моделей.
Мультиагентная оркестрация и архитектура сервисов
Мультиагентные системы ESKOM AI работают на уровне выше традиционных микросервисов: отдельные ИИ-агенты могут использовать как монолитное бизнес-приложение, так и экосистему микросервисов. Ключевая задача – спроектировать интерфейсы так, чтобы внутренняя архитектура целевой системы не ограничивала возможности интеграции с агентной логикой.