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

Первое поколение (1960-е годы) — мейнфреймы: задачи учета и расчета, связанные с прогнозами или моделированием; бухгалтерские программы и первые банковские системы. Каждая программа разрабатывается под конкретную архитектуру ЭВМ, а пользователям обычно предлагается пакетный режим работы. Системные программисты отвечают за ОС и компиляторы, а прикладные — за создание программ, написанных на одном из немногочисленных языков программирования (Алгол, Фортран и пр.). Вычислительные комплексы теоретически поддерживают до 100 тысяч одновременно работающих пользователей и устройств.

Рис. 1. Эволюция ИТ-архитектур

Второе поколение (1970-е годы) — универсальные ЭВМ: приложения усложняются, компьютеры объединяются в сеть; появилась возможность контроля за отдельными производственными процессами и целыми предприятиями; возникают сложные банковские системы. Используются монолитные архитектуры: программные модули в процессе компиляции и сборки собираются в единое приложение, взаимодействующее с пользователями в терминальном режиме. Появились СУБД. Системные программисты отвечают за ОС и компиляторы, а прикладные используют разные универсальные и специализированные языки программирования (Cи, PL/1, Пролог и др.). Поддерживается до 1 млн одновременно работающих пользователей и устройств.

Третье поколение (1980-е годы) — ПК: приложения строят одноранговые сети; программные модули объединяются в монолитное приложение, способное по сети взаимодействовать с другими приложениями; широкое распространение получает автоматизация задач управления предприятием (логистика, продажи, кадровый учет, документооборот и пр.); набирает популярность графический интерфейс; все шире применяются САПР; появились системы управления ресурсами предприятия начального уровня. Приложения работают с пользователями в интерактивном графическом режиме. Появляются первые фреймворки и среды исполнения: FoxPro, Delphi и пр. Системные программисты отвечают за драйверы для ОС и коммуникационные модули, а прикладные разрабатывают интерфейсы пользователя и реализуют бизнес-логику. Системы на базе одноранговых сетей поддерживают до 10 млн одновременно работающих пользователей и/или устройств.

Четвертое поколение (1990-е годы) — клиент-сервер: у сетевой топологии приложений появляется специализация; на сервер переносятся задачи хранения и пакетной обработки данных, а клиенты отвечают за визуализацию и взаимодействие с пользователем; многопользовательский режим обеспечивает поддержку решений задач комплексной автоматизации управления предприятием; широкое распространение получают многопользовательские САПР с библиотеками готовых компонентов; популярны географически распределенные системы и мониторы распределенных транзакций (Tuxedo и пр.). Расширяется спектр и специализация языков программирования (SQL, C++, Object Pascal) и фреймворков (Visual C++, PowerBuilder). Системные программисты отвечают за драйверы ОС и интеграционные библиотеки, прикладные программисты — за логику на «толстом» клиенте, бизнес-логику на сервере базы данных, тестировщики — за проверку работоспособности сложной конфигурации. Системы клиент-сервер поддерживают до 100 млн одновременно работающих пользователей и/или устройств.

Пятое поколение (2000-е годы) — сервисная архитектура: усложнение задач приводит к появлению концепции повторно используемых сервисов; количество специализированных узлов сетевой топологии вырастает до четырех (сервер хранения данных, сервер приложений, сервер интерфейса пользователя, браузер); набирает популярность концепция шины данных предприятия (Enterprise Service Bus, ESB), что позволяет ускорить развертывание приложений поддержки новых бизнес-процессов; появились системы электронной коммерции и первые социальные сети; в компаниях все шире применяется электронный документооборот и автоматизируются основные бизнес-процессы; появляются мобильные приложения; разработчики активно используют фреймворки. В это время появляются первые цифровые платформы поддержки предприятий, работающих в реальном времени [1], а значит, управляемых событиями и данными [2]. Такие платформы призваны устранить разрозненность политик и инвестиций в технологии для концентрации усилий на новых операционных моделях, раскрывающих потенциал всех имеющихся у компании данных. Цифровые платформы играют роль связующего звена между поставщиками приложений, пользователями и потребителями. Углубляется специализация разработчиков: системные программисты отвечают за ПО связующего слоя (middleware) и многократно используемые библиотеки; фронтенд-программисты — за веб-интерфейс; бэкенд-программисты — за API и бизнес-логику сервера приложений; программисты баз данных — за бизнес-логику на сервере баз данных; разработчики мобильных приложений — за приложения для носимых устройств, QA-инженеры — за тестирование с помощью специального инструментария. Системы поддерживают до 1 млрд одновременно работающих пользователей и устройств.

Шестое поколение (2010-е годы) — облака: набирает популярность концепция эластичных распределенных сервисных архитектур; количество сетевых узлов не ограничено; критичным для бизнеса становится время вывода на рынок новых продуктов и услуг — для этого целевые архитектуры собираются из готовых компонентов (сервисов) под конкретную задачу; получают широкое распространение концепция управления релизами и различные варианты каскадного размещения распределенных приложений (Green/Blue Deployment, Canary Releases); машинное обучение входит в практику разработчиков, что помогает справиться с ростом сложности и разнообразием задач; появляется концепция озера данных; глобализуются системы электронной коммерции и социальные сети; ведущие компании завершили автоматизацию своих бизнес-процессов; началась роботизация производственных процессов; все шире применяются мобильные приложения и мультимедийные системы; возник Интернет вещей; появились новые типы интерфейсов пользователя; большинство прикладных разработок ведется на базе фреймворков; цифровые платформы становятся основой бизнеса цифровых монополий. Специализация команд разработчиков продолжает углубляться: разработчик и инженер по данным уже ничего не знают о сетевой топологии приложения и полностью концентрируются лишь на бизнес-логике сервисов; DevOps-инженеры концентрируются на конфигурировании среды непрерывной интеграции и развертывании релизов; бэкенд-программисты отвечают лишь за бизнес-логику атомарных сервисов, размещаемых в контейнерах, и бизнес-логику на сервере баз данных; инженеры данных отвечают за структуру озера данных и код ETL-конвейера по преобразованию данных; QA-инженеры автоматизируют процесс тестирования. Облака поддерживают до 50 млрд одновременно работающих пользователей и устройств.

Сегодня пришло время следующего поколения архитектур поддержки изменяемых «на лету» ИТ-инфраструктур теоретически бесконечного масштаба: географически распределенные конфигурации, динамически настраиваемые в режиме реального времени; киберфизические системы массового обслуживания, ориентированные на непрерывную обработку потоков данных от произвольного количества оконечных устройств; линейно масштабируемые по запросу приложения, обеспечивающие быстрое и неограниченное подключение любого числа источников данных разнообразной природы.

Фактически, седьмое поколение архитектур, получившее название «гиперскейлер» (hypescaler), ориентировано на эффективное решение сверхмасштабных задач в среде Интернета вещей, что позволит безболезненно расширять существующую или создавать новую цифровую платформу предприятия. Например, для подключения к имеющейся ИКТ-инфраструктуре и бизнес-процессам еще одной аппаратно-программной производственной площадки в архитектуре гиперскейлера достаточно развернуть еще один ЦОД (Edge DC) и сеть базовых станций 5G/6G [3]. В архитектуре седьмого поколения специализация разработчиков еще больше сужается по различным прикладным областям (доменам) и инструментальным средам: создатели базовой инфраструктуры платформы; разработчики фабрики развертывания; разработчики инфраструктуры фабрики данных; разработчики инфраструктуры фабрики моделей; разработчики инфраструктуры фабрики самообслуживания; разработчики фабрики нативных приложений; модельеры данных; бизнес-аналитики.

Цифровая платформа эпохи Интернета вещей

В зависимости от масштаба бизнеса, бюджета и квалификации разработчиков реализация цифровых платформ была возможной еще в логике шестого или даже пятого поколения. Однако сегодня для всех цифровых компаний актуальна задача эффективного управления географически распределенными ИКТ-ресурсами в сценариях Интернета вещей и в условиях неограниченного количества подключенных пользователей и источников данных. Соответствующая цифровая платформа должна решать задачи автоматического управления, обеспечения доступа к ресурсам из любой точки и в любое время, поддерживать среды самообслуживания, исполнения и контроля качества услуг, а также содержать средства инвентаризации ресурсов, онлайн-биллинга, но главное — включать фабрики автоматического развертывания приложений, источников и реплик данных.

Время вывода на рынок новых продуктов и наличие автоматизированных средств управления сложными динамическими инфраструктурами — отличительные характеристики цифровых платформ на архитектуре гиперскейлера. При развертывании приложений всех категорий за секунды обеспечивается подключение к сетям 5G/6G. Время вывода на платформу нового приложения («автокомплаенс»), который включает конфигурирование, автоматическую проверку приложений на соответствие требованиям платформы, наличие уязвимостей и т. д., измеряется минутами. В платформе обязательно наличие средств автоматической поддержки отказоустойчивости приложений реализации бизнес-процессов и среды их разработки. Перенос бизнес-процессов на цифровую платформу может потребовать полной переделки уже существующих приложений, особенно разработанных в архитектуре SOA. Как показывает практика, заставить такие приложения «сверхмасштабироваться» невозможно — простым и менее затратным становится вариант сборки приложения с нуля в среде no- или low-code.

Одна из главных особенностей платформы — поддержка средств динамической реконфигурация приложений: сборка/разборка «на лету» целевых функций, поддерживаемых набором готовых и размещенных на платформе компонентов; поддержка специфических сценариев Интернета вещей, необходимых для реализации бизнес-идеи, — например, управление группировками дронов, управление беспилотным транспортом, федеративное машинное обучение и пр. Для всего этого требуется панель автоматического управления, позволяющая пользователям платформы формировать политики работы с арендуемыми ресурсами и бизнес-процессами, включая сценарии реагирования на инциденты.

Важную роль играют средства виртуализации сервисов («интранет сервисов») и моделей на основе механизмов автоматического управления топологией микросервисов, построенных на концепции наложенной сети сервисов (Service Mesh), все шире применяемой сегодня на практике [4]. Виртуализация моделей предназначена для автоматического управления подготовкой наборов обучающих и тестовых данных, конвейеров обучения и тестирования моделей с использованием механизмов DevOps, MLOps, ModelOps, AutoML и управления политиками. Механизм виртуализации моделей позволяет четко определить процесс подготовки, обучения и обновления моделей и отделить его от горячих копий или реплик модели, распределенных по сетевой топологии. Виртуализация модели подразумевает создание повторно используемого объекта обученной модели последней версии, а также конвейера по обучению и тестированию модели с применением необходимых процедур, таких как уточнение признаков (feature engineering), обучение, добавление атрибутов версионности и т. д.

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

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

 

Словарь гиперскейлера

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

DevOps (Development & Operations). Концепция, культурные и инженерные практики, а также соответствующие инструменты автоматизации для повышения эффективности процессов разработки (Development) и эксплуатации (Operation) программного обеспечения за счет непрерывной интеграции и активного взаимодействия профильных специалистов. С точки зрения управления, DevOps позиционируется как agile-подход для устранения организационных и временных барьеров между командами разработчиков и других участников жизненного цикла ПО, с тем чтобы участники могли быстрее и надежнее собирать, тестировать и выпускать новые релизы программных продуктов.

MLOps (Machine Learning Operations). Набор практик и инструментов для развертывания моделей машинного обучения, созданных аналитиками или математиками в «лаборатории данных» для конкретной среды исполнения. Большое влияние на MLOps оказал подход DevOps.

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

ModelOps (Model Operation). Концепция, набор практик и инструментов автоматизации для непрерывной интеграции аналитических моделей в бизнес-процессы, обеспечивающие использование созданных моделей в ИТ-инфраструктуре в условиях непрерывных изменений и обновлений. ModelOps позволяет непрерывно наращивать масштаб применения моделей машинного обучения и средств искусственного интеллекта для гиперавтоматизации бизнес-процессов. ModelOps — это дальнейшее развитие MLOps и AutoML.

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

Интранет данных (Data Mesh). Результат виртуализации источников данных путем определения механизмов виртуализации и оркестрации согласованных наборов данных, привязанных к источнику в форме одного микросервиса или их группы, а также строгого отделения понятия постоянных источников данных от их представлений (реплик, горячих копий и т. п.), распределенных по сети. Data Mesh позволяет скрыть от разработчиков сетевую топологию постоянных источников данных, что делает полностью независимыми и устойчивыми к непрерывным изменениям как сами постоянные источники данных, так и микросервисы, их потребляющие. Механизм оркестрации позволяет автоматически управлять источником данных и его репликами на основе политик. Большое влияние на Data Mesh оказали подходы Service Mesh и DataOps.

Интранет моделей. Результат объединения виртуализованных моделей и конвейеров их обучения в сеть. Виртуализация моделей, конвейеров их обучения или реплик моделей в форме одного микросервиса или группы микросервисов позволяет скрыть от разработчиков сетевую топологию инфраструктуры обучения и непрерывной интеграции моделей. Термин Model Mesh пока распространения не получил

SRE (Site/System Reliability Engineering). Подход, основанный на наборе культурных и инженерных практик и инструментов автоматизации, продвигаемый Google и направленный на обеспечение эксплуатационной надежности распределенных систем. SRE призван обеспечить надежную и безотказную работу распределенных приложений с учетом масштабирования по запросу, отказов или катастроф. Большое влияние на SRE оказал подход DevOps и ITIL.

 

Архитектура гиперскейлера

Рис. 2. Архитектура гиперскейлера

За функциональное наполнение цифровых платформ на базе гиперскейлера отвечают несколько «фабрик» (рис. 2).

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

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

Фабрика моделей. Среда для разметки обучающих и тестовых наборов данных, обучения и тестирования моделей — кандидатов на промышленное использование, а также многократного применения модели для решения различных задач. Фабрика обеспечивает поддержку сквозных процессов непрерывной поставки, сборки, тестирования, интеграции, управления релизами приложений и обучения моделей искусственного интеллекта, а также выполнение различных сценариев машинного обучения (Continuous ML, Federated ML, AutoML) и совмещение сценариев в цепочки. По сути, фабрика является дальнейшим развитием концепций ModelOps, MLOps и AutoML.

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

Рис. 3. Пример географического распределения физической инфраструктуры гиперскейлера

На рис. 3 приведен пример географического распределения физической инфраструктуры гиперскейлера: Central DC — вычислительное ядро, образуемое главными ЦОДами, объединенными в катастрофоустойчивое кольцо с расстоянием между узлами 100–1000 км; Regional Edge — сеть региональных ЦОДов, каждый из которых присоединен как минимум к ближайшему Central DC (50–100 км); Access Edge — сеть контейнерных ЦОДов, выполняющих роль границы единого распределенного облака, причем каждый граничный ЦОД присоединен как минимум к ближайшему Regional Edge (20–40 км); On-prem DC — ЦОД пользователя гиперскейлера, максимально приближенный к источникам данных и присоединенный как минимум к одному ближайшему Access Edge (менее 20 км); Smart Device — вычислительный узел, агрегирующий данные с оконечных устройств и присоединенный к сети, подключенной к On-prem DC и/или ближайшему Access Edge (0–25 м); Constrained Device — зарегистрированное оконечное устройство (датчик, актуатор, камера и т. п.), снабженное контроллером для подключения устройства к Smart Device или локальной сети и, при необходимости, для централизованного выполнения прошивки. Локальная сеть присоединена к сети ЦОДов On-prem DC или как минимум к одному контейнерному Regional Edge.

Коммуникация между уровнями физической инфраструктуры возможна по каналам Интернета, 5G и каналам последней мили: xDSL, FTTx, Wi-Fi, WiMax, DOCSIS, связь по ЛЭП, 6G/5G/LTE, спутниковые каналы. Интерфейс передачи данных нижнего уровня — среда, не предусматривающая маршрутизацию пакетов: RS-232, RS-485, 1Wire, USB, Bluetooth и др.

***

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

В зависимости от вида бизнеса цифровая компания выстраивает свои конкурентные преимущества вокруг определенной предметной области, в которой сосредоточены ее наилучшие компетенции и платежеспособные клиенты: телекоммуникационные компании берут за основу свою сетевую инфраструктуру, делая ставку на 5G, граничные вычисления применительно к сценариям работы в среде Интернета вещей; компании электронной коммерции разворачивают инфраструктуру, в центре которой технологии монетизации трафика и поиска информации; финансовые институты лучше других умеют масштабировать процедуры комплаенса и оказывать финансовые услуги.

Примеры первых гиперскейлеров — Amazon Web Services, Google Cloud Platform и Microsoft Azure. К созданию подобных собственных решений в России приступили, в частности, «Сбер», «Яндекс» и МТС.

Литература

1. Леонид Черняк. На пути к предприятию, управляемому в реальном времени // Открытые системы.СУБД. — 2002. — № 12. — С. 43–45. URL: https://www.osp.ru/os/2002/12/182256 (дата обращения: 20.05.2021).

2. Леонид Черняк. EDA — архитектура, управляемая событиями // Открытые системы.СУБД. —2005. — № 2. — С. 28–25. URL: https://www.osp.ru/os/2005/02/185297 (дата обращения: 20.05.2021).

3. Сюцюань Цяо, Якунь Хуан, Цзюньлян Чэнь, Шахрам Дустдар. 6G: децентрализованная сеть и интеллектуальная сервисная архитектура // Открытые системы.СУБД. —2020. — № 4. — С. 10–15. URL: https://www.osp.ru/os/2020/04/13055721 (дата обращения: 20.05.2021).

4. Александр Бондарик. Платформа для работы в условиях неопределенности // Открытые системы.СУБД. — 2021. — № 2. — С. 13–17. URL: https://www.osp.ru/os/2021/02/13055877 (дата обращения: 20.05.2021).

Александр Прозоров (aalprozorov@sberbank.ru)  —  научный  сотрудник,  МФТИ; Роман Шнырев (rvshnyrev@sberbank.ru)  —  руководитель направления, Лаборатория новых технологических решений  «Сбера»;  Дмитрий Волков (vlk@keldysh.ru) — старший научный  сотрудник,  ИПМ им. М.В. Келдыша РАН (Москва).

DOI: 10.51793/OS.2021.96.54.002