Развертывание и тестирование критически важных рабочих нагрузок в Azure

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

Развертывание и тестирование должны быть основой для всех операций приложений и инфраструктуры, чтобы обеспечить согласованные результаты для критически важных рабочих нагрузок. Будьте готовы к развертыванию еженедельно, ежедневно или чаще. Разработайте конвейеры непрерывной интеграции и непрерывного развертывания (CI/CD) для поддержки этих целей.

Стратегия должна реализовать следующее:

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

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

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

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

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

Развертывание без простоя

Просмотрите следующее видео для обзора развертывания без простоя.

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

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

Эталонные реализации Mission-Critical Online и Azure Mission-Critical Connected иллюстрируют этот подход к развертыванию, как показано на этой схеме.

Среды приложений

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

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

Существуют некоторые общие соображения.

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

• Все среды должны использовать инфраструктуру в качестве артефактов кода (IaC), таких как Terraform или шаблоны Azure Resource Manager (ARM).

Среды разработки

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

Рекомендации по проектированию

• Возможности. Более низкие требования к надежности, емкости и безопасности допустимы для сред разработки.

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

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

Рекомендации по проектированию

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

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

Тестовые или пробные среды

Эти среды используются для тестирования и проверки. Многие циклы тестирования выполняются для обеспечения развертывания без ошибок в рабочей среде. Соответствующие тесты для критически важной рабочей нагрузки описаны в разделе "Непрерывная проверка и тестирование ".

Рекомендации по проектированию

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

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

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

Рекомендации по проектированию

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

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

  Замечание

  Референсная реализация Mission Critical Online предоставляет пример генератора нагрузки пользователя.

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

Рабочие среды

Рекомендации по проектированию

• Возможности. Требуются самые высокие уровни надежности, емкости и безопасности для приложения.

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

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

Рекомендации по проектированию

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

Эфемерные развертывания синего и зеленого цвета

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

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

Рекомендации по проектированию

• Возможности технологий. Воспользуйтесь встроенными функциями развертывания в службах Azure. Например, служба приложений Azure предоставляет вторичные слоты развертывания, которые можно переключить после развертывания. С помощью службы Azure Kubernetes (AKS) можно использовать отдельное развертывание pod на каждом узле и обновить определение службы.

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

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

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

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

Рекомендации по проектированию

• Примените подход развертывания blue/green, чтобы выпустить все изменения в рабочей среде. Развертывайте всю инфраструктуру и приложение каждый раз для любого типа изменений, чтобы обеспечить согласованное состояние и нулевое время простоя. Хотя вы можете повторно использовать среды, мы не рекомендуем использовать его для критически важных рабочих нагрузок. Рассматривайте каждую метку регионального развертывания как временную, с жизненным циклом, связанным с одним выпуском.

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

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

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

  На этом этапе следует вывести из эксплуатации старую и теперь неактивную синюю среду. Для следующего развертывания повторите процесс, поменяв местами синий и зеленый.

Развертывание в рамках подписки

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

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

Рекомендации по проектированию

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

  Это важно

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

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

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

Рекомендации по проектированию

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

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

Непрерывная проверка и тестирование

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

Просмотрите следующее видео, чтобы получить общие сведения о непрерывной проверке и тестировании.

В этом разделе основное внимание уделяется тестированию внешнего цикла. В нем описываются различные типы тестов.

Рекомендации по проектированию

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

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

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

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

• Анализ режима сбоя. Внедрение ошибок в приложение и базовую инфраструктуру и оценку эффекта является важным для оценки механизмов избыточности решения. Во время этого анализа определите риск, влияние и широту влияния (частичное или полное сбой). Пример анализа, который был создан для эталонной реализации Mission Critical Online, см. раздел Риски сбоя отдельных компонентов.

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

Рекомендации по проектированию

Просмотрите следующее видео, чтобы узнать, как можно интегрировать тестирование устойчивости с конвейерами CI/CD Azure DevOps.

• Обеспечение согласованности путем автоматизации всех тестов на компонентах инфраструктуры и приложений. Интегрируйте тесты в конвейеры CI/CD для управления и запуска их, где это применимо. Сведения о вариантах технологии см. в разделе "Средства DevOps".

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

• Выровняйте соглашение об уровне обслуживания тестовой инфраструктуры с соглашением об уровне обслуживания для циклов развертывания и тестирования.

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

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

  Подсказка

  Azure Chaos Studio — это собственный набор средств экспериментирования хаоса. Средства позволяют легко проводить эксперименты хаоса и внедрять ошибки в службах Azure и компонентах приложений.

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

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

• Сканируйте и отслеживайте полную цепочку поставок программного обеспечения и зависимости библиотек для известных уязвимостей безопасности (CVE).

  • Используйте Dependabot для репозиториев GitHub, чтобы убедиться, что репозиторий автоматически обновляется с последними выпусками пакетов и приложений, от которые он зависит.

Инфраструктура в виде развертываний кода

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

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

Рекомендации по проектированию

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

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

Рекомендации по проектированию

• Примените IaC, гарантируя, что все ресурсы Azure определены в декларативных шаблонах и хранятся в репозитории контроля версий. Шаблоны развертываются, а ресурсы подготавливаются автоматически из системы контроля версий с помощью CI/CD пайплайнов. Мы не рекомендуем использовать императивные скрипты.

• Запретить операции вручную для всех сред. Единственное исключение — это полностью независимые среды разработчика.

Средства DevOps

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

Корпорация Майкрософт предоставляет два набора инструментов на основе Azure, GitHub Actions и Azure Pipelines, которые могут эффективно развертывать критически важные приложения и управлять ими.

Рекомендации по проектированию

• Возможности технологий. Возможности GitHub и Azure DevOps перекрываются. Их можно использовать вместе, чтобы получить лучшее из обоих. Распространенный подход заключается в хранении репозиториев кода в GitHub.com или GitHub AE при использовании Azure Pipelines для развертывания.

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

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

  Например, например, трафик распределяется по двум регионам: региону 1 и региону 2. Регион 2 размещает экземпляр инструментария Azure DevOps. Предположим, что в регионе 2 произошел сбой, и экземпляр недоступен. Регион 1 автоматически обрабатывает весь трафик и должен развернуть дополнительные единицы масштабирования, чтобы обеспечить качественный опыт отработки отказа. Но это не сможет работать из-за зависимости Azure DevOps в регионе 2.

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

Рекомендации по проектированию

• Обе технологии размещаются в одном регионе Azure, что может ограничить стратегию аварийного восстановления.

  GitHub Actions хорошо подходит для задач сборки (непрерывная интеграция), но может не использовать функции для сложных задач развертывания (непрерывное развертывание). Учитывая широкий набор функций Azure DevOps, мы рекомендуем использовать его для критически важных развертываний. Однако вы должны сделать выбор после оценки компромиссов.

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

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

Стратегия ветвления

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

Рекомендации по проектированию

• Свести к минимуму доступ. Разработчики должны выполнять свою работу в feature/* и fix/* ветках. Эти ветви становятся точками входа для изменений. Ограничения на основе ролей должны применяться к ветвям в рамках стратегии ветвления. Например, только администраторам разрешено создавать ветки выпуска или соблюдать соглашения об именовании для веток.

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

Рекомендации по проектированию

• Определите приоритет использования GitHub для управления версиями.

  Это важно

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

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

• main Рассматривайте ветвь как непрерывно перемещаемую и стабильную ветвь, которая в основном используется для тестирования интеграции.

  • Убедитесь, что изменения вносятся в main только через pull request (PR). Используйте политику для ветвей для запрета прямых коммитов.
  • Каждый раз при объединению mainpr в среду интеграции он должен автоматически запускать развертывание в среде интеграции.
  • Ветвь main должна считаться стабильной. Выпуск из main должен быть безопасным для создания в любой момент.

• Используйте выделенные release/* ветви, созданные из main ветви и используемые для развертывания в рабочих средах. release/* Ветви должны оставаться в репозитории и могут использоваться для внесения исправлений в релиз.

• Задокументируйте процесс исправления и используйте его только при необходимости. Создайте хотфиксы в ветке fix/* для последующего объединения в ветвь выпуска и развертывания в продакшн.

ИИ для DevOps

Методологии AIOps можно применять в конвейерах CI/CD, чтобы дополнить традиционные подходы к тестированию. Это позволяет обнаруживать потенциальные регрессии или ухудшения состояния, а также позволяет развертываниям быть предварительно остановленными, чтобы предотвратить потенциальные негативные последствия.

Рекомендации по проектированию

• Объем данных телеметрии. Конвейеры CI/CD и процессы DevOps выдают широкий спектр данных телеметрии для моделей машинного обучения. Данные телеметрии варьируются от результатов тестирования и результатов развертывания до операционных данных о компонентах тестирования с составных этапов развертывания.

• масштабируемость. Традиционные подходы к обработке данных, такие как извлечение, преобразование, загрузка (ETL), могут не выполнять масштабирование пропускной способности, чтобы поддерживать рост данных телеметрии развертывания и наблюдаемости приложений. Вы можете использовать современные подходы аналитики, которые не требуют перемещения данных и ETL, таких как виртуализация данных, для обеспечения непрерывного анализа моделей AIOps.

• Изменения развертывания. Изменения в развертывании должны храниться для автоматического анализа и корреляции с результатами развертывания.

Рекомендации по проектированию

• Определите данные процесса DevOps для сбора и анализа. Данные телеметрии, такие как метрики выполнения тестов и данные временных рядов изменений в каждом развертывании, важны.

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

• Внедрение рабочего процесса MLOps.

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

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

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

Ознакомьтесь с рекомендациями по обеспечению безопасности.