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

Применяется к этой рекомендации по контрольным спискам надежности 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 Cлужба автоматизации Azure, Центры событий Azure, функцию Azure, приложение логики или веб-перехватчик для выполнения автоматического восстановления.

Example

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

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

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

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

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