Требования к архитектуре как основа современной разработки HighLoad-систем
Изображение: bellena/Shutterstock.com
Преимущества таких систем более-менее понятны и широко освещены, но информации о том, почему важно тщательно прорабатывать требования и как это делать, мало. Аналитик ИТ-компании SimbirSoft Адель Гарифов попробует пролить свет на эту проблему. В статье автор расскажет, какие базовые требования важно учесть и как они влияют на выбор архитектуры системы и результат в целом. Туториал содержит практические советы по детализации свойств архитектуры в разрезе функциональных требований. Это поможет читателям сформировать новый подход к проработке требований будущего продукта и заложить верную архитектуру.
Небольшое отступление
HighLoad-система – продукт с большим количеством пользователей. Как и любой ИТ-продукт, он выступает как основной или вспомогательный инструмент для бизнеса, который должен решать конкретные задачи. Как правило, речь идет про автоматизацию процессов. HighLoad оправдана там, где большое количество пользователей одновременно выполняют те или иные операции в системе. Такие решения, как правило, используют крупные компании типа Avito, Yandex Market, VK и других.
Рис.1. Автоматизация – наше всё
Если говорить о HighLoad-системах, в голову приходит мысль о распределенной архитектуре. У машин, на которых производятся вычисления, как и у человека, ресурсы ограничены. Поэтому высоконагруженный продукт требуется распределить на несколько машин.
Рис.2. Распределение ресурсов для реализации продукта
Далее поделюсь, как функциональные требования могут повлиять на архитектуру, а также расскажу про управление требованиями.
Спойлер: Как любая сложная структура не может обойтись без описания её функциональности, HighLoad-система нуждается в документации и описании предметной области.
Почему важно тщательно прорабатывать требования к архитектуре до реализации и каких последствий это поможет избежать
Процесс формирования основных требований к архитектуре будущего продукта очень важен, поскольку включает в себя:
- Выявление требований к функциональности системы
- Определение интереса и ценности для конечного пользователя
- Определение основных компонентов системы и их взаимосвязей
- Определение требуемых ресурсов для развертывания и поддержки
- Исследование возможности использования готовых решений или облачных решений с целью оптимизации затрат на поддержание будущей инфраструктуры
В основе любого продукта – люди. Их опыт, знания и интерес влияют на архитектуру продукта. Большинство проектных команд формируется из разных специалистов, которые должны стремиться к одной цели и делать один продукт. Требования помогают задать команде проекта единый вектор направления. За структурное документирование требований отвечает аналитик.
Держим в голове подход Domain Driven Design, который подразумевает необходимость погружения в предметную область и наличие итеративного процесса.
С помощью тщательно проработанных требований можно отсечь лишние коммуникации, зафиксировать все аспекты будущего продукта и при необходимости отследить историю и причины изменений требований в дальнейшем
Что дает проработка требований к архитектуре?
Во-первых, понятные цели продукта и его ограничения. Конкретизация поставленных целей помогает:
- сформировать единое завершенное представление продукта
- верно расставить приоритеты и определить контекст продукта, его первой версии
- обозначить границы продукта.
Тем самым, команда сэкономит бюджет и ресурсы проекта.
Во-вторых, определение структуры и взаимосвязей компонентов будущей системы. Это позволит сформировать верхнеуровневое представление о продукте, отразить необходимые целевые взаимосвязи между компонентами, уменьшить количество лишних связей и зависимостей между компонентами, сделать навигацию по компонентам более простой, а значит, быстрее проектировать и вносить изменения в продукт.
В-третьих, управление изменениями. По мере роста продукт становится сложнее. Связанность компонентов системы может усиливаться. Поэтому отражение всех изменений и принятых решений может быть полезно при возврате к тому или иному участку в будущем для рефакторинга, доработок, копирования функциональности в другой компонент и миграции на другую архитектуру.
В-четвертых, устойчивость к будущим изменениям. Хорошо спроектированная архитектура может:
- обеспечить устойчивость системы к будущим изменениям и расширению
- сэкономить бюджет по мере усложнения системы и реагировать на изменения с меньшими издержками
- увеличить скорость выпуска изменений
Как требования к продукту влияют на требования к архитектуре современных HighLoad-систем
Влияние требований на результат сложно переоценить. Рассмотрим на примере выдуманного кейса, где к продукту с ожидаемой нагрузкой в 500 тысяч уникальных пользователей ежедневно выдвигаются следующие требования:
- Продукт должен иметь конструктор тематических страниц для реализации публикаций новостных страниц с различными виджетами.
- Продукт должен иметь шаблоны редактируемых страниц с публикацией динамических данных.
- Продукт должен иметь функциональность личного кабинета с возможностью единой авторизации между доменами компании.
- Продукт должен агрегировать данные других доменов организации.
- Продукт должен быть SEO-friendly.
На самом деле пунктов может оказаться намного больше, но предлагаю остановиться только на этих пяти требованиях.
Структуру продукта можно представить как монолит (см. Рис.3).
Рис.3. Продукт как монолит
Требование о наличии конструктора (пункт 1) говорит о необходимости реализации интерактивного интерфейса для формирования контента. В ходе проработки требований выясняется, что формировать контент будет внешний пользователь. И, очевидно, что сам редактор не должен быть SEO-friendly.
Здесь возникает разделение интерфейса сайта на широкую аудиторию и пользователей, генерирующих контент.
Итог – минимум две разные роли пользователей, которые будут впоследствии пользоваться разным функционалом продукта, и несколько разных интерфейсов (см. Рис 4.).
Рис.4. Разделение на основе погружения в предметную область
Требования к наличию редактируемого шаблона и «дружелюбности» seo (пункты 2 и 5) будут говорить о том, что Client Side Rendering (Рендеринг на стороне клиента) – не наш путь, хотя он подошёл бы для реализации конструктора. Получается, что нагрузка будет в основном на сервере. Но обычно это достаточно дорогой ресурс, и в ходе более детальной проработки необходимо принять ряд компромиссных решений, которые будут требовать конкретных цифр о нагрузке и используемой функциональности. Также, скорее всего, потребуется добавить поисковый движок типа Elasticsearch.
Требования к наличию конструктора, редактируемых шаблонов и функциональности личного кабинета (пункты 1, 2, 3) говорят о том, что необходимо реализовать ролевую модель. Тут не обойдется без Single Sign-On, поскольку будет нужна авторизация пользователей с других доменов. Но здесь всё упрощается наличием готового механизма авторизации, что потребует лишь интеграции.
Требование к агрегации данных с других доменов (пункт 4) говорит о возможной необходимости кэширования данных для снижения потенциальных нагрузок на внешние сервисы.
Рис.5. Распределение компонентов продукта
Но это всего лишь первые шаги – верхнеуровневая абстракция. При проработке продукта под этими пятью требованиями будет множество деталей, которые необходимо учитывать в этом или следующих релизах системы. Многое захочется декомпозировать, но без требований сложно сказать, как именно это делать. Предметная область продукта недостаточно понятна. Всё выглядит так, как будто система будет представлена двумя монолитами и минимум двумя интерфейсами. В нашем случае мы уходим от монолита к распределенной архитектуре продукта.
Именно требования должны раскрыть назначение продукта. При достаточной проработке требований можно начать декомпозицию и формирование границ контекста продукта и его компонентов.
Как базовые требования обеспечивают понимание необходимых свойств архитектуры
Голые цифры нагрузок не расскажут историю, не объяснят, для чего реализуется продукт и зачем нужен тот или иной его функционал. Так и общее представление без цифр не смогут дать представление, как всё должно будет работать. Если не рассказать историю, каждый по своему будет интерпретировать полученные данные, дополняя пробелы.
Начнем с концепции продукта, где будут представлены общая картина и цели, измеримые критерии успеха продукта.
Для составления концепции нужно разработать требования. Для этого можно опираться на план, предложенный Карлом Вигерсом. И начать нужно с определения требований со стороны бизнеса к продукту, выяснив следующую информацию:
- Вводные данные
- Возможности бизнеса в случае внедрения продукта
- Цели бизнеса
- Критерии успешности продукта
- Видение решения
- Риски для бизнеса
- Предположения и зависимости
Далее прописываем границы и ограничения проекта, а именно:
- Основные функции
- Объем первой версии продукта
- Объем последующих версий продукта
- Ограничения и исключения
И, наконец, уточняем контекст продукта с точки зрения бизнеса:
- Профили заинтересованных сторон
- Приоритеты проекта
- Специфика развертывания и реализации системы
Всё это поможет составить основные требования к продукту. Они необходимы, чтобы специалисты могли разобраться в целях продукта, что он будет из себя представлять и как им будут пользоваться. Подробно останавливаться на всех пунктах не будем, но от этого они не становятся менее значимыми. Основное, на чём хотел бы акцентировать внимание, – как функциональные требования влияют на свойства архитектуры.
Предлагаю остановиться только на основной функциональности. Инструменты User Story Mapping и Event Storming как подходы к исследованию помогут выявить дополнительные особенности продукта. Они позволяют визуализировать и выстроить общее представление будущего продукта. Всё это заложит основу для последующей детальной проработки требований.
Итак, необходимо понять, насколько мы сможем заложить достаточно гибкую архитектуру под цели продукта. Начнём с функциональных требований. Многие функциональные требования оформлены в виде перечислений и не раскрывают сути и предназначения. Нефункциональные требования формируются из совокупности того, какие функциональные возможности продукт будет предоставлять конечным пользователям.
Чтобы развернуть требования более детально, можно использовать метод «5w2h»:
|
Вопросы |
Описание |
|
What?
«Что?» |
Указываем функциональные требования
Здесь можно указать как конкретное функциональное требование, так и часть продукта, которая предоставляет определенный набор функциональности. Всё зависит от уровня декомпозиции. |
|
Why?
«Для чего?», «Какие цели, итоговый результат ждут?» |
Указываем, какие цели и результаты позволяет достигнуть система.
Цели и результаты дадут ясную картину, позволят устранить двусмысленность. В зависимости от понимания целей ситуация может сильно меняться. |
|
Where?
«Где?», «Откуда и где будет доступен продукт?» |
Указываем места, откуда продукт будет доступен конечным пользователям.
Здесь можно фантазировать на тему размещения – свои серверы или облачные. Как будет потребляться продукт, какой нужен клиент? Какие часовые пояса и локализацию необходимо учитывать? Какие конечные устройства будут реализовывать интерфейс продукта, чтобы с ним взаимодействовать? |
|
Who?
«Кто?», «Кто это будет использовать?» |
Указываем типы и роли пользователей, их характеристики и описание.
Будет ли часть системы осуществлять контроль за действием для пользователя с ролью администратор? Кто будет иметь высший приоритет над частью с доступом к редактированию и добавлению? Потребуется обоснование доступности той или иной части системы. |
|
When?
«Когда?», «Когда используется функциональность?», «Когда он должен быть доступен?» |
Указываем, когда предполагается использовать ту или иную функциональность системы
Например, что-то будет востребовано каждый будний день в рабочие часы, а раз в полгода ожидается массовый наплыв всех пользователей. Это напрямую будет влиять на такое свойство, как адаптируемость продукта.
Также можно указать желаемую дату релиза. |
|
How?
«Как?», «Как будет работать функциональность системы?», «Как измерить успех?» |
Указываем основной и альтернативные сценарии предполагаемого использования системы с учетом измеримых показателей успеха.
На каких участках будет наибольшая нагрузка и потребуется проработать частные решения? Этот вопрос влияет на понимание того, какие части системы наиболее подвержены риску и необходимо акцентировать внимание на таких свойствах, как надежность, безопасность. |
|
How much?
«Как часто?», «Как часто будет использоваться функциональность системы?» |
Указываем частоту использования. Чем точнее показатели, тем выше вероятность попадания в цель.
Здесь же можно указать общие показатели нагрузки. |
Перечень вопросов не ограничен приведенными примерами, их можно расширять или сокращать. Суть этого подхода в том, чтобы, определяя общие нефункциональные требования к продукту, пройтись по каждому функциональному требованию для получения более глубокого представления. В разрезе каждого требования можно определить приоритетные свойства архитектуры и саму структуру будущего продукта. Под свойствами архитектуры как раз выступают нефункциональные требования.
В итоге тщательная проработка требований может привести к кардинально другой структуре по сравнению с первоначальным вариантом:
Рис.6. Концептуальная распределенная архитектура микросервисов
Всё зависит от подхода и понимания предметной области. Безусловно, на самом старте практически невозможно учесть все нюансы будущего продукта. Предусмотреть все проблемы, которые будут возникать на этапе разработки. Поэтому требования должны также эволюционировать, как и сам продукт. Постепенно наращивая сложность продукта, формируется и накапливается документация, в которой также увеличивается сложность.
Чтобы верно заложить представление архитектуры будущего продукта, необходимо также учитывать, что все замыслы должны быть реализованы. Поскольку концепт дает только первое общее представление, сами требования впоследствии должны быть проработаны и детализированы по ходу реализации – вплоть до выпуска продукта в производственную среду.
Выбор архитектуры будущего продукта
Каждый продукт создается для определенной цели и всегда с ограниченными ресурсами. Множество факторов, которые влияют на выпуск продукта, требуют компромисса.
Возьмем классический монолит. Его структура определяется одним квантом. Она достаточно проста, с неё начиналось достаточно много продуктов. Но нужно понимать, что при такой структуре на самом старте можно сразу встретиться с проблемами производительности, масштабируемости, адаптируемости и отказоустойчивости.
Микросервисная архитектура, которая позволяет создавать адаптируемые, масштабируемые и достаточно надежные системы с заделом на будущие изменения, также имеет свои проблемы. Например, достаточно сложную структуру архитектуры, а за счёт большого количества компонентов может быть и достаточно затратной. Поскольку компоненты системы распределены и вынуждены общаться по сети между собой, микросервисы могут в некоторых случаях проигрывать монолитам в производительности – но тут всё относительно. Если не следить за связностью компонентов, микросервисная архитектура может превратиться в монолит.
Тщательная проработка требований позволяет с большей вероятностью выбрать верную архитектуру будущего продукта. Впоследствии она будет влиять на бюджет проекта, скорость выпуска функциональности и внесения изменений, удобство поддержки и прочее.
Взять к примеру требование к доступности системы.
|
Время работы в процентах |
Простои в год (в день) |
|
90.0% (одна девятка) |
36 дней 12 часов (2.4 ч) |
|
99.0% (две девятки) |
87 часов 46 минут (14 мин) |
|
99.9% (три девятки) |
8 часов 46 минут (86 с) |
|
99.99% (четыре девятки) |
52 минут 33 секунды (7 с) |
|
99.999% (пять девяток) |
5 минут 35 секунд (1 с) |
|
99.9999% (шесть девяток) |
31.5 секунды (86 мс) |
Требование к доступности в пять девяток на весь продукт может сильно отразиться на бюджете и структуре продукта.
Вместо вывода
Архитектура современных HighLoad-систем должна учитывать множество факторов, включая масштабируемость, отказоустойчивость, производительность и безопасность. Она также должна быть гибкой с прицелом на будущее расширение и модернизацию системы. Все эти моменты важно зафиксировать, структурировать и сделать доступными для всех заинтересованных сторон.
Каждое требование нужно рассматривать в отдельности и в общей картине всего продукта, чтобы сформировать правильное абстрактное представление архитектуры будущей системы. Аналитик как ключевое связующее звено должен умело управлять вновь возникающими требованиями к продукту и развивать документацию, как развивается и продукт в целом. Совокупные функциональные требования позволяют детализировать архитектурные свойства продукта, что и определяет архитектуру будущего продукта. А документирование требований позволит получить нужный результат, не пропустив важных деталей.
Опубликовано 18.04.2024
