Базовая инфраструктура современных цифровых платформ

Технологические гиганты (Apple, Google, Amazon, Tesla, Baidu) начали выпускать собственные микропроцессоры. Аналитики связывают это с дефицитом микроэлектронных компонентов на рынке, однако главные факторы грядущего возможного передела рынка — недостаточная производительность, высокая энергоемкость и стоимость широко используемой сейчас связки CPU/GPU. Кроме того, расширяется область применения глубинных нейронных сетей. Все вместе это вынуждает техногигантов инвестировать в разработку собственных специализированных решений и поддержку перспективных проектов System-on-Chip (SoC). Одновременно интенсивно развивается инфраструктура цифровых платформ под влиянием роста количества источников данных и появления новых профилей нагрузки со стороны Интернета вещей, искусственного интеллекта, беcсерверных вычислений (serverless), программно-конфигурируемых ЦОДов и композитных архитектур (composable architecture).

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

К концу нулевых годов явно проявилась тенденция к централизации вычислительных ресурсов и их переносу в частные или публичные облака, а также к популяризации микросервисных (cloud-native) приложений, адаптированных для DevOps. Затем началось движение в сторону компаний, управляемых данными (data-driven), в надежде получить максимальную выгоду от всех доступных сведений. Сегодня активно популяризируется подход AI-driven: компании управляются искусственным интеллектом, решения которого развертываются во всех точках принятия тактических и оперативных решений. При этом от типа возникающих нагрузок зависит выбор адекватных программно-аппаратных комплексов.

Классификация распределенных приложений и уровни инфраструктуры

Рис. 1. Эволюция архитектуры решений

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

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

В зависимости от варианта «последней мили» выбирается периферийный (On-Prem DC) или граничный ЦОД (Access Edge). Если «управляемые» устройства присоединяются к центру обработки данных через локальную сеть (Ethernet, RS-485, Wi-Fi, LoRaWAN, Sigfox), то для размещения приложений, критичных к работе сети, и онлайн-приложений (Latency Critical App, Online App) необходим периферийный ЦОД. Если управляемые устройства (Smart Device) присоединяются при помощи NB-IoT, LTE-M или 5G/6G, то для размещения таких приложений необходим граничный ЦОД, а для онлайн-приложений — региональные ЦОДы [1]. Технологии 5G/6G добавляют новый вариант организации последней мили и граничных вычислений, что отражается на разделении ответственности между заказчиком и провайдером и, как следствие, на организации топологии физической инфраструктуры.

Рис. 2. Границы сервисов XaaS и порядок разработки приложений для гиперскейла

На рис. 2 представлен порядок разработки распределенных приложений в архитектуре гиперскейла. Здесь имеются две отправные точки — наличие либо отсутствие у пользователя ЦОДов, близких к источникам данных. В первом случае целесообразно говорить о варианте «мультиоблака с туманными вычислениями» (Multi Cloud + Fog Layer): ЦОДы горизонтально объединяются между собой и образуют уровень Fog Layer, где исполняются приложения, критичные к задержкам по времени. Остальные приложения поднимаются на уровень выше — в мультиоблако, где ресурсы дешевле. Уровень мультиоблака необходим по разным причинам: отсутствие зависимости от поставщика, более низкая стоимость вычислительных ресурсов, более короткие передачи данных с нижележащего слоя. Вариант мультиоблака подходит для отраслеобразующих или больших компаний, обеспечивающих критичную для государства инфраструктуру. При отсутствии своих ЦОДов, близких к источникам данных, используется вариант облака с мультидоступом (Cloud + Multi Access Edge), при котором функции слоя туманных вычислений выполняет двухярусный слой граничных вычислений. Первый ярус исполняется на мини-ЦОДах, которые находятся в непосредственной близости от границы сети последней мили. Второй ярус исполняется на региональных ЦОДах, где стоимость ресурсов дешевле, но и задержки больше. Некритичные к задержкам приложения выносятся на уровень вычислительного ядра главных ЦОДов, где стоимость вычислительных ресурсов самая низкая. Вариант облака с мультидоступом более всего подходит для компаний, имеющих обширную или не определенную в пространстве географию поддержки бизнес-процессов, — например, для логистических компаний. Этот вариант подходит и для SMB-компаний, для которых зависимость от провайдера инфраструктуры не критична.

Новые подходы к разработке опираются на типовые варианты программно-аппаратных комплексов (ПАК), позволяющих собирать физическую инфраструктуру для разных уровней, соответствующих конкретным инфраструктурным доменам: Compute — вычислительные ресурсы; Storage — системы хранения; CEP&AI — решения для аналитики и обработки сложных событий в реальном времени, хранения данных, обучения и исполнения моделей искусственного интеллекта; Network — решения для построения комплексных сетей предприятия.

Домен Compute, как правило, представлен x86-системами для поддержки общих нагрузок, таких как виртуализация, контейнеризация, и иногда нагрузок класса «сервер без гипервизора» (bare-metal). ИТ-гиганты [1], в отличие от остальных компаний, активно развивают собственные серверные решения на базе архитектуры ARM, обладающих пока лучшими показателями энергоэффективности и соотношения цена/производительность. Яркий пример такого подхода — компания Amazon, выпускающая серверы собственной разработки на базе процессоров Graviton и продающая их в составе вычислительных ресурсов своего облака.

Домен Storage сегодня развивается под влиянием расширения границ облака и роста объемов данных. Многие компании отказываются от классических массивов сетей хранения (SAN) в пользу распределенных программно-конфигурируемых хранилищ (Software-defined storage, SDS). Однако остаются нагрузки, для которых подходят классические решения SAN или массивы с прямым подключением (DAS), но в условиях расширения количества приложений в микросервисной архитектуре все более популярными становятся SDS-системы, которые, как правило, строятся на серверных мощностях x86-архитектуры либо на базе специализированных ПАК. На рис. 3 проиллюстрирован переход от SAN к SDS.

Рис. 3. Переход от унаследованных архитектур хранения к системам нового поколения на примере NAS

Домен CEP&AI требует особого внимания: правильно выстроенный конвейер для всех фаз ModelOps и MLOps в совокупности с адекватными ПАК позволяет сократить время вывода продукта на рынок, время на обучение моделей AI/ML, повысить производительность приложения, эффект от внедрения моделей и снизить стоимость вычислений в пересчете на операцию. Здесь возможны следующие типы программно-аппаратных комплексов:

BigData — ПАК для обработки и хранения больших данных, может комплектоваться GPU для ускорения обработки задач, например Apache Spark.

AI/ML — ПАК с аппаратными средствами ускорения в ЦОДах для выполнения задач искусственного интеллекта. Как правило, для фазы обучения моделей используются конфигурации с GPU, в то время как для фазы исполнения моделей — узлы с x86-процессорами и GPU, FPGA и специализированными схемами (ASIC). Выбор конфигурации для исполнения моделей в ЦОДе напрямую связан с решаемой задачей искусственного интеллекта: так, например, для рекомендательных систем лучше CPU, в то время как для задач синтеза и распознавания речи лучше GPU. Для задач компьютерного зрения применяются разнообразные ASIC — по мнению аналитиков, в будущем ASIC обойдут GPU для фазы исполнения моделей. На данный момент FPGA относительно редко применяются на открытом рынке в силу их высокой стоимости, но обладают неоспоримым преимуществом: их можно перепрограммировать. Лидер на рынке GPU и платформ для искусственного интеллекта — компания Nvidia. Однако ИТ-гиганты идут своим путем: выпускают свои ASIC для обучения и исполнения моделей, продавая их в составе вычислительных ресурсов своих облаков (Google TPU, Amazon Inferentia и Trainum).

Edge AI — системы с аппаратными средствами ускорения решения задач искусственного интеллекта при их выполнении в региональных ЦОДах или в специализированных конфигурациях в компакт-факторе. Расширение границ вычислений сместило вычислители ближе к источникам данных. Например, так строятся системы видеоаналитики: сервер или коробочное решение с GPU/ASIС обрабатывает данные с камер, распознавая номера автомобилей, а затем передавая их в текстовом формате в ЦОД для дальнейшей обработки, что снижает нагрузку на каналы.

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

Домен Network оккупировали ведущие мировые поставщики сетевого и телекоммуникационного оборудования (Cisco, Huawei и другие компании), в продуктовом портфеле которых присутствуют решения различного масштаба. Скорость передачи данных в облаках между вычислительными узлами составляет сегодня 100 Гбит/с, и многие компании стоят перед выбором: расширить каналы связи между ЦОДами и граничными устройствами или разместить граничные ЦОДы ближе к источникам данных. Набирает популярность и подход к построению сетевых решений на базе сетевых устройств, отвязанных от конкретных фирменных решений (whitebox), на которых можно установить ПО категории Open Source.

Композитная инфраструктура ЦОДов

Рис. 4. Топология композитных инфраструктур

На сегодня самый мощный источник изменений в инфраструктуре распределенных облаков — это композитные инфраструктуры. В отличие от традиционной многоуровневой структуры ЦОДа, композитная (рис. 4) состоит из опорной сети (Core Network), соединяющей набор независимых вычислительных модулей (point of delivery, POD) от разных производителей. Каждый POD определяется как элементарный блок в более крупном ЦОДе, обычно проектируемый и развертываемый одномоментно (сеть + вычислительные ресурсы + хранилище) и имеющий строгую границу с другими модулями POD и ЦОДами в целом. Модуль физически может быть образован сотнями стоек, хотя обычно соответствует контейнерному ЦОДу уровня Access Edge из 8–16 стоек и вмещает 16–32 физических коммутатора, 5–15 тыс. контейнеров или виртуальных машин.

Автоматизация на уровне POD обычно проще, чем на уровне традиционного центра обработки данных, где чаще происходят изменения емкости и конфигурации: появление новых технологий, улучшение соотношения цена/производительность в виде новых конструкций POD не влияет на уже существующие POD, ранее присоединенные к композитному ЦОДу.

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

Можно отметить три важных направления развития композитной инфраструктуры:

1. Модульные системы. Это ПАК собственной разработки, применяемые как на уровне Access Edge, так и в Central DC для исключения узких мест, имеющихся в серверных решениях общего назначения. Как правило, распределенные облака масштабируются путем добавления новых POD — например, Google Cloud Platform со своими кластерами TPU на базе тензорных процессоров или коммерчески доступных Nvidia SuperPOD.

2. Аппаратные функциональные акселераторы (function acceleration card, FAC). Это аппаратные акселераторы для разгрузки CPU от таких нагрузок, как виртуализация, СХД, сетевая виртуализация, обработка сетевого трафика, шифрование, кэширование, различные инфраструктурные функции, исполнение моделей искусственного интеллекта. FAC — один из важнейших столпов облачной стратегии. Впервые устройства такой категории представила компания Amazon в продукте Nitro (рис. 5) в составе своих облачных сервисов, позволивших на 30% разгрузить CPU и отдать освободившиеся мощности конечным потребителям, повысив плотность виртуализации и гибкость управления инфраструктурой. Как видно на рис. 5, исполнение логики управления инфраструктурой (Infrastructure Management), программно-конфигурируемых сетей и хранилищ (Software-Defined Storage), а также программно-конфигурируемой системы безопасности (Software-Defined Security) переносится c центрального процессора на FAC-акселераторы. При этом центральный процессор освобождается для исполнения логики приложений арендаторов (тенантов), что положительно сказывается на экономике архитектуры гиперскейла, при этом как для арендатора, так и для провайдера. На открытом рынке сейчас подобные решения представлены в портфеле компаний Intel (IPU) и Nvidia (DPU).

Рис. 5. Пример FAC — AWS Nitro. Перенос исполнения инфраструктурного ПО с CPU на FAC

3. Эластичные ресурсы для искусственного интеллекта. Это подход, обеспечивающий предоставление по запросу по сети вычислительных мощностей GPU/ASIC для решения задач искусственного интеллекта. При таком подходе можно GPU/ASIC с кластера, оснащенного данными устройствами, презентовать потребителям, чьи виртуальные машины/контейнеры расположены на кластерах без аппаратных ускорителей для искусственного интеллекта. Тем самым повышается утилизация оборудования и снижаются затраты на инфраструктуру путем перераспределения ресурсов по запросу. Пример таких решений — AWS Elastic Inference, Google Elastic TPU.

Энергоэффективность

Основные результаты снижения энергозатрат ожидаются в области обучения и исполнения моделей — вплоть до 95%. Мобильные или автономные управляемые устройства требуют ACIS или других функциональных акселераторов глубинных нейронных сетей милливаттной мощности. Профилирование вычислительной нагрузки в ЦОДах и применение стратегий кеширования, например, для токенизаторов [2] бросают вызов доминированию GPU. Снижение энергозатрат достигается также при использовании федеративного искусственного интеллекта (Federated AI) и нейроморфных архитектур.

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

Для нейроморфных архитектур на основе подхода SoC специализированный процессор может запускать стандартную сверточную нейронную сеть, преобразуя ее в домен событий, что позволяет непосредственно на микросхеме реализовывать трансферное (transfer learning) и пошаговое (incremental learning) обучение. Иначе говоря, один и тот же процессор с высокой производительностью и энергоэффективностью может и обучать, и исполнять сверточную сеть.

***

Фундамент цифровой трансформации — это физические уровни инфраструктуры, которые сегодня претерпевают существенные изменения. Уровни Central DC, Regional Edge, Access Edge будут строиться на основе композитных архитектур, для которых конфигурация собирается из модульных систем со специализированными средствами аппаратной акселерации, вычислительное ядро строится на энергоэффективных решениях, а в состав оборудования входит программно-конфигурируемый слой для горизонтального масштабирования нагрузок. Композитные архитектуры позволяют по запросу собирать требуемую конфигурацию, что дает возможность заранее или «на лету» развернуть специализированный загружаемый образ, не содержащий излишнего инфраструктурного ПО и, для отдельных задач, даже многопользовательской ОС. Это существенно повышает энергоэффективность и производительность распределенных приложений, что становится очень актуальным в условиях растущей стоимости электроэнергии.

Литература

1. Александр Прозоров, Роман Шнырев, Дмитрий Волков. Архитектура цифровых платформ будущего // Открытые системы. СУБД. — 2021. — № 2. — С. 24–28. URL: https://www.osp.ru/os/2021/02/13055934 (дата обращения: 21.11.2021).

2. Caching strategy for tokenizers to help achieve 1.46 ms inference on BERT QA on CPU. URL: https://github.com/huggingface/transformers/issues/13835?fbclid=IwAR1CA2rGPsBobDf_TnxH8wA3OrHMVUUNXo3_Ty3aFg7jVL2zp4J75BlddRI (дата обращения: 21.11.2021).

Александр Прозоров (ap@rtlab.ru)  —  независимый эксперт, Роман Шнырев (rvshnyrev@sberbank.ru)  —  исполнительный директор, Лаборатория новых технологических решений  «Сбера»,  Илья Алексеев (ilya@oscloud.ru)  —  независимый эксперт (Москва).