Архитектура облачных вычислений: гибкость, проектирование и экономия затрат

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

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

Архитектура облачных вычислений: объяснение

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

• Front-end (элементы, видимые конечному пользователю: веб-приложения, браузеры, мобильные устройства, пользовательский интерфейс).
• Back-end («облачная» часть системы: хранилища данных, выделенные серверы, ОС, меры безопасности и др.).

Также требуется сеть для коммуникации front-end и back-end. Обычно они обмениваются данными через интернет, если архитектор не предпочитает частную сеть (стандарт для приватных и гибридных облаков).

Независимо от типа сети, коммуникационный слой между front-end и back-end должен обладать:

• Высокой пропускной способностью.
• Отсутствием задержек (low latency).
• Высокой доступностью.
• Высокой сетевой безопасностью.

В основе дизайна облачной архитектуры лежит сочетание:

• Событийно-ориентированной архитектуры (EDA): программный дизайн, где развязанные сервисы производят, детектируют и реагируют на системные события.
• Сервисно-ориентированной архитектуры (SOA): системы, где набор компонентов предоставляет сервисы другим элементам через протокол коммуникации.

У компании много причин внедрять облачную архитектуру, несмотря на сложность. Основные:

• Более быстрое время выхода на рынок (time-to-market).
• Более быстрое предоставление ресурсов.
• Масштабируемость в реальном времени (вверх и вниз).
• Возможность использования cloud-native решений (Kubernetes и др.).
• Более надежный комплаенс благодаря лучшей видимости данных.
• Экономия затрат (нет нужды в on-prem железе и жесткий контроль использования ресурсов).

Front-end архитектуры облачных вычислений

Front-end выступает клиентом в архитектуре и общается с back-end через интернет или частную сеть. Эта компонента видна пользователю и обеспечивает доступ к облачной платформе.

Два главных элемента front-end:

• Приложение или ПО (обычно веб-браузер или нативное приложение), которое клиент использует для доступа и взаимодействия с облачной платформой. У приложения/браузера есть выделенный UI, который некоторые архитекторы считают отдельным front-end компонентом.
• Клиентское устройство, через которое пользователь подключается и взаимодействует с браузером или приложением (мобильный телефон, планшет, ПК, ноутбук и др.).

Элементы front-end отвечают за:

• Возможность пользователя взаимодействовать с облаком.
• Отправку запросов к back-end через middleware.
• Запрос сервисов у back-end.
• Отображение всей облачной информации (использование ресурсов, проблемы безопасности, алерты мониторинга, паттерны использования и др.).

Облако берет на себя больше обработки, чем клиентское устройство — еще одно преимущество, особенно полезное для remote-first команд и компаний с политикой BYOD.

Back-end архитектуры облачных вычислений

В архитектуре облачных вычислений back-end — это само облако. Этот компонент содержит различные системы, серверы и хранилища с ключевыми ролями:

• Запуск облачных программ и приложений.
• Обеспечение функциональности front-end и ответ на запросы пользователя.
• Развертывание и масштабирование ресурсов.
• Мониторинг всех операций и активностей.
• Безопасность облачных данных и процессов.
• Связывание всех сервисов и приложений.
• Запуск механизмов управления трафиком.
• Управление облачными протоколами.

Облачным провайдером управляет back-end. Однако некоторые компании разрабатывают и поддерживают свое облако — тогда за back-end отвечает внутренняя команда. Также можно разделить задачи между внутренней командой и командой провайдера (частый выбор в строго регулируемых компаниях, соблюдающих HIPAA или PCI).

Если front-end — это просто UI с подключением, то back-end придает облаку его основные принципы:

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

Back-end имеет больше компонентов и значительно больше front-end. Ниже — подробный разбор каждого back-end компонента.

Слой приложений (Application Layer)

Когда пользователь взаимодействует с front-end, слой приложений back-end получает запрос и обрабатывает запросы клиента. У этого слоя несколько жизненно важных ролей:

• Предоставление пользователям доступа к облачным сервисам.
• Связывание back-end и front-end.
• Ответ на front-end запросы.
• Координация потребностей потребителя с ресурсами в back-end.

Сервисный слой (Service Layer)

Сервисный слой добавляет утилитарность back-end облачной архитектуры. Этот компонент обрабатывает каждую задачу и запрос через сервисы для хранения данных, сред разработки приложений, веб-сервисов и др.

Сервисы могут выполнять разнообразные задачи в облачной среде выполнения. Тип доступных сервисов зависит от модели доставки. Существует три основных облачных метода доставки:

• Infrastructure as a Service (IaaS): доступ и контроль над ресурсами облачной архитектуры (хранилища, серверы, сетевая инфраструктура, VM и др.).
• Software as a Service (SaaS): размещение прикладного ПО в облаке. Провайдер обрабатывает все обновления и разработку, вендор поддерживает базовую инфраструктуру.
• Platform as a Service (PaaS): по запросу платформа для разработки ПО. Провайдер хостит полный технологический стек и инструменты, но пользователь отвечает за разработку, управление приложениями и обновления.

Модели доставки — это не модели развертывания облака (гибридное, комьюнити, мультиоблако). Модель доставки определяет тип доступных сервисов, модель развертывания — тип облака.

Middleware

Middleware — программные компоненты, обеспечивающие коммуникацию сетевых устройств и приложений. Этот компонент отвечает за связи между:

• Приложениями.
• Сервисами.
• Облаками среды выполнения (runtime clouds).
• Хранилищами.
• Устройствами инфраструктуры.
• Решениями безопасности.
• Front-end.

Как в традиционном дата-центре, middleware опирается на базы данных и коммуникационные приложения для координации между разными системами.

Облачное хранилище (Cloud Storage)

Хранилище — раздел back-end, хранящий все облачные данные. Тип и емкость зависят от провайдера и требований клиента. Этот сервис позволяет хранить данные в облаке вместо on-prem хранилищ — более безопасный и удобный вариант.

Облачная инфраструктура (Cloud Infrastructure)

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

• Серверы.
• Центральные процессоры (CPU).
• Графические процессоры (GPU).
• Материнские платы.
• Накопители (HDD и SSD).
• Сетевое оборудование с маршрутизаторами и коммутаторами.
• Сетевые и ускорительные карты.
• Инфраструктура охлаждения и питания.

Слой инфраструктуры также включает ПО для запуска и управления всем железом.

Гипервизор (Hypervisor)

Гипервизор — ПО, создающее и запускающее виртуальные машины. Гипервизор выделяет ресурсы одного устройства (CPU, память, хранилище) и позволяет нескольким VM с отдельными ОС работать на одном устройстве.

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

ПО управления (Management Software)

ПО управления обеспечивает плавную и эффективную работу всех операций и программ. Задачи этих систем:

• Аудит безопасности и комплаенса.
• Мониторинг производительности и емкости.
• Отслеживание использования.
• Развертывание новых приложений.
• Интеграция данных.
• Управление аварийным восстановлением.

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

• Масштабирование вверх или вниз для удовлетворения потребностей в использовании или трафике.
• Обеспечение управления (governance) во всей облачной среде.
• Реакция на события по инструкциям от предопределенного порога или облачной политики.

Слой безопасности (Security Layer)

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

• Неизменяемые регулярные бэкапы данных.
• Шифрование данных (at-rest, in-motion, in-use).
• Продвинутые инструменты отладки.
• Виртуальные фаерволы (для всей установки и между тенантами).
• Принципы Zero Trust.
• Многофакторная аутентификация и надежные пароли.
• Системы обнаружения вторжений (IDS).
• Антивирусное и антивирусное ПО.
• Защита от вымогателей (ransomware prevention).

Лучшие практики архитектуры облачных вычислений

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

• Security-first подход: команда безопасности/DevSecOps должна встраивать защиту в дизайн с самого начала. Чем надежнее система безопасности в начале, тем меньше рисков утечек и нарушений по мере роста среды.
• Планирование пиков использования: старайтесь прогнозировать поведение установки при обычных и пиковых нагрузках. Обеспечьте производительность в любом сценарии и подготовите оптимальные механизмы масштабирования.
• Не рискуйте с кибербезопасностью: помимо планирования безопасности с нуля, защитите архитектуру всеми доступными мерами. Найдите провайдера, предлагающего шифрование данных, регулярное управление патчами, защиту эндпоинтов, cloud disaster recovery и надежные политики.
• Непрерывный мониторинг: постоянный мониторинг среды инструментом вроде Nagios по производительности и использованию создает ценные паттерны для оптимизации установки.
• Оптимизация и сокращение затрат: используйте автоматизированные процессы и отслеживание утилизации для устранения ненужных расходов и предотвращения перерасхода ресурсов.

Готовы уйти от on-prem железа?

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