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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 безопасно. Из-за высокой степени параллелизма операций записи лучше использовать алгоритм случайной отсрочки, чтобы избежать повторения той же степени параллелизма через фиксированный интервал.

Сбои, связанные с временем ожидания и подключением (HTTP 408 и HTTP 503)

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

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

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

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

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

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

Для деталей реализации касательно языка, смотрите:

• Сведения о реализации пакета SDK для .NET
• Сведения о реализации пакета SDK для Java

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

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

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

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

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

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

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

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

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

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

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

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

Дальнейшие шаги

• Диагностика и устранение неполадок доступности пакетов SDK Azure Cosmos DB в многорегиональных средах
• Высокий уровень доступности (надежность) в Azure Cosmos DB для NoSQL
• Использование последнего пакета SDK для .NET
• Использование последнего пакета SDK для Java
• Использование последнего пакета SDK для Python
• Используйте последнюю версию Node SDK