Принципы проектирования критически важной рабочей нагрузки
Критически важная методология проектирования опирается на пять ключевых принципов проектирования, которые служат компасом для последующих решений по проектированию в критически важных областях проектирования. Мы настоятельно рекомендуем ознакомиться с этими принципами, чтобы лучше понять их влияние и компромиссы, связанные с несоблюдением.
Важно!
Эта статья является частью серии критически важных рабочих нагрузок Azure Well-Architected . Если вы не знакомы с этой серией, рекомендуем начать с критически важной рабочей нагрузки?
Эти критически важные принципы проектирования резонируют и расширяют основные принципы качества платформы Azure Well-Architected: надежность, безопасность, оптимизация затрат, эффективность работы и эффективность производительности.
надежность;
Максимальная надежность — фундаментальное стремление к наиболее надежному решению, гарантирующее правильное понимание компромиссов.
Принцип проектирования | Рекомендации |
---|---|
Проектирование "активный/активный" | Чтобы обеспечить максимальную доступность и обеспечить отказоустойчивость в регионе, компоненты решения должны распределяться по нескольким регионам Зоны доступности и Azure с помощью модели активного и активного развертывания, где это возможно. |
Уменьшение радиуса взрыва и изоляция сбоя | Сбой невозможно избежать в высокораспределённой мультитенантной облачной среде, такой как Azure. Прогнозируя сбои и коррелированные последствия , от отдельных компонентов до целых регионов Azure, решение можно разработать и разработать устойчивым образом. |
Наблюдение за работоспособностью приложений | Прежде чем устранить проблемы, влияющие на надежность приложений, их необходимо сначала обнаружить и понять. Отслеживая работу приложения относительно известного работоспособного состояния, можно обнаруживать или даже прогнозировать проблемы с надежностью, что позволяет выполнять быстрые действия по исправлению. |
Автоматизация дисков | Одной из основных причин простоя приложения является человеческая ошибка, связанная с развертыванием недостаточно протестированного программного обеспечения или неправильной настройкой. Чтобы свести к минимуму вероятность и влияние человеческих ошибок, крайне важно стремиться к автоматизации во всех аспектах облачного решения для повышения надежности; автоматическое тестирование, развертывание и управление. |
Разработка для автоматического восстановления | Самовосстановление описывает способность системы автоматически устранять сбои с помощью предварительно определенных протоколов исправления, подключенных к режимам сбоя в решении. Это расширенная концепция, требующая высокого уровня зрелости системы с мониторингом и автоматизацией, но с самого начала она должна быть стремлением к максимальной надежности. |
Избегание сложности | Избегайте ненужных сложностей при проектировании решения и всех рабочих процессов, чтобы повысить надежность и эффективность управления, сводя к минимуму вероятность сбоев. |
Уровень производительности
Устойчивая производительность и масштабируемость . Проектирование для обеспечения масштабируемости в комплексном решении без узких мест производительности.
Принцип проектирования | Рекомендации |
---|---|
Проектирование для горизонтального увеличения масштаба | Горизонтальное масштабирование — это концепция, которая фокусируется на способности системы реагировать на спрос за счет горизонтального роста. Это означает, что по мере роста трафика все больше единиц ресурсов добавляются параллельно, а не увеличивают размер существующих ресурсов. Способность системы обрабатывать ожидаемое и неожиданное увеличение трафика с помощью единиц масштабирования имеет важное значение для общей производительности и надежности за счет дальнейшего снижения влияния сбоя одного ресурса. |
Автоматизация для гипермасштабирования | Операции масштабирования в решении должны быть полностью автоматизированы, чтобы свести к минимуму влияние на производительность и доступность от неожиданного или ожидаемого увеличения трафика, гарантируя, что время, необходимое для выполнения операций масштабирования, будет понято и согласовано с моделью работоспособности приложений. |
Непрерывная проверка и тестирование | Автоматическое тестирование должно выполняться в процессах CI/CD, чтобы обеспечить непрерывную проверку для каждого изменения приложения. Необходимо включить нагрузочное тестирование на основе базовых показателей производительности с синхронизированными экспериментами с хаосом для проверки существующих пороговых значений, целевых показателей и предположений, а также для быстрого выявления рисков для устойчивости и доступности. Такое тестирование должно выполняться в промежуточной и тестовой средах, а также при необходимости в средах разработки. Также может быть полезно выполнить подмножество тестов в рабочей среде, особенно в сочетании с сине-зеленой моделью развертывания для проверки новых меток развертывания перед получением рабочего трафика. |
Сокращение накладных расходов с помощью управляемых служб вычислений | Использование управляемых вычислительных служб и контейнерных архитектур значительно сокращает текущие административные и операционные затраты на проектирование, эксплуатацию и масштабирование приложений за счет переноса развертывания и обслуживания инфраструктуры на поставщика управляемых служб. |
Базовая производительность и определение узких мест | Тестирование производительности с подробными данными телеметрии из каждого системного компонента позволяет выявить узкие места в системе, включая компоненты, которые необходимо масштабировать по отношению к другим компонентам, и эти сведения должны быть включены в модель емкости. |
Емкость модели | Модель емкости позволяет планировать уровни масштабирования ресурсов для заданного профиля нагрузки и дополнительно показывает, как системные компоненты работают друг с другом, что позволяет планировать распределение ресурсов на уровне системы. |
Эффективность операционных процессов
Операции по проектированию — благодаря надежному и надежному оперативному управлению.
Принцип проектирования | Рекомендации |
---|---|
Слабосвязанные компоненты | Слабая связь обеспечивает независимое тестирование, развертывание и обновление компонентов приложения по запросу, минимизируя зависимости между командами для поддержки, служб, ресурсов или утверждений. |
Автоматизация процессов сборки и выпуска | Полностью автоматизированные процессы сборки и выпуска сокращают сложности и повышают скорость развертывания обновлений, повышая повторяемость и согласованность в разных средах. Автоматизация сокращает цикл обратной связи от разработчиков, которые отправляют изменения для получения аналитических сведений о качестве кода, охвате тестов, устойчивости, безопасности и производительности, что повышает производительность разработчиков. |
Гибкость разработчика | Автоматизация непрерывной интеграции и непрерывного развертывания (CI/CD) позволяет использовать кратковременные среды разработки с жизненным циклом, привязанным к жизненным циклам связанного ветвь компонента, что повышает гибкость разработчика и позволяет выполнять проверку как можно раньше в рамках цикла разработки, чтобы свести к минимуму затраты на проектирование ошибок. |
Количественное определение работоспособности операций | Полное диагностическое инструментирование всех компонентов и ресурсов обеспечивает постоянную наблюдаемость журналов, метрик и трассировок, а также упрощает моделирование работоспособности для количественной оценки работоспособности приложений в контексте требований к доступности и производительности. |
Отработка восстановления и сбоя | Планирование непрерывности бизнес-процессов (BC) и аварийное восстановление (DR) имеют важное значение и должны выполняться часто, так как обучение может итеративно улучшать планы и процедуры, чтобы обеспечить максимальную устойчивость в случае незапланированного простоя. |
Непрерывное улучшение операционных процессов | Приоритезируйте регулярное улучшение системы и взаимодействия с пользователем, используя модель работоспособности, чтобы понять и измерить эффективность работы с помощью механизмов обратной связи, чтобы позволить командам приложений понять и устранить пробелы в итеративном режиме. |
Безопасность
Всегда безопасный — проектирование комплексной безопасности для поддержания стабильности приложений и обеспечения доступности.
Принцип проектирования | Рекомендации |
---|---|
Мониторинг безопасности всего решения и планирование реагирования на инциденты | Сопоставлять события безопасности и аудита для моделирования работоспособности приложений и выявления активных угроз. Создайте автоматизированные и ручные процедуры реагирования на инциденты с помощью средств управления информационной безопасностью и событиями безопасности (SIEM) для отслеживания. |
Моделирование и тестирование на потенциальные угрозы | Обеспечьте соответствующую защиту ресурсов и создайте процедуры для выявления и устранения известных угроз, используя тестирование на проникновение для проверки устранения угроз, а также статический анализ кода и сканирование кода. |
Идентификация и защита конечных точек | Мониторинг и защита целостности сети внутренних и внешних конечных точек с помощью возможностей безопасности и устройств, таких как брандмауэры или брандмауэры веб-приложений. Используйте стандартные отраслевые подходы для защиты от распространенных векторов атак, таких как распределенные атаки типа "отказ в обслуживании" (DDoS), например SlowLoris. |
Защита от уязвимостей на уровне кода | Выявляйте и устраняйте уязвимости на уровне кода, такие как межсайтовые скрипты или внедрение КОДА, и включайте исправления безопасности в операционные жизненные циклы для всех частей базы кода, включая зависимости. |
Автоматизация и использование минимальных привилегий | Обеспечьйте автоматизацию, чтобы свести к минимуму потребность в взаимодействии с человеком и реализовать минимальные привилегии как в приложении, так и в уровне управления для защиты от кражи данных и вредоносных сценариев субъектов. |
Классификация и шифрование данных | Классифицируйте данные в соответствии с риском и применяйте стандартное отраслевое шифрование при хранении и передаче, обеспечивая безопасное хранение ключей и сертификатов и правильное управление ими. |
Оптимизация затрат
Существуют очевидные компромиссы затрат, связанные с повышением надежности, которые следует тщательно учитывать в контексте требований рабочей нагрузки.
Максимизация надежности может повлиять на общую финансовую стоимость решения. Например, дублирование ресурсов и распределение ресурсов между регионами для обеспечения высокой доступности имеет явные последствия для затрат. Чтобы избежать лишних затрат, не следует перепроектировать и не подготавливать их сверх соответствующих бизнес-требований.
Кроме того, есть дополнительные затраты, связанные с инвестициями в проектирование фундаментальных концепций надежности, таких как использование инфраструктуры как кода, автоматизация развертывания и проектирование хаоса. Это связано с затратами как времени, так и усилий, которые могут быть потрачены в других местах для предоставления новых функций и функций приложения.
Собственная облачная разработка
Управляемые службы, встроенные в Azure . Управляемые службы Azure имеют приоритет из-за снижения административных и операционных издержек, а также тесной интеграции с согласованной конфигурацией и инструментированием в стеке приложений.
Согласование стратегии . Включите новые и улучшенные возможности службы Azure, которые становятся общедоступными, чтобы оставаться ближе к переднему краю Azure.
Использование предварительных версий возможностей и устранение известных пробелов . Хотя общедоступные службы имеют приоритетное значение для обеспечения поддержки, предварительные версии служб Azure активно изучаются для быстрого внедрения, предоставляя технические и практические отзывы для групп продуктов Azure для устранения пробелов.
Выравнивание целевой зоны Azure — развертывается в целевой зоне Azure и соответствует методологии проектирования целевой зоны Azure, но также полностью функциональным и развертываемым в среде без использования за пределами целевой зоны.
Следующий шаг
Изучите сквозные проблемы, связанные с критически важными рабочими нагрузками.