Целевые и нефункциональные требования

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

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

Ключевые моменты

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

Целевые показатели доступности

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

Понимание ваших ожиданий относительно доступности крайне важно для оценки общей работы приложения. Например, если вы хотите достичь целевых показателей уровня обслуживания приложения (SLO), равной 99,999 %, уровень встроенных операций, необходимых приложению, будет гораздо больше, чем в случае, когда эта цель равна 99,9 %.

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

  • Среднее время между сбоями (MTBF) — среднее время между сбоями определенного компонента.
  • Среднее время для восстановления (MTTR) — это среднее время, затрачиваемое на восстановление компонента после сбоя.

Рекомендации для целей доступности

Определены ли показатели SLA, SLI и SLO для всех используемых зависимостей?


Целевые показатели доступности для всех зависимостей, используемых приложением, должны быть понятными и соответствовать целевым показателям приложения. Убедитесь, что соглашения SLA/SLO/SLI для всех используемых зависимостей понятны.

Было ли рассчитано составное соглашение об уровне обслуживания для приложения и (или) ключевых сценариев с использованием соглашений об уровне обслуживания Azure?


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

Примечание

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

Учитываются ли целевые показатели доступности, пока система работает в режиме аварийного восстановления?


Целевые показатели доступности могут быть применены, но могут быть и не применены при работе в режиме аварийного восстановления. Это зависит от приложения. Если целевые показатели должны применяться и в состоянии сбоя, то для достижения большей доступности и устойчивости следует использовать модель N+1. В этом сценарии N — емкость, необходимая для предоставления необходимой доступности. Это также связано с затратами, поскольку более устойчивая инфраструктура обычно является более дорогостоящей. Это должно быть утверждено бизнесом.

Каковы последствия несоблюдения целевых показателей доступности?


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

Целевые показатели восстановления

Цели по восстановлению определяют, как долго рабочая нагрузка может быть недоступна, и сколько данных приемлемо потерять во время аварии. Определите отчеты по целям для приложения и ключевые сценарии. Требуемые целевые отчеты — целевое время восстановления (RTO) — это максимально допустимое время, в течение которого приложение будет недоступно после инцидента. Целевая точка восстановления (RPO) — максимальная продолжительность потери данных, которая допустима во время аварии.

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

Соответствие требованиям платформы приложений

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

Дополнительные сведения см. в статье Служебная шина Azure ценовой категории "Премиум".

Множественные и парные регионы

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

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

Используйте парные регионы, которые существуют в пределах одного географического объекта, и предоставьте собственные функции репликации для целей восстановления, например асинхронною репликацию геоизбыточного хранилища (GRS). В случае планового обслуживания обновления для региона будут выполняться только последовательно. Дополнительные сведения см. в статье Непрерывность бизнес-процессов с помощью парных регионов Azure.

Зоны доступности и наборы

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

Группа доступности (AS) — это логическая конструкция для информирования Azure о том, что служба должна распространять автономные экземпляры виртуальных машин в нескольких доменах сбоя и обновления в регионе Azure. Зоны доступности (AZ) повышают уровень сбоя виртуальных машин до физического центра обработки данных, разрешая развертывание экземпляров реплик в нескольких центрах обработки данных в регионе Azure. В то время как зоны обеспечивают большую устойчивость, чем наборы, существуют проблемы с производительностью и затратами, когда приложения являются чрезвычайно "активными" в разных зонах с учетом физического разделения и расходов на пропускную способность между зонами. Наконец, виртуальные машины Azure и службы Azure PaaS, такие как Service Fabric и служба Azure Kubernetes (AKS), использующие виртуальные машины, могут использовать AZ или AS, чтобы обеспечить устойчивость приложений в пределах региона. Дополнительные сведения см. в статье Непрерывность бизнес-процессов с обеспечением устойчивости данных.

Рекомендации по обеспечению доступности

Приложение размещено на двух или нескольких узлах платформы приложений?


Чтобы обеспечить надежность платформы приложений, крайне важно, чтобы приложение было размещено по крайней мере на двух узлах, чтобы гарантировать отсутствие единой точки отказа. В идеале необходимо применять модель n+1 для обеспечения доступности вычислений, где n — число экземпляров, необходимых для поддержки доступности приложения и требований к производительности.

Примечание

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

Как трафик клиента направляется в приложение в случае сбоя региона, зоны или сети?


В случае крупного сбоя клиентский трафик должен быть направлен в развертывания приложений, которые остаются доступными в других регионах или зонах. В конечном итоге следует использовать распределенное подключение и глобальную балансировку нагрузки в зависимости от того, является ли приложение внутренним или внешним. Такие службы, как Azure Front Door, Диспетчер трафика Azure или сторонние CDN, могут маршрутизировать трафик между регионами в зависимости от работоспособности приложения, запрашиваемого с помощью проб работоспособности. Дополнительные сведения см. в разделе Мониторинг конечной точки Диспетчера трафика.

Соответствие требованиям к платформе данных

Службы данных и хранилища должны работать в конфигурации или SKU высокой доступности. Службы платформы данных Azure предлагают компоненты устойчивости для обеспечения надежности приложений, хотя они могут быть применимы только к определенным SKU, конфигурации или развертыванию. Примеры: критически важные для бизнеса SKU Базы данных SQL Azure или хранилище Azure, избыточное между зонами (ZRS), с тремя синхронными репликами, распределенными между зонами доступности.

Согласованность данных

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

Теорема CAP подтверждает, что невозможно одновременно предоставить распределенному хранилищу данных более двух гарантий:

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

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

Репликация и избыточность

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

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

Рассмотрим, как трафик приложения направляется в источники данных в случае сбоя региона, зоны или сети. Понимание метода, используемого для маршрутизации трафика приложения в источники данных в случае события крупного сбоя, очень важно для того, чтобы определить, соответствуют ли процессы отработки отказа целям восстановления. Многие службы платформы данных Azure предлагают собственные возможности надежности для обработки крупных сбоев, таких как автоматическая отработка отказа Azure Cosmos DB или активная георепликация базы данных Azure SQL.

Примечание

Некоторые возможности, такие как служба хранилища Azure RA-GRS и активная георепликация DB в Azure SQL, нуждаются в отработке отказа на стороне приложения для альтернативных конечных точек в некоторых сценариях сбоя, поэтому для обработки этих сценариев необходимо разработать логику приложения.

Требования к сети и подключению

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

Подключение

  • Используйте глобальную подсистему балансировки нагрузки, используемую для распределения трафика и (или) отработки отказа в регионы. Для направления входящих запросов к внешним конечным точкам приложения, развернутым в нескольких регионах, можно использовать Azure Front Door, Диспетчер трафика Azure или сторонние службы CDN. Важно отметить, что Диспетчер трафика является подсистемой балансировки нагрузки на основе DNS, поэтому отработка отказа должна дожидаться распространения DNS. Для записей DNS следует использовать достаточно низкое значение TTL (срок жизни), хотя не все поставщики услуг Интернета могут его учитывать. Для сценариев приложений, требующих прозрачной отработки отказа, следует использовать Azure Front Door. Дополнительные сведения см. в статье Аварийное восстановление с помощью Диспетчера трафика Azure и Архитектура маршрутизации Azure Front Door.

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

  • Смоделируйте сбои, чтобы убедиться, что подключение осуществляется альтернативными способами. Сбой пути соединения с другими путями соединения должен быть протестирован для проверки подключения и эксплуатационной эффективности. Использование VPN-подключения типа "сеть — сеть" в качестве пути резервного копирования для ExpressRoute обеспечивает дополнительный уровень устойчивости сети для подключения между организациями. Дополнительные сведения см. в статье Использование VPN типа "сеть — сеть" в качестве резервной копии частного пиринга ExpressRoute.

  • Устраните все единые точки отказа в пути к данным (в локальной среде и Azure). Виртуальные сетевые модули (NVA) с одним экземпляром, развернутые в Azure или в локальном центре обработки данных, предоставляют значительный риск подключения. Дополнительные сведения см. в разделе Развертывание виртуальных сетевых модулей высокой доступности.

Службы, поддерживающие зоны

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

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

  • Используйте Azure Load Balancer (уровень "Стандартный") для балансировки нагрузки трафика между зонами доступности. Azure Load Balancer (уровень "Стандартный") учитывает зону для распределения трафика между зонами доступности. Его также можно настроить в конфигурации, избыточной между зонами, чтобы повысить надежность и обеспечить доступность во время сценариев сбоя, влияющих на центр обработки данных в пределах региона. Дополнительные сведения см. в статье Azure Load Balancer уровня "Стандартный" и зоны доступности.

  • Настройте зонды работоспособности для Шлюзов приложений Azure или подсистем Azure Load Balancer. Пробы работоспособности позволяют подсистемам Azure Load Balancer оценивать работоспособность конечных точек сервера, чтобы предотвратить отправку трафика в неработоспособные экземпляры. Дополнительные сведения см. в разделе Подробнее о пробах работоспособности Load Balancer.

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

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

Вернуться к основной статье: Проектирование