2.2.1 · блок 2
Зачем нужна архитектура
Зачем нужна архитектура
Зачем это нужно
«Просто напишем 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 — таблица «выигрыш / платёж».
- [ ] Нарисуйте границы: что внутри вашего сервиса, что — внешние зависимости.