Под капотом облаков. Строим облачную консоль. Часть 1. Знакомство

С чем предстоит иметь дело

Прежде чем перейти к главному, кратко обозначу, что конкретно мы в этой статье будем разбирать. Ведь область облачных вычислений настолько велика, что рассказать про все нюансы облаков вряд ли получится. И во многом это даже бессмысленно, так как информации про виртуализацию и проектирование решений в облаке, итак, предостаточно на просторах интернета. Хотя так или иначе виртуализацию мы затронем, когда будем выбирать чем консоль будет управлять (спойлер: Openstack + OVN).

Мы же с вами будем проектировать и создавать именно саму консоль управления облачными услугами, например, как Сompute, Managed Kubernetes, Managed PostgreSQL и т. д. В каждой из серии этих статей будем разбирать и проектировать один выбранный компонент консоли. Кроме этого, параллельно я буду реализовать его на языке GO в своем GitHub (Ссылка появится в одной из статей, когда будет написан первый компонент).

Ситуация

Давайте представим некую крупную компанию, у которой есть несколько ЦОДов, географически распределенных по разным регионам. Также в самой компании есть несколько тысяч разработчиков, который создают решения как для внутренних нужд компании, так и для продажи и обслуживания клиентов. При этом компания, по объёму вычислительных ресурсов достигла такого уровня, что кажется логичным продавать их как услугу на открытый рынок. Это позволило бы избежать бессмысленного простоя оборудования на разных этапах жизни, например, когда ей требуется сократить затраты на штат и куда-то деть освободившееся оборудования.

Проблема

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

Решение

Конечно же со временем клиенты устают от томительного ожидания. И тут приходит на помощь такое понятие как “Приватное облако”. Где командам заранее выделяются нужные сетевые сегменты, в которых они могут самостоятельно заказывать необходимые ресурсы, в соответствии с квотой и правами. Тем самым достигается скорость получения необходимых ресурсов и изоляция команд сопровождения и разработки друг от друга (рисунок 2).

А на рисунке 3 становится понятно, как процесс будет выглядеть с наличием в компании приватного облака.

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

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

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

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

Основные компоненты

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

• IAM - группа сервисов, отвечающая за авторизацию и выдачу прав на ресурсы пользователям;

• HCI - группа сервисов, отвечающая за взаимодействие с пользователем. Причем не важно каким образом, web-ui, api, cli и прочие инструменты;

• Core - Основной набор сервисов, отвечающий за выполнение заказов, хранение данных о тенанте клиента и оркестрацию ресурсов;

• Billing - группа сервисов, отвечающая за расчет стоимости ресурсов для конечно клиента;

• Control - компоненты для административных функций и вспомогательных операций;

• Integration - интеграционные модули, которые и будут заниматься управлениеминфраструктурой и внешними системами;

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

Не функциональные требования

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

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

• Обновление - так как читателям статей будет не сильно интересно ковыряться в чартах разворота данного решения, после продолжительного обсуждения было принято решение обернуть конечный продукт в оператор k8s дабы облегчить его обновление и разворот;

• Масштабируемость - каждый компонент платформы должен поддерживать горизонтальное масштабирование, использование которого не приводит к не консистентным данным и рассогласованности компонентов;

• Характеристики - каждый микросервис должен быть подвергнут нагрузочному тестирования и результаты тестов должны содержаться в документации;

• Документация - каждый микросервис должен иметь спецификацию интерфейса и функциональную карту;

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

Выбор СУБД

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

• Реляционный

• Ключ-Значения

• Документно-ориентированные

Конечно же есть еще ряд других типов СУБД, но было решено их не рассматривать, так как сценарии их использования не подходят под хранения оперативных данных и поиск/чтения данных небольшими порциями

Реляционные - данных храним таблицах с жесткой структурой и построчно. Хотя данные СУБД используются в большинстве современных решений, имеют ряд минусов: плохая масштабируемость, сложность проектирования и нет инструментов для работы с данными свободной структуры. Хотя и PostgreSQL научился неплохо работать с JSON, но есть решения более пригодные для этого, а нам этот параметр важен, так как предполагается создание конструктора продуктов и определения структуры хранения данных о продукте самим пользователем

Ключ-Значение - данные СУБД вполне бы подошли на роль использования их как основного хранилища для консоли, если бы мы планировали хранить все объекты в стиле kind как в kubernetes. Но тут мы сразу упремся в проблемы, когда нам нужно будет использовать данные для аналитики или выполнять поиск связанных объектов

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

Выбор брокера

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

• RabbitMQ

• ActiveMQ

• Kafka

Если сразу говорить о RabbitMQ для нас удобством является только наличие механизма RPC, что удобно в случаях, когда действия выполняются в четкой последовательности и разными микросервисами (по паттерну saga). Но при наличии проблем с масштабированием, и возможностью реализации паттерна SAGA и в kafka, целесообразность этого решения теряется

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

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

Остальная кучка инфраструктурных сервисов

Подробные рассуждения о выборе других компонентов выкладывать нет смысла, так как они давно стали стандартом отрасли

• Kubernetes - удобство разворота, обслуживания и отказоустойчивость

• Redis - Для хранения распределенных блокировок и кэша

• KeyCloak - будем использовать в группе IAM, давно стал стандартом в части аутентификации, но придется повозиться с мультитенантностью

• APISIX - API Gateway был выбран, потому что имеется положительный опыт работы с ним и смысла рассматривать другой мы не нашли. Хотя существуют и другие достойные решения (kong, tyk, krakend)

В заключении

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

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

Хотелось бы отблагодарить читателя за проявленный интерес и рады комментариям к нашей работе.