Архитектурные особенности on-premises продуктового решения

Введение

Несмотря на активно развивающийся SaaS-сегмент рынка и кажущееся стремление компаний использовать облачные ресурсы, отдельные направления IT-продуктов на рынке продолжают оставаться востребованными крупным бизнесом в виде дистрибуций, разворачиваемых в собственных дата-центрах (англ. on-premises) и под собственным контролем.

Программные решения, адаптированные к такому способу поставки, имеют ряд особенностей архитектурного характера, которые в идеальной картине мира необходимо учитывать на этапе первичного проектирования.

Зачастую разработка on-premises программного решения начинается как заказная (проектная) разработка под конкретного заказчика. Уже далее компания-разработчик ставит перед собой задачу тиражирования полученного решения и продажи другим заказчикам.

Другой похожий вариант развития событий - компания выставляет in-house разработку на продажу на внешний рынок.

В обоих случаях исходная низкоуровневая архитектура программного решения (общий стиль, набор принципов и ограничений, инфраструктура) скорее всего строго подогнана под конкретный запрос первичного заказчика, в результате чего команда продукта сталкивается с проблемой альтернативных дорогостоящих нефункциональных требований, ценность которых неочевидна для бизнес-лидеров, но неоспорима для удовлетворения бюрократического формализма в лице внутренних ЛНА заказчика.

В статье рассматриваются некоторые подобные категории архитектурно-значимых нефункциональных требований (IT, ИБ), варьируемых в широких пределах от заказчика к заказчику, и даются рекомендации по управлению ими с помощью гибких архитектурных принципов.

---

Термин “on-premises” как правило фигурирует в контексте B2B решений с акцентом на серверные вычисления и многопользовательский режим, про что речь и пойдёт далее.

Я не встречал употребление этого термина в отношении B2C, хотя формально такое не запрещено (возможно, синонимом тут был бы термин “stand-alone”). Простой возможный пример B2C on-premises – комплекс IoT-решений для разворачивания умного дома; или, например stand-alone ПО для редактирования фотографий.

Данная статья не про заказную (проектную) разработку, но именно про продуктовое решение условно-независимого вендора, имеющее собственный продуктовый цикл и продуктовое виденье.

Дисклеймер: каждый бизнес по-своему уникален. Также как и каждое программное решение – начиная от необычной идеи, и заканчивая особенностями конечной реализации. Приведённые в статье тезисы относятся к общему восприятию тяжеловесного on-premises сегмента в Российском IT-бизнесе глазами автора и не являются исчерпывающими; могут не иметь веса в отдельных частных случаях.

Эта статья также доступна в моём персональном блоге Domain(Driven)Drill: https://domaindrill.xyz/on-premises-architecture-explained/ .

---

Терминология

On-premises deployment – способ развёртывания коробочного продуктового решения, подразумевающий развёртывание в изолированном корпоративном инфраструктурном контуре заказчика выделенно (dedicated) для данного заказчика.

Коробочное продуктовое решение (коробка) – готовый к развёртыванию самодостаточный комплект поставки (дистрибутив) продуктового решения.

Под инфраструктурным контуром подразумевается совокупность слагаемых:

• Вычислительное оборудование (bare-metal, виртуальные машины)

• Сетевое оборудование (любое сетевое оборудование)

• Группа эксплуатации

  • Департамент IT

  • Департамент надёжности сервисов

  • Сетевой департамент

  • И т.п.

• Корпоративные ЛНА (свод организационно-технических правил и ограничений от ИБ, IT, …)

Сайзинг (англ. sizing) – количественные и качественные требования к аппаратному обеспечению, необходимому для функционирования развёрнутого ПО программного решения при заданных целевых показателях назначения (количество пользователей, пиковая нагрузка, объём информации, …).

---

Тиражируемость

Многие принципы, рассмотренные в данной статье, так или иначе следуют из основного – принципа тиражируемости.

Для продуктового решения, распространяемого только в виде SaaS-версии, и имеющего в топологии пользователей уровень, эквивалентный “организации”, принцип тиражируемости требует возможность уметь давать доступ к продукту одновременно нескольким организациям, изолируя пользователей одной организации от другой.

Речь идёт о виртуализации единой физической инсталляции, что в большей степени ложится в зону ответственности фичи по мультитенантности, а также ряда функциональных блоков, связанных с биллингом и администрированием.

Для on-premises фокус принципа тиражируемости становится более низкоуровневым, так как множество различных заказчиков имеют и самостоятельно обслуживают свои собственные, взаимно независящие друг от друга физические инсталляции, уже изолированные по определению. Очевидно, речь не идёт о виртуализации одной и той же физической инсталляции. Тиражируемой тут уже должна быть инсталляция вместе с прикладным и инфраструктурным слоем.

В общем случае принцип можно сформулировать так:

Принцип тиражируемости: не должно требоваться доработок продуктового решения для типовых внедрений широкого круга потенциальных заказчиков

Когда продукт распространяется только как SaaS-версия, архитектура достаточно детерминирована, так как все архитектурно-значимые характеристики в высокой степени диктуются ограниченным и вполне конкретным кругом заинтересованных лиц (CIO, CFO, CPO, CTO, CISO).

В случае с продуктовой поставкой on-premises, для каждого бизнеса-заказчика (коих конечный круг в общем случае также не определён) полный набор заинтересованных лиц будет столь же конкретным по компетенциям, но отличным по конкретным персоналиям. Отсюда и вероятная корректировка архитектурно-значимых характеристик.

Приняв верной эмпирическую гипотезу незначительности отличия уровня “компетентности” людей, соответствующих одной и той же компетенции в разных компаниях, а также пренебрегая разницей в предметной направленности разных компаний на рынке и их зрелости, маловероятны кардинальные изменения в архитектурно-значимых характеристиках, поступающих, как новые требования при каждом новом внедрении on-premises.

Как архитекторы (и немного экстрасенсы), мы можем до некоторой степени снизить влияние варьирующихся от заказчика к заказчику архитектурно-значимых требований к нашему продуктовому решению путём обеспечения поддержки широкого круга параметров и возможностей функционирования, потенциально подверженных изменению.

К таковым относятся:

• Варианты развёртывания – зависимость от платформы и прикладного ПО, требования к компетенции эксплуатации

• Гибкий сайзинг с прогнозируемой динамикой

• Отключаемость отдельных модулей или возможность подключения дополнительных

• Прикладное ПО

• Интеграционные возможности и пути кастомизации

---

Сетевая изолированность

Важной особенностью инфраструктурного контура развитых (крупных – large enterprise, LE и средних – middle enterprise, ME) предприятий является сетевая изолированность: сетевые узлы внутри изолированного сетевого контура (LAN) недоступны или ограниченно доступны извне (WAN) за счёт файерволов и NAT. Действует также обратное ограничение: серверы вычислительных кластеров, а также рабочие станции офисных сотрудников могут вообще не иметь доступа в WAN.

В большинстве случаев, при наличии строгой сетевой изолированности, отдельные серверы и рабочие станции офисных сотрудников могут получить доступ в WAN, что, однако, потребует потенциально длинной и изобилующей “бутылками на стол” цепочки согласований. Поэтому эту опцию будем считать по-умолчанию недоступной.

Для архитектуры продуктового решения это обозначает в случае выбора доступных альтернативных путей, не полагаться на наличие возможности доступа в интернет. Разумеется, если этого не подразумевает идея самого решения.

Принцип автономности (ограничение): выбирать пути реализации, исключающие потребность доступа в интернет (зависимость от удалённых ресурсов).

Выше речь идёт про штатную эксплуатацию системы, построенной на базе программного решения.

В отдельных компаниях (LE) накладываются более строгие ограничения сетевой изолированности – в том числе, на персонал эксплуатации и, в частности, на процесс первичной установки и последующих установок обновлений – загрузка зависимостей (библиотеки, базовые образы docker, драйверы, …) и вспомогательных инструментов из интернета может быть невозможна.

Вспомогательное ПО, необходимое для удобства инженера эксплуатации, в таких случаях может быть загружено по предварительному согласованию.

Принцип автономности (ограничение): внешние зависимости должны входить в комплект поставки (не обязательно на уровне кода).

Пользовательский доступ из WAN

При доступе извне корпоративной сети в приложение, частым требованием ИБ является экранирование персистентных сервисов посредством дополнительного узла (группы узлов) в ДМЗ, выполняющего функцию прозрачного прокси, с целью снижения вероятности отказа основного кластера, а также упрощения управления доступом к приложению (при инцидентах).

Роль такого узла может выполнять и L7-балансировщик нагрузки.

По согласованию с ИБ, в некоторых случаях подобный узел также может осуществлять SSL-декапсуляцию входящего трафика.

В выполнении данного требования могут возникнуть сложности, если высокоуровневый протокол доступа в приложение отличен от HTTP.

---

Ограниченность аппаратных ресурсов

Несмотря на то, что, как правило, какой-то объём свободных вычислительных ресурсов доступен в компании под возникающие потребности постоянно, любому ресурсу есть предел.

Закупка аппаратного обеспечения в компаниях среднего и крупного сегмента происходит в рамках цикла ресурсного планирования, основная суть которого состоит в том, что всё необходимое оборудование для информационных систем обосновывается и планируется к закупке заблаговременно (годовой цикл планирования).

Исходя из этого, важно иметь достаточно точную оценку требуемого аппаратного обеспечения на момент продажи.

Различные проектные решения внедрений информационных систем на базе одного и того же продуктового решения как правило отличаются вариативностью отдельных (если не всех) целевых показателей назначения в широких пределах (общее число пользователей, пиковая нагрузка, объём данных на пользователя, …) ввиду принципиально различных корпоративных особенностей отдельных заказчиков.

Также могут варьироваться допустимые физические характеристики вычислительной единицы (допустимая переподписка, тактовая частота pCPU, HDD/SSD).

Типовой проектной потребностью для оценки будущих закупок также являются:

• Прогноз динамики роста объёма данных информационной системы на 3-5 лет вперёд;

• Потенциал к масштабированию вычислительной мощности информационной системы (характер кривой масштабирования)

Всё вышеперечисленное ведёт к очевидной потребности в наличии достаточно точной (учитывающей погрешность и риски) методологии расчёта требований к аппаратному обеспечению данного продуктового решения – заветного калькулятора сайзинга, принимающего целевые показатели назначения ИС в качестве аргументов и физические характеристики оборудования в качестве параметров.

Золотое правило предотвращения незапланированной стирки нижнего белья: план чуть больше факта – значительно лучше, чем план сильно меньше факта.

Рекомендация: дизайн решения должен предусматривать возможность регулярной точной оценки сайзинга.

Отдельного внимания заслуживает проблема увеличения сайзинга в связи с выпуском новых фичей.

Разумеется, новая версия ПО, в очередной раз прилетевшая в заказчика, внезапно потребляющая на порядок больше вычислительных ресурсов, чем уже установленная, вызовет, мягко говоря, негодование.

Поэтому актуальное потребляемое количество ресурсов необходимо контролировать.

Принцип легковесности: архитектура решения и/или организация разработки должна предусматривать органиченность (в момент внедрения и в последующей динамике) в размахе потребляемых ресурсов.

Можно также рассматривать принципы-следствия, к части которых мы вернёмся позже:

Принцип модульности/кастомизируемости (на уровне развёртывания): отдельные единицы развёртывания, инкапсулирующие большие группы фичей, должны быть отключаемы от остального решения посредством фича-флагов

В целом, напрашиваются более “лёгкие” алгоритмы и более “скудный” ландшафт прикладного ПО, больше допущений качества функционирования системы ценой постоянства сайзинга.

Данную проблему (как и любую другую) можно решать и в поле договорных отношений, однако, никакой ME/LE бизнес не будет готов к регулярному увеличению сайзинга ИС, не обусловленному собственной очевидной потребностью.

---

Стандартизованность

Важным аспектом является готовность решения к интеграции с широким спектром типовых систем (на уровне бизнеса и инфраструктуры).

К счастью, много подобных систем объединяются в типовые классы систем, на которые распространяются общепринятые интеграционные протоколы.

Поэтому часто данную потребность можно свести к потребности поддержки распространённых открытых интеграционных протоколов.

С другой стороны, наблюдаемость, простота эксплуатации и защиты значительно выше для открытых протоколов, чем для проприетарных.

Принцип стандартизованности: продуктовое решение должно преимущественно зависеть от распространённых и открытых протоколов, платформ, прикладного ПО, вместо специфических проприетарных.

Возможности аутентификации

Типовой потребностью on-premises внедрений является интеграция с корпоративным каталогом учётных записей и требование к SSO (single-sign-on).

Под корпоративным каталогом в большинстве случаев подразумевается Microsoft Active Directory или аналогичные, поддерживающие протокол LDAP (FreeIPA, Samba DC, …).

Непосредственно аутентификация (в том числе, SSO) с использованием внешних IdP может осуществляться по протоколам Kerberos, SAML, OAuth2.0 .

Отдельного рассмотрения заслуживает разновидность SSO путём интеграции с IdP посредством "First-Login flow" – подобный способ отличается тем, что на начальном этапе у целевой системы нет полного объёма пользовательских УЗ в собственной базе данных. Целевая система создаёт учётную запись пользователя в собственной базе данных непосредственно в момент аутентификации. Осуществляется подобный вид SSO как правило по протоколам SAML и OpenID Connect.

Общая рекомендация тут в использовании готовых решений, специализирующихся непосредственно на аутентификации, так как данные задачи хоть и являются обязательными для функционирования системы, но маловероятно относятся к core-домену продукта (support). Как следствие, подсистема аутентификации доступа должна быть инкапсулирована в отдельную архитектурную единицу, и связность с ней должна быть низкой.

Возможности интеграции с типовыми корпоративными системами

Буду краток и просто оставлю тут неисчерпывающий, но минимальный список:

• Системы резервного копирования и восстановления (используемые СУБД должны поддерживать резервное копирование и восстановление)

• Корпоративная централизованная система мониторинга (логи, метрики, алертинг)

• SIEM (стандартный протокол - syslog)

• DLP и антивирус (стандартный протокол - ICAP)

• Корпоративное файловое или объектное хранилище

---

Топология развёртывания

Классическим требованием IT и ИБ является организация "многоуровневой" (синонимы - многозвенной, многослойной, N-tier) топологии развёртывания программного решения, разнесённой на несколько сетевых зон. В частности, трёхуровневая топология.

Требование порождается существенной разницей в применяемых методах обеспечения безопасности, надёжности, эксплуатации по отношению (в основном) к трём ключевым типам серверов:

1. Серверы представления (front-end)

2. Серверы бизнес-логики (back-end)

3. Серверы баз данных

Под серверами представления в разных случаях подразумевается разное. Как правило, в контексте веб-приложений, это не просто веб-сервер, раздающий статическое содержимое для браузеров, но слой, изолирующий сетевую доступность слоя серверов бизнес-логики. Подходящим в таком случае мог бы быть компонент api-gateway или L7-балансировщик нагрузки.

Одна из предпосылок к данному требованию упоминалась выше в разделе "Пользовательский доступ из WAN".

Вынесение логики представления может не иметь смысла для API-only продуктовых решений. В таком случае число "уровней" сокращается до двух.

Принцип N-tier: продуктовое решение должно предусматривать многоуровневую (минимально - два уровня: бизнес-логика и базы данных) топологию развёртывания.

---

Квалификация персонала группы эксплуатации

Управление выпущенной в промышленную эксплуатацию информационной системой на базе продуктового решения обычно осуществляется инженерами группы эксплуатации отдела IT заказчика.

Для отдельных групп систем, критичных для успешного функционирования бизнеса, могут выделяться отдельные группы инженеров эксплуатации. Скорее всего это не наш кейс 😀

А теперь ближе к реальности: у заказчика есть пул из нескольких инженеров “общей практики”, обеспечивающих поддержку множества общекорпоративных информационных систем.

В общем случае не стоит рассчитывать на наличие выдающихся специальных навыков у инженеров эксплуатации для отладки сломавшегося процесса gcc make, как и на наличие неограниченного количества времени для ручного исполнения длинного скрипта установки/обновления, написанного на картинках с водяными знаками в документе pdf, сжатом для отправки по почте, и предполагающего наличие столь же неограниченного множества точек отказа процесса.

С другой стороны, окна RTO (точнее, максимальное окно недоступности) не бывают очень большими – в случае инцидента поломки системы, у инженеров эксплуатации есть довольно короткий промежуток времени, в течение которого можно безболезненно для бизнеса выполнять команды в командной строке и нажимать на все доступные красные кнопки.

На что точно можно рассчитывать: чтение и выполнение несложных и быстрых инструкций в небольшом объёме.

Таким образом, как бы странно это не звучало, автоматизированная система должна быть достаточно автоматизированной, чтобы не требовать у среднего заказчика найма дорогостоящих DevOps-инженеров специально для эксплуатации целевого продуктового решения.

Принцип быстрой эксплуатации: штатные процедуры эксплуатации не должны отнимать большое количество времени у инженеров эксплуатации (считается всё время операции от начала до успешного завершения)

Сюда также относится отсутствие ручных миграций баз данных - это ответственность кода.

Звучит очевидно, но, несмотря на это, многие решения предполагают накатывание миграций баз данных в полностью ручном режиме.

Принцип простой и безопасной эксплуатации: общий подход к обслуживанию программного решения должен быть достаточно простым и подходящим под описание компетенции “уверенный пользователь ПК” и безопасным для среднего инженера эксплуатации заказчиков целевого рынка

С другой стороны, возможны случаи неожиданного использования незадокументированных настроек или возможностей продуктового решения, использование или модификация которых не предполагается, но очевидно доступно и не запрещено в документации.

Принцип “чего не видно, того и нету”: все публично доступные (соответственно, протестированные) точки расширения и кастомизации (конфиги) функциональности должны быть физически отделены от конфигов, которые не являются публичными (менее протестированными), чтобы их случайно не испортили
Например: конфигурационные файлы или приватное API

---

Функционирование в виде нескольких дистрибуций

Релевантно для продуктовых решений, существующих в виде нескольких вариантов дистрибуции (например, SaaS и on-premises):

Принцип гибкости (на уровне кода): отдельные фичи должны быть конфигурируемы и, в частности, отключаемы через фича-флаги в конфигурационных файлах

---

Мониторинг

Отдельная горячая тема для обсуждений, обзываемая на языке зарубежных конкурентов красивым словом “Observability”.

Принцип наблюдаемости: решение должно обеспечивать необходимый для разрешения инцидентов (эксплуатация, ИБ, поддержка, разработка) уровень наблюдаемости: общие логи, логи аудита, трейсы, метрики

SaaS-only продукты грешат неинформативными и слишком избыточными логами. Человек, не знакомый с sed/grep и awk, не сможет извлечь ничего полезного из лог-файла весом в 100mb, содержащего все события системы за 1 минуту, а пресловутая Grafana повесит браузер, пока инженер будет пролистывать бесконечный список в поиске проблемы.

Вкратце:

• решение должно поддерживать конфигурируемый уровень логирования (INFO, ERROR, WARNING, FATAL, …);

• логи не должны содержать чувствительной и потенциально-чувствительной информации (дампы запросов API, содержимое форм, ПДн пользователей системы, содержимое файлов);

• логи не должны содержать избыточной и мусорной информации;

• логи должны содержать идентификатор трейсинга.

Отдельного внимания заслуживают логи аудита безопасности. Тут можно было бы сослаться на ФСТЭК-21 (РСБ-1, РСБ-2), но всё же приведу выжимку.

Логированию в журнал аудита безопасности обязательно подлежат:

• События первичного входа в систему и выхода из системы;

• События защиты информации, связанные с идентификацией, аутентификацией и авторизацией (разграничением доступа) при осуществлении логического доступа;

• События повышения (изменения) прав доступа пользователя в системе.

Логи аудита безопасности должны иметь строгий и дифференцируемый от обычных логов формат.

Минимальный рекомендованный набор информации каждого события:

• уникальный идентификатор события в системе (если применимо);

• наименование события;

• описание события (если применимо);

• результат действия: успешно не успешно (если применимо);

• дата и время события;

• идентификатор субъекта, выполнявшего действие;

• характеристики устройства субъекта, с которого выполнено действие (если возможно);

• информация, позволяющая однозначно определить совершенное действие.

Многие продуктовые решения несут с собой графический интерфейс просмотра логов аудита безопасности собственной разработки. Такое решение я вижу довольно спорным в смысле оправданности в случае on-premises для LE и ME – куда проще и дешевле интегрироваться с корпоративной SIEM-системой по стандартному протоколу syslog, чем пытаться продать инженерам ИБ отдельный неудобный (!) графический интерфейс.

---

Катастрофоустойчивость

Классическое и минимальное исполнение катастрофоустойчивой инсталляции – мульти-ЦОД Active-StandBy с асинхронной репликацией и ручным переключением.

Подобное исполнение в большинстве случаев возможно с минимальными затратами на уровне кода: почти любая СУБД умеет реплицироваться Master-Slave, все реплицируемые СУБД могут быть переключены; сетевые маршруты настраиваются за пределами вычислительного кластера с помощью сетевых инженеров.

Важно не путать с Master-Master геораспределённой инсталляцией. Это разные концепции, которые могут (но не обязательно должны) сосуществовать вместе. Последняя имеет смысл в условиях широкого геораспределения офисов (и отдельных сотрудников) компании и в доменных областях, особо чувствительных к задержкам отклика – телефония, мультимедиа стриминг, аукционы, … .

---

Заключение

Упущение некоторых из упомянутых выше идей может критически влиять на успех on-premises продуктового решения на рынке в целом.

Приведённый набор принципов не является исчерпывающим, однако позволит существенно сэкономить вендору на издержках, связанных с затратами на рефакторинг для удовлетворения неочевидных для функционального заказчика требований (категории требований, не являющиеся функциональными), и сфокусироваться на доработке и расширении основной ценности продуктового решения - бизнес-логике.