A Model-based, Quality Attribute-guided Architecture Re-Design Process at Google
Практический разбор QA-guided редизайна архитектуры: QAS, UML static/runtime views и итоговый trade-off анализ.
Практика чтения для этого источника ещё не опубликована
Ниже доступен готовый редакционный brief из прежнего каталога. Он даёт контекст, но не засчитывается как lab.
Открыть оригиналГотовый редакционный разбор
Он сохранён из прежней версии каталога и расположен после самостоятельной практики, чтобы не подменять чтение оригинала готовым пересказом.
Whitepaper
ICSE-SEIP 2023
A Model-based, Quality Attribute-guided Architecture Re-Design Process at Google.
Whitepaper
ICSE-SEIP 2023
A Model-based, Quality Attribute-guided Architecture Re-Design Process at Google.
В этой работе Google показали не просто редизайн архитектуры, а воспроизводимый процесс принятия архитектурных решений через QA-сценарии, UML-моделирование и явный trade-off анализ. Главная ценность paper в том, что подход практичен для реальных legacy систем.
Первая страница whitepaper (клик по изображению откроет PDF).
Обзор
Review white-paper
Дополнительный разбор процесса и ключевых выводов.
Обзор
Review white-paper
Дополнительный разбор процесса и ключевых выводов.
TL;DR
- Google выбрали критический сценарий QueryTimeSeries и смоделировали только то, что нужно для архитектурного решения.
- Вместо тяжёлой полной модели использовали легковесный набор артефактов: QAS, component/sequence diagrams и trade-off таблицу.
- Разделение static и runtime view помогло прозрачно обсудить конфликтующие QA: availability, maintainability, latency, resource efficiency.
- Результат процесса: аргументированный редизайн с явным планом валидации по метрикам и переносимый шаблон для других команд.
Процесс редизайна (8 шагов)
Шаг 1
Выбрать критический пользовательский сценарий (в paper: QueryTimeSeries).
Шаг 2
Зафиксировать релевантные QA: availability, maintainability, latency, resource efficiency.
Шаг 3
Описать QAS для каждого QA (stimulus -> response -> response measure).
Шаг 4
Согласовать минимальный набор SLO/метрик до обсуждения решений.
Шаг 5
Построить as-is static и runtime модели на одном уровне абстракции.
Шаг 6
Построить to-be модели тем же языком и границами.
Шаг 7
Свести изменения в QA trade-offs + план проверки гипотез данными.
Шаг 8
Встроить артефакты в дизайн-док и процесс архитектурного ревью.
As-is vs To-be (кейс Monarch)
As-is
- Ключевые компоненты: Root/Zone Mixer, Index Server, Leaf, Repository.
- Leaf совмещает compute + index + storage, что повышает связность.
- Replica resolution и query pass проходят через большее число перегруженных узлов.
To-be
- Leaf декомпозирован: отдельные роли для index и query mix.
- Leaf API упрощён до key-value обязанностей хранения.
- Появляются доп. hops, но улучшается изоляция отказов и сопровождаемость.
Анализ по атрибутам качества
Availability
SLO/ожидание
>=99.99% успешных запросов
Риск в as-is
Высокий риск из-за сложного Leaf и fanout-чувствительности.
Эффект to-be
Улучшение за счёт изоляции ответственностей и меньшего blast radius.
Как валидировать
Error budget burn-rate, success-rate QueryTimeSeries, частота partial failures.
Maintainability
SLO/ожидание
Снижение времени rollout/root-cause
Риск в as-is
Высокий риск из-за плотной связности compute/index/storage в Leaf.
Эффект to-be
Улучшение через декомпозицию компонентов и более чистые API границы.
Как валидировать
Rollout time, incidents/month, root-cause time до/после.
Latency
SLO/ожидание
>=99% запросов в пределах M секунд
Риск в as-is
Низкий риск (baseline удовлетворительный).
Эффект to-be
Хуже по hops (12-14 -> 16-18), но в рамках целевого SLO.
Как валидировать
p50/p95/p99 E2E latency и вклад этапов replica/query pass.
Resource efficiency
SLO/ожидание
<10% дополнительного CPU/memory
Риск в as-is
Низкий риск на baseline.
Эффект to-be
Потенциальный overhead из-за доп. RPC, компенсируется лучшей декомпозицией нагрузки.
Как валидировать
CPU/memory/network breakdown и cost-per-query при одинаковой нагрузке.
Итоговая таблица trade-offs
| Quality Attribute | Importance | Risk (as-is) | Trade-off (to-be) | Notes |
|---|---|---|---|---|
| Availability | High | High | + | Лучшая failure isolation и меньший blast radius. |
| Maintainability | Medium | High | + | Границы ответственности чётче, API проще. |
| Latency | High | Low | - | Добавляются RPC hops; нужно контролировать tail latency. |
| Resource efficiency | Medium | Low | - | Доп. overhead по сети/CPU, но потенциал лучшей утилизации. |
Lessons learned
- Моделируйте не систему целиком, а только критический сценарий.
- Разделяйте static и runtime артефакты, иначе обсуждение быстро теряет точность.
- QA должны быть измеримыми до выбора решения, иначе trade-off анализ бесполезен.
- As-is и to-be нужно сравнивать при одинаковом уровне абстракции.
- Итог должен быть компактным: trade-off таблица + план валидации.
Чеклист: как повторить у себя
- [ ] Выбран сценарий и зафиксирован SLO.
- [ ] QA определены и согласованы с командами.
- [ ] QAS описаны для каждого QA.
- [ ] As-is: component + sequence diagram подготовлены.
- [ ] To-be: component + sequence diagram подготовлены.
- [ ] Trade-off таблица и validation plan добавлены в дизайн-док.
- [ ] После релиза заведены метрики, дашборды и алерты для валидации.