Разработка надежных приложений Azure

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

Основные моменты

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

Использование Зон доступности в пределах региона

Если требуется более высокий уровень изоляции сбоев, чем могут предложить Зоны доступности, рассмотрите возможность развертывания в нескольких регионах. Для отработки отказа в случае сбоя следует использовать несколько регионов. Необходимо учитывать и дополнительные затраты. Примерами таких затрат могут служить данные и сеть, а также службы, такие как Azure Site Recovery.

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

Примечание

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

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

Реагирование на сбои

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

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

Помимо стратегии доступности, определите стратегию непрерывности бизнес-процессов и аварийного восстановления (BCDR) для приложения и/или его ключевых сценариев. Стратегия аварийного восстановления должна описывать, как приложение реагирует на аварийную ситуацию, например на региональный сбой или потерю критической службы платформы. Для этого необходимо использовать такие подходы, как повторное развертывание, теплый уровень "активный — пассивный" или горячий уровень "активный — активный".

Чтобы снизить затраты, рассмотрите возможность разделения компонентов и данных приложения на группы. Пример:

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

Рекомендации по повышению надежности

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


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

Спроектировано ли приложение для горизонтального увеличения масштаба?


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

Приложение развернуто в нескольких подписках Azure?


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

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

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