Что такое облачная архитектура
Облачная архитектура
Редко кто обсуждает облачную архитектуру, но без ее понимания невозможно полное понимание самой концепции облака.
Принципы облачной архитектуры
При рассмотрении облачной архитектуры нужно обязательно подразумевать модель облачных вычислений. В статья «Инфраструктура как услуга» мы объясняли, в чем заключается разница между существующими моделями — IaaS, PaaS, SaaS. Рассмотрим архитектуру IaaS.
Как наверняка вы знаете, облако создается из нескольких физических узлов, соединенных быстрыми каналами передачи данных с целью единого управления и передачи больших объемов информации. Слово «несколько» можно воспринимать буквально — фактических из 3–5 узлов можно построить небольшое облако. Как оно будет работать, уже второй вопрос. В реальности в облачного провайдера — сотни и даже тысячи узлов.
Посредством специального ПО виртуализации и формирования облачной инфраструктуру пользователи могут получать доступ к ресурсам облака, при этом не задумываясь ресурсы какого именно физического узла им выделены. По сути, пользователю все равно ресурсы какого узла он использовал и где выполняется его задача, где хранятся его данные — важно, чтобы задача была выполнена, а данные остались в целости и сохранности.
В облаке создаются виртуальные машины, на которых запущены гостевые ОС и различные установленные пользователем приложения. В «виртуалке» может выполняться любая, по сути, «операционка» — Windows Server, Linux, FreeBSD и др.
На одном аппаратном узле можно запустить несколько десятков виртуальных машин, которые сдаются в аренду
Вам кажется, что все так просто? На самом деле архитектура облака модели IaaS выглядит так:
Архитектура IaaS облака: полный вариант
Большинству пользователей знать полную архитектуру и не нужно, но рассмотрим основные моменты. Начнем снизу вверх. Есть некая физическая инфраструктура, состоящая из серверов (Servers), сетевого оборудования (Networks) и устройств хранения (Storage). На этой физической инфраструктуре выполняется облачная операционная система.
Как обычно, самый низкий уровень любой операционной системы — это драйверы для взаимодействия с железом. Такие драйверы есть и у нашей облачной ОС — драйверы физической инфраструктуры (Physical infrastructure drivers). Есть и драйверы облака (cloud drivers) — они нужны для соединения с другими, внешними облаками (external clouds).
Ядро нашей облачной ОС — всякие диспетчеры. Есть диспетчер виртуальных машин (VM manager), диспетчер сети (Network manager), диспетчер хранилища (Storage manager) Каждый из диспетчеров отвечает за свою часть операционной системы.
Облачная архитектура и XaaS
Переход на облачную архитектуру обеспечивает легкую масштабируемость, безопасность и расширенную совместную работу.
Может быть, вы уже слышали что-нибудь о некоторых из следующих возможностей: IaaS, PaaS, SaaS, DaaS, FaaS, DBaaS. Возможно, вы даже использовали некоторые из них, не зная названия применяемой концепции.
Итак, давайте поговорим об облаке в контексте веб-приложений.
Монолитная. Вся серверная часть развернута в одном месте, поэтому ее очень сложно масштабировать для больших приложений.
Микросервисная. Бэкэнд разделен на подмножества (в основном это зависит от размера приложения, но обычно от 10 до 80) микросервисов, которые могут быть развернуты на разных физических серверах, каждый микросервис должен отражать бизнес-функцию, например, аутентификацию, платежи и т.д.
Функциональная (по событию). В отличие от монолита и микросервисов, выполняются только в течение нескольких секунд, когда в этом есть необходимость; Примером может служить AWS Lambda, написанная на es7:
Итак, давайте рассмотрим подробнее, чтобы лучше понять, что они из себя представляют.
Это общий акроним, означающий любые решения aaS.
База данных как услуга ⸺ это платформа, на которой размещается база данных, обеспечивающая резервное копирование, кластеризацию и высокую доступность. Самыми популярными DBaaS являются Amazon Aurora, Amazon DynamicDB, mLab, IBM Cloudant и MongoDB Atlas.
Инфраструктура как услуга ⸺ это самый низкий уровень из всех XaaS. Это дает нам большие возможности, но требует сложной настройки. IaaS предоставляет виртуальную машину, которую мы должны поддерживать. Разница между IaaS и наличием физической серверной комнаты в том, что нам не нужно покупать какие-либо физические компьютеры, и у нас могут быть серверы в разных частях мира. Однако по сравнению с другими XaaS, IaaS сложнее поддерживать, и для этого требуется хороший инженер DevOps, который настраивает виртуальные машины для эффективной и безопасной работы.
Как правило, вам не нужно настраивать CI (непрерывную интеграцию). Просто нажмите коммит, он распознает, что приложение находится в Node.js, и запустит npm install (вы можете добавить дополнительные команды в сценарий postinstall, который запускается NPM после установки зависимостей) и npm start. Если приложение написано на Ruby, оно будет запускать установку пакета и аналогично для других сред.
Главный недостаток ⸺ это не гибкость, потому что невозможно установить собственные системные зависимости (например, из apt-get), и вы можете использовать только одну из доступных технологий.
Еще один недостаток ⸺ данные небезопасны. Если, например, вы используете Heroku как Paas и mLab как DBaaS, доступ к вашим данным будет иметь не только mLab, но и Heroku, потому что вы никогда не знаете, какой код на самом деле выполняется на сервере. Может быть, что кроме вашего кода, они добавляют свои собственные промежуточные программы, чтобы что-то регистрировать.
Программное обеспечение как услуга предоставляет готовое программное обеспечение, такое как библиотеки NPM / GEM, но оно не требует от нас какого-либо развертывания / обслуживания сервера.
Простым примером является почтовое приложение, такое как SparkPost или SendGrid. Все, что нам нужно сделать, это отправить в браузере HTTP-запрос с адресом отправителя электронной почты, адресом получателя, темой электронной почты, содержимым электронной почты и т. д. С другой стороны, без такого инструмента нам пришлось бы настроить SMTP-сервер и масштабировать его, по мере роста количества писем.
Другие примеры: Google Apps (например, Google Drive), DropBox и Slack ⸺ эти приложения могут использоваться в повседневных задачах, но они также имеют большие возможности интеграции. Помимо уже существующего SaaS, некоторые компании (например, SAP) предлагают писать новые SaaS по запросу.
Данные как услуга похожи на SaaS, их можно даже рассматривать как подмножество SaaS. В частности, это API (обычно HTTP), который возвращает некоторые данные, например курсы валют, спортивные результаты или прогнозы погоды.
Что такое самый большой DaaS? Вероятно, Facebook, собирающий много данных и предоставляющий их для приложений Facebook. Другими популярными DaaS являются Google Maps, Google Translate API или AccuWeather.
Список полезных DaaS будет в следующей статье, подписывайтесь.
Функциональность как услуга ⸺ даже проще, чем PaaS. Как следует из названия, сервис основан на функциях, которые могут запускаться заданным событием, поэтому это архитектура, основанная на событиях. Уровень простоты настолько высок, что это называется бессерверная архитектура. Разработчик просто пишет функцию, и ему не нужно задумываться о таких темах, как развертывание, ресурсы сервера, масштабируемость, потому что FaaS автоматически масштабируется. Таким образом, выставление счетов основывается на реальном потреблении, а не на заявленных потребностях в ресурсах.
Наиболее ярким примером является AWS Lambda, но есть и другие, такие как Google Cloud Functions, Microsoft Azure Functions, Iron.io и Webtask.io.
Разделим функции по особенностям Microsoft Azure Functions:
Как видите, с помощью FaaS мы можем реализовать любой алгоритм (смотрите полнота Тьюринга), потому что мы можем обрабатывать HTTP-запрос, мы можем отправить другой HTTP-запрос и, более того, мы можем обрабатывать время и события очереди.
Функции можно комбинировать с микросервисами, поэтому мы можем соединить FaaS с PaaS, но также можно построить весь бэкэнд на FaaS (с некоторыми ограничениями на технологии, используемые на стороне бэкэнда).
Однако давайте обсудим еще один недостаток ⸺ мы пишем код, который работает на определенном FaaS (например, функции Microsoft Azure), поэтому переход на другой FaaS (например, функции Google) может потребовать переписывания даже половины кода, написанного как функции FaaS. С другой стороны, переход от одного PaaS к другому относительно проще.
XaaS даже больше, чем вы можете себе представить:
Как видите, многие из XaaS могут даже иметь один и тот же акроним, и одно может быть подмножеством другого. Сложный вопрос, какой XaaS следует использовать в том или ином проекте и конкретной ситуации. Я полагаю, что в то же время разные инженеры DevOps могли бы выбрать совершенно разные решения. Мой любимый подход: создать архитектуру, ориентированную на микросервисы в PaaS, потому что она просто сочетает в себе гибкость и простоту.
Конечно, мы должны облегчить себе жизнь, используя некоторые внешние SaaS, такие как интеграции SparkPost или Slack, и некоторые внешние DaaS, чтобы легко получать данные, такие как текущие курсы обмена валют. Более того, мы можем основать некоторую (5%
20% в зависимости от наших потребностей) часть нашей системы на FaaS, простые функции без сохранения состояния, которые соединяют несколько служб, поэтому использование FaaS просто сэкономит время на развертывании и мониторинге.
Я надеюсь, что эта статья поможет вам выбрать правильный XaaS (или несколько из них одновременно) в вашем проекте.
😏 Материалы о создании и развитии цифровых продуктов для предпринимателей, менеджеров и специалистов на канале Цифровая ферма единорогов и чат Мышление предпринимателя.
Введение в разработку облачной архитектуры
Извлеките максимальную пользу из облачных решений, приведя архитектуру облачных вычислений в соответствие с потребностями ваших рабочих нагрузок и бизнес-целями.
Основы облачной архитектуры
Качественная разработка облачной среды начинается с оценки имеющихся рабочих нагрузок и потребностей бизнеса.
Ваша облачная инфраструктура на стороне сервера состоит из аппаратного обеспечения ЦОД, виртуализации, приложений и услуг.
Новейшие облачные технологии Intel® обеспечивают оптимизацию производительности и максимальное использование ресурсов.
Организации прибегают к помощи облачных технологий для разработки искусственного интеллекта, оптимизации эксплуатации и рабочих процессов, а также для динамического масштабирования инфраструктуры с учетом меняющихся требований бизнеса. При разработке облачного сервиса полезно помнить, что вы создаете как инфраструктуру, так и бизнес-модель для дальнейшего масштабирования, обеспечения устойчивости и гибкости. Для достижения этих целей в ходе разработки облачной архитектуры необходимо учитывать уникальные особенности, определяемые рабочими нагрузками, пользователями и эксплуатационными затратами.
Организации прибегают к помощи облачных технологий для разработки искусственного интеллекта, оптимизации эксплуатации и рабочих процессов, а также для динамического масштабирования инфраструктуры с учетом меняющихся требований бизнеса. При разработке облачного сервиса полезно помнить, что вы создаете как инфраструктуру, так и бизнес-модель для дальнейшего масштабирования, обеспечения устойчивости и гибкости. Для достижения этих целей в ходе разработки облачной архитектуры необходимо учитывать уникальные особенности, определяемые рабочими нагрузками, пользователями и эксплуатационными затратами.
Принципы облачной архитектуры
Перед тем как приступать к разработке облачного сервиса, необходимо в первую очередь оценить существующие условия и потребности бизнеса. Вот примеры вопросов, которые вашей команде будет необходимо рассмотреть.
Получив понимание о текущей производительности облачной среды и развитии ваших потребностей, вы сможете принимать более эффективные решения о том, где должны быть сосредоточены ваши приложения. Вы можете определить необходимость модернизации вашей инфраструктуры в локальной среде для поддержки необходимого облачного дизайна.
В зависимости от потребностей вы можете привлечь сторонние организации для консультаций по разработке облачных сред. Это может происходить до, во время или после вашей оценки. Системный интегратор, поставщик услуг управления, поставщик облачных сервисов или поставщик аппаратного обеспечения могут помочь вам определить оптимальную платформу и архитектуру для вашей облачной среды.
Дополнительную информацию об аспектах облачной трансформации см. в инфографике «Шесть «М» облачной трансформации»:
Компоненты облачной инфраструктуры
Существуют две стороны облачной среды. Сторона клиента — то, что видно конечному пользователю, иными словами, это пользовательский интерфейс. Программно-аппаратная сторона — то, на чем работает облачная среда. Программно-аппаратная сторона состоит из аппаратного обеспечения ЦОД, виртуализации, приложений и услуг. Сторона клиента связана с программно-аппаратной стороной посредством промежуточного ПО. Как в локальной среде, так и посредством вашего поставщика облачных услуг, облачная программно-аппаратная инфраструктура состоит из следующих уровней.
Аппаратное обеспечение ЦОД
В основе любого облачного сервиса лежит аппаратное обеспечение ЦОД, принимающее на себя рабочие нагрузки — серверы, системы хранения и сети. В зависимости от ваших текущих рабочих нагрузок, аппаратное обеспечение может включать в себя ускорители, такие как FPGA. Они особенно полезны, когда решаются специализированные рабочие задачи, такие как приложения глубинного обучения.
Далее, уровень виртуализации абстрагирует ваши вычислительные и сетевые аппаратные средства и запоминающие устройства. Виртуализация позволяет создавать виртуальные машины (ВМ). Чтобы стимулировать оптимальное использование, многие различные приложения, каждое на своей отдельной ВМ, могут работать на одном и том же аппаратном обеспечении центра обработки данных. Кроме того, каждая ВМ может запускать свою собственную операционную систему — например, Linux, Ubuntu или Windows — для обеспечения повышенной гибкости предоставления облачных услуг.
Уровень приложений и услуг
Уровень приложений и услуг на программно-аппаратной стороне вашей облачной среды поддерживает пользовательский интерфейс, который отображается на стороне клиента. Здесь запросы конечных пользователей координируются с помощью имеющихся ресурсов программно-аппаратной стороны.
Книга «Руководство по архитектуре облачных приложений»
В этом руководстве структурированы рекомендации по проектированию масштабируемых, отказоустойчивых и высокодоступных облачных приложений. Оно призвано помочь вам в принятии решений об архитектуре, независимо от того, какую облачную платформу вы используете.
Руководство организовано как последовательность шагов — выбор архитектуры → выбор технологий для вычисления и хранения данных → проектирование приложения Azure → выбор шаблонов → проверка архитектуры. Для каждого из них приведены рекомендации, которые помогут вам при разработке архитектуры приложения.
Сегодня мы публикуем часть первой главы этой книги. Полную версию вы можете скачать бесплатно по ссылке.
Оглавление
Выбор архитектуры
Первое решение, которое вам нужно принять при проектировании облачного приложения, — выбрать архитектуру. Выбор архитектуры зависит от сложности приложения, области применения, его типа (IaaS или PaaS) и задач, для решения которых оно предназначено. Также важно учитывать навыки команды разработчиков и менеджеров проекта, а также наличие у приложения готовой архитектуры.
Выбор архитектуры накладывает определенные ограничения на структуру приложения, ограничивая выбор технологий и других элементов приложения. С этими ограничениями связаны как преимущества, так и недостатки выбранной архитектуры.
Приведенная в этом разделе информация поможет вам найти баланс между ними при реализации той или иной архитектуры. В этом разделе приведены десять принципов проектирования, которые следует иметь в виду. Следование этим принципам поможет создать более масштабируемое, отказоустойчивое и управляемое приложение.
Мы выделили набор вариантов архитектуры, которые обычно используются в облачных приложениях. Посвященный каждому из них раздел содержит:
Краткий обзор вариантов архитектуры
В этом разделе приведен краткий обзор выделенных нами вариантов архитектуры, а также даны общие рекомендации по их использованию. Более подробную информацию вы сможете найти в соответствующих разделах, доступных по ссылкам.
N-уровневая
N-уровневая архитектура чаще всего используется в корпоративных приложениях. Для управления зависимостями приложение делится на слои, каждый из которых отвечает за определенную логическую функцию, например за представление данных, бизнес-логику или доступ к данным. Слой может обращаться с вызовами к другим слоям, расположенным ниже. Однако такое деление на горизонтальные слои может стать причиной возникновения дополнительных трудностей. Например, может оказаться сложно внести изменения в одну часть приложения, не затронув другие его элементы. Поэтому часто обновлять такое приложение непросто, и разработчикам придется реже добавлять новые функции.
N-уровневая архитектура — это естественный выбор при переносе уже используемых приложений, построенных на базе многоуровневой архитектуры. Поэтому такая архитектура чаще всего используется в решениях IaaS (инфраструктура как услуга) или в приложениях, сочетающих IaaS с управляемыми службами.
Веб-интерфейс — очередь — рабочая роль
Для решений PaaS подходит архитектура «веб-интерфейс — очередь — рабочая роль». При такой архитектуре приложение имеет веб-интерфейс, который обрабатывает HTTP-запросы, и серверную рабочую роль, отвечающую за операции, которые выполняются длительное время или требовательны к вычислительным ресурсам. Для взаимодействия между интерфейсом и серверной рабочей ролью используется очередь асинхронных сообщений.
Архитектура «веб-интерфейс — очередь — рабочая роль» подходит для относительно простых задач, требовательных к вычислительным ресурсам. Как и N-уровневая архитектура, эта модель проста для понимания. Использование управляемых служб упрощает развертывание и эксплуатацию. Но при создании приложений для сложных предметных областей бывает трудно контролировать зависимости. Веб-интерфейс и рабочая роль могут легко разрастись до крупных монолитных компонентов, которые трудно поддерживать и обновлять. Как и для N-уровневой архитектуры, для этой модели характерны меньшая частота обновлений и ограниченные возможности совершенствования.
Микрослужбы
Если приложение предназначено для решения более сложных задач, попробуйте реализовать его на базе архитектуры микрослужб. Такое приложение состоит из множества небольших независимых служб. Каждая служба отвечает за отдельную бизнес-функцию. Службы слабо связаны между собой и для взаимодействия используют контракты API.
Над созданием отдельной службы может работать небольшая команда разработчиков. Службы могут развертываться без сложной координации между разработчиками, что упрощает их регулярное обновление. Архитектура микрослужб сложнее в реализации и управлении по сравнению с предыдущими двумя подходами. Она требует зрелой культуры управления процессом разработки. Но если все организовано правильно, такой подход помогает увеличить периодичность выпуска новых версий, ускорить внедрение инноваций и сделать архитектуру более отказоустойчивой.
Архитектура CQRS (Command and Query Responsibility Segregation, распределение ответственности между командами и запросами) позволяет разделить операции чтения и записи между отдельными моделями. В результате части системы, отвечающие за изменение данных, изолируются от частей системы, которые отвечают за чтение данных. Более того, операции чтения могут выполняться в материализованном представлении, которое физически отделено от базы данных, в которую ведется запись. Это позволяет независимым образом масштабировать процессы чтения и записи и оптимизировать материализованное представление для выполнения запросов.
Модель CQRS лучше всего использовать для подсистемы более крупной архитектуры. В общем случае ее не стоит применять ко всему приложению, поскольку это неоправданно усложнит его архитектуру. Она хорошо проявляет себя в системах совместной работы, где большое число пользователей одновременно работают с одними и теми же данными.
Архитектура на основе событий
Архитектура на основе событий использует модель публикации-подписки, в которой поставщики публикуют события, а потребители подписываются на них. Поставщики независимы от потребителей, а потребители независимы друг от друга.
Архитектура на основе событий хорошо подходит для приложений, которые должны быстро получать и обрабатывать большие объемы данных с низкой задержкой, например для Интернета вещей. Кроме того, такая архитектура хорошо проявляет себя в случаях, когда различные подсистемы должны по-разному обрабатывать одни и те же данные о событиях.
Большие данные, большие вычисления
Большие данные и большие вычисления— это специальные варианты архитектуры, применяемые для решения особых задач. При использовании архитектуры больших данных крупные наборы данных делятся на фрагменты, которые затем обрабатываются параллельно для целей анализа и формирования отчетов. Большие вычисления также называют высокопроизводительными вычислениями (HPC). Эта технология позволяет распределять вычисления между множеством (тысячами) процессорных ядер. Эти архитектуры можно применять для имитационного моделирования, 3D-рендеринга и других подобных задач.
Варианты архитектуры как ограничения
Архитектура выступает в роли ограничения при проектирования решения, в частности она определяет, какие элементы можно использовать и какие связи между ними возможны. Ограничения задают «форму» архитектуры и позволяют сделать выбор из более узкого набора вариантов. Если ограничения выбранной архитектуры соблюдены, у решения появляются характерные для этой архитектуры свойства.
Например, для микрослужб характерны следующие ограничения:
Прежде чем выбрать архитектуру, убедитесь, что вы хорошо понимаете лежащие в ее основе принципы и связанные с этим ограничения. В противном случае вы можете получить решение, которое внешне соответствует выбранной модели архитектуры, но в нем полностью не раскрыт потенциал этой модели. Важно также руководствоваться здравым смыслом. Иногда разумнее отказаться от того или иного ограничения, чем стремиться к чистоте архитектуры.
В следующей таблице показано, как осуществляется управление зависимостями в каждой их архитектур, и для решения каких задач больше всего подходит та или иная архитектура.
Анализ преимуществ и недостатков
Ограничения создают дополнительные трудности, поэтому важно понимать, чем приходится жертвовать при выборе того или иного варианта архитектуры, и уметь ответить на вопрос, перевешивают ли преимущества выбранного варианта его недостатки для конкретной задачи в конкретном контексте.
Ниже перечислены некоторые недостатки, которые нужно учитывать при выборе архитектуры:
N-уровневая архитектура
В N-уровневой архитектуре приложение делится на логические слои и физические уровни.
Слои представляют собой механизм распределения ответственности и управления зависимостями. Каждый слой имеет собственную область ответственности. Слои более высокого уровня пользуются службами слоев более низкого уровня, но не наоборот.
Уровни разделены физически и работают на разных компьютерах. Один уровень может обращаться к другому напрямую или с помощью асинхронных сообщений (очереди сообщений). Хотя каждый слой должен размещаться на собственном уровне, это не обязательно. На одном уровне можно разместить несколько слоев. Физическое разделение уровней делает решение не только более масштабируемым и отказоустойчивым, но и более медленным, так как для взаимодействия чаще используется сеть. Традиционное трехуровневое приложение состоит из уровня представления, промежуточного уровня и уровня баз данных. Промежуточный уровень является необязательным. Более сложные приложения могут состоять из более чем трех уровней. На схеме выше показано приложение с двумя промежуточными уровнями, отвечающими за различные функциональные области.
N-уровневое приложение может иметь закрытую архитектуру слоев или открытую архитектуру слоев.
Области применения архитектуры
N-уровневая архитектура обычно применяется в приложениях IaaS, где каждый уровень работает на отдельном наборе виртуальных машин. Однако N-уровневое приложение не обязательно должно быть чистым приложением IaaS. Зачастую бывает удобно использовать для некоторых компонентов решения управляемые службы, особенно для кэширования, обмена сообщениями и хранения данных.
N-уровневую архитектуру рекомендуется использовать в следующих случаях:
Преимущества
Недостатки
Рекомендации
N-уровневая архитектура на виртуальных машинах
В этом разделе приведены рекомендации по построению N-уровневой архитектуры при использовании виртуальных машин.
В этом разделе приведены рекомендации по построению N-уровневой архитектуры при использовании виртуальных машин. Каждый уровень состоит из двух или более виртуальных машин, размещенных в наборе доступности или в масштабируемом наборе виртуальных машин. Использование нескольких виртуальных машин обеспечивает отказоустойчивость в случае сбоя одной из них. Для распределения запросов между виртуальными машинами одного уровня используются подсистемы балансировки нагрузки. Уровень можно масштабировать горизонтально, добавляя в пул новые виртуальные машины.
Каждый уровень также помещается внутрь собственной подсети. Это означает, что их внутренние IPадреса относятся к одному и тому же диапазону. Это позволяет легко применять к отдельным уровням правила групп безопасности сети (NSG) и таблицы маршрутизации.
Состояние веб-уровня и бизнес-уровня не отслеживается. Любая виртуальная машина может обрабатывать любые запросы для этих уровней. Уровень данных должен состоять из реплицированной базы данных. Для Windows мы рекомендуем использовать SQL Server с группами доступности Always On для обеспечения высокой доступности. Для Linux следует выбрать базу данных, которая поддерживает репликацию, например Apache Cassandra.
Доступ к каждому из уровней ограничивается группами безопасности сети (NSG). Например, доступ к уровню баз данных разрешен только для бизнес-уровня