Рекомендации по обработке временных сбоев

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

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

Терминология

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

Временные ошибки

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

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

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

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

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

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

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

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

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

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

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

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

Определите, имеется ли встроенный механизм повтора

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

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

Определите, подходит ли операция для повторной попытки

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

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

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

Определите подходящее количество повторов и интервал времени

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

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

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

  • Экспоненциальный откат. Приложение некоторое время ждет перед первой повторной попыткой, а затем экспоненциально увеличивает время между каждой последующей повторной попыткой. Например, операция может повторяться через 3 секунды, 12 секунд, 30 секунд и т. д. Для дальнейшего улучшения этой стратегии можно добавить jitter в экспоненциальный откат. Jitter представляет случайную задержку для каждой повторной попытки, что помогает предотвратить одновременные повторные попытки нескольких клиентов и вызвать всплеск нагрузки.

  • Добавочные интервалы. Приложение ожидает некоторое время до первого повтора, а затем добавочно увеличивает время между каждой последующей повторным попыткой. Например, она может повторить операцию через 3 секунды, 7 секунд, 13 секунд и т. д.

  • Регулярные интервалы. Приложение ожидает одинаковый период времени между каждой новой попыткой. Например, она может повторить операцию каждые 3 секунды.

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

  • Рандомизация. Любая из стратегий повторных попыток, перечисленных ранее, может включать рандомизацию, чтобы предотвратить несколько экземпляров одного и того же клиента от отправки последующих повторных попыток одновременно. Например, один экземпляр может повторить операцию через 3 секунды, 11 секунд, 28 секунд и т. д., а другой экземпляр может повторить операцию через 4 секунды, 12 секунд, 26 секунд и т. д. Случайное использование — это полезный метод, который можно объединить с другими стратегиями.

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

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

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

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

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

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

Избегайте антишаблонов

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

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

• Никогда не выполняйте немедленную повторную попытку более одного раза.

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

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

Тестирование стратегий повторных попыток и реализации

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

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

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

  • Для пользовательских служб, которые вы создаете и развертываете, принудительно вызывайте временные ошибки, на время отключая или перегружая службу. (Не пытайтесь перегружать какие-либо общие ресурсы или общие службы в Azure.)

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

  • При тестировании устойчивости клиентского веб-приложения к временным сбоям используйте инструменты разработчика браузера или возможность вашей платформы тестирования имитировать или блокировать сетевые запросы.

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

Управление конфигурациями политики повторов

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

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

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

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

Регистрируйте и отслеживайте временные и устойчивые сбои

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

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

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

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

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

Управляйте операциями, которые постоянно завершаются сбоем

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

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

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

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

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

Оптимизация реализации повторных попыток

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

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

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

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

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

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

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

Example

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

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

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

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

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