Стратегии архитектуры для самовосстановления и самосохранения

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

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

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

Определения

Проектирование избыточности

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

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

Проектирование для самосохранения

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

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

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

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

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

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

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

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

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

Проектирование для самовосстановления

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

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

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

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

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

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

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

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

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

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

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

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

Реализация режима грациозной деградации

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

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

Реализация механизмов обработки временных сбоев

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

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

Реализация фоновых заданий

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

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

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

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

Упрощение функций Azure

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

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

Example

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

Связанные ссылки

• Шаблоны надежности
• Обработка временных сбоев
• Разработка фоновых заданий
• Шаблоны облачной разработки
• Проектирование самовосстановления

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

Ознакомьтесь с полным набором рекомендаций.