Разработка с учетом самовосстановления

Разрабатывая приложение, предусмотрите возможность его самовосстановления при сбоях

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Структурированный подход к самовосстановлению приложений см. в статье "Проектирование надежных приложений для Azure".