Проектирование облачной архитектуры
Ключевая задача проектирования архитектуры — обеспечение постоянной доступности системы наряду с разработкой корпоративных сервисов.
Проектирование архитектуры — это главным образом проектирование архитектуры приложений и технической архитектуры. Проектирование архитектуры приложения предусматривает использование специфичных для отрасли функций, стеков технологий и этапов разработки корпоративных приложений. Проектирование технической архитектуры носит более общий характер. В следующих разделах рассматриваются пять аспектов проектирования архитектуры, которые больше всего влияют на непрерывную работоспособность сервисов: высокая доступность (HA), масштабируемость, производительность, безопасность и стоимость.
HA: одна зона доступности, аварийное восстановление в нескольких зонах доступности, мультиактивная и удаленная среда аварийного восстановления (две площадки с тремя центрами)
Масштабируемость: горизонтальное и вертикальное масштабирование
Производительность: планирование производительности, измерение, контроль и компромиссы в отношении производительности
Безопасность: безопасность сети, данных, хоста и приложений
Стоимость: расчет стоимости, оптимизация и управление затратами
Высокий уровень доступности
Под доступностью понимается способность продукта или услуги выполнять определенную функцию при определенных условиях в заданное время или в течение заданного периода времени. Это показатель надежности и эксплуатационной технологичности продукта. Доступность сервисов обычно определяется соглашением об уровне обслуживания (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, а площадку аварийного восстановления — на платформе поставщика облачных услуг.
Проектирование решения высокой доступности с одной зоной доступности
- Описание решения
Поуровневое развертывание сервисов. Уровень веб-доступа, уровень сервиса, уровень данных и зона управления.
Высокая доступность сервисов. Отказ от развертывания на одном узле; развертывание в режиме HA (в кластере или в режиме «активный/резервный»).
Высокая доступность облачных сервисов. Выбранные сервисы Cloud.ru развернуты в режиме НА.
С точки зрения непрерывности функционирования сервиса и доступности данных такое решение обеспечивает высокую доступность на базе кластеров и режима «активный/резервный». Приложения развертываются не на отдельных узлах, а в кластерах или в режиме «активный/резервный». Такой вариант может оказаться более дорогостоящим, но он позволяет значительно повысить уровень доступности.
- Ключевые аспекты проектирования с обеспечением НА
В таблице ниже перечислены приоритеты при проектировании с обеспечением НА.
Компонент |
Приоритеты при проектировании с обеспечением НА |
|---|---|
Высокая доступность сервисов |
Раздельное развертывание. Разные компоненты развертываются на разных ECS. Развертывание конфигурации HА. Такое развертывание используется для всех узлов. Если развертывание конфигурации с высокой доступностью (в режиме «активный/резервный» или на базе кластеров) не поддерживается, должно быть доступно экстренное решение, например, резервное копирование облачного сервера (через CSBS) и аварийная среда. Поуровневое развертывание. Сервисы развертываются отдельно на веб-уровне, уровне сервисов и уровне базы данных. Автоматическое масштабирование. Сервис автоматического масштабирования можно использовать для корректировки вычислительных ресурсов в соответствии с изменениями объема обрабатываемых сервисом данных. |
Высокая доступность облачных сервисов |
|
Надежность данных |
|
Проектирование решения высокой доступности с двумя зонами доступности
- Описание решения и ключевые аспекты проектирования:
Сервисные модули. Для сервисов, поддерживающих развертывание на базе кластеров, ресурсы размещаются в двух зонах доступности с балансировкой нагрузки с помощью ELB. Для ECS с одним узлом используется сервис аварийного восстановления хранилища (SDRS) для восстановления на уровне зоны доступности.
Высокая доступность облачных сервисов. Первичные и резервные узлы развернуты в разных зонах доступности.
Синхронизация баз данных. Используется сервис RDS; инстансы БД RDS развертываются в режиме «первичный/резервный» в разных зонах доступности, а данные синхронизируются.
Аварийное переключение. В случае отказа зоны доступности сервисы баз данных RDS автоматически переключаются на резервные базы данных. Сервисы приложений могут передаваться серверам аварийного восстановления автоматически или с помощью всего нескольких команд.
Тестирование аварийного восстановления. Пользователи могут тестировать работоспособность аварийного восстановления с помощью всего нескольких команд.
Проектирование решения высокой доступности с двумя площадками и тремя центрами (несколько регионов)
- Описание решения и ключевые аспекты проектирования:
Продуктивные центры и центр аварийного восстановления развернуты в двух регионах Cloud.ru.
Продуктивные центры развернуты в двух зонах доступности, а центр аварийного восстановления — в одной зоне.
Инстансы БД RDS развернуты в обоих продуктивных центрах и в центре аварийного восстановления для выполнения репликации по схеме «первичный/резервный» 1:1:1.
Конфигурации, журналы, моментальные снимки и резервные копии, созданные в производственных центрах и центре аварийного восстановления, реплицируются в регионы с помощью сервиса хранения объектов (OBS).
При отказе одной продуктивной зоны доступности сервисы переключаются на другую зону доступности, также выполняется переключение баз данных.
В случае отказа обоих продуктивных центров выполняется переключение базы данных, и благодаря изменению конфигурации DNS 100% пользовательского трафика перенаправляется в центр аварийного восстановления.
После восстановления продуктивных центров выполняется переключение базы данных, и DNS направляет 100% пользовательского трафика в продуктивные центры.
Некоторые сервисы, выполняющие только чтение или анализ данных, могут быть перемещены в центр аварийного восстановления для повышения эффективности его использования.
- Преимущества решения:
Это решение обеспечивает максимальную бесперебойность сервисов и доступность данных. Данные и сервисы будут защищены даже в случае чрезвычайных ситуаций в масштабах региона.
Целевая точка восстановления (RPO) определяется интервалом репликации базы данных. Серверы в центре аварийного восстановления работают всегда, поэтому целевое время восстановления (RTO) может быть практически нулевым. Время, необходимое для выполнения аварийного переключения, зависит от того, сколько займет обновление кэша DNS. Обычно оно занимает несколько минут и может быть ускорено за счет использования механизма балансировки нагрузки серверов GSLB.
Обеспечение высокой доступности аварийного восстановления — сложный проект, который предусматривает контроль входящего трафика, воссоздание сервисного уровня, управление промежуточным ПО и базами данных, а также организацию взаимодействия многочисленных систем. Для построения систем аварийного восстановления высокой доступности требуются профессиональные навыки. Если заказчики хотят быстро создать систему аварийного восстановления высокой доступности, но им не хватает соответствующего опыта, оптимальным выбором будет мультиоблачный сервис высокой доступности (MAS). Этот сервис является производным от решения для обеспечения высокой доступности мультиоблачных приложений в линейке потребительских сервисов Cloud.ru. Он обеспечивает сквозную отказоустойчивость сервиса и возможности тестирования аварийного восстановления, которые охватывают все уровни — от уровня входящего трафика и приложений до уровня данных. Сервис MAS гарантирует быстрое восстановление работоспособности и высокую бесперебойность сервисов.
Масштабируемость
По сравнению с традиционными IDC облако предлагает более мощные ресурсы и возможности масштабирования.
Масштабируемость в облаке
Возможны несколько вариантов масштабирования, предназначенных для разных сценариев работы сервисов.
Вертикальное масштабирование. Для монолитных приложений, независимых приложений и приложений с сохранением состояния (stateful) иногда требуется быстрая модернизация оборудования, чтобы по мере развития сервисов адаптироваться к изменениям спроса. Например, во время рекламных акций такие приложения часто требуют намного больше ресурсов, чем обычно. В этом случае компания может использовать пользовательский интерфейс или открытые API для быстрого масштабирования ресурсов путем добавления дополнительных виртуальных ЦП, памяти, пропускной способности и дискового пространства для обработки растущих рабочих нагрузок. После завершения мероприятий можно восстановить исходные спецификации ресурсов, что позволит снизить расходы.
Горизонтальное масштабирование. Для распределенных приложений, приложений без сохранения состояния (stateless) и быстро меняющихся приложений ресурсы, распределенные в фиксированных соотношениях, могут не всегда соответствовать стремительным изменениям спроса. Благодаря возможностям горизонтального масштабирования приложения могут использовать широкие ресурсы облака и оперативно масштабироваться в соответствии с предварительно настроенными политиками, чтобы обеспечить обработку колебаний трафика как во время рекламных мероприятий, так и после них. Кроме того, эти приложения могут систематически и гибко наращивать ресурсы по мере увеличения рабочих нагрузок.
Экстремальное масштабирование. Чтобы адекватно реагировать на непредвиденные всплески трафика, например, при появлении важных новостей, система должна поддерживать возможности экстремального расширения. Когда происходят такие события, может потребоваться быстрое добавление тысяч вычислительных ядер. Оптимальный выбор в этом случае — масштабирование в облаке.
Существует несколько способов настройки процессов масштабирования:
По расписанию. Для увеличения или уменьшения объема ресурсов в указанное время можно создать запланированную задачу.
С использованием показателей. Для мониторинга показателей производительности ресурсов, таких как загрузка ЦП и средний сетевой трафик, можно создать задачу с выдачей оповещения. Когда отслеживаемый показатель достигает заданного значения, срабатывает сигнал оповещения и выполняется масштабирование ресурсов.
На основе заданного диапазона. Вы можете установить верхний и нижний пределы емкости. Когда количество инстансов вычислительного ресурса выходит за нижнюю или верхнюю границу, система автоматически добавляет или удаляет инстансы таким образом, чтобы их количество оставалось в пределах заданного диапазона.
Вручную. Вы можете добавлять, отключать или удалять существующие ресурсы вручную.
Проектирование масштабируемого решения
Возможности масштабирования можно проектировать по уровням. План обеспечения масштабирования на каждом уровне выглядит следующим образом:
Уровень приложения. Если на этом уровне используется микросервисная архитектура и развертывание приложений на основе контейнеров с помощью Cloud Container Engine (CCE) в облаке Cloud.ru, то благодаря возможностям автоматического масштабирования CCE приложения могут по требованию автоматически увеличивать и уменьшать производительность. Во время автоматического масштабирования, запускаемого сигналом оповещения от AOM, сервисные модули автоматически добавляются или удаляются в ответ на колебания рабочей нагрузки. Если этот уровень развернут с помощью Elastic Cloud Server (ECS) в облаке Cloud.ru, приложения могут автоматически масштабироваться на основе политик масштабирования, настроенных в Auto Scaling.
Уровень промежуточного ПО сообщений. Облачный сервис распределенных сообщений Distributed Message Service (DMS) для инстансов RabbitMQ Premium развертывается в кластерах, и по мере изменения объема сообщений и рабочей нагрузки может увеличивать или уменьшать масштаб по вертикали.
Уровень промежуточного ПО кэширования. Основная/резервная служба Distributed Cache Service (DCS) для инстансов Redis из облака Cloud.ru по мере увеличения или уменьшения объема горячих данных может увеличивать или уменьшать масштаб по вертикали.
Уровень промежуточного ПО базы данных. Промежуточное ПО распределенной базы данных использует Distributed Database Middleware (DDM), которое развернуто в кластере. С увеличением количества сервисов базы данных спецификации кластера DDM можно плавно расширять, чтобы справиться с обработкой большого объема данных.
Уровень базы данных. В сценариях, где объемы считываемых данных существенно превышают объемы записываемых, сервис Relational Database Service (RDS) поддерживает плавное наращивание количества инстансов базы данных, доступных только для чтения. Работая с DDM, можно масштабировать несколько инстансов. Данные в больших таблицах разбиваются по горизонтали и равномерно распределяются по инстансам базы данных, что повышает емкость и производительность базы данных.
Производительность
Производительность — это ключевой показатель эффективности любой программной системы. Это также один из важнейших аспектов проектирования облачной инфраструктуры. При проектировании быстродействия необходимо учитывать параметр масштабируемости, поскольку он критически важен для обеспечения высокой производительности. Кроме того, необходимо учитывать специфику выбранного решения, способы измерения и мониторинга производительности и возможные компромиссы в отношении производительности.
На производительность облачных приложений влияют следующие факторы:
Задержка вычислений: время ожидания между операциями и прямая характеристика производительности облачных вычислений
Пропускная способность сети: скорость, с которой обрабатываются данные
Пропускная способность передачи (байт/секунда или бит/секунда): ключевой показатель производительности
Количество операций ввода-вывода, выполняемых системой хранения данных за одну секунду (IOPS): показатель передачи данных
Параллельный доступ к данным: возможность одновременного запуска нескольких программ
Выбор решения:
Выбирайте и комбинируйте решения, которые наилучшим образом соответствуют вашим потребностям.
Применяйте новые методы выбора решений и оптимизируйте выбор ресурсов и конфигураций с помощью данных.
Измерение производительности:
Настройка показателей измерения и мониторинга производительности.
Автоматический запуск тестов производительности.
Используйте визуализацию данных для выявления проблем с производительностью, состояний ожидания или малого потребления.
Мониторинг производительности:
Определите область мониторинга, показатели и пороговые значения.
Создайте полное многомерное представление о производительности.
Компромиссы в отношении производительности.
Найдите оптимальное соотношение сложности и производительности архитектуры, используя, например, методы сжатия или кэширования.
Безопасность
Заказчикам облачных инфраструктур необходимо обеспечить следующий функционал безопасности:
Непрерывность работы сервисов — например, функционал блокировки сетевых атак, предотвращения вторжений и обеспечения нормативно-правового соответствия.
Конфиденциальность данных — защита от несанкционированного доступа извне, со стороны сотрудников организации и провайдеров облачных услуг.
Эффективное управление ЭиТО — например, поддержка политик безопасности, выявление и предотвращение рисков, а также аудит и отслеживание операций.
Архитектура разрабатывается таким образом, чтобы усовершенствовать следующие аспекты сетевой безопасности:
Границы региона
Защита границ. Контролируемые соединения, предотвращение несанкционированных частных и внешних подключений и ограничение беспроводного доступа.
Политики контроля доступа
Предотвращение вторжений. Предотвращение известных угроз, предотвращение неопознанных угроз и аудит вторжений.
Защита от вредоносного кода. Обнаружение вредоносного кода и фильтрация спама.
Системные аудиты. Аудит действий пользователей, аудит и анализ событий безопасности.
Сетевые соединения
Архитектура сети. Резервирование производительности, каналов и устройств и изолирование сегментов.
Связь и передача данных. Использование технологий шифрования для обеспечения конфиденциальности и целостности данных при передаче.
Вычислительная среда
Идентификация личности. Унификация идентификации и комплексные учетные данные.
Контроль доступа. Управление разрешениями пользователей и очистка избыточных учетных записей.
Аудит безопасности. Аудит действий пользователей и защита процесса аудита.
Предотвращение вторжений. Обнаружение вторжений, закрытие неиспользуемых портов и сканирование уязвимостей.
Обнаружение и блокирование вредоносного кода.
Проверка целостности образов и защита моментальных снимков.
Целостность и конфиденциальность данных при передаче и хранении.
Безопасное уничтожение данных. При удалении данных сервисного приложения необходимо также удалить все копии в облачном хранилище.
Центр управления
Управление системой. Аутентификация личности и конфигурация системы для системных администраторов
Управление аудитом. Управление разрешениями и аудит операций.
Управление безопасностью. Управление разрешениями и аудит операций.
Централизованное управление и контроль. Независимые защищенные сегменты, мониторинг сети, централизованный аудит журналов и осведомленность о событиях безопасности.
На рисунке ниже показана архитектура безопасности в облаке. Подробнее см. в разделе «Безопасность».
Сокращения:
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: группа безопасности
NACL: список управления доступом к сети
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
Расходы
Затраты на облачную инфраструктуру определяются такими факторами, как использование ресурсов по требованию и их тарификация, гибкое масштабирование и потребление ресурсов.