Поделиться через

Разработка устойчивых приложений с помощью пакетов SDK Azure Cosmos DB

  • Статья

ОБЛАСТЬ ПРИМЕНЕНИЯ: NoSQL

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

Обзор

См. видеообзор основных понятий, обсуждаемых в этой статье:

Режимы подключения

Пакеты SDK Azure Cosmos DB могут подключаться к службе в двух режимах подключения. Пакеты SDK для .NET и Java могут подключаться к службе в режиме шлюза и прямом режиме, а другие пакеты — только в режиме шлюза. В режиме шлюза используется протокол HTTP и режим Direct обычно использует протокол TCP.

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

В целом, для пакетов SDK в режиме шлюза можно ожидать трафик HTTP, а для пакетов SDK в прямом режиме — сочетание трафика HTTP и TCP при различных обстоятельствах (например, при инициализации или получении метаданных либо сведений о маршрутизации).

Экземпляры клиентов и подключения

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

Распределенные приложения и сети

При проектировании распределенных приложений есть три ключевых фактора:

  • ваше приложение и среда, в которой оно выполняется;
  • сеть, которая включает любой компонент между приложением и конечной точкой службы Azure Cosmos DB;
  • конечная точка службы Azure Cosmos DB.

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

Для Azure Cosmos DB предусмотрен полный набор соглашений об уровне обслуживания, но ни одно из них не гарантирует уровень доступности в 100 %. Сетевые компоненты, которые соединяют ваше приложение с конечной точкой службы, могут временно испытывать аппаратные сбои и терять пакеты. Даже в вычислительной среде, где выполняется приложение, могут возникать пиковые нагрузки ЦП, влияющие на работу. Эти условия могут повлиять на операции пакетов SDK. Обычно при возникновении таких сбоев поступают сообщения об ошибках с определенными кодами.

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

Должно ли приложение выполнять повторные попытки при возникновении ошибок?

Короткий ответ — да. Но не при всех ошибках имеет смысл повторять попытки. Некоторые коды ошибок или состояний не являются временными. В таблице ниже они описаны подробнее:

Код состояния Следует добавить повторную попытку Повторная попытка SDK Описание
400 Нет Нет Недопустимый запрос
401 Нет Нет Не авторизовано
403 Необязательно Нет Forbidden
404 Нет Нет Ресурс не найден
408 Да Да Истекло время ожидания для запроса
409 Нет Нет Конфликт возникает, когда идентификатор и партиционный ключ, предоставленные для ресурса в операции записи, уже заняты существующим ресурсом или когда было нарушено уникальное ограничение ключа.
410 Да Да Исключения Gone (временный сбой, который не должен нарушать соглашение об уровне обслуживания).
412 Нет Нет Сбой предварительного условия происходит, если при операции указано значение eTag, отличное от версии, доступной на сервере. Это ошибка оптимистического управления параллельностью. Повторите запрос после считывания последней версии ресурса и обновления eTag в запросе.
413 Нет Нет Размер сущности запроса слишком большой
429 Да Да Повторная попытка при получении статуса 429 безопасна. Ознакомьтесь с руководством по устранению неполадок HTTP 429.
449 Да Да Временная ошибка, которая возникает только при операциях записи и является безопасной для повторных попыток. Это может указывать на проблему проектирования, из-за которой слишком много параллельных операций пытается обновить тот же объект в Azure Cosmos DB.
500 Нет Нет Сбой операции из-за непредвиденной ошибки в службе. Обратитесь в поддержку Azure, направив им запрос.
503 Да Да Служба недоступна

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

HTTP 403

Пакеты SDK для Azure Cosmos DB обычно не выполняют повторные попытки при возникновении сбоев HTTP 403. Но есть определенные ошибки, связанные с HTTP 403, на которые приложение может отреагировать. Например, если вы получаете сообщение об ошибке, указывающее на заполнение ключа раздела, вы можете изменить ключ раздела документа, который вы пытаетесь записать, в соответствии с бизнес-правилом.

HTTP 429

Пакеты SDK для Azure Cosmos DB по умолчанию сначала выполняют повторную попытку при ошибках HTTP 429 на основе конфигурации клиента, учитывая заголовок ответа службы x-ms-retry-after-ms, дожидаясь указанного времени перед следующей попыткой.

При превышении попыток повторного выполнения SDK ошибка возвращается в ваше приложение. В идеале можно проверить заголовок x-ms-retry-after-ms в ответе, чтобы получить указание относительно того, как долго следует ожидать перед повторным выполнением запроса. Ещё один вариант — алгоритм экспоненциальной отсрочки или настройка клиента для увеличения числа повторных попыток при HTTP 429.

HTTP 449

Пакеты SDK Azure Cosmos DB повторяют попытки при ошибке HTTP 449 с увеличивающейся задержкой в течение заданного периода времени для обработки большинства сценариев.

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

Сбои, связанные с временем ожидания и подключением сети, являются наиболее распространенными ошибками. Пакеты SDK для Azure Cosmos DB сами по себе устойчивы и будут повторять попытки в случае тайм-аутов и проблем с подключением по протоколам HTTP и TCP, если повторные попытки целесообразны.

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

Если у учетной записи доступно несколько регионов, пакеты SDK также пытаются выполнить повторную попытку в других регионах.

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

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

Сведения о реализации для конкретных языков

Для получения дополнительных сведений о реализации для конкретных языков см.:

Влияют ли повторные попытки на задержку?

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

SDK для Azure Cosmos DB содержат подробные сведения в своих журналах и данных диагностики, которые помогают определить, какие повторы происходят. Дополнительные сведения см. в статьях Как выполнить сбор данных диагностики пакета SDK для .NET и Как выполнить сбор данных диагностики пакета SDK для Java.

Как устранить задержку повторных попыток?

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

Однако эта приоритизация также означает, что запросы, которые будут приводить к сбою, всегда будут выполняться в одном конкретном регионе в первую очередь для заданного сценария ошибок. Если в этом сценарии предпочтительнее переключение на резерв в другой регион, это обычно обрабатывается на уровне инфраструктуры (диспетчера трафика), а не на уровне SDK. Правильная настройка и конфигурация инфраструктуры могут обеспечить эффективное перенаправление трафика во время региональных сбоев, уменьшая задержку, связанную с повторными попытками между регионами в сценарии сбоя. Дополнительные сведения о настройке отработки отказа на уровне инфраструктуры можно найти в документации по Диспетчеру трафика Azure. Некоторые SDK поддерживают реализацию похожих стратегий отработки отказа непосредственно на уровне SDK. Например, ознакомьтесь с высоким уровнем доступности пакета SDK для Java и пакета SDK для .NET.

Что можно сказать о региональных сбоях?

Пакеты SDK для Azure Cosmos DB охватывают региональную доступность и могут выполнять повторные попытки в других регионах учетной записи. Статья Сценарии и конфигурации повторных попыток в средах с несколькими регионами поможет понять, какие сценарии охватывают другие регионы.

В каких случаях обращаться в службу поддержки клиентов

Перед обращением в службу поддержки клиентов сделайте следующее:

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

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

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