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

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

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

• Обнаружение сбоев.
• Элегантно реагируйте на сбои.
• Ведение журнала и мониторинг сбоев для предоставления операционной осведомленности.

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

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

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

Проектирование самостоятельного восстановления рабочей нагрузки является фундаментальным в компоненте надежности Платформы Azure Well-Architected Framework, который подчеркивает создание устойчивых систем, которые могут противостоять сбоям и восстанавливаться до полнофункционального состояния. Создайте стратегию самостоятельного восстановления для поддержки показателей доступности рабочей нагрузки, включая целевые уровни обслуживания (SLO).

Recommendations

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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