Для критически важных рабочих нагрузок

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

Что такое критически важная рабочая нагрузка?

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

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

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

Видео: критически важные рабочие нагрузки в Azure

Каковы общие проблемы?

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

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

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

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

Критически ли критически важны только надежность?

Хотя основное внимание критически важных рабочих нагрузок уделяется надежности, другие аспекты Well-Architected Framework также важны при создании и эксплуатации критически важной рабочей нагрузки в Azure.

• Безопасность: то, как рабочая нагрузка устраняет угрозы безопасности, такие как распределенные атаки типа "отказ в обслуживании" (DDoS), будет иметь значительное влияние на общую надежность.

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

• Эффективность производительности. Доступность — это не просто простое время безотказной работы, а согласованный уровень службы приложения и производительности по сравнению с известным состоянием работоспособности.

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

Каковы ключевые области проектирования?

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

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

Область конструирования	Сводка
Проектирование приложений	Использование архитектуры единиц масштабирования в контексте создания высоконадежного приложения. Также рассматриваются шаблоны проектирования облачных приложений, которые позволяют масштабировать и обрабатывать ошибки.
Платформа приложений	Факторы принятия решений и рекомендации, связанные с выбором, проектированием и конфигурацией соответствующей платформы размещения приложений, зависимостей приложений, платформ и библиотек.
Платформа данных	Выбор в технологиях хранения данных с помощью оценки требуемого объема, скорости, разнообразия, достоверности.
Сеть и подключение	Концепции топологии сети на уровне приложения с учетом необходимых возможностей подключения и избыточного управления трафиком. Критические рекомендации, предназначенные для разработки безопасной и масштабируемой глобальной сетевой топологии.
Моделирование и наблюдаемость работоспособности	Процессы для определения надежной модели работоспособности, сопоставления количественных состояний работоспособности приложения с помощью наблюдаемости и операционных конструкций для достижения операционной зрелости.
Развертывание и тестирование	Искоренить время простоя и поддерживать работоспособность приложения для операций развертывания, предоставляя ключевые рекомендации и рекомендации, предназначенные для разработки оптимальных конвейеров CI/CD для критически важных приложений.
Безопасность	Защитите приложение от угроз, направленных на прямое или косвенное компрометацию его надежности.
Операционные процедуры	Внедрение DevOps и связанных методов развертывания используется для обеспечения эффективных и согласованных операционных процедур.

пояснительные примеры;

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

• Базовая архитектура приложения с выходом в Интернет — предоставляет основу для создания ориентированных на облако высокомасштабируемых приложений с выходом в Интернет в Microsoft Azure. Доступ к рабочей нагрузке осуществляется через общедоступную конечную точку и не требует подключения частной сети к окружаемой организационной технической среде.

  См. реализацию: Mission-Critical Online

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

• Базовая архитектура в целевой зоне Azure — предоставляет основу для создания корпоративного облачного приложения в Microsoft Azure с использованием существующей сетевой инфраструктуры и частных конечных точек. Рабочая нагрузка требует частного подключения к другим ресурсам организации и принимает зависимость от предварительно предоставленных виртуальных сетей для подключения к другим ресурсам организации. Этот вариант использования предназначен для сценариев, требующих интеграции с более широким организационным техническим пространством для общедоступных или внутренних рабочих нагрузок.

  См. реализацию : Mission-Critical Connected

Отраслевые сценарии

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

• Оператор-уровень в телекоммуникационной отрасли

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

Следующий шаг

Начните с изучения методологии проектирования для критически важных сценариев приложений.

Методология проектирования