Зачем это нужно
«Просто напишем API и вызовем model.predict» — работает в демо. В продакшене появляются вопросы: где хранить фичи? как обновлять модель без даунтайма? что делать, если latency вырос в 10 раз? Архитектура — это осознанные решения о границах системы, компромиссах между скоростью разработки, надёжностью и стоимостью.
Без архитектурного мышления ML-проект превращается в «большой ноутбук в продакшене». С ним — вы можете объяснить, почему выбрали batch inference, и что измените, когда нагрузка вырастет.
Основные идеи
Границы (boundaries). Систему делят на части с чёткими интерфейсами. ML scoring service не должен напрямую лезть в таблицы заказов — он получает фичи через Feature Store или API. Границы упрощают тестирование, замену компонентов и параллельную работу команд.
Quality attributes (атрибуты качества). Функциональность — «что делает». Атрибуты качества — «как хорошо»:
Performance — latency, throughput.
Availability — uptime 99.9%.
Scalability — выдерживает рост RPS в 10×.
Maintainability — новый разработчик разбирается за неделю.
Security — данные не утекают, доступ по ролям.
Нельзя максимизировать всё сразу. Архитектура — выбор приоритетов.
Trade-offs (компромиссы). Framework System Design Space предлагает думать о решениях как о точках в пространстве альтернатив:
| Решение | Выигрыш | Платёж |
|---|---|---|
| Online inference | Низкая latency | Сложнее масштабировать GPU |
| Batch scoring | Дешевле, проще | Данные устаревают на часы |
| Монолит | Быстрый старт | Сложно масштабировать команды |
| Микросервисы | Независимый деплой | Сетевая сложность, observability |
Хороший архитектор не ищет «идеальное решение», а фиксирует: мы выбрали X, потому что приоритет — Y, и принимаем риск Z.
ML-специфика. Для ML-сервисов добавляются атрибуты:
Reproducibility — можно воспроизвести обучение.
Model freshness — модель не устарела.
Observability of predictions — drift, data quality.
Архитектура связывает DS-эксперименты с инженерной инфраструктурой: где проходит граница между notebook и production pipeline?
Как это выглядит на практике
Команда строит антифрод-scoring. PM требует latency < 100 ms (online). DS хочет тяжёлую ensemble-модель. MLE предлагает компромисс:
Online path: лёгкая модель (LightGBM) для синхронного скоринга.
Batch path: тяжёлый ensemble пересчитывает риск раз в час для всех активных пользователей.
Trade-off зафиксирован в ADR-001 в Confluence. Quality attributes: p95 latency 80 ms (online), recall ≥ 0.92 (batch уточняет).
На Jira Epic «Fraud Scoring v2» ссылка на architecture page. Backend не тянет фичи из DWH напрямую — только через Feature API (граница).
Что сделать после занятия
Для учебного проекта выпишите 3 quality attributes и приоритет (что важнее).
Опишите один trade-off: online vs batch inference — таблица «выигрыш / платёж».
Нарисуйте границы: что внутри вашего сервиса, что — внешние зависимости.