Рекомендации по самовосстановлению и самосохранения

  • Статья

Применяется к этой рекомендации по контрольным спискам надежности Платформы Azure Well-Architected Framework:

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

Связанные руководства.Временныесбои фоновых заданий |

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

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

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

Определения

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

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

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

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

Руководство по проектированию инфраструктуры и шаблоны

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

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

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

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

Руководство по проектированию приложений и шаблоны

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

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

  • Шаблон асинхронного Request-Reply. Отделяйте серверную обработку от внешнего узла, если серверная обработка должна быть асинхронной, но для внешнего интерфейса требуется четкий ответ.

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

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

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

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

  • Настройка времени ожидания запроса. Настройка времени ожидания запроса для вызовов служб или баз данных. Время ожидания подключения к базе данных обычно устанавливается равным 30 секундам.

  • Шаблон Привратника. Защита приложений и служб с помощью выделенного экземпляра узла для брокера запросов между клиентами и приложением или службой. Брокер проверяет и очищает запросы и может обеспечить дополнительный уровень безопасности для ограничения направлений атак системы.

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

  • Шаблон регулирования. Управление потреблением ресурсов, используемых экземпляром приложения, отдельным клиентом или всей службой. Этот шаблон позволяет системе продолжать функционировать и соблюдать соглашения об уровне обслуживания (SLA), даже если увеличение спроса создает крайнюю нагрузку на ресурсы.

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

Фоновые задания

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

Ниже приведены распространенные примеры фоновых заданий.

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

Дополнительные сведения см. в статье Рекомендации для фоновых заданий.

Руководство по самовосстановлению

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

Руководство по проектированию инфраструктуры

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

  • Вычислительные ресурсы. Azure Масштабируемые наборы виртуальных машин и большинство служб вычислений "платформа как услуга" (PaaS) можно настроить для автоматической отработки отказа.

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

  • Хранилище. Используйте параметры избыточного хранилища с автоматической отработкой отказа.

Руководство по проектированию приложений и шаблоны

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

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

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

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

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

  • Шаблоны тестирования. Включает тестирование шаблонов, которые реализуются в рамках стандартных процедур тестирования.

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

Автоматические действия по самовосстановлению

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

Упрощение поддержки Azure

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

Используйте группы действий Azure Monitor для уведомлений, таких как электронная почта, голосовая связь или SMS, а также для активации автоматических действий. Когда вы получите уведомление о сбое, активируйте служба автоматизации Azure runbook, Центры событий Azure, функцию Azure, приложение логики или веб-перехватчик для выполнения автоматического действия по восстановлению.

Рекомендации

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

Пример

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

Контрольный список надежности

См. полный набор рекомендаций.

Контрольный список надежности