Как мы строим публичное облако с нуля: опыт MWS

Привет, Хабр! Меня зовут Данила Дюгуров, я CTO MWS. Сегодня расскажу, как наша команда создаёт облако MWS, и на его примере разберу ключевые концепции, которые лежат в основе построения облаков в целом: от аппаратного обеспечения и выбора сетевой архитектуры до организации работы в инфраструктурной команде. А ещё порассуждаю о том, что лучше для облачного провайдера — вендорский софт или OpenStack — и что в итоге выбрали мы. Спойлер: ни то ни другое.

Зачем мы разрабатываем ещё одно облако

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

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

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

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

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

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

Как выглядит облако со стороны

Схема ниже — классическое деление на три слоя плюс централизованные системы, с которыми интегрируется всё остальное. В слое IaaS есть несколько ключевых блоков:

Первый — Compute, сердце облачной платформы, та часть, которая занимается виртуализацией вычислений CPU и GPU. Второй — Network, кровеносная система облака. Надёжность платформы, возможности для масштабирования и реализации множества сценариев сильно зависят от работы сети. У большинства облачных провайдеров виртуальная сеть и сетевые функции — это самое слабое место. Третий — Block Store — это сетевые и локальные диски. И последний — Object Store. 

Чтобы построить настоящее масштабируемое облако, нужно вложить много сил в создание инфраструктурного слоя — это фундамент, он определяет потенциал продукта в целом.

Следующий слой — PaaS. Главное здесь — платформа данных, контейнерная экосистема и ML-направление. Базы данных, контейнеры, которые вы запускаете, — всё это строится поверх систем виртуализации инфраструктуры, так что качество PaaS во многом определяется именно нижним уровнем IaaS, который мы обсудили ранее.

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

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

При этом далеко не все организации понимают, что не просто меняют CAPEX на OPEX, когда переходят в облако. Использование готовых платформенных сервисов помогает ускорять time-to-market, удешевить эксперименты, снизить косты на тех самых «тяжёлых» инженеров. Кроме того, если провайдер может нанять более сильную команду, то и качество сервисов будет выше, чем в отдельно взятой компании. В общем, разработка платформенных сервисов стимулирует развитие всего рынка, здесь борьба облаков между собой в самом разгаре.

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

Из чего состоит облако

Шаг 0. Определяемся с платформой виртуализации

Есть три базовых подхода к построению облачной платформы. Первый — приобрести вендорский продукт, например VMware. Второй — взять open source решение вроде OpenStack и попытаться сделать сервис на нём. Третий — строить и создавать технологии самостоятельно.

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

К облаку предъявляются серьёзные требования к масштабированию и надёжности, поэтому все его компоненты в идеале должны быть распределёнными by design. Всё это подводит нас к третьему подходу — созданию собственных технологий. Тут основная сложность состоит в том, что с точки зрения инженерного мастерства разрыв с первыми двумя подходами получается очень большим.

Создавать технологии самостоятельно и эксплуатировать существующие — не одно и то же. Даже если у вас есть команда, умеющая допиливать OpenStack, скорее всего, этого будет недостаточно. Чтобы построить своё, понадобится команда более высокого класса.

Шаг 1. Определяемся с подходом к системам хранения данных

Здесь тоже существует несколько подходов. Можно взять вендорское программно-аппаратное обеспечение. Это огромная индустрия, рынок, на котором компании предлагают свои свитчи и сетевые карты, специализированные серверы, свои диски — это дорого. Большинство enterprise-компаний организуют свою on-prem-инфраструктуру на базе таких решений.

Существует подход гиперконвергентной инфраструктуры (Hyper Converged Infrastructure — HCI), когда все узлы в кластере имеют одинаковые роли. Получается красивая инженерная картинка: все серверы одинаковые и на них запускают как виртуальные машины, так и ноды хранения данных. На небольшом масштабе выглядит более экономично и легковесно. Но если попытаться построить по такой схеме публичное облако, вы столкнётесь с целым ворохом проблем at scale. 

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

Все современные распределённые технологии хранения и обработки информации строятся на принципах разделения ресурсов вычисления и хранения — это означает, что они управляются независимо. Такой подход позволяет достичь лучшей масштабируемости, экономической эффективности и гибкости at scale. Мы в MWS разделяем эту идею и используем её.

Шаг 2. Строим сетевую инфраструктуру

Кроме топологии разделения Storage и Сompute, нужно подумать об организации сети. Как правило, сеть в облаках состоит из трёх крупных блоков:

1. Underlay-сеть — физическая сеть, с помощью которой коммутированы реальные серверы в ЦОД.

2. Overlay-сеть — наложенная сеть, те самые виртуальные сети, где живут виртуальные машины пользователей.

3. Сетевые функции — огромное количество разных сервисов: DNS, VPN, Load Balancer и так далее.

Сегодня обсудим только Underlay-сеть. Ниже схематично изображена её топология:

Во-первых, у нас есть две независимых сетевых фабрики: management-сеть для управляющего трафика инфраструктуры и компонентов облака; dataplane-сеть для трафика пользовательской нагрузки. В каком-то смысле вся индустрия свелась к построению так называемых сетей Клоза с архитектурой Leaf-Spine. Архитектура известна полвека и успешно применяется в телекоммуникациях, но сейчас набирает обороты и в дата-центрах. 

Архитектура двухуровневая, в ней каждый leaf — коммутатор нижнего уровня — подключён к каждому spine — коммутатору верхнего уровня. Более того, применяют dual-homing, когда один и тот же сервер подключён сразу к двум свитчам в целях резервирования. Одну такую конструкцию называют pod’ом. У неё есть физические пределы масштабирования, когда в них упираются, то начинают строить второй pod и связывать их между собой с дополнительным уровнем spine-ов. Этот уровень spine-ов называется super-spine.

Концептуально наша задача сделать Underlay-сеть максимально простой, некой «трубой» по перекладыванию IP-пакетов, а всю сложность унести на уровень реализации Overlay-сети. Такой подход упрощает эксплуатацию Underlay-сети, а также позволяет использовать более дешёвое commodity-оборудование для построения сети. В основе мы строим сеть с L3-маршрутизацией на базе bgp-протокола и Ipv6-only. А подробнее о том, как мы адаптируем технологию SRv6 для построения виртуальных сетей, мы рассказывали на конференции Nexthop.

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

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

Шаг 3. Налаживаем работу инфраструктурных команд

Когда вы подходите к созданию облака со стороны команды разработки, становится очевидно, что облако не одно — их много. Например, один стенд объединяет компоненты IaaS, другой — компоненты IaaS и PaaS, у разных команд разработки IaaS есть множество своих «железных» стендов с разным набором компонент облака. Есть pre-prod-стенд, на котором встречаются все компоненты облака перед тем, как уйти в продакшен. 

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

Разработчикам облака, как и пользователям, нужны: базы данных, платформа наблюдаемости, балансировщики нагрузок и многое другое. Тут возникает вопрос — «Кто все это им предоставит?».

Есть два подхода: первый — dogfooding. В широком смысле — это практика использования сотрудниками компании собственных продуктов и сервисов. Если переложить это понятие на облачный контекст, такая схема позволяет командам разработки облака использовать сервисы самого облака для эксплуатации своих компонент. Умозрительно красивый инженерный подход, но в такой модели возникает много сложностей. Например, возникают циклические зависимости, из-за которых при сбое одного компонента появляются сложности с его восстановлением, поскольку штатные механизмы управления его развёртыванием также оказываются недоступны из-за этого сбоя. 

Самый примитивный пример для иллюстрации: после выкладки упал артефакторий образов контейнеров. Чтобы откатить на старую версию, нужно скачать образ из артефактория — но он не работает. Получается замкнутый круг. В реальности образуются куда более сложные круги зависимостей, обнаружение которых происходит уже в продакшене, когда что-то пошло не так. Кроме того, никуда не уходит вопрос управления деплоем компонентов виртуализации на физический кластер: нужно решать всё те же проблемы управления жизненным циклом компонентов облака, которые нельзя разместить в «клиентском» контуре.

Существует и множество других примеров, которые показывают, что удовлетворение требований по догфуддингу неминуемо ведёт как к усложнению самого облака, так и к появлению двух инфраструктур: одной —  для компонентов, которые можно реализовать в «клиентском» контуре, второй — для которых это сделать невозможно.

Второй подход — когда инфраструктурный контур полностью изолирован и никак не связан с тем продуктом, который мы предлагаем пользователю. Мы формируем одно облако для заказчиков и другое внутреннее облако на bare metal, заточенное под развёртывание своей микросервисной архитектуры. Мы решили пойти именно по этому пути. Наш опыт подсказывает, что такой подход более эффективен, как с точки зрения сложности построения и эксплуатации, так и с точки зрения обеспечения безопасности и отказоустойчивости всей конструкции в целом.

Если говорить об организации команд разработки, то здесь также есть два пути. Первый — разделить все команды, чтобы каждая из них работала со своей архитектурой и инфраструктурой. Но есть огромное количество инфраструктурных и продуктовых аспектов, которые должны быть реализованы в каждом сервисе: «Как интегрироваться с ресурсной моделью?», «С менеджером управления квотами?», «А с системой аутентификации и авторизации?», «Как запускать асинхронные задачи?», «Как отливать аудитные логи?» и десятки, даже сотни подобных вопросов. 

Если каждая команда начинает всё это делать самостоятельно, то компания будет тратить время и ресурсы продуктовых команд, чтобы реализовать одну и ту же часть технологической инфраструктуры, а главное, с большой вероятностью ещё и получим большую энтропию — в каждой команде одна и та же задача будет решена по-своему. Ситуация усугубляется, когда в дело вступает Security & Compliance. Для облака это один из важнейших вопросов с точки зрения качества продукта, и чем больше разнообразие технологий, тем сложнее их защищать.

Чтобы избежать этих сложностей, мы в MWS выбрали централизованный подход к разработке. Выделили полноценное направление, которое называем Development Platform. В рамках него мы развиваем инфраструктурные наработки, которые переиспользуют все продуктовые команды. Development Platform — отдельная команда, которая тесно сотрудничает с коллегами из других направлений.

Если говорить про технологический стек, то мы работаем только на компилируемых, статически типизируемых языках программирования, для большинства Control Plane-компонент используем Kotlin. Для реализации Data Plane-компонент используем Go, а ещё C и C++, где зависим от opensource-компонент, написанных на соответствующих языках, например таких, как VPP. 

Мы ограничили спектр используемых технологий. Например, команды не могут взять любую базу данных по своему желанию, для хранения метаданных мы выбрали PostgreSQL, для потоковой обработки данных — Kafka, для аналитических данных — ClickHouse. Верим, что такой подход к разработке окажется эффективным в долгосрочной перспективе.

В заключение

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

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

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