Проектирование облачной архитектуры

Ключевая задача проектирования архитектуры — обеспечение постоянной доступности системы наряду с разработкой корпоративных сервисов.

Проектирование архитектуры включает:

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

  • проектирование технической архитектуры, которое носит более общий характер.

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

  • Высокая доступность: одна зона доступности, аварийное восстановление в нескольких зонах доступности, мультиактивная и удаленная среда аварийного восстановления (две площадки с тремя центрами).

  • Масштабируемость: горизонтальное и вертикальное масштабирование.

  • Производительность: планирование производительности, измерение, контроль и компромиссы в отношении производительности.

  • Безопасность: безопасность сети, данных, хоста и приложений.

  • Стоимость: расчет стоимости, оптимизация и управление затратами.

../../_images/cloud-architecture-design__objectives-and-principles.svg

Высокий уровень доступности

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

SLA

Продолжительность простоев в неделю

Продолжительность простоев в месяц

Продолжительность простоев в год

99%

1,68 ч

7,2 ч

3,65 дня

99,90%

10,1 мин

43,2 мин

8,76 ч

99,95%

5 мин

21,6 мин

4,38 ч

99,99%

1,01 мин

4,32 мин

52,56 мин

100,00%

6 с

25,9 с

5,26 мин

Решения для обеспечения высокой доступности

Для большинства облачных сервисов Cloud.ru доступны различные варианты развертывания в режиме HA. Они обеспечивают высокую доступность на нескольких уровнях, включая уровни ЦОДа, оборудования, данных, а также уровень самостоятельно созданных сервисов.

У Cloud.ru есть несколько зон доступности (AZ). Каждая зона имеет независимые системы кондиционирования, пожаротушения, контроля влажности и электроснабжения. Отказ какой-либо AZ не влияет на работоспособность других AZ.

Предусмотрены три варианта развертывания в режиме высокой доступности:

  • Одна зона доступности

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

  • Две зоны доступности в пределах одного города

    Сервисы, требующие высокой доступности, можно развернуть локально на оборудовании, расположенном в нескольких местах в пределах одного города. Такой подход гарантирует непрерывность работы даже в случае отказа сети, физического устройства или источника электропитания одной аппаратной. Пользователи Cloud.ru могут разворачивать сервисы в масштабах нескольких зон доступности. Зоны доступности изолированы друг от друга, поэтому при отказе одной из них сервисы можно переключить на другую зону доступности, что позволит быстро восстановить их работоспособность. Большинство продуктов для облачных сервисов обладают соответствующими возможностями. Выберите необходимые функциональные возможности на этапе приобретения и выполните развертывание.

  • Несколько облаков

    Чтобы удовлетворить требования некоторых предприятий к высокой доступности, Cloud.ru поддерживает развертывание средств многооблачного аварийного восстановления. Предприятия могут разворачивать продуктивные сервисы в облаке Cloud.ru, а площадку аварийного восстановления — на платформе поставщика облачных услуг.

Проектирование решения высокой доступности с одной AZ

  • Описание решения
    • Поуровневое развертывание сервисов. Уровень веб-доступа, уровень сервиса, уровень данных и зона управления.

    • Высокая доступность сервисов. Отказ от развертывания на одном узле, развертывание в режиме HA (в кластере или в режиме активный/резервный).

    • Высокая доступность облачных сервисов. Выбранные сервисы Cloud.ru развернуты в режиме НА.

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

  • Ключевые аспекты проектирования с обеспечением НА

    В таблице ниже перечислены приоритеты при проектировании с обеспечением НА.

Компонент

Приоритеты при проектировании с обеспечением НА

Высокая доступность сервисов

Раздельное развертывание.

Разные компоненты развертываются на разных ECS.

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

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

Высокая доступность облачных сервисов

  • Уровень доступа к сети:
    • Частная линия: HA в режиме активный/активный или активный/резервный.

    • VPN: частная линия (активная) + VPN (резервная) или VPN (активная) + VPN (резервная).

    • ELB: несколько ECS работают в качестве бэкенд-серверов ELB, обеспечивая доступность и масштабируемость системы. В балансировщике нагрузки активирована проверка работоспособности.

    • ELB является потенциальной точкой отказа в системе и нуждается в мониторинге средствами CES.

    • NAT Gateway: если доступ в интернет необходим большому количеству ECS, для ограничения числа подключений ECS используется SNAT.

  • Выбор типов облачных сервисов (RDS, DCS и др.):

    Продуктивные сервисы необходимо разворачивать в режиме активный/резервный или на базе кластеров. Например, инстансы БД RDS должны быть развернуты в режиме первичный/резервный, а Redis — на базе кластеров. Самостоятельно созданные сервисы на ECS также должны соответствовать этому требованию.

Надежность данных

  • Предусмотрены решения для резервного копирования и восстановления данных. Например, для резервного копирования данных ECS используется сервис CBR и политика резервного копирования RDS. Резервные копии критически важных данных сохраняются в других регионах или в автономных IDC.

  • Периодически проверяется надежность резервного копирования и восстановления данных, а также выполняется тестирование работоспособности аварийного восстановления.

Проектирование решения высокой доступности с двумя AZ

  • Описание решения и ключевые аспекты проектирования:
    • Сервисные модули. Для сервисов, поддерживающих развертывание на базе кластеров, ресурсы размещаются в двух зонах доступности с балансировкой нагрузки с помощью ELB. Для ECS с одним узлом используется сервис резервного копирования и восстановления данных CBR для восстановления на уровне зоны доступности.

    • Высокая доступность облачных сервисов. Первичные и резервные узлы развернуты в разных зонах доступности.

    • Синхронизация баз данных. Используется сервис RDS. Инстансы БД RDS развертываются в режиме первичный/резервный в разных зонах доступности, а данные синхронизируются.

    • Аварийное переключение. В случае отказа зоны доступности сервисы баз данных RDS автоматически переключаются на резервные базы данных. Сервисы приложений могут передаваться серверам аварийного восстановления автоматически или с помощью всего нескольких команд.

    • Тестирование аварийного восстановления. Пользователи могут тестировать работоспособность аварийного восстановления с помощью всего нескольких команд.

Масштабируемость

По сравнению с традиционными IDC облако предлагает более мощные ресурсы и возможности масштабирования.

Масштабируемость в облаке

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

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

  • Горизонтальное масштабирование. Распределенные в фиксированных соотношениях ресурсы не всегда соответствуют стремительным изменениям спроса в случае распределенных приложений, приложений без сохранения состояния (stateless) и быстро меняющихся приложений. Горизонтальное масштабирование приложений позволяет обеспечить обработку колебаний трафика как во время рекламных мероприятий, так и после них за счет ресурсов облака и возможности оперативного масштабирования в соответствии с предварительно настроенными политиками. Кроме того, эти приложения могут систематически и гибко наращивать ресурсы по мере увеличения рабочих нагрузок.

  • Экстремальное масштабирование. Чтобы адекватно реагировать на непредвиденные всплески трафика, например, при появлении важных новостей, система должна поддерживать возможности экстремального расширения. Когда происходят такие события, может потребоваться быстрое добавление тысяч вычислительных ядер. Оптимальный выбор в этом случае — масштабирование в облаке.

Существует несколько способов настройки процессов масштабирования:

  • По расписанию. Для увеличения или уменьшения объема ресурсов в указанное время можно создать запланированную задачу.

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

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

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

Проектирование масштабируемого решения

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

  • Уровень приложения. Если на этом уровне используется микросервисная архитектура и развертывание приложений на основе контейнеров с помощью Cloud Container Engine (CCE) в облаке Advanced, то благодаря возможностям автоматического масштабирования CCE приложения могут по требованию автоматически увеличивать и уменьшать производительность. При автоматическом масштабировании, запускаемом сигналом оповещения от AOM, сервисные модули автоматически добавляются или удаляются в ответ на колебания рабочей нагрузки. Если этот уровень развернут с помощью Elastic Cloud Server (ECS) в облаке Advanced, приложения могут автоматически масштабироваться на основе политик масштабирования, настроенных в Auto Scaling.

  • Уровень промежуточного ПО сообщений. Облачный сервис распределенных сообщений Distributed Message Service (DMS) для инстансов RabbitMQ развертывается в кластерах. По мере изменения объема сообщений и рабочей нагрузки он может увеличивать или уменьшать масштаб по вертикали.

  • Уровень промежуточного ПО кеширования. Master/Standby-инстансы сервиса Distributed Cache Service (DCS) for Redis из облака Advanced могут увеличивать или уменьшать масштаб по вертикали по мере увеличения или уменьшения объема горячих данных.

  • Уровень промежуточного ПО базы данных. Промежуточное ПО распределенной базы данных использует Distributed Database Middleware (DDM), которое развернуто в кластере. С увеличением количества сервисов базы данных спецификации кластера DDM можно плавно расширять, чтобы справиться с обработкой большого объема данных.

  • Уровень базы данных. В сценариях, где объемы считываемых данных существенно превышают объемы записываемых, сервис Relational Database Service (RDS) поддерживает плавное наращивание количества инстансов базы данных, доступных только для чтения. Работая с DDM, можно масштабировать несколько инстансов. Данные в больших таблицах разбиваются по горизонтали и равномерно распределяются по инстансам базы данных, что повышает емкость и производительность базы данных.

Производительность

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

На производительность облачных приложений влияют следующие факторы:

  • Задержка вычислений: время ожидания между операциями и прямая характеристика производительности облачных вычислений.

  • Пропускная способность сети: скорость, с которой обрабатываются данные.

  • Пропускная способность передачи (байт/секунда или бит/секунда): ключевой показатель производительности.

  • Количество операций ввода-вывода, выполняемых системой хранения данных за одну секунду (IOPS): показатель передачи данных.

  • Параллельный доступ к данным: возможность одновременного запуска нескольких программ.

  • Выбор решения:

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

    • Применяйте новые методы выбора решений и оптимизируйте выбор ресурсов и конфигураций с помощью данных.

  • Измерение производительности:

    • Настройка показателей измерения и мониторинга производительности.

    • Автоматический запуск тестов производительности.

    • Используйте визуализацию данных для выявления проблем с производительностью, состояний ожидания или малого потребления.

  • Мониторинг производительности:

    • Определите область мониторинга, показатели и пороговые значения.

    • Создайте полное многомерное представление о производительности.

  • Компромиссы в отношении производительности.

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

Безопасность

Заказчикам облачных инфраструктур необходимо обеспечить:

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

  • конфиденциальность данных — защиту от несанкционированного доступа извне;

  • эффективное управление ЭиТО — поддержку политик безопасности, выявление и предотвращение рисков, а также аудит и отслеживание операций.

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

  • Границы региона

    • Защита границ. Контролируемые соединения, предотвращение несанкционированных частных и внешних подключений и ограничение беспроводного доступа.

    • Политики контроля доступа.

    • Предотвращение вторжений. Предотвращение известных угроз, предотвращение неопознанных угроз и аудит вторжений.

    • Защита от вредоносного кода. Обнаружение вредоносного кода и фильтрация спама.

    • Системные аудиты. Аудит действий пользователей, аудит и анализ событий безопасности.

  • Сетевые соединения

    • Архитектура сети. Резервирование производительности, каналов, устройств и изолирование сегментов.

    • Связь и передача данных. Использование технологий шифрования для обеспечения конфиденциальности и целостности данных при передаче.

  • Вычислительная среда

    • Идентификация личности. Унификация идентификации и комплексные учетные данные.

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

    • Аудит безопасности. Аудит действий пользователей и защита процесса аудита.

    • Предотвращение вторжений. Обнаружение вторжений, закрытие неиспользуемых портов и сканирование уязвимостей.

    • Обнаружение и блокирование вредоносного кода.

    • Проверка целостности образов и защита моментальных снимков.

    • Целостность и конфиденциальность данных при передаче и хранении.

    • Безопасное уничтожение данных. При удалении данных сервисного приложения необходимо также удалить все копии в облачном хранилище.

  • Центр управления

    • Управление системой. Аутентификация личности и конфигурация системы для системных администраторов.

    • Управление аудитом. Управление разрешениями и аудит операций.

    • Управление безопасностью. Управление разрешениями и аудит операций.

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

На рисунке ниже показана архитектура безопасности в облаке. Подробнее см. в разделе «Безопасность».

../../_images/cloud-architecture-design__security.svg

Сокращения:

  • AAD: Advanced Anti-DDoS

  • Anti-DDoS: сервис очистки трафика

  • WAF: Web Application Firewall

  • ELB: Elastic Load Balance

  • OBS: Object Storage Service

  • EVS: Elastic Volume Service

  • SFS: Scalable File Service

  • SG: Security Group (группа безопасности)

  • NACL: Network Access Control List (сетевые списки контроля доступа)

  • HSS: Host Security Service

  • CGS: Container Guard Service

  • DBSS: Database Security Service

  • DEW: Data Encryption Workshop

  • RDS: Relational Database Service

  • DCS: Distributed Cache Service

  • CBH: Cloud Bastion Host

  • CTS: Cloud Trace Service (аудит)

  • CES: Cloud Eye Service (мониторинг)

  • IAM: Identity and Access Management (аутентификация)

  • SA: Situation Awareness

  • SCM: SSL Certificate Manager

Расходы

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

Масштабная конференция
GoCloud 2024:
облачные грани будущего